Hooman Mallahzadeh (talk | contribs) →Applying a style for the Vector 2022: new section Tag: New topic |
Tag: Reply |
||
Line 150: | Line 150: | ||
Finally, I should note that this unexpected behavior in clipboard functionality is frequently occurred for me both in English Wikipedia and in Persian Wikipedia. Thanks, [[User:Hooman Mallahzadeh|Hooman Mallahzadeh]] ([[User talk:Hooman Mallahzadeh|talk]]) 04:30, 2 January 2024 (UTC) |
Finally, I should note that this unexpected behavior in clipboard functionality is frequently occurred for me both in English Wikipedia and in Persian Wikipedia. Thanks, [[User:Hooman Mallahzadeh|Hooman Mallahzadeh]] ([[User talk:Hooman Mallahzadeh|talk]]) 04:30, 2 January 2024 (UTC) |
||
:Please file a task upstream. You do not need to support IE. You will also want to test with an accessibility agent or two. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 21:31, 2 January 2024 (UTC) |
Revision as of 21:31, 2 January 2024
Removal of .hlist
I've just now removed hlist from where it was implicated in Common.css, Mobile.css, and Minerva.css as part of conversion to TemplateStyles. If you see issues please leave a comment here. Izno (talk) 21:26, 11 January 2023 (UTC)
- @Izno Thanks for all the work on this! One very minor thing: the navbar in MediaWiki:Watchlist-summary is horizontal on that page, but when it actually appears at the top of my watchlist is a vertical bulleted list. I guess because it isn't within
.mw-parser-output
- is there an easy way to fix that? the wub "?!" 21:41, 11 January 2023 (UTC)- Yup, I figured that kind of report would be the most visible, and most likely, error report to get i.e. one that's in the interface. It's a trivial change, so just give me a sec. Izno (talk) 21:42, 11 January 2023 (UTC)
- And fixed. Izno (talk) 21:44, 11 January 2023 (UTC)
- That was quick, thanks! the wub "?!" 21:54, 11 January 2023 (UTC)
- One of the issues that I've stumbled upon is archives of the main page. I've come up with two different fixes: Special:Diff/1144679174 or Special:Diff/1144679256. Not sure which one is better and not sure if it's worth it to do it for every page in the archive. This particular page for 2019 July 21 is linked from Talk:Main Page right now. —andrybak (talk) 03:07, 15 March 2023 (UTC)
- @Andrybak, if you're going to do it, use the template version, either as in 1144679174, or with start/end version, or with {{hlist}}.
- I didn't do them because it wasn't worth it to start, but I see it as a valid improvement. It should be trivially AWBable. Izno (talk) 05:54, 15 March 2023 (UTC)
Request for edit to .flagicon in MediaWiki:Mobile.css
Change from:
.flagicon img {
min-width: 25px;
}
to:
.content .flagicon a > img, .content .flagicon noscript > img {
max-width: none !important;
}
Introduced by phab:T116318 and, from reading it, I have deduced the actual point of introducing .flagicon img
was to override this:
.content a > img, .content noscript > img {
max-width: 100% !important;
height: auto !important;
}
25px is too much for a lot of flags. SocietyBox (talk) 14:09, 1 August 2023 (UTC)
- Yes, that's the point of the block. I haven't liked that block myself since it doesn't deal with the actual problem CSS except by implication. And these days, it could be done in TemplateStyles, and that I haven't jumped to either because of flagicon's many uses on some pages (but that's probably a problem of those pages and not of TemplateStyles). So it should probably be moved to Template:Flagicon/styles.css instead. Izno (talk) 18:38, 1 August 2023 (UTC)
- @Izno The override is only needed when
skins.minerva.base.styles
is loaded. I don't know how to add that restriction if I were to add it to Template:Flagicon/styles.css. SocietyBox (talk) 20:59, 3 August 2023 (UTC)
- @Izno The override is only needed when
- Never mind. I think I've figured it out. Process started with styles.css added and edit requested on Template talk:Flagicon. Will request for edits to MediaWiki:Mobile.css afterwards. SocietyBox (talk) 21:21, 3 August 2023 (UTC)
- Hate to break it to you, but Mobile.css is loaded the same amount as base.styles are for Minerva. So status quo isn't winning anything either :)
- The other thing about it is that other skins have a similar restriction with width for mobile resolutions, even though neither are loaded with Mobile.css (Timeless specifically loads similar, though Vector 22 will also soon have such a thing based on other discussion I've had lately). So removing the mobile/desktop difference is an overall improvement.
- Some comments about the TemplateStyles page since I said I would follow up:
- I've removed the .skin-minerva selector per above.
- I've removed the .content selector because TemplateStyles fundamentally can't target that class (remember, it is scoped to .mw-parser-output, which is always inside .content).
- I've removed noscript because that's for some other part of the software that isn't relevant to flag icons.
- Izno (talk) 21:25, 3 August 2023 (UTC)
- Never mind. I think I've figured it out. Process started with styles.css added and edit requested on Template talk:Flagicon. Will request for edits to MediaWiki:Mobile.css afterwards. SocietyBox (talk) 21:21, 3 August 2023 (UTC)
@Izno Requesting this change instead:
Diff:
− | .flagicon img {
min-width: 25px; } | + | .flagicon a > img, a.flagicon > img {
min-width: 25px; } |
You can aim for your perfect solution as you wish but please just make this one change so I can end my involvement in the matter. SocietyBox (talk) 20:04, 4 August 2023 (UTC)
- @Izno want to deal with this? I was going to nd it as stale otherwise. — xaosflux Talk 03:19, 8 October 2023 (UTC)
- See my previous comments from IANB. If someone does want to do it (Pppery asked for the right, which I guess is why you're here :), they should verify the above CSS is correct. I am pretty sure it is not. Izno (talk) 16:37, 8 October 2023 (UTC)
Not done per Xaosflux - stale, contested request. * Pppery * it has begun... 22:28, 10 October 2023 (UTC)
- See my previous comments from IANB. If someone does want to do it (Pppery asked for the right, which I guess is why you're here :), they should verify the above CSS is correct. I am pretty sure it is not. Izno (talk) 16:37, 8 October 2023 (UTC)
Infobox and TemplateStyles
@Izno: I've recently been trying out the new "Always enable safe mode" setting (Special:Preferences#mw-prefsection-rendering) and I noticed many of the infoboxes look out of place (Example) That seems to be because all the rules live in MediaWiki:Common.css rather than template styles.
Could we move these styles to https://en.wikipedia.org/w/index.php?title=Template:Infobox.css and include that on ? Jdlrobson (talk) 17:02, 27 September 2023 (UTC)
- @Jdlrobson, no. There are 5000+ pages to clean and no one has been jumping up and down to work on them. Izno (talk) 17:08, 27 September 2023 (UTC)
- I know there's a lot but we need to start somewhere?
- I was thinking we could create Template:infobox.css and put styles common to all templates in there we can start adding
<templatestyles src="Template:Infobox.css" />
to infobox templates. - Now I'm navigating in safe mode it's really obvious where those styles are not loading, so I'd be happy to help with the tedious grunt work of adding the template style to templates on enwiki ie. I am jumping up and down to work on them if you want me :-) Jdlrobson (talk) 20:18, 27 September 2023 (UTC)
I know there's a lot but we need to start somewhere?
By fixing the 5k pages. Starting somewhere is "fix 1, then fix another". Maybe fix 10 pages a day and we'll be done in two years. Two people could fix it twice as fast. That's what actually needs to be done. Still jumping up and down? :) (I've noticed even the other usual gnomes haven't started hacking on this problem -- because it's non-trivial find-replace. Both in the finding and the replacing.)- The TemplateStyles page for infoboxes already exists. It's Module:Infobox/styles.css. It's trivial to add the styles to template pages as there are only some 25-50 templates/modules that would use it. If I wanted, I could do that in an hour. The issue is that it's not a win when we still have so many pages that need the styles to be in Common.css, those templates using these styles would have double loading styles (once from Common.css and once from the TemplateStyles, and there's no wins from compression for the exact same styles) (incidentally, why I'm not happy there's any non-trivial content in the current TemplateStyles page). That's not what needs to be done to clean up this technical debt from 15+ years ago and why I haven't done it myself, since you should not and do not want to add that to the 5000 mainspace pages. That doesn't fix the debt we're running.
- I know there are patterns in the mass of pages; I just don't have the skill to act on each pattern. As an example, on the working page I identified some 600 pages that are using a handcrafted {{infobox awards list}} that could use a bot. When I inquired on the bot requests page (and an earlier feeler), crickets. Izno (talk) 22:12, 27 September 2023 (UTC)
- "The issue is that it's not a win when we still have so many pages that need the styles to be in Common.css, those templates using these styles would have double loading styles "
- Why is this not a win? Template styles ship in HTML, and are deduplicated so this won't have any impact on first paint. It would just mean maybe an extra kB of HTML down the wire? I see no performance concerns with this, but it would get us a bit closer to the finish line. Jdlrobson (talk) 20:03, 28 September 2023 (UTC)
it would get us a bit closer to the finish line
No, it would not. It's just more work for me down the road removing the additional TemplateStyles calls when all is said and actually done.Template styles ship in HTML, and are deduplicated so this won't have any impact on first paint.
This is irrelevant to what I am saying. Common.css does not ship in HTML, so it is not compressed along with the TemplateStyles. So we would be sending extra HTML down the line for your niche of two-hands worth of users who decide to browse with safe mode on.- "all is said and actually done." and I say this above for the reason that if we don't block on actually cleaning up the 5k pages worth of debt, then Common.css is functionally never going to get cleaned of the styles, and so we'll be sending that extra 1k or whatever of styles down the pipe forever. That is not a win for anyone.
- Actually cleaning the uses actually moves us forward. Adding a tag to two dozen templates does not. Izno (talk) 21:42, 28 September 2023 (UTC)
- Okay. Move this code out of MediaWiki:Common.css is the ultimate goal and I trust you have thought more about this then I have.
- What would you propose that we concretely need to do here? Is there a wiki page that details what needs to be done and in what order from your perspective? (If not could you create one). I'm happy to help gather people and help coordinate such an effort. Perhaps an editathon for example could clean the 5k pages worth of debt, but we need to understand what that debt looks like and agree on how to fix it. Jdlrobson (talk) 19:03, 3 October 2023 (UTC)
- MediaWiki talk:Common.css/to do#Infobox. You can read the opening section for the lay-person's "why does this page exist" at #description. This is where I have been coordinating the entirety of my TemplateStyling efforts—because I knew I would not be able to do it alone, I wanted a paperwork trail, and I eventually did need the 'why is this happening'. See also #Done for the previous work. Izno (talk) 19:42, 3 October 2023 (UTC)
- Thanks! That's super helpful as a starting point. Jdlrobson (talk) 17:50, 5 October 2023 (UTC)
- @Izno I was thinking about this some more, and I wondered would it make sense to have an AbuseFilter rule for including "infobox" in new edits? I'm not sure if abuse rules can be limited to new content. That might help spread the work here. Another thing that might help is making use of Special:LintErrors to flag this as an error to leverage more people to fix. Given most of these errors occur in namespaces without template editing rights that seems achieveable.
- Is the goal to fix all 3000+ of these pages before moving these rules out of Common.css or are there other blockers? Jdlrobson (talk) 18:58, 3 November 2023 (UTC)
- @Jdlrobson, the 5k main space pages need cleaning and then there's a couple dozen remaining instances in templates and elsewhere that need to be adjusted, also documented in the same location on the to do page.
- Edit filters can track additions of new wikitext particularly, but from everything I've observed it's just 5k pages worth of pre-{{infobox}} infoboxes: we're not dealing with a firehose of new additions (without verifying, I imagine we get 1 or 2 of those a month, which is a fair few magnitudes different from the legacy). For the most part, these are all reasonably caught by the Special:Searchs already there.
- Even without that, my personal metrics for "readiness for removal from Common.css" in the general have been "best effort to have found instances in the wild" and "affects a SUBJECTSPACE page" rather than "total removal", mostly ignoring sandboxes, testcases, talk pages and talk page sandboxes (except where the class was used predominantly on talk pages like the former
messagebox
and now-TemplateStyledtmbox
), and so on. You'll see that many of the Special:Search links either in the infobox section specifically or in one of the other already-worked sections do quite a bit to exclude stuff, and even though many still have false positive hits for a meaningful use, they're all in the 10^2 realm of counts. Having a class that is no longer usable without TemplateStyles in an archive is not a big deal relatively e.g. to archives broken by a missing </s>. Speaking of, I'm not sure how LintErrors would help. It works over the Parsoid HTML rather than the wikitext, so every element with the class would be flagged. Which is not the objective, because that's about a million pages. :) There is a project on this dimension that could reasonably catch any last minute adds etc, and I might call on them to provide a list at a later date since Special:Search does trip up from having a rough time with the regex (/infobox/
catches{{infobox
, which means my typical tricks to coax Special:Search to give me good results, much less avoid a timeout, don't always work :( ). - Most of the people who can fix watch this page or have shown up here before. I've tried to avoid making a big fuss about the work in general, but a comment at WP:VPT about it probably would not be remiss. I have also considered reaching out to WikiProjects here and there, but I've noticed that the ones that could be focused to WikiProjects have successfully been fixed by gnomes on the large (WOSlinker for example just did 200 pages that could be converted to {{infobox GAA tournament}}). Which still isn't fun to do and it would be nice to get help with, I just haven't spent a lot of time figuring out what all the groupings of pages are that need adjustment to approach (potentially-inactive/dead) WikiProjects with. Izno (talk) 21:12, 3 November 2023 (UTC)
- What about running a virtual technical editathon where a few of us with template edit rights get together and try to tackle a chunk of these? Would something like that be helpful? Jdlrobson (talk) 21:24, 3 November 2023 (UTC)
- Isn't this one of those things the WMF is supposed to give people grants to do? Are they still doing that? jp×g🗯️ 05:49, 13 November 2023 (UTC)
- There's meta:Rapid grant and similar. Assuming this task is important enough for that, that the main participants are motivated by money, that it's worth the overhead of applying, etc. –Novem Linguae (talk) 16:54, 13 November 2023 (UTC)
- I don't think it is, and anyway I personally try to steer clear of attaching my motivation to edit to monetary value (especially in a case like this). That would make it feel more like work. ;) Izno (talk) 04:05, 14 November 2023 (UTC)
- There's meta:Rapid grant and similar. Assuming this task is important enough for that, that the main participants are motivated by money, that it's worth the overhead of applying, etc. –Novem Linguae (talk) 16:54, 13 November 2023 (UTC)
- Thanks! That's super helpful as a starting point. Jdlrobson (talk) 17:50, 5 October 2023 (UTC)
- MediaWiki talk:Common.css/to do#Infobox. You can read the opening section for the lay-person's "why does this page exist" at #description. This is where I have been coordinating the entirety of my TemplateStyling efforts—because I knew I would not be able to do it alone, I wanted a paperwork trail, and I eventually did need the 'why is this happening'. See also #Done for the previous work. Izno (talk) 19:42, 3 October 2023 (UTC)
- Also, apparently templatestyles have been causing some performance issues recently when used on almost every single page. That might be something to consider here. —TheDJ (talk • contribs) 19:25, 27 September 2023 (UTC)
- I'm unconcerned about that for en.wp. None of our templates reach the use that Commons have. (And, there's something to be said that templates like commons:Template:information just simply shouldn't exist any more between SDC and free text solutions.) Izno (talk) 19:47, 27 September 2023 (UTC)
I saw that "toccolours" is on the list of things to take care of. Module:Category series navigation has over 300k transclusions so one change here can clear a large batch from the list. How should this be replaced? Pinging also @Tom.Reding. Gonnym (talk) 11:29, 31 October 2023 (UTC)
- Thanks for the ping. This is beyond my competency, so I won't be able to help, but it's good & interesting to know this is going on! ~ Tom.Reding (talk ⋅dgaf) 11:42, 31 October 2023 (UTC)
- You can leave questions on that page, it's meant to be a working page. One misunderstanding: That actually won't clear a large batch, as that's just search results for the string of interest. (It will of course restore colors to that many pages if you were to readd the styles in some way.)
- You can see I haven't 1) spent a lot of time thinking about much less working on toccolours (and toc in the next section) and 2) don't really know what I want to do about things that look like TOCs in certain skins. (To some extent, this particular template looks nice even without the styles in Vector 2022.) Izno (talk) 17:49, 31 October 2023 (UTC)
Applying a style for the Vector 2022
Hi, in Vector 2022, if we want to select title of an article and we accidentally extend the selected area to select Table of Content button with the icon , then the text copied in clipboard would wrongly be (for example for the article "Wikipedia"):
Toggle the table of contents
Wikipedia
This is not the intended clipboard and the first line is not required, i.e., only "Wikipedia" as the title of the article is enough and the text "Toggle the table of contents" makes the clipboard data wrong.
The solution to this problem could be applying this style:
.vector-page-titlebar-toc {
-webkit-user-select: none; /* Safari */
-ms-user-select: none; /* IE 10 and IE 11 */
user-select: none; /* Standard syntax */
}
I have tested that code in my css page at User:Hooman Mallahzadeh/common.css and it prevents this behavior very well.
Finally, I should note that this unexpected behavior in clipboard functionality is frequently occurred for me both in English Wikipedia and in Persian Wikipedia. Thanks, Hooman Mallahzadeh (talk) 04:30, 2 January 2024 (UTC)
- Please file a task upstream. You do not need to support IE. You will also want to test with an accessibility agent or two. Izno (talk) 21:31, 2 January 2024 (UTC)