Jump to content

MediaWiki talk:Common.css

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Xaosflux (talk | contribs) at 21:52, 11 June 2021 (→‎pblock-style: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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)[reply]

I saw this bug happen again on this article. -- Great Brightstar (talk) 14:29, 7 April 2021 (UTC)[reply]
@Izno and Jon (WMF): thought you'd want to look at this. — xaosflux Talk 14:15, 6 April 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
 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)[reply]
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)[reply]
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)[reply]
I reported at phab:T283462. -- Great Brightstar (talk) 15:53, 23 May 2021 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
And Alexa also, I'm sure. Izno (talk) 22:36, 29 April 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

That is not how CSS works. You will need JavaScript for something like that. Izno (talk) 14:48, 17 May 2021 (UTC)[reply]
@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)[reply]

Unexpected effects

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

Does this mean that WP:TSTYLE is ruled out as cause? -DePiep (talk) 15:12, 17 May 2021 (UTC)[reply]
OK, your reply there crossed so I'll follow over there. -DePiep (talk) 15:14, 17 May 2021 (UTC)[reply]

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)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.css&oldid=1028105567"