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)[reply]
Hmm, we could of course avoid that by setting right 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)[reply]
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)[reply]
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)[reply]
(edit conflict) I looked for an ancestor class we could use to tell if the language dropdown is shown, and lo and behold, <body> has the class mw-interlanguage-selector-disabled when the dropdown is present. This looks like a bug in itself.Nardog (talk) 03:40, 5 February 2022 (UTC)[reply]
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)[reply]
Huh? The presence of mw-interlanguage-selector-disabled reflects the "Use a compact language list" option, no matter which Vector you use. Since this is unexpected, I've filed phab:T301033. Nardog (talk) 06:10, 5 February 2022 (UTC)[reply]
Nardog 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.
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)[reply]
I see. Anywho, the selector should probably be .skin-vector-2022 .mw-indicator #coordinates because it is .mw-indicator #coordinates you're overriding after all and just #coordinates is already set to top: 0; (and it has higher specificity no matter the order, of course). Nardog (talk) 06:27, 5 February 2022 (UTC)[reply]
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:
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 hack.) Izno (talk) 23:18, 10 February 2022 (UTC)[reply]
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)[reply]
@Amaury: 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. :
I've got some slighly different CSS rules, mainly to make it fill out the width:
.mw-workspace-container{max-width:100%;}.mw-article-toolbar-container,.mw-content-container{max-width:calc(100%-11em);/* 11em is the width of #mw-panel */margin-right:0;}.mw-footer-container{padding-top:0;padding-bottom:0;}
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. — xaosfluxTalk14:45, 26 April 2022 (UTC)[reply]
WMF has plans to make Vector 22 use CSS grid, so it might be wise to wait for that to happen before deploying a gadget that will break because of different underlying structure. phab: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)[reply]
In terms of simply making everything full width, the css
@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). — xaosfluxTalk13:15, 27 April 2022 (UTC)[reply]
@Xaosflux: 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#654515:59, 27 April 2022 (UTC)[reply]
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)[reply]
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!). — xaosfluxTalk14:28, 28 April 2022 (UTC)[reply]
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? ― Blaze WolfTalkBlaze Wolf#654514:29, 28 April 2022 (UTC)[reply]
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. — xaosfluxTalk17:56, 28 April 2022 (UTC)[reply]
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)[reply]
@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. — xaosfluxTalk09:36, 29 April 2022 (UTC)[reply]
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. That's very bad design if these changes are intentional! KPu3uC B Poccuu (talk) 03:26, 30 April 2022 (UTC)[reply]
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 David Tornheim'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)[reply]
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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)[reply]
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. — xaosfluxTalk13:21, 6 October 2022 (UTC)[reply]
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.
@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). — xaosfluxTalk15:21, 8 November 2022 (UTC)[reply]
I can make a bug report for FlaggedRevs but isn't this more of phab: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)[reply]
@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)[reply]
@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). — xaosfluxTalk16:23, 8 November 2022 (UTC)[reply]
@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)[reply]
@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. phab: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). — xaosfluxTalk17:05, 8 November 2022 (UTC)[reply]
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#L-41 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)[reply]
Partly done: 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)[reply]
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
To support phab:T331679/phab: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:
/* Don't display some stuff on the main page */.page-Main_Page#deleteconfirm,.page-Main_Page#t-cite,.page-Main_Page#footer-info-lastmod,.action-view.page-Main_Page#siteSub,.action-view.page-Main_Page#contentSub,.action-view.page-Main_Page#contentSub2{display:none!important;}/* nudge coordinates indicator display */#coordinates{line-height:2;font-size:92%;white-space:nowrap;}/* Override [[phab:T265947]] */.mw-body-contentblockquote{border-left:none;}
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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?
/* [[phab:T360844]] */html.skin-theme-clientpref-nighttable[bgcolor]a,html.skin-theme-clientpref-nightth[style*="background"]:not([style*="transparent"]):not([style*="inherit"])a,html.skin-theme-clientpref-nighttd[style*="background"]:not([style*="transparent"]):not([style*="inherit"])a,/* should not apply to th elements which have their own background. */html.skin-theme-clientpref-nighttr[style*="background"]:not([style*="transparent"]):not([style*="inherit"])tda{color:var(@color-base,#202122);text-decoration:underline;}@media(prefers-color-scheme:dark){html.skin-theme-clientpref-ostable[bgcolor]a,html.skin-theme-clientpref-osth[style*="background"]:not([style*="transparent"]):not([style*="inherit"])a,html.skin-theme-clientpref-ostd[style*="background"]:not([style*="transparent"]):not([style*="inherit"])a,html.skin-theme-clientpref-ostr[style*="background"]:not([style*="transparent"]):not([style*="inherit"])tda{color:var(@color-base,#202122);text-decoration:underline;}}
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)[reply]
Jdlrobson 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)[reply]
Jon (WMF): In addition to the great point Jonesey95 has made, in smaller wikis we sometimes know an article should be created as it is already created in English Wikipedia but it's not created yet locally so we like to have the red link at least. −Ebrahimtalk18:06, 30 July 2024 (UTC)[reply]
Done Izno (talk) 03:42, 5 February 2022 (UTC)
19:37, 26 April 2022 (UTC)
In progress Looking in to this. — xaosflux Talk 19:47, 6 July 2022 (UTC)
Partly done: 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)