e·h·w·Stock post message.svg To-do:

Deprecate?
Awaiting scap
Upstream

Cleaning up message box CSSEdit

I made Special:PermaLink/906004310 (Module:Message box/sandbox) + Special:PermaLink/906003901 (Module:Message box/configuration/sandbox) + Template:Cmbox/styles.css, Template:Ombox/styles.css, Template:Imbox/styles.css, Template:Fmbox/styles.css, Template:Ambox/styles.css, Template:Tmbox/styles.css, Module:Message box/styles.css (All need to protected before we move forward). And now we need to replace the sandbox modules with the main ones and then remove 10KB of not needed CSS from here. That would save hundreds of Terabytes in network (even after minification and compression) per month, not to mention the CPU usage in the servers. I did a similar thing in wikidata, works fine. Is anyone willing to help? ping User:Galobtter per history 23:55, 12 July 2019 (UTC) — Preceding unsigned comment added by Ladsgroup (talkcontribs)

@Ladsgroup: Have you checked to verify that all uses of the CSS in Common.css are invoked only from within the box templates? Also, please consider storing the CSS in the module space since that is where the HTML originates. --Izno (talk) 02:14, 13 July 2019 (UTC)
@Ladsgroup:
  1. cmbox is missing it's first rules.   Done
  2. The compact ambox rules were forgotten
  3. I have no idea if noflip actually does anything in templatestyles (and if this affects transferability to other wikis for that reason).
  4. fmbox is used in editnotices and other MediaWiki messages, we should verify if they even work there (aka is there mw-parser-output wrapping in editnotices..). Suggest leaving these in MediaWiki:Common.css for that reason
  5. There is one css line with .skin-vector etc would break in templatestyles. Move it to Vector.css ??
  6. Izno's point that there might be usages of the classes outside of the module.. We'll have to find those.
That's the potential problems i can spot.—TheDJ (talkcontribs) 14:36, 13 July 2019 (UTC)
Oh, there is another issue. This breaks the stackability of amboxes, as there is now two link elements before every ambox, and that breaks the sibling selector table.ambox + table.ambox . So that should have a variant like: table.ambox + link + link + table.ambox.. We should probably sprinkle a comment next to the module that inserts templatestyles to make sure future editors don't accidentally break that. —TheDJ (talkcontribs) 14:50, 13 July 2019 (UTC)
Attempting to undo these edits indicates no output of mw-parser-output, and that's without edit notices. Anomie? --Izno (talk) 15:01, 13 July 2019 (UTC)
mw:Extension:TemplateStyles#Caveats, first bullet? You may have to manually add a wrapper div for messages used outside the content area if TemplateStyles is to apply. Anomie 18:29, 13 July 2019 (UTC)
User:TheDJ Regarding 1, it's done. Thanks for catching. Regarding 2, Are you sure it's used? I couldn't find it in the module. 3) I don't know either :/ fixing it should be on hands of the person moving it I think 4) It seems they are wrapped, so it's fine I guess 5) I can't do it, I don't have access, can you? 5) yeah, we should check. I can help as much as possible if I'm not alone. 6) I'm not sure but I think they get deduplicated I think, I don't know if I understood you correctly. Ladsgroupoverleg 19:42, 13 July 2019 (UTC)
It is not a question of duplication but simply that we should not regress on display of boxes using the styling but not using the templates which would otherwise wrap those styles. --Izno (talk) 19:51, 13 July 2019 (UTC)
Er, did you misnumber there? with duplicate 5s and a 6 rather than 7? --Izno (talk) 19:54, 13 July 2019 (UTC)
Yup, my bad, sorry. Ladsgroupoverleg 23:32, 13 July 2019 (UTC)
As for skin-vector, that is allowed in TemplateStyles. See the same link that Anomie provided, last bullet of #Caveats. --Izno (talk) 19:51, 13 July 2019 (UTC)
It seems we can't do the compact ambox. Adding them errors with "Invalid or unsupported value for property list-style-image at line 87 character 20" Ladsgroupoverleg 23:35, 13 July 2019 (UTC)
If you're referring to what's currently at lines 876–886 of MediaWiki:Common.css, you should be able to if the images are uploaded to Commons rather than trying to use url(/w/skins/etc...). You'll probably also have to drop the IE<11 hack from line 885. Or if the skin images are really needed, you could file a Phabricator task to add the appropriate URLs to the config. BTW, it seems the MonoBook image being used there was deleted in April. Anomie 16:43, 14 July 2019 (UTC)

I would keep compact ambox for now, what do you think if we put the new styles into the module and slowly and after checks remove the classes from here? Ladsgroupoverleg 19:21, 15 July 2019 (UTC)

Ladsgroup, i think that is the best approach. Just implement and then remove css one template family at a time. Unfortunately, I can't help with that, as I no longer have the required editing rights. — Preceding unsigned comment added by TheDJ (talkcontribs) 07:28, 16 July 2019 (UTC)
I totally understand :( Anyone else willing to help? Ladsgroupoverleg 13:26, 20 July 2019 (UTC)
Will look about doing this after finishing #Hatnote CSS to TemplateStyles. Some notes from quick investigation now and when I previously looked at this:
  • noflip is a function of CSSJanus, [1] would suggest that TemplateStyles does indeed work with that (if it noflip didn't work, that certainly would be a clear bug in TemplateStyles)
  • I think all fmboxes should be wrapped in
    <div class = "mw-parser-output">
    
    since they are almost always used in system messages. Quite a few editnotices use non-fmbox Message boxes too. For that the best solution I think is to make Template:Editnotice load wrap all editnotices in mw-parser-output. Apart from those, 12 system messages use Module:Message box, and some editintro messages, [2], which can be manually fixed to use mw-parser-output as necessary.
  • Then here would be fixing the uses outside of the templates.
  • As TheDJ says, would need to fix the css for the presence of two link elements before every ambox.
  • As Izno says, the css should really be at say Module:Message box/ambox.css, since you can use ambox outside of Template:Ambox.
  • Would need to wait 30 days for all parser outputs to be invalidated after updating Module:Message box, so that all pages with message boxes load the styles. Galobtter (pingó mió) 00:10, 21 July 2019 (UTC)

Let's keep a centralized progress checklist. —TheDJ (talkcontribs) 22:06, 23 July 2019 (UTC)

/w/skins/Vector/images/bullet-icon.png and /w/skins/MonoBook/resources/images/bullet.gif are not part of Mediawiki code baseEdit

Hi, /w/skins/Vector/images/bullet-icon.png is not part anymore of mediawki codebase. At least it leads to a HTTP 404... but this is still part of Common.css. This should be removed or replaced. Kelson (talk) 08:15, 16 July 2019 (UTC)

Same problem with /w/skins/MonoBook/resources/images/bullet.gif Kelson (talk) 08:16, 16 July 2019 (UTC)
  • Looks like this is left over from 4 years ago - as there is no file, should be safe to remove - does anyone have any other comments on this? — xaosflux Talk 15:08, 16 July 2019 (UTC)
    Anomie actually noted the vector item in the ambox discussion above. That one should be removed. However, there is a replacement for the Monobook one at '/w/skins/MonoBook/resources/images/bullet.svg'. Speaking of which, that one should probably select for skin-monobook. --Izno (talk) 16:27, 16 July 2019 (UTC)
  • OK, glad we've got some people looking at this, I'm turning off the ER for now (that I turned on) - need an explicit sample code worked out first (e.g. Change "xxx" to "yyy"). — xaosflux Talk 17:16, 16 July 2019 (UTC)
  • Removed png fallback. Png image was removed recently per phab:T220327. Looks like that monobook specific styling should be scoped to skin-monobook (or moved to MediaWiki:Monobook.css?) and updated to use svg. Galobtter (pingó mió) 00:39, 21 July 2019 (UTC)
    I would fix the selector and the image and then work toward moving it to TStyles per the above thread. --Izno (talk) 04:42, 26 July 2019 (UTC)

Thanks for removing bullet-icon.png... but what about bullet.gif? Do we (should) have a phabricator ticket about that? Kelson (talk) 15:20, 21 July 2019 (UTC)

No, should use bullet.svg instead. Galobtter (pingó mió) 20:20, 21 July 2019 (UTC)
Why you don't fix it then? Kelson (talk) 06:47, 24 July 2019 (UTC)

/w/skins/MonoBook/resources/images/bullet.gif is not part of Mediawiki code baseEdit

Hi, /w/skins/Vector/images/bullet-icon.gif (only the png problem has been fixed in previous discussion) is not part anymore of mediawki codebase. At least it leads to a HTTP 404... but this is still part of Common.css. This should be removed or replaced. Kelson (talk) 12:29, 3 August 2019 (UTC)

Change

	list-style-image: url(/w/skins/MonoBook/resources/images/bullet.gif);

to

	list-style-image: url(/w/skins/MonoBook/resources/images/bullet.svg);

in the

.compact-ambox table .mbox-text-span {
	display: list-item;
	line-height: 1.5em;
	list-style-type: square;
	list-style-image: url(/w/skins/MonoBook/resources/images/bullet.gif);
}

per the above discussion. This is the more conservative change. I expect per the ambox template stylization that these will eventually leave Commons.css, and possibly be selective for other skins, but that can be Down The Road. --Izno (talk) 19:09, 3 August 2019 (UTC)

On an aside, I'm pretty sure the reason that block does not restrict itself to a certain skin is so that all the skins have a fallback which includes some styling. Otherwise, it would be as-if Modern or Timeless had no styling at all on the point. --Izno (talk) 19:12, 3 August 2019 (UTC)
Yeah; and modern uses the same bullet image too. Galobtter (pingó mió) 01:10, 5 August 2019 (UTC)
  Donexaosflux Talk 14:29, 4 August 2019 (UTC)

Interface-protected edit request on 19 July 2019Edit

Please remove

/* For template documentation */
/* TemplateStyles */
.template-documentation {
	clear: both;
	margin: 1em 0 0 0;
	border: 1px solid #a2a9b1;
	background-color: #ecfcf4;
	padding: 1em;
}

I have added the CSS to the module itself (not using TemplateStyles though) - see Special:Permalink/906971298#Moving CSS. Thanks, --DannyS712 (talk) 15:21, 19 July 2019 (UTC)

Oppose: discussion at Template talk:Documentation. --RexxS (talk) 16:57, 19 July 2019 (UTC)
  Not done as there is an ongoing discussion right now, feel free to reactivate when resolved. — xaosflux Talk 17:20, 19 July 2019 (UTC)
Quick note that once this is reimplemented in TemplateStyles per the discussion there, you'd have to wait a few days or so for all the pages that transclude the module to update before the styles can be removed from common.css Galobtter (pingó mió) 20:54, 19 July 2019 (UTC)

Hatnote CSS to TemplateStylesEdit

Per a search, the only uses of the class hatnote outside of Module:Hatnote are these and these. These are mostly modules that use it to show a message in preview for which I've created Module:Preview warning message. So once those modules are updated to use Module:Preview warning message, then we can update Module:Hatnote from Module:Hatnote/sandbox to use Module:Hatnote/styles.css, and after waiting, can remove the hatnote styles from common.css. Posting here in case anyone knows if there is anything else that would need fixing. (regarding interface messages, would just have to fix MediaWiki:Wantedpages-summary. There's also a couple of edit notices using {{hatnote}}, but I think all edit notices should be wrapped in mw-parser-output by changing Template:Editnotice load) Galobtter (pingó mió) 00:09, 21 July 2019 (UTC)

Template:Editnotice load has been updated. — xaosflux Talk 22:08, 23 July 2019 (UTC)
  • Honestly, all those module uses of hatnote look like misuses, and I would advocate instead for their own CSS rather than loading the entire hatnote template and styles. Hatnotes are for navigation, not for errors. <div class="template-preview-error error"> would be vastly more appropriate. --Izno (talk) 04:47, 26 July 2019 (UTC)

Navbar UL: should it be inline-block?Edit

About a year ago, I noticed that the tables at 2018 FIFA World Cup looked ugly because Safari would insert a line break after the ul {{navbar}}. Now, .navbar ul {…display:inline-block} fixes this; so, shouldn't this be the case? inline-block is accepted by IE8+, so we should be fine unless someone is using Wikipedia on a very old POS system. Sceptre (talk) 17:48, 16 September 2019 (UTC)

@Sceptre: is this a single-page issue? Can it be fixed more locally with a template style? — xaosflux Talk 03:20, 29 September 2019 (UTC)
It happens when Module:Sports table is invoked with an option for navbar links, and I suspect a lot of other places where the navbar module is invoked with the option for brackets. At that point, it becomes a case of pick-your-poison where you do the edit, either on Common.css or Module:Navbar. I imagine the least intrusive (and more sensible; it doesn’t make sense to declare a style in a .css then locally override it on every instance) thing to do would a Common.css edit, ironically. Sceptre (talk) 04:28, 29 September 2019 (UTC)
Sceptre, to confirm, you want to change
.navbar ul {
display: inline;
white-space: nowrap;
}
to
.navbar ul {
display: inline-block;
white-space: nowrap;
}
?
I think it would be useful if someone else confirmed the issue in Safari and that the above fixes it (since I have no access to a machine running Safari). Galobtter (pingó mió) 23:07, 10 October 2019 (UTC)
I do indeed see this on Safari on my machine, and moving to inline-block does indeed solve it. I'm not entirely sure why this is all here and not in the modules, but w/e. I haven't tested or checked if it mucks anything up elsewhere, though. Why does Safari treat this differently than other browsers? ~ Amory (utc) 18:27, 13 October 2019 (UTC)
Yeah, I never got around to moving the styles to the module from common.css. Maybe I'll do that now. https://github.com/mathjax/MathJax/issues/1982 seems to be the same issue? Galobtter (pingó mió) 18:59, 13 October 2019 (UTC)
Consider whether a slight bug is relevant. --Izno (talk) 02:37, 11 October 2019 (UTC)
IE8 is in the basic support category, though, so maybe not a huge issue. ~ Amory (utc) 15:31, 13 October 2019 (UTC)
Return to "Common.css" page.