Writ Keeper (talk | contribs) |
|||
(46 intermediate revisions by 19 users not shown) | |||
Line 9: | Line 9: | ||
|archive = MediaWiki talk:Common.css/Archive %(counter)d |
|archive = MediaWiki talk:Common.css/Archive %(counter)d |
||
}} |
}} |
||
{{ |
{{talk header|search=yes|archive_age=90|archive_bot=lowercase sigmabot III}} |
||
{{to do|small=yes|inner= |
{{to do|small=yes|inner= |
||
* [[MediaWiki talk:Common.css/to do|TemplateStyles]] |
* [[MediaWiki talk:Common.css/to do|TemplateStyles]] |
||
}} |
}} |
||
== Applying a style for the Vector 2022 == |
|||
== Removal of .hlist == |
|||
{{tracked|T354235}} |
|||
Hi, in Vector 2022, if we want to select title of an article and we accidentally extend the selected area to select Table of Content button with the icon [[file:Ic toc 48px.svg]], then the text copied in clipboard would wrongly be (for example for the article "[[Wikipedia]]"): |
|||
I've just now removed hlist from where it was implicated in Common.css, Mobile.css, and Minerva.css as part of [[MediaWiki talk:Common.css/to do#description|conversion to TemplateStyles]]. If you see issues please leave a comment here. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 21:26, 11 January 2023 (UTC) |
|||
<syntaxhighlight lang = "text"> |
|||
Toggle the table of contents |
|||
Wikipedia |
|||
</syntaxhighlight> |
|||
This is not the intended clipboard and the first line is not required, i.e., only "Wikipedia" as the title of the article is enough and the text "Toggle the table of contents" makes the clipboard data wrong. |
|||
The solution to this problem could be applying this style: |
|||
:@[[User:Izno|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 <code>.mw-parser-output</code> - is there an easy way to fix that? [[User:the wub|the wub]] [[User_talk:The wub|<span style="color: #080;">"?!"</span>]] 21:41, 11 January 2023 (UTC) |
|||
<syntaxhighlight lang = "css"> |
|||
::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. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 21:42, 11 January 2023 (UTC) |
|||
.vector-page-titlebar-toc { |
|||
::And fixed. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 21:44, 11 January 2023 (UTC) |
|||
-webkit-user-select: none; /* Safari */ |
|||
:::That was quick, thanks! [[User:the wub|the wub]] [[User_talk:The wub|<span style="color: #080;">"?!"</span>]] 21:54, 11 January 2023 (UTC) |
|||
-ms-user-select: none; /* IE 10 and IE 11 */ |
|||
: One of the issues that I've stumbled upon is [[Special:Permalink/907221455|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. —[[User:Andrybak|andrybak]] ([[User talk:Andrybak|talk]]) 03:07, 15 March 2023 (UTC) |
|||
user-select: none; /* Standard syntax */ |
|||
::@[[User:Andrybak|Andrybak]], if you're going to do it, use the template version, either as in 1144679174, or with start/end version, or with {{tl|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. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 05:54, 15 March 2023 (UTC) |
|||
</syntaxhighlight> |
|||
I have tested that code in my css page at [[User:Hooman Mallahzadeh/common.css]] and it prevents this behavior very well. |
|||
Finally, I should note that this unexpected behavior in clipboard functionality is frequently occurred for me both in English Wikipedia and in Persian Wikipedia. Thanks, [[User:Hooman Mallahzadeh|Hooman Mallahzadeh]] ([[User talk:Hooman Mallahzadeh|talk]]) 04:30, 2 January 2024 (UTC) |
|||
== Request for edit to .flagicon in [[MediaWiki:Mobile.css]] == |
|||
:Please file a task upstream. You do not need to support IE. You will also want to test with an accessibility agent or two. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 21:31, 2 January 2024 (UTC) |
|||
{{edit fully-protected|MediaWiki:Mobile.css|answered=yes}} |
|||
::How to file a task upstream in case you don't know how to do it: [https://phabricator.wikimedia.org/maniphest/task/edit/form/43/ Click here], fill it out, and tag it Desktop Improvements (Vector 2022). –[[User:Novem Linguae|<span style="color:blue">'''Novem Linguae'''</span>]] <small>([[User talk:Novem Linguae|talk]])</small> 23:59, 2 January 2024 (UTC) |
|||
:::I made a task for it at T354235. Thanks, [[User:Hooman Mallahzadeh|Hooman Mallahzadeh]] ([[User talk:Hooman Mallahzadeh|talk]]) 05:27, 3 January 2024 (UTC) |
|||
::::@[[User:Izno|Izno]]@[[User:Novem Linguae|Novem Linguae]] The task is not resovled yet and may be not resolved in near future. But we can apply that style here. Would you please apply this styles [[MediaWiki:Common.css|here]]? Thanks, [[User:Hooman Mallahzadeh|Hooman Mallahzadeh]] ([[User talk:Hooman Mallahzadeh|talk]]) 06:19, 6 May 2024 (UTC) |
|||
== the checker background == |
|||
Change from: |
|||
<syntaxhighlight lang="css"> |
<syntaxhighlight lang="css"> |
||
@media screen { |
|||
.flagicon img { |
|||
/* Put a chequered background behind images, only visible if they have transparency, |
|||
min-width: 25px; |
|||
* except on main, user, and portal namespaces |
|||
} |
|||
*/ |
|||
body:not(.ns-0):not(.ns-2):not(.ns-100) .gallerybox .thumb img { |
|||
background: #fff url(//upload.wikimedia.org/wikipedia/commons/5/5d/Checker-16x16.png) repeat; |
|||
} |
|||
</syntaxhighlight> |
</syntaxhighlight> |
||
This is, apparently, being loaded for all pages on the English Wikipedia. While the PNG is only 81 bytes, it does necessitate that the browser make a second request to load the resource. This is kind of inefficient, deshou? |
|||
to: |
|||
Instead, we could do this: |
|||
<syntaxhighlight lang="css"> |
<syntaxhighlight lang="css"> |
||
@media screen { |
|||
.content .flagicon a > img, .content .flagicon noscript > img { |
|||
/* Put a chequered background behind images, only visible if they have transparency, |
|||
max-width: none !important; |
|||
* except on main, user, and portal namespaces |
|||
} |
|||
*/ |
|||
body:not(.ns-0):not(.ns-2):not(.ns-100) .gallerybox .thumb img { |
|||
background: #fff url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAAAAAA6mKC9AAAAGElEQVQYV2N4DwX/oYBhgARgDJjEAAkAAEC99wFuu0VFAAAAAElFTkSuQmCC') repeat; |
|||
} |
|||
</syntaxhighlight> |
</syntaxhighlight> |
||
Now, <code>//upload.wikimedia.org/wikipedia/commons/5/5d/Checker-16x16.png</code> is 63 bytes, and <code>data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAAAAAA6mKC9AAAAGElEQVQYV2N4DwX/oYBhgARgDJjEAAkAAEC99wFuu0VFAAAAAElFTkSuQmCC</code> is 130, so we are adding another 67 bytes to the stylesheet, but we're eliminating an 81-byte PNG file, so overall we save 14 bytes -- and we also save the necessity of a whole extra request to load the PNG. |
|||
Right? Or no? <b style="font-family: monospace; color:#E35BD8">[[User:JPxG|<b style="color:#029D74">jp</b>]]×[[Special:Contributions/JPxG|<b style="color: #029D74">g</b>]][[User talk:JPxG|🗯️]]</b> 04:10, 22 February 2024 (UTC) |
|||
Introduced by [[phab:T116318]] and, from reading it, I have deduced the actual point of introducing <code>.flagicon img</code> was to override this: |
|||
:Not 100% sure on upstream (including client-side) caching optimizations; suspect the PNG is more likely to stay cached there? — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 10:18, 22 February 2024 (UTC) |
|||
::I don’t know if any of them is cached longer, but there are multiple groups of people, and not everyone would benefit from the inlining: |
|||
::* People who regularly visit Wikipedia (many people). They have everything cached, inlining wouldn’t matter much for them. |
|||
::* People who read Wikipedia articles every now and then (most people). They currently download Common.css when they visit Wikipedia, and then <em>don’t</em> download the image, as the rule never applies in article space (browsers won’t download images just because they see them in the stylesheet). Their bandwidth usage would <em>increase</em> if the image was inlined. |
|||
::* People who visit <em>non-mainspace</em> pages every now and then (relatively few people). They currently download Common.css when they visit Wikipedia, and then <em>may</em> download the image if they view a non-mainspace gallery. Their bandwidth usage may <em>decrease</em> (or increase, if they don’t view such galleries) if the image is inlined. |
|||
::Given that the second group is far more populous than the third one, I think inlining the image would be a net loss. —[[User:Tacsipacsi|Tacsipacsi]] ([[User talk:Tacsipacsi|talk]]) 16:34, 25 February 2024 (UTC) |
|||
== Interface-protected edit request on 20 March 2024 == |
|||
{{edit interface-protected|MediaWiki:Mobile.css|MediaWiki:Common.css|answered=yes}} |
|||
Please add this to <code><nowiki>Mobile.css</nowiki></code>: |
|||
<syntaxhighlight lang="css"> |
<syntaxhighlight lang="css"> |
||
.mobileonly { |
|||
.content a > img, .content noscript > img { |
|||
display: inline; |
|||
max-width: 100% !important; |
|||
height: auto !important; |
|||
} |
} |
||
</syntaxhighlight> |
</syntaxhighlight> |
||
and the following to <code><nowiki>Common.css</nowiki></code>: |
|||
25px is too much for a lot of flags. [[User:SocietyBox|SocietyBox]] ([[User talk:SocietyBox|talk]]) 14:09, 1 August 2023 (UTC) |
|||
<syntaxhighlight lang="css"> |
|||
.mobileonly { |
|||
display: none; |
|||
} |
|||
</syntaxhighlight> |
|||
While <code><nowiki>.nomobile</nowiki></code> is defined well outside of these files, <code><nowiki>.mobileonly</nowiki></code> (which is present in Fandom wikis) is not. This serves as a switch to allow content to be shown on mobile only while being hidden on desktop. [[User:Awesome Aasim|Awesome]] [[User_talk:Awesome Aasim|Aasim]] 19:17, 20 March 2024 (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. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 18:38, 1 August 2023 (UTC) |
|||
:[[File:Red information icon with gradient background.svg|20px|link=|alt=]] '''Not done for now:''' please establish a [[Wikipedia:Consensus|consensus]] for this alteration '''[[Wikipedia:Edit requests|before]]''' using the {{Tlx|Edit interface-protected}} template.<!-- Template:EIp --> I don't see a reason for this. And moreover nomobile should also be avoided. If a specific element absolutely must not be displayed at a certain resolution, then it can use TemplateStyles and a media query. (Such cases probably honestly don't exist.) Ignoring both of those, Mobile.css's days are numbered. See the recent announcement in tech news. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 21:01, 20 March 2024 (UTC) |
|||
::@[[User:Izno|Izno]] I am not finding where that information is. A link please? [[User:Awesome Aasim|Awesome]] [[User_talk:Awesome Aasim|Aasim]] 17:52, 21 March 2024 (UTC) |
|||
:::Ah, not announced yet anywhere. [[phab:T248416]] [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 05:58, 22 March 2024 (UTC) |
|||
:Plus, using the <code>display: inline</code> declaration to reverse the effect of a <code>display: none</code> is not always correct: [//www.w3.org/TR/CSS21/visuren.html#display-prop the <code>display:</code> property] allows several values, some of which are significant for structured block elements such as lists and tables. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] 🌹 ([[User talk:Redrose64|talk]]) 22:10, 20 March 2024 (UTC) |
|||
:Pages should be written agnostic of what the browser will be. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 18:10, 21 March 2024 (UTC) |
|||
== Interface-protected edit request on 11 April 2024 == |
|||
::@[[User:Izno|Izno]] The override is only needed when <code>skins.minerva.base.styles</code> is loaded. I don't know how to add that restriction if I were to add it to [[Template:Flagicon/styles.css]]. [[User:SocietyBox|SocietyBox]] ([[User talk:SocietyBox|talk]]) 20:59, 3 August 2023 (UTC) |
|||
{{edit interface-protected|MediaWiki:Minerva.css|answered=yes}} |
|||
::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. [[User:SocietyBox|SocietyBox]] ([[User talk:SocietyBox|talk]]) 21:21, 3 August 2023 (UTC) |
|||
Replace |
|||
:::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 :) |
|||
<syntaxhighlight lang="css">.flagicon img { |
|||
:::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. |
|||
min-width: 25px; |
|||
:::Some comments about the TemplateStyles page since I said I would follow up: |
|||
}</syntaxhighlight> |
|||
:::# I've removed the .skin-minerva selector per above. |
|||
with |
|||
:::# 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). |
|||
<syntaxhighlight lang="css">.flagicon img { |
|||
:::# I've removed noscript because that's for some other part of the software that isn't relevant to flag icons. |
|||
min-width: 23px; |
|||
:::[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 21:25, 3 August 2023 (UTC) |
|||
}</syntaxhighlight> |
|||
The default size for flag icons is 23px, so setting the min-width to 25px is causing all flag icons to be larger than they should be. This is problematic for [[Template:Flag data]] which takes advantage of the fact that 25px is 2px larger than the default size of 23px. Additionally, using 23px was the proposed fixed for [[phab:T116318]]. <span class="nowrap">– [[User:BrandonXLF|<span style="color:blue;">Brandon</span><span style="color:green;">XLF</span>]] ([[User talk:BrandonXLF|talk]])</span> 18:43, 11 April 2024 (UTC) |
|||
@[[User:Izno|Izno]] Requesting this change instead: |
|||
: {{done}} [[User:Pppery|* Pppery *]] [[User talk:Pppery|<sub style="color:#800000">it has begun...</sub>]] 15:36, 13 April 2024 (UTC) |
|||
== Interface-protected edit request on 5 May 2024 == |
|||
'''Diff:''' |
|||
{{TextDiff |
|||
|.flagicon img { |
|||
min-width: 25px; |
|||
}|.flagicon a > img, a.flagicon > img { |
|||
min-width: 25px; |
|||
}|}} |
|||
{{edit interface-protected|MediaWiki:Common.css|answered=yes}} |
|||
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. [[User:SocietyBox|SocietyBox]] ([[User talk:SocietyBox|talk]]) 20:04, 4 August 2023 (UTC) |
|||
Can you please add this to the common.css? |
|||
<syntaxhighlight lang="css">body { font-family: serif; }</syntaxhighlight> |
|||
That is the [[serif]] font, and it is the font for nearly all the encyclopedias. Additionally, it constitutes the font of an actual encyclopedia. Thank you. [[Special:Contributions/143.44.165.227|143.44.165.227]] ([[User talk:143.44.165.227|talk]]) 02:17, 5 May 2024 (UTC) |
|||
:[[File:Red information icon with gradient background.svg|20px|link=|alt=]] '''Not done for now:''' please establish a [[Wikipedia:Consensus|consensus]] for this alteration '''[[Wikipedia:Edit requests|before]]''' using the {{Tlx|Edit interface-protected}} template.<!-- Template:EIp --> – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 02:52, 5 May 2024 (UTC) |
|||
== Interface-protected edit request on 30 May 2024 == |
|||
:@[[User:Izno|Izno]] want to deal with this? I was going to nd it as stale otherwise. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 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. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 16:37, 8 October 2023 (UTC) |
|||
::: {{not done}} per Xaosflux - stale, contested request. [[User:Pppery|* Pppery *]] [[User talk:Pppery|<sub style="color:#800000">it has begun...</sub>]] 22:28, 10 October 2023 (UTC) |
|||
{{edit interface-protected|MediaWiki:Common.css|answered=yes}} |
|||
== Infobox and TemplateStyles == |
|||
Please remove the background on `mw-warning-with-logexcerpt.mw-warning-with-logexcerpt.mw-warning-with-logexcerpt, div.mw-lag-warn-high, div.mw-cascadeprotectedwarning, div#mw-protect-cascadeon {` or replace it with a CSS variable that can adapt to dark mode. I am not sure why this is styled as an error, when the message itself is a warning and has a triangle - so the color is confusing so I personally would vote for removing it or moving it to [[MediaWiki:Timeless.css]] etc.. |
|||
{{ping|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 ([https://en.wikipedia.org/w/index.php?title=Army_of_Sambre_and_Meuse&safemode=1 Example]) That seems to be because all the rules live in [[MediaWiki:Common.css]] rather than template styles. |
|||
I have a [https://meta.wikimedia.org/wiki/User:Jdlrobson/global.js global script] for forcing dark mode on all pages, and when dark mode gets enabled on the editor, this will break. It would be good to fix this before that happens! Thanks in advance! |
|||
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 ? [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 17:02, 27 September 2023 (UTC) |
|||
Example: https://en.wikipedia.org/w/index.php?title=Template:Sidebar_with_collapsible_lists&action=edit (with dark mode global script). <span style="background:white; color: black;">🐸</span> [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 04:46, 31 May 2024 (UTC) |
|||
:@[[User:Jdlrobson|Jdlrobson]], [[MediaWiki talk:Common.css/to do#Infobox|no]]. There are 5000+ pages to clean and no one has been jumping up and down to work on them. [[User:Izno|Izno]] ([[User talk: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 <pre><templatestyles src="Template:Infobox.css" /></pre> 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 :-) [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 20:18, 27 September 2023 (UTC) |
|||
:::{{tq|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 {{tl|infobox awards list}} that could use a bot. When [[Wikipedia:Bot requests/Archive 84#Hand-made Template%3AInfobox awards list|I inquired on the bot requests page]] (and [[Template talk:Infobox awards list#600 pages which use a handmade version of this|an earlier feeler]]), crickets. [[User:Izno|Izno]] ([[User talk: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. [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 20:03, 28 September 2023 (UTC) |
|||
:::::{{tq|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 {{em|removing}} the additional TemplateStyles calls when all is said and actually done. |
|||
:::::{{tq|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 {{em|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. [[User:Izno|Izno]] ([[User talk: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. [[User:Jdlrobson|Jdlrobson]] ([[User talk: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. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 19:42, 3 October 2023 (UTC) |
|||
::::::::Thanks! That's super helpful as a starting point. [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 17:50, 5 October 2023 (UTC) |
|||
:::::::::@[[User:Izno|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? [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 18:58, 3 November 2023 (UTC) |
|||
::::::::::@[[User:Jdlrobson|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-{{tl|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:Search]]s 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 <code>messagebox</code> and now-TemplateStyled <code>tmbox</code>), 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 (<code>/infobox/</code> catches <code><nowiki>{{infobox</nowiki></code>, 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 {{tl|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. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 21:12, 3 November 2023 (UTC) |
|||
:Also, [[phab:T343131#9140322|apparently]] templatestyles have been causing some performance issues recently when used on almost every single page. That might be something to consider here. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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.) [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 19:47, 27 September 2023 (UTC) |
|||
:This is styled as an error because that's the importance we assign it, not the arbitrary importance assigned to it by the WMF at a date long after our modification was added. Stjn had a similar block in the ru.wp CSS which he modified to the CSS at [[:ru:MediaWiki:Common.css#L-111]], which I just haven't had a chance to test. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 18:52, 31 May 2024 (UTC) |
|||
== toccolours and Module:Category series navigation == |
|||
::@[[User:Izno|Izno]] If the goal is to style this as an error, it would be better to use the Codex design token to ensure accessibility with links etc and get the night mode equivalent for consistency: |
|||
::<syntaxhighlight lang=css> |
|||
background-color: var(--background-color-error-subtle); |
|||
</syntaxhighlight> |
|||
::While I don't think it looks great, having a warning icon with a red color, if this style needs to be retained as is, without the CSS variable, you need to also add a rule for text color - like what I'm doing in [[User:Jdlrobson/common.css]]. Without that, the interface will become unusable in dark mode. |
|||
::<syntaxhighlight lang=css> |
|||
/* https://en.wikipedia.org/wiki/MediaWiki_talk:Common.css#Applying_a_style_for_the_Vector_2022 */ |
|||
.mw-warning-with-logexcerpt.mw-warning-with-logexcerpt.mw-warning-with-logexcerpt, div.mw-lag-warn-high, div.mw-cascadeprotectedwarning, div#mw-protect-cascadeon { |
|||
color: black; |
|||
} |
|||
</syntaxhighlight> <span style="background:white; color: black;">🐸</span> [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 15:54, 8 June 2024 (UTC) |
|||
::: {{done}} using the error-subtle design token, and keeping the existing color as fallback since the variable doesn't seem to be defined at all on Vector legacy which I use. [[User:Pppery|* Pppery *]] [[User talk:Pppery|<sub style="color:#800000">it has begun...</sub>]] 01:35, 18 June 2024 (UTC) |
|||
== Edit request 18 June 2024 == |
|||
{{Edit interface-protected|MediaWiki:Minerva.css|answered=yes}} |
|||
Change <code>--color-link</code> to <code>--color-progressive</code> at lines 144 and 132, as the CSS variable <code>--color-link</code> does not exist. |
|||
<pre>html.skin-theme-clientpref-night .infobox a { |
|||
color: var( --color-link ) !important; |
|||
} |
|||
@media (prefers-color-scheme: dark) { |
|||
... |
|||
html.skin-theme-clientpref-os .infobox a { |
|||
color: var( --color-link ) !important; |
|||
} |
|||
}</pre> |
|||
-> |
|||
<pre>html.skin-theme-clientpref-night .infobox a { |
|||
color: var( --color-progressive ) !important; |
|||
} |
|||
@media (prefers-color-scheme: dark) { |
|||
I saw that "toccolours" is [[MediaWiki_talk:Common.css/to do#toccolours|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 @[[User:Tom.Reding|Tom.Reding]]. [[User:Gonnym|Gonnym]] ([[User talk: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! <b>~</b> <span style="font-family:Monotype Corsiva; font-size:16px;">[[User:Tom.Reding|Tom.Reding]] ([[User talk:Tom.Reding|talk]] ⋅[[WP:DGAF|dgaf]])</span> 11:42, 31 October 2023 (UTC) |
|||
html.skin-theme-clientpref-os .infobox a { |
|||
: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.) |
|||
color: var( --color-progressive ) !important; |
|||
: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.) [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 17:49, 31 October 2023 (UTC) |
|||
} |
|||
}</pre> |
|||
[[User:I Am Andumé|Andumé ]] ([[User talk:I Am Andumé|talk]]) 01:22, 18 June 2024 (UTC) |
|||
:{{ping|Jon (WMF)}} since you put it there I believe. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 01:26, 18 June 2024 (UTC) |
|||
:: I suspect what was meant was "color:LinkText", but I'll let Jon comment. [[User:Pppery|* Pppery *]] [[User talk:Pppery|<sub style="color:#800000">it has begun...</sub>]] 01:42, 18 June 2024 (UTC) |
|||
:::Switching --color-link to --color-progressive makes sense - we've been moving away from color-link to color-progressive. Thanks for flagging this! [[User:Jon (WMF)|Jon (WMF)]] ([[User talk:Jon (WMF)|talk]]) 16:39, 18 June 2024 (UTC) |
|||
::::{{done}} [[User:Writ Keeper|Writ Keeper]] [[User Talk: Writ Keeper|⚇]][[Special:Contributions/Writ_Keeper|♔]] 16:50, 18 June 2024 (UTC) |
Revision as of 16:50, 18 June 2024
Applying a style for the Vector 2022
Hi, in Vector 2022, if we want to select title of an article and we accidentally extend the selected area to select Table of Content button with the icon , then the text copied in clipboard would wrongly be (for example for the article "Wikipedia"):
Toggle the table of contents
Wikipedia
This is not the intended clipboard and the first line is not required, i.e., only "Wikipedia" as the title of the article is enough and the text "Toggle the table of contents" makes the clipboard data wrong.
The solution to this problem could be applying this style:
.vector-page-titlebar-toc {
-webkit-user-select: none; /* Safari */
-ms-user-select: none; /* IE 10 and IE 11 */
user-select: none; /* Standard syntax */
}
I have tested that code in my css page at User:Hooman Mallahzadeh/common.css and it prevents this behavior very well.
Finally, I should note that this unexpected behavior in clipboard functionality is frequently occurred for me both in English Wikipedia and in Persian Wikipedia. Thanks, Hooman Mallahzadeh (talk) 04:30, 2 January 2024 (UTC)
- Please file a task upstream. You do not need to support IE. You will also want to test with an accessibility agent or two. Izno (talk) 21:31, 2 January 2024 (UTC)
- How to file a task upstream in case you don't know how to do it: Click here, fill it out, and tag it Desktop Improvements (Vector 2022). –Novem Linguae (talk) 23:59, 2 January 2024 (UTC)
- I made a task for it at T354235. Thanks, Hooman Mallahzadeh (talk) 05:27, 3 January 2024 (UTC)
- @Izno@Novem Linguae The task is not resovled yet and may be not resolved in near future. But we can apply that style here. Would you please apply this styles here? Thanks, Hooman Mallahzadeh (talk) 06:19, 6 May 2024 (UTC)
- I made a task for it at T354235. Thanks, Hooman Mallahzadeh (talk) 05:27, 3 January 2024 (UTC)
- How to file a task upstream in case you don't know how to do it: Click here, fill it out, and tag it Desktop Improvements (Vector 2022). –Novem Linguae (talk) 23:59, 2 January 2024 (UTC)
the checker background
@media screen {
/* Put a chequered background behind images, only visible if they have transparency,
* except on main, user, and portal namespaces
*/
body:not(.ns-0):not(.ns-2):not(.ns-100) .gallerybox .thumb img {
background: #fff url(//upload.wikimedia.org/wikipedia/commons/5/5d/Checker-16x16.png) repeat;
}
This is, apparently, being loaded for all pages on the English Wikipedia. While the PNG is only 81 bytes, it does necessitate that the browser make a second request to load the resource. This is kind of inefficient, deshou?
Instead, we could do this:
@media screen {
/* Put a chequered background behind images, only visible if they have transparency,
* except on main, user, and portal namespaces
*/
body:not(.ns-0):not(.ns-2):not(.ns-100) .gallerybox .thumb img {
background: #fff url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAAAAAA6mKC9AAAAGElEQVQYV2N4DwX/oYBhgARgDJjEAAkAAEC99wFuu0VFAAAAAElFTkSuQmCC') repeat;
}
Now, //upload.wikimedia.org/wikipedia/commons/5/5d/Checker-16x16.png
is 63 bytes, and data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAAAAAA6mKC9AAAAGElEQVQYV2N4DwX/oYBhgARgDJjEAAkAAEC99wFuu0VFAAAAAElFTkSuQmCC
is 130, so we are adding another 67 bytes to the stylesheet, but we're eliminating an 81-byte PNG file, so overall we save 14 bytes -- and we also save the necessity of a whole extra request to load the PNG.
Right? Or no? jp×g🗯️ 04:10, 22 February 2024 (UTC)
- Not 100% sure on upstream (including client-side) caching optimizations; suspect the PNG is more likely to stay cached there? — xaosflux Talk 10:18, 22 February 2024 (UTC)
- I don’t know if any of them is cached longer, but there are multiple groups of people, and not everyone would benefit from the inlining:
- People who regularly visit Wikipedia (many people). They have everything cached, inlining wouldn’t matter much for them.
- People who read Wikipedia articles every now and then (most people). They currently download Common.css when they visit Wikipedia, and then don’t download the image, as the rule never applies in article space (browsers won’t download images just because they see them in the stylesheet). Their bandwidth usage would increase if the image was inlined.
- People who visit non-mainspace pages every now and then (relatively few people). They currently download Common.css when they visit Wikipedia, and then may download the image if they view a non-mainspace gallery. Their bandwidth usage may decrease (or increase, if they don’t view such galleries) if the image is inlined.
- Given that the second group is far more populous than the third one, I think inlining the image would be a net loss. —Tacsipacsi (talk) 16:34, 25 February 2024 (UTC)
- I don’t know if any of them is cached longer, but there are multiple groups of people, and not everyone would benefit from the inlining:
Interface-protected edit request on 20 March 2024
Please add this to Mobile.css
:
.mobileonly {
display: inline;
}
and the following to Common.css
:
.mobileonly {
display: none;
}
While .nomobile
is defined well outside of these files, .mobileonly
(which is present in Fandom wikis) is not. This serves as a switch to allow content to be shown on mobile only while being hidden on desktop. Awesome Aasim 19:17, 20 March 2024 (UTC)
- Not done for now: please establish a consensus for this alteration before using the
{{Edit interface-protected}}
template. I don't see a reason for this. And moreover nomobile should also be avoided. If a specific element absolutely must not be displayed at a certain resolution, then it can use TemplateStyles and a media query. (Such cases probably honestly don't exist.) Ignoring both of those, Mobile.css's days are numbered. See the recent announcement in tech news. Izno (talk) 21:01, 20 March 2024 (UTC)- @Izno I am not finding where that information is. A link please? Awesome Aasim 17:52, 21 March 2024 (UTC)
- Ah, not announced yet anywhere. phab:T248416 Izno (talk) 05:58, 22 March 2024 (UTC)
- @Izno I am not finding where that information is. A link please? Awesome Aasim 17:52, 21 March 2024 (UTC)
- Plus, using the
display: inline
declaration to reverse the effect of adisplay: none
is not always correct: thedisplay:
property allows several values, some of which are significant for structured block elements such as lists and tables. --Redrose64 🌹 (talk) 22:10, 20 March 2024 (UTC) - Pages should be written agnostic of what the browser will be. — xaosflux Talk 18:10, 21 March 2024 (UTC)
Interface-protected edit request on 11 April 2024
Replace
.flagicon img {
min-width: 25px;
}
with
.flagicon img {
min-width: 23px;
}
The default size for flag icons is 23px, so setting the min-width to 25px is causing all flag icons to be larger than they should be. This is problematic for Template:Flag data which takes advantage of the fact that 25px is 2px larger than the default size of 23px. Additionally, using 23px was the proposed fixed for phab:T116318. – BrandonXLF (talk) 18:43, 11 April 2024 (UTC)
Interface-protected edit request on 5 May 2024
Can you please add this to the common.css?
body { font-family: serif; }
That is the serif font, and it is the font for nearly all the encyclopedias. Additionally, it constitutes the font of an actual encyclopedia. Thank you. 143.44.165.227 (talk) 02:17, 5 May 2024 (UTC)
- Not done for now: please establish a consensus for this alteration before using the
{{Edit interface-protected}}
template. – Jonesey95 (talk) 02:52, 5 May 2024 (UTC)
Interface-protected edit request on 30 May 2024
Please remove the background on `mw-warning-with-logexcerpt.mw-warning-with-logexcerpt.mw-warning-with-logexcerpt, div.mw-lag-warn-high, div.mw-cascadeprotectedwarning, div#mw-protect-cascadeon {` or replace it with a CSS variable that can adapt to dark mode. I am not sure why this is styled as an error, when the message itself is a warning and has a triangle - so the color is confusing so I personally would vote for removing it or moving it to MediaWiki:Timeless.css etc..
I have a global script for forcing dark mode on all pages, and when dark mode gets enabled on the editor, this will break. It would be good to fix this before that happens! Thanks in advance!
Example: (with dark mode global script). 🐸 Jdlrobson (talk) 04:46, 31 May 2024 (UTC)
- This is styled as an error because that's the importance we assign it, not the arbitrary importance assigned to it by the WMF at a date long after our modification was added. Stjn had a similar block in the ru.wp CSS which he modified to the CSS at ru:MediaWiki:Common.css#L-111, which I just haven't had a chance to test. Izno (talk) 18:52, 31 May 2024 (UTC)
- @Izno If the goal is to style this as an error, it would be better to use the Codex design token to ensure accessibility with links etc and get the night mode equivalent for consistency:
background-color: var(--background-color-error-subtle);
- While I don't think it looks great, having a warning icon with a red color, if this style needs to be retained as is, without the CSS variable, you need to also add a rule for text color - like what I'm doing in User:Jdlrobson/common.css. Without that, the interface will become unusable in dark mode.
- 🐸 Jdlrobson (talk) 15:54, 8 June 2024 (UTC)
/* https://en.wikipedia.org/wiki/MediaWiki_talk:Common.css#Applying_a_style_for_the_Vector_2022 */ .mw-warning-with-logexcerpt.mw-warning-with-logexcerpt.mw-warning-with-logexcerpt, div.mw-lag-warn-high, div.mw-cascadeprotectedwarning, div#mw-protect-cascadeon { color: black; }
- Done using the error-subtle design token, and keeping the existing color as fallback since the variable doesn't seem to be defined at all on Vector legacy which I use. * Pppery * it has begun... 01:35, 18 June 2024 (UTC)
Edit request 18 June 2024
Change --color-link
to --color-progressive
at lines 144 and 132, as the CSS variable --color-link
does not exist.
html.skin-theme-clientpref-night .infobox a { color: var( --color-link ) !important; } @media (prefers-color-scheme: dark) { ... html.skin-theme-clientpref-os .infobox a { color: var( --color-link ) !important; } }
->
html.skin-theme-clientpref-night .infobox a { color: var( --color-progressive ) !important; } @media (prefers-color-scheme: dark) { ... html.skin-theme-clientpref-os .infobox a { color: var( --color-progressive ) !important; } }
Andumé (talk) 01:22, 18 June 2024 (UTC)
- @Jon (WMF): since you put it there I believe. Izno (talk) 01:26, 18 June 2024 (UTC)
- I suspect what was meant was "color:LinkText", but I'll let Jon comment. * Pppery * it has begun... 01:42, 18 June 2024 (UTC)
- Switching --color-link to --color-progressive makes sense - we've been moving away from color-link to color-progressive. Thanks for flagging this! Jon (WMF) (talk) 16:39, 18 June 2024 (UTC)
- I suspect what was meant was "color:LinkText", but I'll let Jon comment. * Pppery * it has begun... 01:42, 18 June 2024 (UTC)