MediaWiki talk:Vector-2022.css

Interface-protected edit request on 5 February 2022
Change to Ideally I want to align it with #siteSub but I don't know how, as I can't figure out how the distance between header.mw-body-header and #bodyContent is derived. But -3em seems good enough. Nardog (talk) 03:31, 5 February 2022 (UTC)
 * ✅ Izno (talk) 03:42, 5 February 2022 (UTC)

Wait, the coordinates already appear in the perfect position when you're logged out if you just remove the rule. Nardog (talk) 03:40, 5 February 2022 (UTC)


 * Logged out doesn't have Vector 2022 yet, unless you are specifically using useskin.
 * That said, that location interferes with other indicators like protection icons. See New York City for example. Izno (talk) 03:41, 5 February 2022 (UTC)
 * Hmm, we could of course avoid that by setting  but I know of no way of doing so only when an indicator is present, I'm afraid... Nardog (talk) 03:56, 5 February 2022 (UTC)
 * Yeah. I'm probably going to bite the bullet and put this in an indicator, and then maybe we can get this styled the way we want. Izno (talk) 04:15, 5 February 2022 (UTC)
 * Ok, did this. Managed not to break Vector. I did note a bug with how Vector-2022.css is getting included (n.b. it's being included in RL before, not after, Vector.css), so the display there won't be perfect until such time as WMF fixes it either by removing the dependency on Vector.css or by fixing the load order. Izno (talk) 05:47, 5 February 2022 (UTC)
 * I looked for an ancestor class we could use to tell if the language dropdown is shown, and lo and behold, has the class   when the dropdown is present. This looks like a bug in itself. Nardog (talk) 03:40, 5 February 2022 (UTC)
 * This looks like it reflects whether the "Use a compact language list" option is on, not on whether the dropdown is shown. Nardog (talk) 04:01, 5 February 2022 (UTC)
 * Nope, I'm seeing this too, and this matters because with it the top offset should be 0 and without it it should be 3.5em. Really?! --Izno (talk) 06:05, 5 February 2022 (UTC)
 * Huh? The presence of  reflects the "Use a compact language list" option, no matter which Vector you use. Since this is unexpected, I've filed T301033. Nardog (talk) 06:10, 5 February 2022 (UTC)
 * Right now, logged in, the offset for new Vector should be 3.5em, without the interlanguage links at the top. With them at the top, the offset apparently needs to be 0.
 * Open Brooklyn in a private window and Brooklyn not in a private window (these are the same URL, just repeating for emphasis). Notice where the coordinates are in each. Izno (talk) 06:17, 5 February 2022 (UTC)
 * What does this have to do with what I struck and then removed and you restored? Nardog (talk) 06:20, 5 February 2022 (UTC)
 * Oh, I guess it's just Wait, the coordinates already appear in the perfect position when you're logged out if you just remove the rule. that I care about, but the stuff you had later looked relevant. Izno (talk) 06:23, 5 February 2022 (UTC)
 * I see. Anywho, the selector should probably be  because it is   you're overriding after all and just   is already set to   (and it has higher specificity no matter the order, of course). Nardog (talk) 06:27, 5 February 2022 (UTC)

This solution doesn't work. A CSS only solution to make these position absolute is impossible to do in such a way that doesn't break compability with pages which use indicators or users that use gadgets (see screenshots [ 1, 2, 3]

If you want to retain the coordinates at the top of the page there's only 2 solutions that will work and are being used by other communities: Jon (WMF) (talk) 16:10, 7 February 2022 (UTC)
 * Make it an indicator like they do on french Wikipedia
 * Use JavaScript like they do on Basque Wikipedia
 * Making it an indicator is what I suggested at VPT and what Izno alredy tried, and it led to other problems so he's undone it for now. Nardog (talk) 03:56, 8 February 2022 (UTC)
 * No, he's talking about ditching the CSS entirely making it an indicator. Izno (talk) 20:57, 9 February 2022 (UTC)
 * I thought that's what you were trying to do, down the line. Nardog (talk) 22:10, 10 February 2022 (UTC)
 * No, the most recent deployment was "Izno tries to hack around putting it inside an indicator to have a similar view as now" with clearly not enough success and not "trying to put it in an indicator". To put it in an indicator is removing any related CSS whatsoever (trivial) and then figuring out why one of the functions in the coordinates module broke when I did (less trivial), and then deploying related changes to that module (trivial). (That module is a .) Izno (talk) 23:18, 10 February 2022 (UTC)

widener gadget?
Following up from Special:PermaLink/1082288016

I actually like this new style, but I'm just wondering there's a way to give it a fluid width. It seems to have a fixed width, so when viewing episode tables, for example, everything is more squished compared to the legacy Vector style. Amaury • 22:49, 11 April 2022 (UTC)
 * here is a quick-and-dirty hack you could try, it is safe, but it may cause odd display issues (don't come blaming me if it does). You can put this in your Special:MyPage/vector-2022.css file. :


 * Someone who has spent more time with that annoyance may come by here and give a better set of rules. — xaosflux  Talk 00:47, 12 April 2022 (UTC)
 * I've got some slighly different CSS rules, mainly to make it fill out the width:


 * I put those in back in October, when I first turned on New Vector. They still work fine for me, but no guarantees of course. --rchard2scout (talk) 09:22, 12 April 2022 (UTC)
 * @Rchard2scout noticed you didn't touch .mw-page-container, are you keeping that one narrower? — xaosflux  Talk 10:05, 12 April 2022 (UTC)


 * I'm surprised no one turned this into a gadget yet... —Th e DJ (talk • contribs) 09:52, 12 April 2022 (UTC)
 * @TheDJ we probably will, if we can get anyone to agree on which widths are best :) — xaosflux  Talk 10:04, 12 April 2022 (UTC)

Should we make a vector-2022 widening gadget? Any preferred sizes? — xaosflux  Talk 10:27, 26 April 2022 (UTC)
 * Well as far as "should we" - I think this is an obvious yes, at least as a beta gadget for feedback. So I'm really looking for feedback on some of the values in the collapsed section above. —  xaosflux  Talk 14:45, 26 April 2022 (UTC)
 * WMF has plans to make Vector 22 use CSS grid, so it be wise to wait for that to happen before deploying a gadget that will break because of different underlying structure. T303484.
 * As for widening, I believe that most people will want full width, not some arbitrary other less-narrow but still limited width. That is what I personally will want. Izno (talk) 15:43, 26 April 2022 (UTC)
 * In terms of simply making everything full width, the css  seems to work the best. –  Brandon XLF  (talk) 19:11, 26 April 2022 (UTC)
 * Hmm, maybe there is still some extra padding going on - still seems a little chubby in whitespace? — xaosflux  Talk 22:04, 26 April 2022 (UTC)


 * MediaWiki:Gadget-wide-vector-2022 version 0.1 is up, try these links:
 * Today's FA in default Vector 2022
 * The same, with the widener as well
 * — xaosflux  Talk 13:05, 27 April 2022 (UTC)
 * I see a very minor difference. Not big enough to be noticeable unless directly comparing. ― Blaze WolfTalkBlaze Wolf#6545 13:07, 27 April 2022 (UTC)
 * what screen type and resolution are you using? I'm seeing a good 15% of the screen recovered (mostly from the right side gutter being removed). — xaosflux  Talk 13:09, 27 April 2022 (UTC)
 * I don't know what you mean by screen type. According to this website my screen resolution is 1366 x 768. ― Blaze WolfTalkBlaze Wolf#6545 13:12, 27 April 2022 (UTC)
 * @Blaze Wolf was asking if it was a desktop/mobile/tablet type. I saw the big change on desktop at 1680 X 1050. Are you seeing any big whitespace gaps at all (this could only be something that starts to be a problem at resolutions wider than you are using). — xaosflux  Talk 13:15, 27 April 2022 (UTC)
 * NOpe. And my screen type is a laptop. ― Blaze WolfTalkBlaze Wolf#6545 14:00, 27 April 2022 (UTC)
 * Thanks, I think the large whitespace is really only a problem for people with wider resolutions. — xaosflux  Talk 15:27, 27 April 2022 (UTC)
 * No problem. I'll be in a place in about an hour or so where I have access to a widescreen monitor (I don't know what the resolution is) so I'll see how much of a difference it makes on that. ― Blaze WolfTalkBlaze Wolf#6545 15:59, 27 April 2022 (UTC)
 * Ok ya that looks much better. Now I'm on a 2560 x 1080 PC monitor and I see a significant difference. ― Blaze WolfTalkBlaze Wolf#6545 18:07, 27 April 2022 (UTC)
 * @Blaze Wolf thanks for the note, you can enable this for more testing via the Gadgets options in your preferences (it is in the testing section near the bottom). — xaosflux  Talk 18:56, 27 April 2022 (UTC)
 * Eh I probably won't. I'm not really a fan of 2022 vector. ― Blaze Wolf</b>Talk<sub title="Discord Username" style="margin-left:-22q;">Blaze Wolf#6545 18:57, 27 April 2022 (UTC)
 * OK, thanks for the feedback so far - sounds like it was a net-positive, when on a wide display, and if using vector-2022. — xaosflux  Talk 18:59, 27 April 2022 (UTC)
 * Yes definitely. It acts similar to how normal vector scales to different screen sizes. ― <b style="background:#0d1125;color:#51aeff;padding:1q;border-radius:5q;">Blaze Wolf</b>Talk<sub title="Discord Username" style="margin-left:-22q;">Blaze Wolf#6545 19:06, 27 April 2022 (UTC)
 * Looks much better to me; well done. It's nearly as good as legacy Vector, apart from the white band of wasted space across the top (which I know is out of scope for this task). Certes (talk) 13:21, 28 April 2022 (UTC)
 * @Certes try this view again - I also shrunk the padding under the header from 2em to 0.5em. May need to rename this from "widener" to "stretch" or something :) —  xaosflux  Talk 14:07, 28 April 2022 (UTC)
 * Also an improvement, thanks. (Needs a browser tab refresh to take effect.) Certes (talk) 14:11, 28 April 2022 (UTC)
 * There is still a bunch of what seems like wasteful padding and forced margins, but I keep colliding elements in to each other when tweaking right now - will revisit (any ideas welcome!). — xaosflux  Talk 14:28, 28 April 2022 (UTC)
 * Well I know that legacy vector is able to do it without any issues. Maybe we could try and figure out how legacy vector works? ― <b style="background:#0d1125;color:#51aeff;padding:1q;border-radius:5q;">Blaze Wolf</b>Talk<sub title="Discord Username" style="margin-left:-22q;">Blaze Wolf#6545 14:29, 28 April 2022 (UTC)
 * I think I just started getting carried away trimming margins and paddings - but the layout is a little different (notably with how the toolbar (Article/talk) overlaps with the sidebar, then is using static values to push it back out by default. —  xaosflux  Talk 17:56, 28 April 2022 (UTC)
 * Is this still in the works? I came here from the Japanese Wikipedia. Thought I was on the mobile version of the site until I realized it was the new default. It really feels cramped. I would love a button that just extends the width so it is like legacy. Thanks. 76.173.99.79 (talk) 09:33, 24 July 2022 (UTC)
 * Coming from the Village Pump thread, I've just enabled the gadget and I do not see any difference. KPu3uC B Poccuu (talk) 09:08, 29 April 2022 (UTC)
 * @KPu3uC B Poccuu thanks for the note. The differences start to appear if you are (a) actually using vector-2022 as your skin (or clicked on one of the force examples above) and (b) have a wide screen - looks like it starts being evident after 1300 widths. — xaosflux  Talk 09:36, 29 April 2022 (UTC)
 * Both conditions are satisfied I'm afraid. Still no difference on my end. Here is how it looks on my end when I view the linked above page, just to be extra sure.Wikipedia page screenshot on widescreeen monitor.png That's very bad design if these changes are intentional! KPu3uC B Poccuu (talk) 03:26, 30 April 2022 (UTC)
 * @KPu3uC B Poccuu is that what you see, when using this link? That looks like w/o the gadget. — xaosflux  Talk 09:38, 30 April 2022 (UTC)
 * Yes indeed, that's what I get when visiting the link. Exactly! Nothing has changed for me after activating the gadget. KPu3uC B Poccuu (talk) 13:10, 30 April 2022 (UTC)

Bug report: History of Asian art The paranoma image stretches the page all the way through the end of the picture. – robertsky (talk) 08:07, 3 August 2022 (UTC)


 * Ping to (major contributor for Module:Wide image) who may have some good ideas on this. —  xaosflux  Talk 09:45, 3 August 2022 (UTC)
 * See User:Xaosflux/sandbox133 (use the reload link at the top). — xaosflux  Talk 09:46, 3 August 2022 (UTC)

Another bug report: Visual Editor may appear stretched in certain instances. I am unable to determine the cause for this, but a recent encounter is on 's user page when editing in source mode (was on it to find an example of a template being used, unrelated to this bug report/issue). – robertsky (talk) 01:55, 5 August 2022 (UTC)

Hide TOC
Need to be able to hide TOC like the Main Menu ....for more info see Village pump (technical). Causing readability issues for those who use this on mobile view for full screen Moxy - 19:37, 26 April 2022 (UTC)
 * Splitting this to a new section, since it isn't about widening. — xaosflux  Talk 10:05, 27 April 2022 (UTC)

Interface-protected edit request on 6 July 2022
The recent changes to page tabs (changes) have moved the page tabs to below the page title and now the coords are appearing on top of the Edit/history buttons. Can -3em be changed to -1em to avoid the overlap. Terasail [✉️] 19:25, 6 July 2022 (UTC)
 * Looking in to this. — xaosflux  Talk 19:47, 6 July 2022 (UTC)
 * ✅ — xaosflux  Talk 19:49, 6 July 2022 (UTC)

Overlapped icon fix
https://en.wikipedia.org/wiki/Kanjuruhan_Stadium_disaster

On the above link, the lock icon overlaps the coordinates still. Can you fix this for me? RapMonstaXY (talk) 12:54, 6 October 2022 (UTC)


 * Let's try pushing it down instead. Think there is still a lot of dispute about (a) if coordinates are content, (b) regardless of if they are content: do they belong in the content area of the page. —  xaosflux  Talk 13:21, 6 October 2022 (UTC)

Message Box/Coordinates Problem
Fix the message box/coordinates positioning so that they wont overlap with each other. Ok?

Examples:
 * https://en.wikipedia.org/wiki/2007_Glorietta_explosion

RapMonstaXY (talk) 14:25, 13 October 2022 (UTC)
 * See T281974 for work on that. — xaosflux  Talk 14:28, 13 October 2022 (UTC)

Override pending changes box positioning
Problem described at Village pump (technical).

The change is to move the box from the right to the left of the toolbar, as changing vertical alignment could cause further collisions with elements such as coordinates (maybe?). So just moving from right to left seems to be a better approach.

To do this add the following: Terasail [✉️] 15:11, 8 November 2022 (UTC)


 * @Terasail this sounds like a problem that would affect all projects, so perhaps a tempoary workaround as above - but shouldn't this be addressed at the root? (Open a bug with the extension). — xaosflux  Talk 15:21, 8 November 2022 (UTC)
 * I can make a bug report for FlaggedRevs but isn't this more of T281974 (Coordinates issue). With that task being more general it might just be better for a mention there. Since other wikis that use pending changes don't appear to use the same workaround as us anyway. I looked at fi:Järjestelmäviesti:Vector.css since they use pending changes but they don't seem to have any similar css although I am not great with other language wikis and don't have the reviewer flag elsewhere. Terasail [✉️] 15:33, 8 November 2022 (UTC)
 * @Xaosflux Having also briefly looked at als & ru wiki Vector.css aswell it appears that only enwiki repositions .flaggedrevs_short and everyone else just leaves it in the default position so I am not too sure how much of a bug this is compared to self inflicted errors from adjusting default values... Terasail [✉️] 15:47, 8 November 2022 (UTC)
 * @Terasail the "coordinates" problem is still a design kerfuffle - but "view history" is built in. While other wikis have "pending changes" I think the problem here is a collision with mw:Extension:PageTriage? So opening a ticket for the problem with PageTriage would be at least what I'd want to see before we put a hack that has to load for every single reader (who don't have this problem, as they don't see those controls). — xaosflux  Talk 16:23, 8 November 2022 (UTC)
 * @Xaosflux This shouldn't have anything to do with PageTriage it should be only from mw:Extension:FlaggedRevs. The box itself is created by FlaggedRevsXML.php (in that extension) so I think opening a ticket is redundant going with my previous logic as this appears to me to be exclusively pending changes related. The extension itself is labled as "clunky, complex and not recommended for production use" so I can't see much benefit to creating a bug report here when we create the bug by not using default positioning for this extension.
 * The default of this box is the top right of #mw-content-text however it appears in 2017 this box was repositioned to be inline with the title of the article (As a continuation of some previous code?) I am guessing for aesthetic reasons. So I mean its less of a bug and more of a lack of foresight that in 2022 there would be a new skin that swaps the title/tools order. Terasail [✉️] 16:58, 8 November 2022 (UTC)
 * @Terasail thanks for more info - so this is still a "FlaggedRevs" had a collision in vector-2022 problem - which would occur anywhere (including outside of WMF wikis) where that extension was installed. And because of this bug, we want to slap a hack on top of it.  We certainly do that, but that doesn't excuse why a bug isn't opened. It looks like similar problems (e.g. T316947) with that extension have been worked on.  Bottom line, I don't want to add technical debt to our entire skin that isn't referenced to the "better" solution (fix the offending extension). —  xaosflux  Talk 17:05, 8 November 2022 (UTC)
 * I 100% agree that adding hacks to a problem is a worse solution than fixing the problem. I guess I just see it differently to you, I see the issue being MediaWiki:Vector.css rather than the extension. I tested disabling the added css (When the box was still visible) and there was no collisions with any page elements on either vector or V22. The issue is using "position: absolute;" - Rarely a good way to solve a problem and on top of that the problem being solved is only asthetic... which is why no other language wikis override the default (I am assuming). Therefore I see no point in creating a task where some WMF dev eventually replies that they are not going to solve a problem that only exists for enwiki because of css created by enwiki. My original idea was to just IPER the removal of the css but being well aware of how people hate elements of vector changing especially when caused by V22. I thought this would be the better idea. Terasail [✉️] 17:17, 8 November 2022 (UTC)
 * TLDR: Bit of a ramble, but I don't see a phab ticket as a solution, the soliton is to remove lines 41-47 of MediaWiki:Vector.css (and pending changes is more hassle then it provides benefit over semi-prot) Terasail [✉️] 17:18, 8 November 2022 (UTC)
 * I've made the CSS of interest apply only to legacy vector. I have no fundamental objection to total removal if that's desirable along the same lines: using absolute is almost always a hack. Izno (talk) 18:04, 8 November 2022 (UTC)

Interface-protected edit request on 7 March 2024
Remove the block starting from MediaWiki:Vector-2022.css. The relevant patch has been merged upstream for a few weeks now (thanks ). Izno (talk) 16:54, 7 March 2024 (UTC)
 * ✅ — xaosflux  Talk 19:38, 7 March 2024 (UTC)
 * Thank you Izno —Th e DJ (talk • contribs) 21:52, 7 March 2024 (UTC)

Interface-protected edit request on 1 April 2024
To support T331679/T357580, there are a couple blocks we should copy from MediaWiki:Vector.css. This change request 1) adds the interface removals for the main page, 2) adds the removal of the border bar that WMF added in Vector, and 3) removes the lead comment, which are known factors of the skin.css pages that need not repeated here (going into the future). Please copy-paste the following over the existing Vector-2022.css page:

Izno (talk) 03:37, 1 April 2024 (UTC)


 * @Izno have you tested this locally yet? Seems like until those are done we're going to be serving double the styles here? Any FUC? — xaosflux  Talk 13:51, 9 April 2024 (UTC)
 * Yes, double the styles is intended for the time being (and these aren't exactly heavy-weight). No, this won't cause FOUCs. @Xaosflux Izno (talk) 16:54, 9 April 2024 (UTC)
 * ✅ — xaosflux  Talk 17:05, 9 April 2024 (UTC)

Links inside tables
I added some styles a while back to https://en.wikipedia.org/wiki/MediaWiki:Minerva.css#L-135 that change the color of links to black (and underlined) when present in an element with a background color for dark mode. They've been working pretty well there, consistently more than halving error reports I see on top 100 most viewed pages.

To be honest these would also work well on the standard theme as in many cases I've noticed editors often overlook links inside tables. For example, all the links in the relegation zone on https://en.wikipedia.org/wiki/2010%E2%80%9311_Premier_League are inaccessible but perhaps we should focus on the dark theme for now?

🐸 Jdlrobson (talk) 01:47, 29 May 2024 (UTC)


 * I forgot to add - another approach if we dislike the contains selectors would be to do this Consider_globally_setting_link_color_inside_tables_with_background (possibly with an override class similar to the plainlink class that resets it back to a blue link). 🐸 Jdlrobson (talk) 01:59, 29 May 2024 (UTC)
 * Isn't that  quite 'expensive' to be evaluating on every page load? —  xaosflux  Talk 17:34, 29 May 2024 (UTC)
 * These days most literature seems to conclude it is not a problem. Performance of contains query was investigated in https://phabricator.wikimedia.org/T358240 and concluded it was not a problem but as always it depends.
 * This rule could also be applied with JavaScript in a more readable away - adding a class that applies these rules and encouraging editors to add that class in the content (i could see that being a useful gadget!) 🐸 Jdlrobson (talk) 18:17, 1 June 2024 (UTC)
 * ✅ as proposed (except for a minor CSS syntax correction) since this has seen no action for weeks. This does not bar further improvements. * Pppery * <sub style="color:#800000">it has begun... 01:46, 18 June 2024 (UTC)

and others: I observed today that in this article, the first wikilink in the table ("Main") is colored white instead of blue or black. I think the above change might have something to do with this coloring. – Jonesey95 (talk) 19:04, 18 June 2024 (UTC)


 * This should have been fixed by this change - there was a misunderstanding around token usage. 🐸 Jdlrobson (talk) 16:36, 20 June 2024 (UTC)

T367463 hack fixed?
is the hack for T367463 still needed? This task is marked resolved. — xaosflux  Talk 15:46, 11 July 2024 (UTC)


 * Yep! Thanks for flagging. ✅ Jon (WMF) (talk) 16:01, 11 July 2024 (UTC)