MediaWiki talk:Common.css/Archive 19

Archive 15

←

Archive 17

Archive 18

Archive 19

visualhide removal

I'm thinking to remove visualhide next. Its current use is more or less this search.

In fact, this now has a parallel implementation at Template:sronly (though I've left a comment or two there about name changing among other things).

For uses outside the template as in another template that doesn't want the template dependency itself as in the several uses above, someone could just add the templatestyles tag directly. (I actually added accessibly hidden text to another template entirely coincidentally the other day.)

Any objections from page watchers? I'll invite some of the associated talk pages here. --Izno (talk) 16:54, 2 December 2020 (UTC)

@Izno: a very quick review looks like this may be incorporated to 1MM+ pages via those modules? It is an awfully hacky css, so I'd think moving it to template styles may be better if possible. — xaosflux ^Talk 17:03, 2 December 2020 (UTC)

The CSS has a very specific use case, yes. The worry I have is that some of those uses might be ending up in links for whatever reason, so we need to discuss how to deal with that. --Izno (talk) 17:04, 2 December 2020 (UTC)

High usage might be through {{Convert}} (>1M calls); possibly because of {{Frac}} code copy (where it serves requirement "copy-paste from rendered page while saving correct number notation", i.e. add space after the whole-number). Is there an alternative? -DePiep (talk) 18:18, 2 December 2020 (UTC)

style="display:none" does not seem to work (whitespace stays). U+200A   HAIR SPACE ( ,  ) might be acceptable here; /testcases. -DePiep (talk) 20:30, 2 December 2020 (UTC)

The class's use in T:Frac is a result of hiding the + sign deliberately to sighted readers (what value that might have is in this recent archived discussion and the link within to its original instituting). --Izno (talk) 21:35, 2 December 2020 (UTC)

That's {{Sfrac}} using the "+" this way, but indeed screenreader related. -DePiep (talk) 22:04, 2 December 2020 (UTC)

Just waiting on Convert now; Johnuniq said he will get to it soonly. --Izno (talk) 05:25, 12 December 2020 (UTC)

Resurrected TODO

I resurrected MediaWiki talk:Common.css/to do today to keep notes and search links for TemplateStyling. --Izno (talk) 01:17, 13 December 2020 (UTC)

Group of users interested in changes to CSS

Watchers of this page may be interested in Wikipedia talk:Manual of Style/Accessibility § Group of users interested in changes to CSS. Izno (talk) 22:07, 20 December 2020 (UTC)

Tailoring editnotices for source editing vs. VE

Following up from this VPT discussion, I'd like to see classes added to here that would allow for creation of editnotices that give different instructions based on whether one is editing in VisualEditor or source code. This would be useful for editnotices that give instructions on how to edit a page, since those instructions will typically be different based on the editor. PrimeHunter put together some rough code at the VPT thread that works but might need to be refined (I'm not sure exactly how) to be suitable for here. {{u|Sdkb}} ^talk 20:09, 29 January 2021 (UTC)

I do not support a change here, especially as the originating discussion identified another fix for what was wanted. As for nomobile, that class may not survive into the future after speaking to the relevant dev and I would accordingly advise against relying on it for anything. --Izno (talk) 23:05, 6 February 2021 (UTC)

hlist description list term following a description details subitem starts a new line

Consider this example:

<div class="hlist">
; Thing
: Item
:: Subitem
; Thing 2
: Item 2
</div>

...which renders as:

Thing

Item

Subitem

Thing 2

Item 2

Note that the case of a description term following a description details item works as expected:

<div class="hlist">
; Thing
: Item
: Item B
; Thing 2
: Item 2
</div>

...which renders as:

Thing

Item

Item B

Thing 2

Item 2

This issue probably also affects other "mixed" lists (e.g. a ul item following an ol subitem, though I haven't tested any of them. I also haven't investigated how this issue might be fixed in the hlist styles. 「ディノ奴千？！」^{☎ Dinoguy1000} 07:59, 7 February 2021 (UTC)

As a note, the former is not a valid use of description lists with its "subitem".

As for the latter comment, we're looking at combinations of what is already present for the solution, meaning the addition of a lot of selectors. With 3 list kinds, that's another set of 6 selector rows. I'm not sure that's worth it. --Izno (talk) 10:07, 7 February 2021 (UTC)

The use case which exposed this is https://yugipedia.com/wiki/Template:Series_2_sets, where each term is a year and each details item is a release, with some items having subitems where a "release" happened in multiple parts; can you make any recommendations for alternate markup to use for this? 「ディノ奴千？！」^{☎ Dinoguy1000} 18:17, 7 February 2021 (UTC)

If necessary, we (that is, the Yugipedia wiki) could host the necessary extra selectors ourselves (probably via a new hlist-adjacent class added in needed cases via TemplateStyles), I just don't know what the new CSS would have to be (and obviously, if we can instead use some alternate markup that's actually correct without losing any semantic/visual information, we'd prefer that instead). 「ディノ奴千？！」^{☎ Dinoguy1000} 19:22, 7 February 2021 (UTC)

Okay, taking a second look since I was on my phone before, the second case should not be an issue for you; the CSS in place today already accounts for it:

• UL1
• UL2
  1. OL1
  2. OL2
• UL3

Please double check you have the same hlist CSS on this point.

On the first point, this is actually a bug previously identified with Parser.php and sublists in description lists. See phab:T223277. There is a work around for non-hlists, which is to add an additional empty colon beneath the first list, but you can see it does not render beautifully with hlist:

DT1

DD1

DTS

DDS

DT2

DD2

It affects all kinds of sub lists of definition lists (apparently; I only tested with unordered sublists), so I wonder why we even support the CSS now.... Anyway, from memory of the discussion of this issue, it is resolved in Parsoid. --Izno (talk) 01:50, 8 February 2021 (UTC)

Thanks for the rundown. Our hlist CSS should be the same (except for some extra classes I added years ago to customize the separator), unless the CSS has been changed here since August 2019 (it doesn't appear so). The workaround you mentioned (the empty colon) is actually what I found to fix the display when I first encountered this bug. I could of course add CSS to hide the empty element, but that's not very satisfactory (but then, maybe nothing short of having the bug fixed in the parser would be). Parsoid is on my wishlist for the wiki, and has been for a very long time, but it's something of an open question whether we'll actually be able to install it any time soon. 「ディノ奴千？！」^{☎ Dinoguy1000} 07:47, 8 February 2021 (UTC)

Parsoid/PHP comes with 1.35, but it still does not serve reads. (That's looking like 1.37 or later, possibly.)

As for CSS to hide the 'empty' element, there's nothing to target it with. MediaWiki doesn't recognize the element as empty. --Izno (talk) 08:48, 8 February 2021 (UTC)

After a quick test, the CSS .hlist dd:empty { display: none; } appears to correctly hide these empty elements without any side effects; according to MDN and caniuse it's also got very good browser support. Is there anything you're aware of with it that might catch me off-guard, or should the selector be tweaked somehow (e.g. to reduce the chance of unwanted side effects), before I implement this on Yugipedia? 「ディノ奴千？！」^{☎ Dinoguy1000} 10:19, 12 February 2021 (UTC)

That seems reasonable. Test it and see what happens. --Izno (talk) 15:36, 12 February 2021 (UTC)

Preview warning and hatnotes moving to TemplateStyles

I plan to remove hatnote styles from Common.css Soon. From what I can see based on general research at MediaWiki talk:Common.css/to do#Hatnote, basically the only remaining uses of the class directly are in modules dedicated to hatnotes and templates or modules using preview warnings.

I plan to separate preview warnings from using the hatnote class. Though they are currently styled similarly because they do use the hatnote class, preview warnings are not fundamentally hatnotes. They are not present to serve a navigational purpose and moreover generally display in a different place at a different time than hatnotes.

What I am not sure about, in preparing to remove hatnote CSS, is whether the templates/modules using a preview warning as listed on the to-do page should depend on a single implementation as at Module:If preview (and at some point Module:If preview/styles.css via the module) or whether they should include the styles sheet directly and continue doing whatever they want for preview warnings otherwise.

I have a slight preference, even if it introduces the dependency, is to make these systems all use the one module (possibly with modification). Thoughts are appreciated. Izno (talk) 21:40, 22 April 2021 (UTC)

For those of us to whom most of the above is unclear, it would probably help to show how a new system would work. Can you mock up a side-by-side test case or demonstration page? – Jonesey95 (talk) 04:35, 29 April 2021 (UTC)

Basically, we have text today like

{{if preview|1=<div class="hatnote" style="color:red">This diagram should use the BSicon '''[[:File:BSicon {{{1}}}.svg|{{{1}}}]]'''; at some point an existing but less suitable icon was substituted.</div>}}

in several templates, and it would be good/nice to simplify that to something like

{{preview warning|1=This diagram should use the BSicon '''[[:File:BSicon {{{1}}}.svg|{{{1}}}]]'''; at some point an existing but less suitable icon was substituted.}}

(or possibly module-only version as in something like

{{#invoke:Preview warning|warning|1=This diagram should use the BSicon '''[[:File:BSicon {{{1}}}.svg|{{{1}}}]]'''; at some point an existing but less suitable icon was substituted.}}

This would abstract and standardize the details of the support mechanisms for preview warnings (TemplateStyles, pre- and post-text for the specific template/module's use of the preview warning module). The general pattern, if not exact text, is used all over the place, though there's an almost-standard <div class="hatnote" style="color:red"><strong>Warning:</strong> TEXT (this message is shown only in preview).</div> in most of the modules/templates. Clearly not totally standardized today, and it probably should be.

(There might be some followup later on whether the current general implementation is considered or cargo-cult.) Izno (talk) 19:05, 29 April 2021 (UTC)

As for Module:Track gauge, I have been working on, I see no reason to keep a local solution in there. I'd say you are free to solve as you prefer (use the dedicated module). -DePiep (talk) 07:26, 29 April 2021 (UTC)

Looking at this as the author of Module:Hatnote group, which might need tweaking… as long as hatnotes continue to use the same baseline classes on their outer div, no changes should be necessary to that module—the code should work fine even if the styles are specified in a TemplateStyles sheet, and moving to TemplateStyles is generally a good idea. However, if the set of "default" classes (currently "hatnote" and "navigation-not-searchable") changes in Module:Hatnote, then the module will probably need updating, as it briefly misbehaved when "navigation-not-searchable" was added. Possibly Module:Hatnote should get a utility method to output its predefined class list—that'd solve that problem for the forseeable future. For preview warnings, I generally trust that the changes made will be sensible, but I support using a more unified implementation on general principles. On the thought of unifying—I wonder if it would make sense to unify the sort of styling that hatnotes introduce—indentation, italicization, etc.—into its own meta-format that preview warnings, hatnotes, and other things could all adopt. That's probably a bad idea, but it's an interesting one. {{Nihiltres |talk |edits}} 17:52, 29 April 2021 (UTC)

Hatnotes will continue to use .hatnote. There is enough tooling that depends on it even if it needed change, and I know of no reason why that class should change. Particularly, the WMF depends on it for the MobileFrontend implementation in at least two ways: they apply their own styling to hatnotes and they use the class to identify what can/can't be moved around to get their "first paragraph above the infobox" implementation on mobile (along with .ambox).

I looked at the Hatnote group module also and I came to the same conclusion that it shouldn't need to change.

Changing the styles from its current style is one reason to stop depending on hatnote, for that matter. I don't necessarily know if we want that. I've already removed at least one style that hatnote uses that preview-warning wouldn't need (the flip on italics with <i>). Izno (talk) 18:22, 29 April 2021 (UTC)

I also know that google and apple used to have special handling for elements with the hatnote class. Don't want to hear that in Siri answers after all :D —TheDJ (talk • contribs) 21:01, 29 April 2021 (UTC)

And Alexa also, I'm sure. Izno (talk) 22:36, 29 April 2021 (UTC)

One of the things I am additionally tracking is to move the functionality of Module:Preview warning to Module:If preview (currently implemented at Module:If preview/sandbox). The latter seems like a reasonable house for it. Izno (talk) 16:07, 30 April 2021 (UTC)

I support this change. "If preview" is more neutral than "Preview warning". Some templates may use the template to display a message that is merely informational and not a warning. – Jonesey95 (talk) 17:46, 30 April 2021 (UTC)

Templates which do display a message without wanting a warning can either use {{if preview}} or its module implementation regardless of whatever we do with preview warning. Preview warning would be its own function and possibly its own template, with assorted names like "invoke:If preview|warning" or {{preview warning}} calling the module. Izno (talk) 18:34, 30 April 2021 (UTC)

About hatnotes: Will it create an additional load on the user if these styles are removed in TS? I mean page weight and load frequency. Iniquity (talk) 19:43, 30 April 2021 (UTC)

Page weight will go up slightly for pages that use that style and go down slightly where it is not. "Hatnote" is used on 3% of all pages and ~1m/6.5m of mainspace pages = 15%, so that is savings in the broader sense. (This is the fundamental beneficiary premise of TemplateStyles.) Izno (talk) 19:59, 30 April 2021 (UTC)

Unexpected effects

Moved to Template talk:Track gauge. --Izno (talk) 15:06, 17 May 2021 (UTC)

Does this mean that WP:TSTYLE is ruled out as cause? -DePiep (talk) 15:12, 17 May 2021 (UTC)

OK, your reply there crossed so I'll follow over there. -DePiep (talk) 15:14, 17 May 2021 (UTC)

AutoCorrect

I am trying to make a simple tool that will help to automatically replace a user’s wrong using characters with the correct one in Mon Wiktionary at wikt:mnw:မဳဒဳယာဝဳကဳ:Common.css It doesn’t work. Anyone can help me for that? --Htawmonzel (talk) 08:31, 17 May 2021 (UTC)

That is not how CSS works. You will need JavaScript for something like that. Izno (talk) 14:48, 17 May 2021 (UTC)

@Htawmonzel: Lines 3-5 in the linked page are:

body{
<input type=”ၚ်” placeholder=”replaced” id=”င်” onkeyup=”submit()”/>
}

Here, lines 3 and 5 are perfectly valid to begin and end a CSS rule, but line 4 is a HTML tag for an input element and not CSS at all. In a CSS rule, the part between the opening and closing braces may only contain a semicolon-separated list of zero or more valid CSS declarations. HTML tags are not CSS declarations. As a side note, the ” character (Unicode U+201D) is not valid as a value delimiter in HTML - only the ' and " characters (Unicode U+0027 and U+0022 respectively) are valid for this purpose. --Redrose64 🌹 (talk) 20:40, 17 May 2021 (UTC)

pblock-style

I'm adding in a "yellow" override for .mw-contributions-blocked-notice-partial .mw-warning-with-logexcerpt, as a result of the RfC that was held at WP:VPR in Special:PermaLink/1028105161#Change_the_partial_block_message_to_be_orange_or_yellow_instead_of_red. — xaosflux ^Talk 21:52, 11 June 2021 (UTC)

Special:Book download box

Special:Book has had a disabled and confusing download box for years. I've requested it be hidden or removed at T285400, but I still think it would be good to hide it locally until that task is dealt with as that can take a long time or simply not happen. The following is what I think should be added.

.mw-special-Book #coll-downloadbox {
    display: none;
}

--Trialpears (talk) 16:00, 23 June 2021 (UTC)

Testing on testwiki - added to their common.css, pending refresh. — xaosflux ^Talk 19:34, 23 June 2021 (UTC)

(Many special pages won't process common.css....). — xaosflux ^Talk 19:36, 23 June 2021 (UTC)

 Done — xaosflux ^Talk 00:56, 24 June 2021 (UTC)

Consider optimize the view of subboxes in infobox

The MinervaNeue skin usually used display:block; property for <table> and <caption> elements while you see them on smaller screens, but this may cause problems in infobox, making sub table narrower and shift to left even if you set width:100% property, this problem is happened on this page. To fix this problem, I suggest adding following rules:

body.skin-minerva .infobox table {
	display: table;
}
body.skin-minerva .infobox caption {
	display: table-caption;
}

This is based on my discoveries on {{rail freight}}. -- Great Brightstar (talk) 13:56, 6 April 2021 (UTC)

I saw this bug happen again on this article. -- Great Brightstar (talk) 14:29, 7 April 2021 (UTC)

@Izno and Jon (WMF): thought you'd want to look at this. — xaosflux ^Talk 14:15, 6 April 2021 (UTC)

MinervaNeue on smaller screens actually uses display:flex for infoboxes.. So it's sort of important to clarify what screen sizes we are talking about here. —TheDJ (talk • contribs) 15:59, 6 April 2021 (UTC)

OK, I see, this problem is often happened if the screen is narrower than 720 px. -- Great Brightstar (talk) 09:53, 12 April 2021 (UTC)

Remember that MediaWiki:Minerva.css doesn't load on mobile and MediaWiki:Mobile.css is not render blocking and MediaWiki:Common.css loads on desktop Minerva. If you must do this on wiki i'd highly recommend doing it inside the template itself using mediawiki:Extension:TemplateStyles NOT one of the site CSS modules.

I want to note we have a larger problems with tables that also impacts Vector (see phab:T267161 ), so it might be time to get our heads together to find a long term solution rather than to continue to patch things on specific wikis in this way which makes the problem even more complicated.

I do think this discussion needs more information. It's hard to judge the merits of these 2 rules without understanding where you want to fix it and which screen sizes have been tested. Jon (WMF) (talk) 03:45, 7 April 2021 (UTC)

TemplateStyles will not come any time soon for infobox. There are some 5.4k uses in the wild that must be cleaned first, either to use infobox directly or one of its using templates. (I recently added some CSS on that point to Common.css and Mobile.css, but that's not relevant to this discussion.) That effort is documented over there.

I would not be bothered to add this also to Mobile.css if this CSS is actually necessary. I am not totally certain it is, in the same vein as you are uncertain. Izno (talk) 04:35, 7 April 2021 (UTC)

"There are some 5.4k uses in the wild that must be cleaned first, either to use infobox directly or one of its using templates" This is true.. BUT... the infobox classes have a lot of css that isn't actually that much used in those cases. Many of those 5.4k uses only really need the positioning float/clear/margin etc parts of infobox. So maybe we should start with moving out infobox bordered and infobox geography. —TheDJ (talk • contribs) 09:28, 11 April 2021 (UTC)

Geography is basically done as you can see, the templates using it just need to not use it anymore and use template-specific tstyles instead (which I'm poking at for the dozen templates). In most cases replacement with e.g. wikitable is generally called for, sometimes with other tweaks. In others it really is an infobox... But sure. Help appreciated. :) :) :) Izno (talk) 13:19, 11 April 2021 (UTC)

Here is what I've seen on Firefox, I reproduced following instructions at MDN: https://postimg.cc/pmrfrq37 -- Great Brightstar (talk) 10:28, 7 April 2021 (UTC)

 Not done - deactivating the immediate edit request, please continue discussion - if a consensus emerges reactivate the request. — xaosflux ^Talk 13:51, 4 May 2021 (UTC)

Ok, I actually took a look at this. This is a problem of Minerva being too aggressive in its styling. Tables inside infoboxes shouldn't be getting any styling via the skin, though I can understand why this is happening. Minerva also probably shouldn't be changing display mode of tables. There are probably better ways to get the display desired.

I recommend an upstream for this. Izno (talk) 23:24, 18 May 2021 (UTC)

I think just add some exceptions is enough. Changing display mode of tables is still necessary for large table on mobile phone. --Great Brightstar (talk) 15:29, 23 May 2021 (UTC)

I reported at phab:T283462. -- Great Brightstar (talk) 15:53, 23 May 2021 (UTC)

@Izno: Seen from Phabricator, the developer doesn't willing to fix, so we have to do it ourselves in {{Infobox}}. --Great Brightstar (talk) 03:09, 25 July 2021 (UTC)

Not really interested in supporting this here. It reintroduces inline styles which are generally bad. Suboptimal display can probably just be tolerated. Izno (talk) 03:15, 25 July 2021 (UTC)

(If you want to speed us getting to TemplateStyles where I am more than happy to add this, you can help work on MediaWiki talk:Common.css/to do#Infobox.) Izno (talk) 03:19, 25 July 2021 (UTC)

Interface-protected edit request on 15 July 2021

Add

.nonextendedmover-show {
  display: none !important;
}

to MediaWiki:Group-extendedmover.css. This would allow different text to be shown to users who are extendedmovers and users who are not. A similar thing has been done previously at MediaWiki:Group-extendedconfirmed.css. (the use-case I have in mind is cleaning up some visual clutter on WP:RM/TR, as presumably extendedmovers will not need to see the basic instructions listed there) Elli (talk | contribs) 01:38, 15 July 2021 (UTC)

@Xaosflux: You actioned what's being cited as precedent here, in case you wanna chime in. Personally, I'd prefer to see some level of discussion or consensus (as prior) before proliferating these things; accessibility, among other concerns. ~ Amory (u • t • c) 14:20, 25 July 2021 (UTC)

@Amorymeltzer: while extendedconfirmed is a wide ranging group that is autogranted, this is a very niche group - I don't really see why this is needed. — xaosflux ^Talk 14:31, 25 July 2021 (UTC)

 Not doneElli I think it'd be good to see a more full use-case for this. If it's just to remove instructions, for sure it's not good to always hide them. Instructions are good for everyone, even old timers and experts. What can be done is to put Wikipedia:Requested moves/Technical requests/Instructions (or whatever) in a box with a class ID which can then be hid by folks who want to hide them. That's what commonly available for many editnotices, etc. ~ Amory (u • t • c) 14:37, 25 July 2021 (UTC)

@Amorymeltzer: fair. I'd like to really have these classes for all user groups - similar to the group-show classes - but I can understand wanting to avoid adding extra classes. Elli (talk | contribs) 15:04, 25 July 2021 (UTC)

I am concerned that there is any content that would not be visible to the general administrator public as currently in MW:G-EC.css. @Xaosflux: We should consider removing it. Izno (talk) 18:13, 25 July 2021 (UTC)

Can we see some examples of any of those current use cases? — xaosflux ^Talk 19:20, 25 July 2021 (UTC)

Specific request about hlist

This discussion was started Module talk:List by Jdlrobson/Jon (WMF) but is highly related to this page. I've moved it here for wider feedback.

As a Wikimedia staff member, I'm looking to remove a big chunk of technical debt inside MediaWiki:Mobile.css#L-149 and MediaWiki:Common.css as well as the Minerva skin (T213239) and core (T174399). Doing this will lead to better design consistency between desktop and mobile, and better performance (Mobile.css is not render blocking and the styles are not needed on every page and every project). There was an attempt to add this code to core, prior to the introduction Extension:TemplateStyles but having this in core no longer makes sense. I find myself stuck in a chicken/egg type situation with several moving parts.

To fix this problem

1) This module should load template styles tag, e.g. Template:Hlist/styles.css

2) The CSS needs to be removed from MediaWiki:Mobile.css

3) The CSS needs to be removed from core.

4) The CSS should then be removed from MediaWiki:Common.css

I need help with step number 1 at the current time.

Who can help me achieve this? I am happy to undertake most of the work here so would just be looking for someone to test changes in a sandbox and apply them.

If you have any questions or concerns about this please let me know and I'll happily help provide answers. Jdlrobson (talk) 23:13, 25 August 2021 (UTC)

Jdlrobson, I think I've spammed the existence of MediaWiki talk:Common.css/to do in your general direction before. :) It is how I am coordinating TemplateStyles. I am mostly alone in this effort (though Frietjes helped a lot killing NavFrame off as one person I should go barnstar!!!). I am currently working on bordered infoboxes.

When you say most of the work (regarding hlist), realize that means sorting some 150k uses of the class as identified by the search there. I haven't dug into the details yet on the point, but you can probably get the gist of my process by looking at some of the other sections, completed or otherwise, as well as my work on MediaWiki wiki for the templates/modules not yet changed here. (Most of my contributions at MWW are directly related. The mediawikiwiki:MediaWiki talk:Gadget-site.css discussions may also be pertinent.) IznoPublic (talk) 09:06, 20 September 2021 (UTC)

In the meantime, I think I could add .mw-parser-output in Common.css (and Mobile if it's not there yet) just to get the specificity to elements inside the parser output. I don't know if that helps. Izno (talk) 17:09, 20 September 2021 (UTC)

@Izno: The parser-output class wouldn't help with much. What would help is to remove all the ".hlist" rules in MediaWiki:Mobile.css, and introduce Hlist TemplateStyles to the most popular templates. Even if that means certain templates don't look "right" on mobile, that's going to better for mobile, as MediaWiki:Mobile.css loads via JavaScript so render with a repaint which is a performance problem. It will also hopefully be noticeable to other editors and allow you to share the work fixing impacted templates which should be as simple as including a the TemplateStyles Hlist stylesheet e.g. Template:Hlist/styles.css

I think that could help you out by sharing the burden by making the problem visible. I wouldn't worry about desktop - loading a template style in the hlist templates as well as inside MediaWiki:Common.css shouldn't be a problem.

If there's anything I can help with here e.g. bots/scripting/some kind of feature flag for you to test anything out let me know. Jdlrobson (talk) 21:43, 22 September 2021 (UTC)

To respond to the latest comment (TLDR: FOUCs and unstyled content for everyone!):

I am not worried about display on mobile here but instead all pages, desktop or mobile. There are some 150k pages that use the global definitions today. While I can make short work of some bunch of those in a way that takes care of the "majority" (predominantly modifying Module:Navbox, Module:Sidebar, Module:List, Template:Flatlist, and Module:Navbar -- I've made implementations of what I would need to do here already at MediaWiki wiki, so that is in fact trivial), there are still all those pages (not templates, pages) using a raw class="hlist", whether in tables (as I've been working on lately; see MediaWiki talk:Common.css/to do#wikitable/toc hlist), table cells/rows, ad hoc divs, or some other uses. We will end up with FOUCs for pages where the hlist loads too late in the page by loading coincidentally in one of the above listed module/templates (rather than prior to the content using the class), or we will end up with entirely unstyled lists.

Regarding mobile particularly, it will be especially susceptible to unstyled lists (rather than simple FOUCs) with some "quick fix plan" a la the above because most template invocations of the hlist TemplateStyles are going to be inside class="navbox" (Navbar will load them, and Navbox separately if its navbar does not exist for whatever [supported] reason), which I know you are aware gets ripped out in MobileFrontend. Those styles accordingly never reach the user and so the 'real' content on the actual page of interest fails to display as intended.

As for "add them anyway even without removal", that seems to miss the point of TemplateStyles: pages will get the (marginally more-expensive styles twice - once with mw-parser-output prefixed and once without), which is also bad (and then I also have to keep our cats from modifying styles without modifying them in both places). Even if it's just "remove it out of Mobile while we continue working the problem", then we end up in the hole above.

There are about 5k pages that we care about where we would be guaranteed to have unstyled lists in both mobile and desktop (this search excludes a lot of namespaces, including every talk namespace). That search also excludes templates that have one of the search-exclusionary templates via their documentation but need hlist styles because their output includes a raw hlist. That search ignores all the pages where an FOUC is still possible on either desktop or mobile (because I see that part of the search as impossible with the access I have to searches).

I know that Krinkle mused that perhaps Mobile.css should be render-blocking these days, with the understanding that communities are still working on TemplateStyles (NB I disagree that we should keep things like infobox styles in global sheets just because they are re-used and am wholly in favor of moving everything to TemplateStyles if I can). Perhaps that really should be investigated.

After all that, at a minimum to proceed with a potential change that would cause unstyled or FOUC cases as above, I would need a consensus decision (probably a WP:RFC on WP:VPPRO) saying it's okay to remove the styles in Common/Mobile.css. I do not anticipate that consensus discussion going the way you or I might want....

As I said, we need people to help (I do not know how to raise the visibility and the desirability of working on MediaWiki talk:Common.css/to do without the nuclear option removing the styles first and then fixing pages second - if you have ideas on this point...). In the particular case of hlist, I need a (possibly couple) sane searches that don't timeout or pagepiles/lists to find all the pages with raw use of the class. (Note all the different ways I can search on the /to do page to find things and that hlist is nontrivial on the point to boot.) Izno (talk) 00:40, 4 October 2021 (UTC)

As for bots, this is a hard problem to bot I think, but I guess I could reach out to the community to see if it's possible. The problem is not particularly context aware but given the use of hlist in tables there is some non-0 complexity. --Izno (talk) 00:52, 4 October 2021 (UTC)

> theere are still all those pages (not templates, pages) using a raw class="hlist"

> There are about 5k pages that we care about where we would be guaranteed to have unstyled lists in both mobile and desktop (this search excludes a lot of namespaces, including every talk namespace).

5k doesn't seem to much in the grand scheme of things. One think to remember here is that Minerva currently ships a minimal hlist stylesheet. We could feature flag this for English Wikipedia only, to provide more time to update these styles as needed, but I think using the hlist class in this way is not good, particularly for newbie editors who may not be comfortable with seeing raw HTML in wikitext. Shouldn't we be discouraging this anyway?

>Those styles accordingly never reach the user and so the 'real' content on the actual page of interest fails to display as intended.

Seems off topic. The fact Navbox is stripped from HTML is another problem. It clearly shouldn't happen, and loading styles that are never used just adds weight to fixing that issue, but is not a concern for me.

> As for "add them anyway even without removal", that seems to miss the point of TemplateStyles: pages will get the (marginally more-expensive styles twice - once with mw-parser-output prefixed and once without),

TemplateStyles deduplicates repeated styles. Templates can share the same stylesheet. GZip will also deduplicate any identical styles so the performance concern here doesn't seem tobe valid.

> I know that Krinkle mused that perhaps Mobile.css should be render-blocking these days,

MediaWiki:Mobile.css was always meant as a temporary solution working around the fact that MediaWiki:Common.css didn't include styles that were common. I don't want to put more energy to improving MediaWiki:Mobile.css and would instead rather focusing on slimming down MediaWiki:Common.css for all users by relying more on TemplateStyles, so we can include it on mobile too. Ideally, MediaWiki:Mobile.css will get removed around the same time as the hlist styles and replaced with MediaWiki:Common.css and/or MediaWiki:Minerva.css. Jdlrobson (talk) 21:36, 13 October 2021 (UTC)

@Jdlrobson: 5k doesn't seem to much in the grand scheme of things That's just a raw count of pages, not the count of how many of those are templates and how many pages are affected by those templates. Separately, you seem to have decided to ignore the concern about FOUC or totally unstyled content. That second set of pages are not included in that 5k estimate.

Raw HTML in wikitext You mean raw HTML like {| class="wikitable"\n|- class="hlist"\n| ... |}? Or {{arbitrary template|class=hlist}}? Those look pretty wikitextish to me. :)

Shouldn't we be discouraging this anyway? This is a skill I am lacking. :) Anyway, the class has been deployed for a decade in a place where people had easy access to it, never mind that there was a huge push to use it, well, for its purpose. So people used it.

(NB it's not the only class like that; infobox and navbox and even the bloody navbox sub-classes and still others in the set all have this issue. Heck, I used it like so, before TemplateStyles rolled out of course; since then, I have definitely used the hlist class in a module-based template that could one day later find the class or as its template form.)

Seems off topic. It is not. I am also not talking about what navbox does without reason; I am telling you what it does and how that will impact pages where the navbox template is the cause of the addition of the TemplateStyles and the TemplateStyles are located nowhere else on the page, but where the page does contain the hlist class outside of that navbox. On mobile, the hlist will be unstyled as hlist; on desktop, there will be a FOUC. Simple as that. The quantity of these pages is probably non-0, though I can maybe serve up a search like the above.

TemplateStyles deduplicates repeated styles ... GZIP I know how TemplateStyles works. I am saying it misses the point to put these into TemplateStyles before removal from Common.css. I am of the understanding that the stylesheet (Common.css + other RL sheets) and the final delivered HTML are not zipped together (yet?). If they are not zipped together, then the end user will receive the styles twice, and one of those copies will not be compressed to nothing. What can you say on the point?

This concern may be negligible, but there is at least one other engineer (Krinkle) who has been thinking about the consequences of TemplateStyles more fully with regard to how often the styles will be downloaded to the end user.

I don't want to put more energy to improving MediaWiki:Mobile.css From what I can see of prior work, Mobile.css can be made render-blocking today with a config option (your comment). Is that correct?

If I really have to, I can simply turn on a gadget with the site styles (as is done on MediaWiki wiki with mediawikiwiki:MediaWiki:Gadget-Site.css by setting the gadget to styles only) and render block things that way on both desktop and mobile. I would prefer not to since the page history/attribution can get a little messy, but that's another option if the technical debt in MobileFrontend is that important to you today. Izno (talk) 23:42, 13 October 2021 (UTC)

5k: Understood, however that's still small from my perspective when we've made similar changes. Usually we tend to make sure all common templates are fixed first before dropping code, so I'd recommend that as being the focus.

Using inline hlist class: We could have a template that was just hlist styles if we needed. I don't think it's a hardship to inject that template above these usages and I think that is enough friction to get useful templates created e.g. {{ hlistwikitable }}

FOUC: If you've got a FOUC then a template is not loading the template styles or is using a generic class.

GZIP: Glad you understand all this. I didn't want to assume. My assumption here is Common.css needs to be taken out of the equation, but yes of course if it's in the stylesheet and inline HTML then it's duplicated, but the performance implications are different. The real issue here is including it in common.css in the first place. Last time I checked only 30% of all wiki pages were using the hlist element, so I'd argue that you are already penalizing the majority of pages by loading it everywhere and that this is a much bigger problem than double loading it on certain pages. On mobile where it's loaded it's also causing reflows which are even worse.

Gadgets: This is a good idea and allows editors who want to fix this issue to disable the default-on gadget so they can identify broken pages. I think this would be a good interim compromise while the transition to template-only styles is made. Jon (WMF) (talk) 17:37, 14 October 2021 (UTC)

Navbox: I still don't understand the concern here, but if you include the Navbox template, the MobileFormatter only removes the table not the styles. However other templates shouldn't be relying on Navbox for their styles. They should be sharing the same stylesheet. Jon (WMF) (talk) 17:39, 14 October 2021 (UTC)

I'm not following why moving CSS from the primary locations in to a gadget load could possibly be a good idea? — xaosflux ^Talk 17:42, 14 October 2021 (UTC)

Right now, MediaWiki:Mobile.css loads after the page does, not before. This causes FOUCs. If you want, one way to ensure styles are delivered to users before the page starts loading is to make a default-on styles-only gadget. This works for both unregistered and registered users. Izno (talk) 23:17, 14 October 2021 (UTC)

@Izno: thanks for the note, so this is unlike common.css; minerva.css; etc? So really begs the question, why can't that just be fixed upstream? — xaosflux ^Talk 01:29, 15 October 2021 (UTC)

@Xaosflux: Correct, it is not like the others, as it loads after the content is on the page. (There are pluses and minuses to loading the stylesheet late on the page, so it was and really is still today a reasonably valid engineering decision made then.)

Jon doesn't want to "fix" it upstream (the task for which is phab:T190083, with some others in the Related Objects tabs that might be interested reading). As above:

MediaWiki:Mobile.css was always meant as a temporary solution working around the fact that MediaWiki:Common.css didn't include styles that were common. I don't want to put more energy to improving MediaWiki:Mobile.css and would instead rather focusing on slimming down MediaWiki:Common.css for all users by relying more on TemplateStyles, so we can include it on mobile too. Ideally, MediaWiki:Mobile.css will get removed around the same time as the hlist styles and replaced with MediaWiki:Common.css and/or MediaWiki:Minerva.css.

The end goal (almost everything is TemplateStyled) is shared. How to get there is, uh, blocked on the fact that I am the only one working on it here and we have many thousands of pages that need fixing. :) Hence this discussion, at least particularly for hlist. Izno (talk) 01:37, 15 October 2021 (UTC)

Before people start tearing down the existing hlist structure, please review the comprehensive discussions that took place a few years ago that produced the present set-up. --Redrose64 🌹 (talk) 21:23, 14 October 2021 (UTC)

It's being torn down only in the sense that the styles are being moved to TemplateStyles (at some point), and Jon wants to move the timeline of removal to before its uses are all fixed in the wild. We'll still use hlist at the end of the day, just not in arbitrary classes i.e. you'll need to use {{flatlist}} or {{hlist}} for arbitrary uses, with probably some limited support in module-based templates like {{navbox}} to set hlist in a class parameter without invoking another template. Izno (talk) 23:12, 14 October 2021 (UTC)

@Jdlrobson: (I'm just picking the one name)

We could have a template that was just hlist styles if we needed. I do not want to go down that path if I can avoid it (I can't avoid it for e.g. plainrowheaders I think) because I really want to move away from spooky action at a distance as best I can, meaning always using {{flatlist}} (with {{endflatlist}} as necessary) or {{hlist}} (unless invoking from inside some small set of modules like Module:Navbox).

FOUC My impression was that you can get FOUCs (or partially unstyled) if the styles are placed after the element they style (hence why Mobile.css causes FOUCs/partially unstyled content). Is that untrue?

much bigger problem than double loading it on certain pages Well, we're still penalizing the other 70% in a double loading scenario, just not as much. :^)

Gadgets Ok. That said, if loading Common.css on mobile is the future anyway, that might be a waste of time? It's a fairly easy path to take I guess, but as you can see, MediaWiki:Gadget-site.css history looks a little messy.

if you include the Navbox template, the MobileFormatter only removes the table not the styles MobileFormatter will rip out anything inside the container it rips out. That includes TemplateStyles inside the element (which are "just" inline <style> elements). Take a look at mediawikiwiki:Manual:$wgEnotifWatchlist versus mobile version. Navbox is gone as are the relevant <style> elements, among them the hlist TemplateStyles (which are added as part of Module:Navbar). In fact, I'm even using a trick as discussed at Template talk:Navbox to rip the navbox styles out on mobile as well.

All that said, en.wp is just one of the biggest wikis. There are one-thousand wikis, most I would guess are more in the realm of "haven't started"... Izno (talk) 00:09, 15 October 2021 (UTC)

MediaWiki:Noscript.css

Discovered this while going through MW source code – CSS placed here is loaded for non-javascript clients. We can put this to good use by creating it with:

div.noscript-show {
  display: block !important;
}
span.noscript-show { 
  display: inline !important;
}

The group-*.css pages also have some more (p, small, table, li) but those are probably unnecessary.

Usecase: pages on which scripts are loaded using the withJS method, it's good to show fallback text for non-javascript clients which is presently done quite clumsily (eg. see the text here). Putting class="noscript-show" style="display: none" will enable us to fine-tune the text specifically for non-js users. cc: Sdkb, Enterprisey. – SD0001 (talk) 16:55, 30 October 2021 (UTC)

You can target these elements using TemplateStyles more gracefully. Are you sure you still want the change to Noscript.css? Izno (talk) 17:19, 30 October 2021 (UTC)

@Izno is there a way using TemplateStyles to tell if the user has JS enabled? – SD0001 (talk) 18:14, 30 October 2021 (UTC)

I don't understand the question. You can use html.client-js and html.client-nojs as selectors in TemplateStyles as you please. Izno (talk) 18:31, 30 October 2021 (UTC)

Nope, templatestyles prefixes all selectors with .mw-parser-output so those won't work. – SD0001 (talk) 18:47, 30 October 2021 (UTC)

@SD0001: I would not have told you it was possible if it was not. Please review mediawikiwiki:Extension:TemplateStyles#Caveats, last bullet: To target styles based on skins, use a selector such as body.skin-vector .myClass; specification of the body element is required and must be followed by a descendant combinator (i.e. the space). Other classes on the body or html elements may be targeted in the same manner. 1.32+ Izno (talk) 19:17, 30 October 2021 (UTC)

Orange bar of doom now peach bar of doom

Looks like a few months ago the new message alert for (desktop) IP editors was changed from this:

You have a new message from another user (last change).

to this:

You have a new message from another user (last change).

Should we restore the old behavior on enwiki? All it should take is:

div.usermessage {
    background-color: #ffce7b;
    border: 1px solid #ffa500;
}

IMO the new color scheme blends in too much, at least on my screen (ancient ThinkPad). I'm not sure if this change needs a widely-attended discussion since we're just restoring old behavior that was changed without discussion, but I'll raise this on WP:VPT if needed. Suffusion of Yellow (talk) 23:25, 29 October 2021 (UTC)

I don't see a need to revert the colors whatsoever (this is bikeshedding), and am 100% not in favor of reverting in Common.css for it. This also matches the style guide so it makes it more consistent with the rest of the UI. Izno (talk) 23:38, 29 October 2021 (UTC)

Well, I was thinking of this in the context of WP:THEYCANTHEARYOU. For some reason, desktop (not just mobile) users sometimes seem oblivious to their talk pages, though I don't know if the color change has anything to do with it. I wouldn't consider it bikeshedding anymore than the color of a stop sign. "Ignoring" user talk page messages can get you blocked. And since over a year after I reported the issue, the WMF still hasn't implemented any kind of message at all for mobile users, I see an almost 0% chance of success getting that change reverted. Suffusion of Yellow (talk) 00:09, 30 October 2021 (UTC)

Yes, I personally thought this concern might be coming from a TCHY perspective. I'm just not convinced that this change (basically, background color only) has any effect on whether someone can hear you. The orangepeach banner is still just as disruptive in the general "hey there's something you need to care about, please look at me" perspective. (Unless we consider that no-one sees any banners.)

At the end of the day, you might sell me on the hypothesis "the present color in the WM style guide is not sufficiently disruptive to indicate an issue, non-critical (vice an issue, critical)" (see messages section of the style guide, linked in the patch), but that's a general issue that can/should be A/B tested, which we do not have the onwiki technology to assess anyway. I.e., if there's any reason to change it (to any other color), it should be tested by the WMF UI design team anyway.

All that said, this banner color no longer matches the color that registered users receive (which is much closer to the original orange at #fc3, matching the border of the peach version). So the change has introduced an inconsistency that should be corrected. Izno (talk) 02:16, 30 October 2021 (UTC)

Now that you say it, the .mw-echo-alert color (#fc3), is even better:

You have a new message from another user (last change).

Anything that's different from the other messages, and at least somewhat ugly, is fine by me. The point is that your beautifully designed mountain community, with everything from the houses to the ski shop signs to, yes, the bikesheds, in tasteful shades of green and brown, can't also have the "RAILROAD CROSSING AHEAD" signs in green and brown also. Suffusion of Yellow (talk) 03:04, 30 October 2021 (UTC)

" For some reason, desktop (not just mobile) users sometimes seem oblivious to their talk pages" It's because talk pages are a dumb concept that only exists in wikipedia :D —TheDJ (talk • contribs) 11:12, 2 November 2021 (UTC)

I agree with Izno on this, the new colors seem fine. Legoktm (talk) 00:54, 30 October 2021 (UTC)

Exactly, they seem fine to developers because they look nice. However, the intention is that users be required to at least view talk page messages. They can delete them or ignore them (possibly at their peril), but they need to see them. The change needs to be reverted even if a tedious RfC is required. Johnuniq (talk) 01:20, 30 October 2021 (UTC)

And they can still see them. As I said, I think changing the color back is bikeshedding, and there is a reason to have made the change in the first place. Izno (talk) 02:03, 30 October 2021 (UTC)

I'm not sure if you're referring to me when you mean "developers", but I don't think the new colors look nice, or at least that's not my motivation. Some people really like the orange, some people really don't (see T58845#4535499 and follow-ups). Part of the reason I use Timeless is because it hides the orange bar. I'm sure that even if the text was obnoxiously blinking, people would still not click on it. So you can count me as skeptical that the orange makes that much of a difference. Personally, I think if you really want people to read their talk page messages, use something like nerdalert. Legoktm (talk) 07:21, 30 October 2021 (UTC)

Johnuniq, could you clarify? You replied to "I agree with Izno on this" (User:Legoktm) saying "Exactly", then you follow up with "The change needs to be reverted" (i.e., use old color). To me, contradicting. -DePiep (talk) 15:51, 30 October 2021 (UTC)

• Support using old color, or the "even better" #fc3. Especially per Suffusion of Yellow's "Anything that's different from the other messages, and at least somewhat ugly, is fine by me." The color needs to be vaguely disturbing, like baby vomit, not calming and yummy, like cotton candy. Mathglot (talk) 08:40, 30 October 2021 (UTC)
• Support #fc3 per Mathglot. Do <blink> and <marquee> still work? Certes (talk) 17:03, 30 October 2021 (UTC)
• Oppose, follow Izno. I am not a UI designer myself, but I can agree with their line. Also, I'm happy to have learned that modern UI is not about flashing around warnings. -DePiep (talk) 17:23, 30 October 2021 (UTC)
• Weakly Oppose Changing the colour, as it would be an entirely pointless change that doesn't accomplish anything. The existing notice is extremely obvious when presented to IP editors and I don't see making the colour "ugly" making people more likely to read their talk page. Strongly Oppose making the text blink, scroll or animated, as such elements are difficult/obnoxious to read and have accessibility issues. 192.76.8.77 (talk) 12:25, 31 October 2021 (UTC)

  I'm fairly sure Certes was joking about the blink/marquee. :-) Suffusion of Yellow (talk) 18:10, 31 October 2021 (UTC)

• Oppose the standard UI scheme should be fine here. The main TCHY problem isn't the color - it is that it isn't displayed to people on mobile (yet) - and that is being looked in to elsewhere already. — xaosflux ^Talk 13:53, 31 October 2021 (UTC)
• If a disruptive notice is to be desired, then I think that the new color scheme does not achieve that. To me, the new color scheme is too much similar to the preview notice at the top of a preview page:
  This is only a preview; your changes have not yet been saved! → Go to editing area

• I routinely ignore that notice so it would seem to me that a different color scheme for the doom message would be a better choice.
• —Trappist the monk (talk) 15:15, 31 October 2021 (UTC)

• Oppose the new colour is visible enough IMO, I don't think it's worth creating inconsistency between wikis and adding more CSS just to change it back. NemesisAT (talk) 15:16, 31 October 2021 (UTC)
• Weak oppose - I think paler one is sufficient. Less "loud" on the eyes Cas Liber (talk · contribs) 18:15, 31 October 2021 (UTC)
• Weak oppose on changing back the colour. However I think adding an icon might be a good compromise to make it a bit more eye catching, and in fact the design style guide recommends using icons. Probably would need a phab task. the wub "?!" 00:37, 2 November 2021 (UTC)
• Comment don't care, it doesn't matter, this is not why people don't understand/read their talk page. —TheDJ (talk • contribs) 11:16, 2 November 2021 (UTC)

Interface-protected edit request on 2 December 2021

Replace

table.ambox + table.ambox {      /* Single border between stacked boxes. */
	margin-top: -1px;
}

with

/* Single border between stacked boxes. */
table.ambox + table.ambox,
table.ambox + .mw-empty-elt + table.ambox {
	margin-top: -1px;
}

This will prevent the borders of the two amboxes from appearing together when they are separated by {{Dated maintenance category}} based template. This is because {{Dated maintenance category}} outputs a nowiki tag (which is needed to prevent blank lines from appearing at the top of articles) in addition to the category link it produces. The combination of a nowiki tag and a category link causes mediawiki to output a .mw-empty-elt element, which breaks the current CSS.

Right now two amboxes separated by a DMC based template look like:

[[Category:{{{1}}}]]

With the proposed changes, they would look the same as two amboxes that are not separated by a DMC based template, which is:

– BrandonXLF (talk) 05:50, 2 December 2021 (UTC)

 Done @BrandonXLF: I don't love having to have this in common.css, but since it is adding that extra selector is ok. — xaosflux ^Talk 14:07, 2 December 2021 (UTC)

TemplateStyles for navbox

I am preparing to remove the CSS for navbox out of MediaWiki:Common.css in the near future in lieu of its current TemplateStyles implementation (see MediaWiki talk:Common.css/to do#description for rationale), but it will have one effect that may warrant review. Please take a minute to review or comment at Template talk:Navbox#TemplateStyles followup. Izno (talk) 22:31, 21 December 2021 (UTC)

It's out of my depth, but do I understand I check my pet navboxes after this change? Moment of change will be notified I understand. -DePiep (talk) 03:41, 22 December 2021 (UTC)

Yes, you'll see the removal happen in Common.css, plus I'll probably leave a comment at template talk:Navbox when it does occur. Izno (talk) 05:26, 22 December 2021 (UTC)

Fixing overflowing edit summaries on the watchlist

Tracked in Phabricator
Task T158725

Certain long edit summaries (such as this one to Wikipedia:RedWarn) cause content to overflow off the side of the screen.

The edit summary in contained in a span:

<span class="comment">(Edit summary content)</span>

of which the class (comment) is:

span.comment {
	font-style: italic;
	unicode-bidi: -moz-isolate;
	unicode-bidi: isolate;
}

We can use the overflow-wrap property (MDN) to cause a line break if the entire edit summary cannot be placed on its own "line" without overflowing. This CSS property is well supported by web browsers.

I propose we add the following CSS to MediaWiki:Common.css:

span.comment {
	overflow-wrap: break-word;
}

The break-word value allows for normally unbreakable words to be broken at arbitrary points if there are no otherwise acceptable break points in the line, which given the rarity of edit summaries this long (and the option to view the entire summary unbroken with a single click) I think this to be a good choice of word breaking method -- TNT (talk • she/they) 18:34, 3 December 2021 (UTC)

? @TheresNoTime: I looked at your example in monobook and vector, and in neither case is it going off my screen or causing horizontal scroll bars. — xaosflux ^Talk 19:37, 3 December 2021 (UTC)

@Xaosflux are you looking at the diff view? That one doesn't overflow, but I think TheresNoTime's issue is specifically occurring when viewing such changes on Special:Watchlist. -- Asartea ^{Talk | Contribs} 20:36, 3 December 2021 (UTC)

OK, was able to see it. @TheresNoTime: can you confirm this is the problem identified in phab:T158725? If we are going to hack around a problem, I'd like to be able to reference the bug. — xaosflux ^Talk 20:54, 3 December 2021 (UTC)

@Xaosflux: yup that seems to be the same bug.. may be worth seeing if this "fix" can be moved upstream a bit -- TNT (talk • she/they) 21:03, 3 December 2021 (UTC)

The problem here is actually the fact that RC and watchlist are a table. Tables overflow to fit the content of their cells when needed. In turn wrap (incl overflow-wrap:break-word) gets avoided as long as the parent can expand. Therefore this content can never wrap with this rule. —TheDJ (talk • contribs) 11:43, 4 December 2021 (UTC)

ah wait, that's only if grouping is enabled of course... hmm, i guess then it can work. —TheDJ (talk • contribs) 12:03, 4 December 2021 (UTC)

Don't worry, I did test it before proposing it 😝 -- TNT (talk • she/they) 15:38, 4 December 2021 (UTC)

 Done — xaosflux ^Talk 23:28, 5 December 2021 (UTC)

I'm also upstreaming this and some related cases. [1] [2][3] —TheDJ (talk • contribs) 08:48, 6 December 2021 (UTC)

This can be removed again btw, it's now in core. —TheDJ (talk • contribs) 10:04, 10 January 2022 (UTC)

@TheDJ: it sure would have been nice if you gave proper credit, but ho hum 🤷‍♀️ -- TNT (talk • she/her) 10:13, 10 January 2022 (UTC)

Sorry about that. Is your username ok, or do you want a specific name ? —TheDJ (talk • contribs) 10:52, 11 January 2022 (UTC)

Removed. — xaosflux ^Talk 11:16, 10 January 2022 (UTC)

And in TIL, overflow-wrap: break-word; / word-wrap: break-word is the same as word-break: break-word, except it only applies to inline elements and the 'added' 'deleted' parts of our diffs are inline-blocks.... —TheDJ (talk • contribs) 11:26, 11 January 2022 (UTC)

Main page heading

CSS to hide the Main Page heading in MediaWiki:Vector.css with .action-view.page-Main_Page .firstHeading is no longer needed per Wikipedia:Tech news#Tech News: 2022-02. For confirmation, https://en.wikipedia.org/wiki/Main_Page?useskin=vector&safemode=1 displays no heading. Some skins still display a heading without CSS to hide it, but phab:T298715 says that will end later this week. vector and minerva show no heading. monobook, modern (at top left), timeless and cologneblue currently show a heading.

The mobile https://en.m.wikipedia.org/wiki/Main_Page displays "Welcome, PrimeHunter!" due to the default MediaWiki:Wikimedia-mobile-mainpage-title-loggedin. That seems social-media like and a little creepy to me, giving a vibe of sites logging lots of user data for possibly nefarious purposes. It also takes up valuable screen space on mobile devices, and we already say "Welcome to Wikipedia" right afterwards. I suggest blanking the message as "unprofessional" for an encyclopedia. PrimeHunter (talk) 11:12, 11 January 2022 (UTC)

@PrimeHunter: agree in removing that $1 - it is only impacting registered editors, so it's not that bad - but I'd rather it be consistent anyway. — xaosflux ^Talk 11:14, 11 January 2022 (UTC)

I have no problem removing after the couple other skins get the change necessary. I don't see a strong reason to touch the individual skin.css pages for just the week or two (Timeless is on wmf.18, likely next week) in this case.

Something Stjn brought up was that we should probably have an H1 somewhere on the page to replace it, which we haven't done a good job of with the CSS version either. Izno (talk) 18:46, 11 January 2022 (UTC)

unprofessional ? You'll don't have names at your jobs ? It can stay as far as I'm concerned. —TheDJ (talk • contribs) 10:47, 2 February 2022 (UTC)

Mainpage-title

Moved from MediaWiki Talk:vector.css

Now that we have Mainpage-title/Mainpage-title-loggedin, shouldn't line 8 be removed? NguoiDungKhongDinhDanh 12:57, 1 February 2022 (UTC)

This was a request to remove from vector.css, but this applies to multiple skins and needs more review first. — xaosflux ^Talk 14:07, 1 February 2022 (UTC)

I've removed the ones that seemed to exist in Vector, Timeless, and Monobook. Izno (talk) 18:28, 1 February 2022 (UTC)

As a followup, we now have an H1 on the page, in what I think is a reasonable spot. Izno (talk) 19:04, 1 February 2022 (UTC)

@Izno The original H1 containing "Main Page" is still there, just now MediaWiki automatically hides it with CSS. I think ideally the heading wouldn't be added to the output at all rather than hidden with CSS, but for now I'm not sure if having two H1s is a good idea. – BrandonXLF (talk) 03:48, 2 February 2022 (UTC)

As I had to point out in an issue related to this fix, the display: none H1 is not rendered of course, but also not served by accessibility agents. Nobody knows the first one is there, and even web spiders will ignore it these days. Izno (talk) 05:07, 2 February 2022 (UTC)

Interesting. Well as long as if everyone is ignoring the first H1 properly, then there shouldn't be any issues. – BrandonXLF (talk) 07:31, 2 February 2022 (UTC)

I bet there are modules and scripts that simply assume the existence of #firstHeading so hiding it is indeed a better idea. Nardog (talk) 11:16, 2 February 2022 (UTC)

Plainrowheaders background color

In cases where the row headers are apparent, or apparent with a flag image or row number preceeding them, it is more aesthetically pleasing to make the row headers' background color match the rest of its data cells. Otherwise, in the latter case, you would have one dark column of row headers in between light columns. I recommend adding a "plainrowheadersbg" class, which would only set "background-color: inherit;". Inherit for cases where you want a dark background for a row like "sorttop" that can be styled on the row. It was brought up at some point by @Timeshifter:, which I also like the style. I have it styled in Template:COVID-19 pandemic data/styles2.css for tables like Template:2020 monthly cumulative COVID-19 death totals by country and Template:COVID-19 pandemic data/Rhode Island medical cases by municipality. Jroberson108 (talk) 01:52, 14 February 2022 (UTC)

Using both the "plainrowheaders" and "plainrowheadersbg" classes would make the row headers look the same as the data cells, except it would still be a row header with scope="row" for accessibility purposes. This would help alleviate what I believe is the most popular workaround of not making it a row header just because they don't like the heavy look of it. I assume most sighted people can usually tell if the left column is or isn't describing the data without a background color, especially since the content is read in a order we are use to ("left to right", "top to bottom"). Jroberson108 (talk) 05:04, 14 February 2022 (UTC)

This is not a change I am interested in implementing. plainrowheaders itself was added as a compromise originally for cases of similar manner and the adder gave something of an opinion on "no more". Secondly, it adds to the global cost of addition to Common.css.

Secondly, this loss of distinguishing factor between the header and cell is a loss for even "sighted" people, who may not know what the most important part of a table is.

Individual templates where this is deemed reasonable may implement something with TemplateStyles. Izno (talk) 06:48, 14 February 2022 (UTC)

Almost all people know that nearly all tables have their most important info in the cells at the top and left side. I think Mediawiki should work on a way to only download table CSS if the software sees some table markup in the page. Then tables could be greatly improved. White background for data cells via a class instead of a template {{Import-blanktable}}. Lighter gray color for headers instead of the relatively darker gray color now used. Many more options, row numbers, etc.. --Timeshifter (talk) 08:00, 14 February 2022 (UTC)

Interface-protected edit request on 14 February 2022

Requesting that the following CSS be appended to the /* Show hidden items that have class="sysop-show". */ area of MediaWiki:Group-sysop.css:

.nonsysop-show {
  display: none !important;
}

See Special:PermanentLink/1071739737 for the desired end result. There are some cases where some text is only relevant to non-administrators and could be hidden from administrators. The template Template:If administrator would require this change to work properly. This would align with the existing templates Template:If extended confirmed and Template:If autoconfirmed. Mz7 (talk) 03:53, 14 February 2022 (UTC)

I do not think this should be implemented. I would find it extremely concerning if this class were used for abuse and casual administrators were unable to see the text added. Izno (talk) 04:48, 14 February 2022 (UTC)

 Not done agree with Izno, not just for abuse but in general sysops are editors, if editors are seeing things sysops should see them too so they know what the editor see. — xaosflux ^Talk 11:33, 14 February 2022 (UTC)

NB, looks like we did not hide those other ones from sysops, for the same reason. — xaosflux ^Talk 12:17, 14 February 2022 (UTC)

@Izno and Xaosflux: These are reasonable points, and I don't really have a compelling enough use case for this kind of CSS class to override your concerns. Accordingly, I've nominated the {{If administrator}} template for deletion. (Withdrawn in favor of refactoring the template to remove the second parameter that hides content from admins.) I will mention, though, that the existing template {{If autoconfirmed}} does work because of the existence of the CSS class unconfirmed-show in MediaWiki:Group-autoconfirmed.css—if we are worried about the potential for abuse, then this CSS class presents a similar problem where abusive content could be shown only to new editors and be invisible to experienced ones. (The template is used predominantly at Wikipedia:Files for upload/Wizard to give different instructions depending on whether the user is autoconfirmed.) Mz7 (talk) 22:41, 14 February 2022 (UTC)

Similarly, {{If extended confirmed}} works because of nonextendedconfirmed-show in MediaWiki:Group-extendedconfirmed.css. This one is a little interesting because most administrators aren't members of the explicit group "extended confirmed" because the extendedconfirmed right is bundled with the sysop group. As a result, {{If extended confirmed}} has the effect of showing some content to non-extendedconfirmed editors and administrators and other content only to extendedconfirmed editors. Mz7 (talk) 22:53, 14 February 2022 (UTC)

@Mz7, Izno, and Xaosflux: Yeah, I think that, if we're concerned about potential for abuse, {{If autoconfirmed}} presents a far greater potential for abuse. I've checked the transclusions of that in the past to make sure it's not being used for anything improper, and I just added an additional safeguard. Given that the inherent vulnerability already exists, I don't see any real marginal risk with this. If we want to guard against abuse, could we get this to work only outside of mainspace? {{u|Sdkb}} ^talk 22:59, 14 February 2022 (UTC)

My concern was less "security" (which is valid) then: if editors see things, admins should as well. Admins get tasked with all sorts of support like "when I go to this page, I see this thing". — xaosflux ^Talk 00:36, 15 February 2022 (UTC)

@Xaosflux: That's a good reason to be cautious about when to use the template, but not so much a reason to prevent it working anywhere. There are certainly valid use cases, where it can help to make instructions simpler and more accessible. {{u|Sdkb}} ^talk 01:04, 15 February 2022 (UTC)

There is an extremely low number of workflows where an admin can't follow the normal editor process, and they should be aware of them. — xaosflux ^Talk 01:18, 15 February 2022 (UTC)

Not only that, but nothing has to observe these classes to begin with (think text only browsers/systems, Alexa, apple dictionary, google excerpts etc). Keeping these things visible to admins makes everyone aware that these classes are just bandaids and should not be relied upon. This entire system is an unreliable courtesy and was never intended to be used more than absolutely required. This continuous scope creep was exactly the reason why we were hesitant to introduce the classes in the first place if my memory serves me well. —TheDJ (talk • contribs) 11:10, 15 February 2022 (UTC)

Possible typo in Mobile.css

Should ".heading-holder hlist li:after," be ".heading-holder .hlist li:after,"? Note the added full stop before "hlist". This may relate to the above issue. – Jonesey95 (talk) 00:00, 21 February 2022 (UTC)

It doesn't, but I fixed it anyway. Izno (talk) 00:18, 21 February 2022 (UTC)

Apparent quirk in nested hlists in mobile

Please see Template talk:Flatlist and the accompanying test case (link forces mobile view) for an issue with missing parentheses. MediaWiki:Mobile.css seems to indicate that closing parens should appear. – Jonesey95 (talk) 18:33, 20 February 2022 (UTC)

... wat. I don't understand what's going wrong there. Like, no idea. Izno (talk) 22:38, 20 February 2022 (UTC)

I did some testing and added a comment over there. – Jonesey95 (talk) 23:17, 20 February 2022 (UTC)

The issue is caused by a rule in https://github.com/wikimedia/mediawiki-skins-MinervaNeue/blob/master/skinStyles/mediawiki.hlist/minerva.less which uses content: none !important; to remove the content from all the last children of lists with the hlist-separated class.

The easiest solution would be to add !important to the content: ") "; rule in MediaWiki:Mobile.css. A rule with padding-left: 0; should also be added to cancel out the one in the file linked above. The rule #content .hlist-separated li:after in Mobile.css is making the line-height 0.8em when it should be 1em, so something should also be done about that as well. – BrandonXLF (talk) 18:17, 22 February 2022 (UTC)

Yes, we came to that conclusion over in the other discussion that hlist-separated was actually at fault. Izno (talk) 18:54, 22 February 2022 (UTC)

small caps inconsistent with Greek

On WP-en, I needed a small-cap delta for a non-Unicode character. But the small-cap template had no effect. I am told there that how the letters display depends on my browser. Could something be done to ensure that small caps display correctly?

On my browser (Firefox), the following basic Greek letters display as small caps:

εζηικνξοςτυψϝ

and these do not:

αβγδθλμπρσφχω

That's true whether or not I log in.

However, in the Falkon browser, all are correctly small-cap.

Is this a bug that needs to be fixed at Firefox?

Please ping me if you respond. Thanks. — kwami (talk) 21:11, 28 February 2022 (UTC)

@Kwamikagami: Both strings display correctly for me (Firefox 97, Ubuntu 16.04) in legacy Vector, Monobook and Timeless. Certes (talk) 21:50, 28 February 2022 (UTC)

I'm also using FF 97.0.1 (64-bit), but in Mint 20.3. — kwami (talk) 21:57, 28 February 2022 (UTC)

This sounds like you do not have the fonts you want installed on your system. There's no meaningful way to do something about that here. Izno (talk) 23:26, 28 February 2022 (UTC)

Letters in the second group are more widely used in science and especially mathematics than the first group. Could a font containing mathematical symbols be overriding the small cap font on your machine? Certes (talk) 23:40, 28 February 2022 (UTC)

My default fonts are the same in FF and Falkon for Greek, but they're different for Latin. I changed both to the default (Deja Vu), and the Greek is now all proper small caps. But why should my Latin font prefs affect the display of Greek? Deja Vu is a terrible font for linguistics, so I don't want to leave that as my default. — kwami (talk) 00:06, 1 March 2022 (UTC)

@Kwamikagami: adding attribute lang="el" ("el" is two-letter code for Greek language) to the <span>...</span> tag seems to help for me in Firefox. As per [4]. —⁠andrybak (talk) 00:32, 1 March 2022 (UTC)

Yes, that resolves it, thanks. On WP-en, that means a span tag is needed in addition to the small-cap template. I'll drop them a comment and see if they want to modify their instructions. — kwami (talk) 00:39, 1 March 2022 (UTC)

@Kwamikagami: They're all proper small capitals for me. Firefox 97.0.1. --Redrose64 🌹 (talk) 23:43, 28 February 2022 (UTC)

For me as well with the default fonts, but not with the SIL fonts that are needed for full IPA support. — kwami (talk) 00:41, 1 March 2022 (UTC)

Issue with padding/margin caused by CSS rule here

The CSS rules on MediaWiki:Common.css § L-653 cause an issue on my Firefox version that means the red-warning box shown to indicate previous deletions is too short in height. This only is the case when not editing (i.e. when &action=edit&redlink=1 is not in the URL). I can post a screen-shot if necessary. Locally disabling either the padding or margin through inspect element from the lines just below fix the issue for me. Dreamy Jazz ^{talk to me | my contributions} 01:02, 1 March 2022 (UTC)

yes please share a screenshot (an easy place to do so is https://phabricator.wikimedia.org/file/upload/ ) —TheDJ (talk • contribs) 09:25, 2 March 2022 (UTC)

Or WP:WPSHOT. --Redrose64 🌹 (talk) 20:36, 2 March 2022 (UTC)

Plainrowheaders row and rowgroup scopes

Further information: Wikipedia talk:Manual of Style/Accessibility/Data tables tutorial § Rowgroups and plainrowheaders

Currently, the "plainrowheaders" class only targets table header cells with a scope of "row". It should include a scope of "rowgroup" for row headers that span multiple rows. Add .wikitable.plainrowheaders th[scope=rowgroup] selector. Jroberson108 (talk) 21:22, 20 March 2022 (UTC)

@Izno: I see Common.css was updated. Can you also update Mobile.css? Jroberson108 (talk) 19:23, 22 March 2022 (UTC)

Protected edit request (3 March 2022)

Please change the icon used for PDF files from File:Icons-mini-file acrobat.gif to File:Icon pdf file.png per the outcome of this Village Pump RFC. Thryduulf (talk) 18:14, 3 March 2022 (UTC)

 Done Writ Keeper ⚇♔ 18:18, 3 March 2022 (UTC)

Thank you. Thryduulf (talk) 18:27, 3 March 2022 (UTC)

Horse, meet cart ..... commons:Commons:Administrators'_noticeboard/Blocks_and_protections#Protection_request_for_File:Icon_pdf_file.png... — xaosflux ^Talk 19:00, 3 March 2022 (UTC)

Editor Writ Keeper's recent edit needs some fixing. The new icon looks ok when rendered at the normal article-body font size, but when rendered in a reference section (where I suspect you will find the vast majority of these icons) or some other place that reduces the font size, the icon gets clipped top and bottom. Examples using font sizes taken from mw.common.css shown against File:Icons-mini-file acrobat.gif (the old icon) for comparison:

example ← [http://www.example.pdf example]

example ← <span style="font-size: 125%">[http://www.example.pdf example]</span>

example ← <span style="font-size: 118%">[http://www.example.pdf example]</span>

example ← <span style="font-size: 90%">[http://www.example.pdf example]</span>

example ← <span style="font-size: 88%">[http://www.example.pdf example]</span>

example ← <span style="font-size: 85%">[http://www.example.pdf example]</span>

example ← <span style="font-size: 80%">[http://www.example.pdf example]</span>

An example in real life: Big Bang § References.

—Trappist the monk (talk) 23:16, 3 March 2022 (UTC)

Requeued, this needs some work - I'm not ready to just revert yet though. — xaosflux ^Talk 11:02, 4 March 2022 (UTC)

I believe this is not a new problem, or anything as a result of this change; I think it's always existed. It's just a little more noticeable because the image itself is bigger. Writ Keeper ⚇♔ 16:15, 4 March 2022 (UTC)

To elaborate, I tested this by adding this to my common.css file, and then adding relevant URLs to my sandbox at various sizes. Both images get cut off at the different font-sizes. Writ Keeper ⚇♔ 16:26, 4 March 2022 (UTC)

Think this is still a problem that needs to be addressed - the RfC landed on this, but didn't illustrate this problem which could have resulted in a different result. Would a slightly smaller version of this file fix this? — xaosflux ^Talk 16:33, 4 March 2022 (UTC)

Agreed, for sure. A smaller file size would probably work, but I think we could also use background-size:contain to dynamically resize the image relative to the font around it (and then change the padding to ~1.4em rather than defining it in terms of pixes, so that the padding afforded to the icon also scales). I've tried it here, and added appropriate test cases to my sandbox. The scaling doesn't do great in terms of the legibility of the "PDF" text in the icon, but it works. (I thought I remembered the RFC allowing for that possibility?) Writ Keeper ⚇♔ 16:55, 4 March 2022 (UTC)

Here is a single data point. I added a variant of your css to my css page. That seems to work well for me with my browser (chrome more-or-less-up-to-date, win 10 desktop). I have no experience with other browsers or operating systems and (gasp) I don't own (am not tethered to) a smart(?) phone. No doubt, more data-points required.

—Trappist the monk (talk) 16:57, 5 March 2022 (UTC)

Cross-post from VPP: icon appears correctly in Safari 15.3, MacOS 11.6.4. 68.173.76.118 (talk) 01:29, 7 March 2022 (UTC)

@Writ Keeper, Xaosflux, and Trappist the monk: Since we're trying to accommodate a 16px image, we should specify padding in pixels. Changing padding-right: 18px; to padding: 8px 18px 8px 0; should accommodate the icon regardless of text size without affecting row height (at least in my tests in Chrome). Using background-size:contain; causes the icon to be unacceptably blurry. --Ahecht (TALK
PAGE) 18:17, 14 March 2022 (UTC)

 Done OK, I've gone with the last suggestion of using padding: 8px 18px 8px 0;. If this results in a markedly worse result than the already bad result, please revert. — xaosflux ^Talk 14:32, 16 March 2022 (UTC)

Unless its just some caching waiting to update, it doesn't look like this fixed the examples above - are ou seeing this fixed @Ahecht:? — xaosflux ^Talk 14:34, 16 March 2022 (UTC)

FWIW, the example PDF icons above were cropped for me before, and they look good now. They also look good at Big Bang § References. – Jonesey95 (talk) 14:49, 16 March 2022 (UTC)

@Jonesey95 thanks for the note, and they do look better for me as well now; should anyone see any issues please let us know! — xaosflux ^Talk 15:19, 16 March 2022 (UTC)

@Xaosflux Yes, they look better to me. Must be a caching issue. --Ahecht (TALK
PAGE) 15:41, 16 March 2022 (UTC)

The comment /* Change the external link icon to an Adobe icon for all PDF files */ should be updated to /* Change the external link icon to a PDF icon for all PDF files */ to reflect the change. Letcord (talk) 00:03, 4 April 2022 (UTC)

 Done — xaosflux ^Talk 00:24, 4 April 2022 (UTC)

Removing messagebox and standard-talk

Page watchers may be interested in WP:VPT#Removing messagebox and standard-talk. Izno (talk) 21:34, 27 April 2022 (UTC)

As well as linked there, I've made a brief migration guide for users who wish to improve their user or user talk pages with the styles of interest. It can be found at MediaWiki talk:Common.css/messagebox.

I am removing the styles right about now. Izno (talk) 21:24, 3 May 2022 (UTC)

In preparing Module:Coordinates for indicator and templatestyles usage

• I propose we change all #coordinates selectors in the various skin.css files to :not(.mw-indicator) > * > #coordinates (because you cannot do :not(.mw-indicator) #coordinates unfortunately). This should simplify the transition and allow us to easily rollback the changes without having overlapping and cached CSS definitions.
• I also propose removing any .mw-indicator #coordinates as I have moved these into Module:Coordinates/sandbox/styles.css
• Once we rolled out the new coordinates, we can then remove these CSS definitions altogether from skin css (once remaining uses have been dealt with of course).

—TheDJ (talk • contribs) 19:10, 28 July 2022 (UTC)

@TheDJ there has been a bunch of initial discussion in Wikipedia:Village_pump_(technical)#Coordinates_in_Vector_2022 - but what we haven't really had is a community decision of: "Where on our articles do we want to present this information to our readers?". Being able to provide examples for decision making may be a good first step. — xaosflux ^Talk 20:05, 28 July 2022 (UTC)

Well as it is now, they can only really easily go to one spot, which is left of the FA/Protection icons, which is below the vertical bar. I don't see why we need to have a discussion about this. It's broken now just as much. Wether we decide on a final 'good' position where they need to go before or after these proposed changes isn't relevant to the technical changes that need to happen and can just as well be handled separately right ? If anything, this is going to make it easier for people to test and present their proposals I think. —TheDJ (talk • contribs) 20:11, 28 July 2022 (UTC)

@TheDJ it's "broken" in vector-2022 because they are colliding with things like protection icons correct? Moving those icons out of the way could be another fix though, correct? — xaosflux ^Talk 13:43, 29 July 2022 (UTC)

Potentially there is only going to be one way to fix this collision that is supportable - but if there are multiple ways we should present them and let the community decide; we shouldn't just assume that what some of us technical people think is best is what content- and reader- focused people will think is best. — xaosflux ^Talk 13:47, 29 July 2022 (UTC)

If someone wants to think up different methods to present and different methods to implement those presentations, they can go ahead. If we want to block this on that that's fine too. But don't expect me to organise a brainstorm session :) —TheDJ (talk • contribs) 13:56, 29 July 2022 (UTC)

@TheDJ heard. We can frame it as an announcement first: "Here is the problem" "This is the immediate solution being proposed", "This is what this solution will change" (esp if it will change things that are not currently "broken" - like display changes in everything that isn't vector-2022). If you have other technical solutions, your input is welcome here. — xaosflux ^Talk 14:08, 29 July 2022 (UTC)

Edit request to remove workaround for a fixed bug

After the fix for T227228 is deployed (which should happen on 18 August, on the usual schedule), the following workaround will no longer be needed and can be removed:

/* Adds padding above Watchlist announcements where new recentchanges/watchlist filters are enabled */
.mw-rcfilters-enabled .mw-specialpage-summary {
	margin-top: 1em;
}

Matma Rex talk 18:17, 10 August 2022 (UTC)

 Not done for now: Waiting for the 18th. Please feel free to ping me around that time if I don't remember to do it myself. Izno (talk) 02:07, 15 August 2022 (UTC)

Should be good to go now. Matma Rex talk 23:19, 18 August 2022 (UTC)

 Done Izno (talk) 23:34, 18 August 2022 (UTC)

mbox is now TemplateStyled only

I've just removed TemplateStyles for mbox and family. There may be some adjustments needed (I already see Template:Talk header above). Please report any issues here and be patient if you see something. :) Izno (talk) 17:48, 17 August 2022 (UTC)

Izno, wording removed TemplateStyles confuses me. I assume you mean that CSS for this template (family of templates?) was moved from Common.css to TemplateStyles. Am I understanding it correctly? —⁠andrybak (talk) 13:19, 23 August 2022 (UTC)

.... yes. Good catch. --Izno (talk) 17:41, 23 August 2022 (UTC)

Suppressing CentralNotice banners on Elizabeth_II

Given the time sensitivity and the public optics, I'm going to be bold and suppress all CentralNotice banners locally on the article for Elizabeth_II. Seddon ^talk 15:15, 8 September 2022 (UTC)

Endorsing fwiw — TheresNoTime (talk • she/her) 16:24, 8 September 2022 (UTC)

@Seddon Um why? Forcing a hack in to enwiki's common.css seems like a bad idea here. We get lots of popular articles, what makes this one so special now? — xaosflux ^Talk 16:25, 8 September 2022 (UTC)

We don't even have that article on the main page. — xaosflux ^Talk 16:28, 8 September 2022 (UTC)

Said article is already getting a lot of attention, and when the inevitable happens I can certainly understand the negative optics of CN/donation banners appearing on a recently deceased monarch's article — TheresNoTime (talk • she/her) 16:29, 8 September 2022 (UTC)

@TheresNoTime but it is fine to fund-raise off of other main page linked articles such as the 2022_Russian_invasion_of_Ukraine and UN Human Rights Office assessment of human rights concerns in Xinjiang? I think before we start supporting project wide css hacks for individual articles there should be some discussion. — xaosflux ^Talk 16:35, 8 September 2022 (UTC)

@Xaosflux: Fair points as always Xaosflux... I think perhaps it'd be best if you self-revert for a moment there Seddon ​​ — TheresNoTime (talk • she/her) 16:38, 8 September 2022 (UTC)

I'd also think a typical user story would include: Open Wikipedia to see what we have to say about subject (I'm sure it will become a main page blurb) - where the user would still get the CN's in their face before being able to click though. — xaosflux ^Talk 16:41, 8 September 2022 (UTC)

Is this supposed to be considered an WMF OFFICE action? I don't see what this has to do with Software Engineering?? — xaosflux ^Talk 16:26, 8 September 2022 (UTC)

@Xaosflux: Considering this was posted, and the edit made with Seddon's volunteer account, I'd call it a stretch to consider it an office action I also see no issue with you reverting a bold addition from a fellow administrator — TheresNoTime (talk • she/her) 16:31, 8 September 2022 (UTC)

@TheresNoTime the edit (Special:Diff/1109210453) was made by a WMF Staff account User:Seddon (WMF). — xaosflux ^Talk 16:34, 8 September 2022 (UTC)

So it was! Sorry 🤦‍♀️ stands to reason too if I'd given it a few more seconds of thought, given that Seddon's volunteer account isn't an IA.. sigh — TheresNoTime (talk • she/her) 16:36, 8 September 2022 (UTC)

• If WMF wants to not show certain CN's to Wikipedia readers right now, they should just turn of said CN's for enwiki. — xaosflux ^Talk 16:43, 8 September 2022 (UTC)
• @Xaosflux: My apologies: given the reservations expressed here I have self reverted and appreciate your feedback here. It was a stopgap solution whilst I try do this on other banners. This was less about fundraising (which I'm not actively involved in) and more the weird optics of Wiki Loves Monuments banners running offering prizes on this particular article. Unfortunately WLM banners are fragmented by separate campaigns and so I need to make changes to multiple ones. Broadly speaking I am of the opinion that we should have community CentralNotice banners should be more sensitive of events like major deaths and wars to avoid what is an uncomfortable juxtaposition. Seddon ^talk 16:59, 8 September 2022 (UTC)

  I think my solution will likely to be creating a Mediawiki namespace template on meta that can be added to all banners that will enable us to add more finesse for excluding high traffic major events like that which is expected to be announced. Seddon ^talk 17:01, 8 September 2022 (UTC)

  @Seddon thanks for the update - and I'm not suggesting that this isn't an idea worthy of exploring. I think it could be useful for there to be a project-controlable list of pages that don't show CentralNotices. Perhaps a __NOCENTRALNOTICE__ magic word even. Letting the CNAdmins also skip pages is also a good idea that could be done upstream. I do however think there may be considerable community viewpoints of what should be skipable if handled locally - thus the call for some discussion. — xaosflux ^Talk 17:04, 8 September 2022 (UTC)

  A MediaWiki-namespace list is a good idea. A magic word is IMO rather not – this is a sensitive thing, and people might easily want that “their” articles don’t show banners, only “other” articles, so a judgement of an administrator may be necessary. It may be useful to set an expiry as well, so that articles aren’t forgot on the list for years (although it probably complicates the implementation quite a bit). —Tacsipacsi (talk) 08:02, 9 September 2022 (UTC)

Sortable table headers not showing arrows

Recently the blue watch star in #p-views was having the same issue. I'm using Chrome on Windows 10 (all up to date) and was seeing the error "Failed to load resource: net::ERR_CONTENT_DECODING_FAILED" for that and now am seeing it for the arrows on sortable table headers. Fred Gandt · talk · contribs 15:12, 21 December 2022 (UTC)

@Fred Gandt: Always post an example when you report something. Maybe it's just a case of Help:Sorting#Background colors in sortable headers but we have no way to tell without an example. PrimeHunter (talk) 15:56, 21 December 2022 (UTC)

That sounds like behavior that can't be resolved here. Either your network has been having problems or there is an issue up the stack. Given there have been no deployments for MediaWiki in A While, I'd guess the former. Izno (talk) 16:27, 21 December 2022 (UTC)

Sorry for the lack of example; the issue is evident on all correctly configured examples on WP:SORT. Hope this helps. Fred Gandt · talk · contribs 16:47, 21 December 2022 (UTC)

They're back now. Technology \o/ Fred Gandt · talk · contribs 17:28, 21 December 2022 (UTC)

Plainlist removed

Plainlist is now only available in the contexts of {{plainlist}} and {{unbulleted list}}. There is some special affordance for it in Module:Infobox, Module:Navbox, and Module:Sidebar, and then a few other modules expand the styles directly. (See also MediaWiki talk:Common.css/to do#Plainlist.)

If you see issues, please let me know. It's most likely to be the job queue needing to catch up. Izno (talk) 17:58, 22 December 2022 (UTC)

Parsoid specific CSS needed for Cite

Can we get this CSS added to Common.css? This will let backlinks for named refs localized properly when rendering Parsoid HTML.

span[ rel~='mw:referencedBy' ] a:before {
	content: counter( mw-ref-linkback, lower-alpha );
}

See T326467 SSastry (WMF) (talk) 22:12, 7 January 2023 (UTC)

That seems like a helluvan expensive selector. Couldn't we at least add > before a? Nardog (talk) 00:27, 8 January 2023 (UTC)

Yes, that is a good suggestion to make it a child selector with the > since the a tags in this case are indeed direct children of the span. SSastry (WMF) (talk) 01:08, 8 January 2023 (UTC)

Can you point to a sandbox page where this is demonstrated as a problem, such that the problem can be validated as resolved if this is done? Also - what about mobile? Does mobile not have this problem? This smells like a bad hack so far.... — xaosflux ^Talk 01:39, 8 January 2023 (UTC)

Right now, this is not a problem because Cite extension has the CSS for this. However, we have been refactoring that Parsoid-specific CSS for Cite to split it into (a) universal rules (b) language-specific rules (c) wiki-specific rules. This is being done as part of T156350 and T156351.

As part of that refactoring, I ended up moving some enwiki specific rules to the english-language css file (which was meant to be temporary till we moved it to enwiki's Common.CSS), but since en is part of the fallback chain for other languages, it interfered with Parsoid rendering for other languages (ex: hewiki).

In this now-merged gerrit patch, that CSS has been removed to prevent that. So, when that patch is deployed on next week's train, enwiki will no longer have this rule (which had been served so far from the Cite extension). Hence, this request is to move that rule to Common.CSS since this belongs to category (c) above. This only preserves the status quo for mobile rendering as well as rendering for pages when opened in VisualEditor. This is not a new rule being added -- just being moved from the Cite extension to enwiki's Common.css.

As part of T156351 above, we'll probably have additional changes in the future (that task itself is part of the work to make Parsoid HTML be the default rendering).

Does that help explain this request? I will take your comments as feedback that I should have created a separate phab task that articulated this fully rather than lazily piggybacking onto T326467. SSastry (WMF) (talk) 01:54, 8 January 2023 (UTC)

No, I think attaching to that task was fine, you reached out to the right people. Rendering in this area of VE isn't perfect anyway, for example VE still uses the upward arrow while English Wikipedia has that customized to the chevron, and the named references should be bold (and I think italic?); VE's display has neither. I suspect your future requests will find those. I do think it would have been wise not to merge that patch before talking to us rather than after. Izno (talk) 02:01, 8 January 2023 (UTC)

Thanks! That is correct. https://gerrit.wikimedia.org/r/plugins/gitiles/integration/visualdiff/%2B/cc0d73a292ca509b98369a0deeff1edf064b5e90/lib/parsoid.custom_styles.yaml#17 should give you a preview what those other change might look like for enwiki. Those aren't finalized yet but it is close -- it probably needs some additional review of the CSS before we call it all done and ready to ship to Common.css of different wikis. SSastry (WMF) (talk) 02:06, 8 January 2023 (UTC)

Regarding your observation about the ordering of how I handled this, in my mind, this was mostly a rearrangement of where CSS lived vs something new and hence felt it was straightforward. That said, I agree it would still have been prudent to alert you all here first since there was a lot more detail and context here that was not all obvious. Thanks for working with me here! SSastry (WMF) (talk) 03:20, 8 January 2023 (UTC)

The bad hack, according to the Parsing team, is how the Cite extension makes its reference lists today. Parsoid does things differently (and probably, more correctly; we set these qualities in text when they should be in CSS). The biggest issue with the suggested CSS is that it's a slow rule (according to ancient wisdom at least, I'm not totally sure how relevant it is today). It'd be much nicer to see a class attached to the element instead (which has been an issue in another context I think). Izno (talk) 01:58, 8 January 2023 (UTC)

 Done So this is done, though I've added a class to hopefully help with speed (but probably in the wrong spot :( ).

It would be wise for [ rel~='mw:referencedBy' ] to be a class instead. Even the code editor complains about it being a slow selector. See CSS Tricks on the point. SSastry (WMF) Izno (talk) 02:54, 8 January 2023 (UTC)

Thanks for the change and the pointer. I will consult with WMF engineers who know CSS better than me to advise me on this. SSastry (WMF) (talk) 03:07, 8 January 2023 (UTC)

@SSastry (WMF), ah, I remembered where a similar criticism was made recently, the figure transition and another thread on same. Izno (talk) 03:52, 8 January 2023 (UTC)

FWIW, the warning set of the code editor is quite ancient, it keeps warning me that I should include -o- prefixed rules, even though Presto has been dead for almost a decade now. The CSS Tricks page seems to be more or less up-to-date, though. (By the way, according to the CSS Tricks page, adding the extra class didn’t help much, as its in the leftmost position, while selectors are read right-to-left. It may have actually even worsened the situation by adding one more check the browser needs to do – and a pretty slow descendant one.) —Tacsipacsi (talk) 21:17, 8 January 2023 (UTC)

Oh yes, the code editor is ancient, it has warnings about IE6. I haven't seen it suggest vendor specific rules I don't think, though. Izno (talk) 23:04, 8 January 2023 (UTC)

And yeah, both that and the fact there's a span attached to the slow selector. Izno (talk) 23:11, 8 January 2023 (UTC)

I bet modern browsers are optimized to prioritize faster operations like classes and tag names. Nardog (talk) 00:40, 9 January 2023 (UTC)

As mentioned above, selectors are parsed right to left, that is, the <a> tag is matched first, using a "by tag name" index (so that's fast), then its parent is checked to see if it's a span, and then only after both those checks pass will any class or attribute checks be done. So the "rel check" may be "slow" but it is only done on links already matching span > a. If you want to optimize this further (not sure it's necessary) it would be better done by either adding something to the a tag; reducing the number of matches of the span > a could be done by adding an additional attribute check on span or something else like requiring the a to be the :first-child of the span, but in both cases you're counting on the browser to do the "fast" extra check before the "slow" rel check, and I don't think that's guaranteed anywhere. Unless it's attached to the a tag you're likely just slowing things down.

As with any optimization, I'd be hesitant to start adding extra stuff to the selector w/o a reliable benchmark/profile to show it has a meaningful effect. (EDIT: after writing this, I saw that MatmaRex answered more or less the same, but with actual benchmarks and concrete suggestions. Thanks!) C. Scott Ananian (talk) 22:20, 9 January 2023 (UTC)

CSS selector performance

Regarding selector performance: it's actually quite easy to test with a bit of JavaScript. You can go to a large page (I picked San Francisco), open your browser console and run the snippet below. This doesn't necessarily represent how slow the selectors are exactly on a real page, since displaying a whole page is different in many ways from this simple test, but I think it can be used to judge their relative performance.

Conventional wisdom states that CSS selector engines interpret them "right-to-left" – that is, given a selector like span[ rel~='mw:referencedBy' ] a, the engine would first make a list of all nodes that match a and then filter it to only keep those that also have an ancestor node that matches span[ rel~='mw:referencedBy' ]. This is mostly true, but there are some optimizations for special cases. For example, I learned recently that #id tag is optimized to find the node with the ID first (but #id tag, #id2 tag is not!) (phab:T324523#8445297).

I was testing on normal page view HTML (where basically none of the selectors match) and on Parsoid HTML [5] (where they do), the results are very similar in both cases, because – due to the algorithm above – the important part of the selector is the a, requiring the processing of all links on the page. What exactly we check for each link is less important.

So here's a snippet for comparing several of the ideas in the discussion above, and its results:

// Add classes so that we can test equivalent class and attribute selectors
Array.from( document.querySelectorAll( "span[ rel~='mw:referencedBy' ]" ) ).forEach( function ( el ) {
	el.classList.add( 'test-referencedBy' );
} );
Array.from( document.querySelectorAll( "span[ rel~='mw:referencedBy' ] a" ) ).forEach( function ( el ) {
	el.classList.add( 'test-referencedBy-a' );
} );

// List of selectors to compare
var selectors = [
	"span[ rel~='mw:referencedBy' ] a",
	"span[ rel~='mw:referencedBy' ] > a",
	"span.test-referencedBy a",
	"span.test-referencedBy > a",
	".test-referencedBy-a",
	".references span[ rel~='mw:referencedBy' ] > a",
];

// Measure time to execute each selector (1000 times)
for ( var i = 0; i < selectors.length; i++ ) {
	var t = Date.now();
	for ( var j = 0; j < 1000; j++ ) {
		document.querySelectorAll( selectors[ i ] );
	}
	console.log( selectors[ i ] + ': ' + ( Date.now() - t ) + ' ms' );
}

Selector		Notes	Firefox	Chrome	IE 11
	span[ rel~='mw:referencedBy' ] a	Original	561 ms (baseline)	560 ms (baseline)	1053 ms (baseline)
1.	span[ rel~='mw:referencedBy' ] > a	Direct child instead of ancestor	168 ms (~30%)	200 ms (~35%)	569 ms (~50%)
2.	span.test-referencedBy a	Class instead of attribute	554 ms (~100%)	123 ms (~20%)	870 ms (~80%)
3.	span.test-referencedBy > a	Both changes combined	172 ms (~30%)	117 ms (~20%)	507 ms (~50%)
4.	.test-referencedBy-a	Simple class selector	152 ms (~30%)	126 ms (~20%)	398 ms (~40%)
5.	.references span[ rel~='mw:referencedBy' ] > a	Current version from common.css	174 ms (~30%)	143 ms (~25%)	575 ms (~50%)

(Note that these are sums over 1000 attempts – the actual impact of adding this on page load times is thus <1 ms. Still, if we have a few hundred selectors like this, it will become noticeable.)

Findings:

1. Changing the ancestor selector to a direct child selector improves performance on every browser (and it doesn't require any changes to the HTML), so that was a very good suggestion, thanks Nardog! This also makes obvious sense with the right-to-left algorithm – the engine only needs to examine one node, instead of the whole tree.
2. Changing the attribute selector to a class selector produces very varied effects between the browsers – no change on Firefox, minor improvement and IE, and large improvement on Chrome. It seems that Chrome actually uses a different algorithm here, as the timing is basically the same as a simple class selector. (note that we'd have to add the class to every relevant node in HTML to benefit from this)
3. Combining 1 and 2 is only a minor improvement over just 1, and only on Chrome.
4. A simple class selector is the fastest of all, so if we do end up changing the HTML output for this, we should add the class to the node we're actually targeting with the selector.
5. Adding another ancestor selector on the left actually makes the selector slower or has no effect – either due to requiring another check in the right-to-left algorithm, or due to being too complicated for some optimizations.

Hope you enjoy reading this as much as I enjoyed writing it :) Matma Rex talk 01:05, 9 January 2023 (UTC)

Adding the .references looks reasonable without a class to select since it appears to help Chrome without pessimizing Firefox too much (or at all, a half dozen ms relative to the other choice is decidedly in the realm of test error). Otherwise, I get the sense of "modern browser go brr". Might be interesting to see what Edge 18 was like just for curiosity's sake. Izno (talk) 03:43, 9 January 2023 (UTC)

Slight clarification, in case this helps any reader -- in Finding #1 @Matma Rex stated "instead of the whole tree" -- to be clear, an ancestor selector walks *just the parents* from the right hand selector. So it has cost proportional to the "depth of the tree" at that site, *not* the "whole tree". In my experience, the depth of HTML trees tends to be extremely shallow, in CS terms, so a DOM with tens of thousands of nodes will maybe have depth 10. Still, that's 10x the cost of the direct ancestor selector, since it's 10 nodes to check (running up all the way to the root) instead of just one. But it won't be worse on (say) a very large page compared to a very short page; in the wikipedia context the maximum tree depth can be treated as more-or-less constant regardless of the "article size". The exceptions are things (which I've come across on wiki!) like a deeply nested table of (say) the results of all professional field hockey games played in Russia over the past hundred years -- although there again, it's not the "hundred years" which causes performance issues, it's the "deeply nested table" part.

Reinforcing the "trees tend to be pretty shallow" case, note that the difference between #1 and #5 is 5ms for IE and 6ms for Firefox. That's the cost of "walking up the parents to the root and checking for a class". Chrome is the unusual case here, with 57ms extra ms saved when looking at the parents. That's certainly some optimization magic going on -- perhaps they know that .foo tagname is extremely common even though it's pretty much an antipattern, and so they subdivide their tag name index by containing class? See below for more discussion of indexes. In any case, this is speculation, and I'd say that Chrome's behavior very much shouldn't be relied upon, since strictly speaking #5 is asking the CSS engine to do "more work", and the fact that it happens to fall into some narrow optimization bucket is not tied to any inherent properly of the DOM or CSS (again, see discussion of DOM-mandated indexes below) and isn't really guaranteed to persist across time, much less across browser implementations.

Re: finding #2, note that .foo desugars in CSS into [class~="foo"] and Chrome appears to do that desugaring and then optimize ~= in the general case, whereas other browsers are special-casing only the class attribute -- following the example of the DOM, which has classList but no equivalent property giving "~=" behavior for other attributes.

The DOM-mandated "direct indexes" are (1) IDs (getElementById; note performance may degrade significantly if IDs are repeated), (2) tag names (getElementsByTagName) and (3) class (getElementsByClass). So in that sense #4 isn't surprising, since you'll switching to the index-based fast path instead of doing any selector matching at all. You can retain most of this speed if the class is the rightmost thing in the selector since it's fetching the initial starting points from an index; the performance differences between (say) something something .foo and something something foo are related mostly to the size of the "initial starting points" that the index contains, not "tag" vs "class" per se. That is, the benefits of using a class as your starting point are greater for (say) a tags, since there are a lot of them in the by-tag-name index, than they are for (say) figure which there are much less of. If almost every figure has the same class on it, then the starting point size is going to be pretty much the same whether you're using the tag name index or the class name index. (As discussed before, the bane of the tagname index are the extremely common tag names such as a ,div , and span, so it's not surprising that Chrome is doing tricks to subdivide those bins... but that's very much not a standard practice reflected in any DOM API. Note also that for ancestor selectors we mentioned that the speed was proportional to the depth of the tree, which is relatively limited even in large articles, but for the tagname index the number of a tags (for example) very much depends on the size of the article, so tagname selectors will generally (in the absence of optimizations like Chrome's) get slower as your article gets larger.)

You can look at the source of the zest library if you want to see most of these optimizations/performance characteristics in action. :) C. Scott Ananian (talk) 22:48, 9 January 2023 (UTC)

Adding .extendedconfirmed-show classes to MediaWiki:Group-sysop.css

If I'm reading the code correctly, once a user becomes an admin, they can no longer see extendedconfirmed-show classes because crats tend to remove extendedconfirmed from admins upon promotion. The solution to this is probably to add extendedconfirmed-show classes to MediaWiki:Group-sysop.css. If someone wants to draft this up, I think it'd make a decent edit request. Thanks. –Novem Linguae (talk) 17:43, 23 January 2023 (UTC)

Just to confirm: this text is extendedconfirmed-show, and is not displayed to admins currently.

The simplest way to fulfill this request would be to simply copy the CSS from MediaWiki:Group-extendedconfirmed.css (except for the .nonextendedconfirmed-show rule) to Group-sysop.css (since the only CSS there pertains to this class). 「ディノ奴千？！」^{☎ Dinoguy1000} 18:09, 23 January 2023 (UTC)

Are these classes even being used in any significant places? (i.e. can sysop-show just be added as a second class?) — xaosflux ^Talk 18:47, 23 January 2023 (UTC)

It would fix this kind of bug: Template talk:Database report#Update now button. I agree that adding both classes is the workaround. However, is there any downside to fixing this at the .css level, so that folks don't have to remember to add both classes? –Novem Linguae (talk) 19:13, 23 January 2023 (UTC)

Some 40 subject space pages directly. Izno (talk) 19:15, 23 January 2023 (UTC)

I suppose this isn't an issue anywhere unless both classes aren't in there though. (this search) - in which case the page that @Novem Linguae mentioned above seems to be the only one that would need any work. — xaosflux ^Talk 19:25, 23 January 2023 (UTC)

I decided to keep users in my search set as admins do need to enforce on users' pages at times. Izno (talk) 19:34, 23 January 2023 (UTC)

Izno will never be able to enforce this! .... — xaosflux ^Talk 19:56, 23 January 2023 (UTC)

Not really sure why you're giving me a bunch of dots. This would have been the equivalent search. Izno (talk) 20:10, 23 January 2023 (UTC)

@Izno you missed the Easter egg there (Special:Diff/1135292961) - point was that regardless of any css settings, admins could still enforce policies. — xaosflux ^Talk 00:50, 24 January 2023 (UTC)

The issue, as I've pointed out earlier on this page with this series of classes, is what admins can(not) see and so whether they know to. Hence, you made my point for me. :) Izno (talk) 01:02, 24 January 2023 (UTC)

Honestly, we need to look into rolling this set of classes back. Like, all the way, all of them, everywhere. They are not maintainable and they fundamentally disadvantage some set of people where they are used. Izno (talk) 19:14, 23 January 2023 (UTC)

Update for T314318

Please make changes like the following,

https://it.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.css&type=revision&diff=130152006&oldid=127986303

For more information, see mw:Parsoid/Parser_Unification/Media_structure/FAQ

Thanks, Arlolra (talk) 02:01, 2 February 2023 (UTC)

@Arlolra: you are proposing adding that to this section:

/* Minimum thumb width */
.thumbinner {
	min-width: 100px;
}

correct? Can you point to any pages that are poorly presenting output without this in place? — xaosflux ^Talk 17:20, 2 February 2023 (UTC)

 Done Xaosflux, this is an edit preventing potential future issues. I do not know precisely why the original CSS was added. Izno (talk) 17:25, 2 February 2023 (UTC)

@Izno thanks, I was sort of wondering if we even needed the old one anymore. — xaosflux ^Talk 17:34, 2 February 2023 (UTC)

Added October 2007 based on this VPT discussion. I honestly don't think even a 100px image is realistic especially with default thumbs in the 200+ range, but we have |upright= these days so it would be hard to get started measuring. Izno (talk) 17:43, 2 February 2023 (UTC)

Thanks @Izno. Yes, it's for forward compatibility. Arlolra (talk) 17:46, 2 February 2023 (UTC)

Interface-protected edit request on 3 February 2023

Please remove the following style –

/* Fix for hieroglyphs specificity issue in infoboxes ([[phab:T43869]]) */
.mw-parser-output table.mw-hiero-table td {
	vertical-align: middle;
}

This workaround is no longer needed as I have resolved phab:T43869 and the change was deployed in the latest release. This is verified to work in wikis that did not use this workaround, such as jawiki. Compare current page with how it looked before. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:45, 3 February 2023 (UTC)

 Done However, I've left a comment about the patch that was merged on the task, ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ, that you may wish to consider if you want the workaround to be useful into the future. Izno (talk) 06:56, 3 February 2023 (UTC)

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)

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:

1. I've removed the .skin-minerva selector per above.
2. 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).
3. 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)

@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)

toccolours and Module:Category series navigation

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)

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 https://en.wikipedia.org/w/index.php?title=Template:Infobox&action=edit ? 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

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-TemplateStyled tmbox), 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)

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)