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
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)Reply
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)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
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)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.
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)Reply
What does this have to do with what I struck and then removed and you restored? Nardog (talk) 06:20, 5 February 2022 (UTC)Reply
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:
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)Reply
Nardog No, he's talking about ditching the CSS entirely and making it an indicator. Izno (talk) 20:57, 9 February 2022 (UTC)Reply
I thought that's what you were trying to do, down the line. Nardog (talk) 22:10, 10 February 2022 (UTC)Reply
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. :
Someone who has spent more time with that annoyance may come by here and give a better set of rules. — xaosfluxTalk 00:47, 12 April 2022 (UTC)Reply
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;}
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)Reply
@Rchard2scout noticed you didn't touch .mw-page-container , are you keeping that one narrower? — xaosfluxTalk 10:05, 12 April 2022 (UTC)Reply
I'm surprised no one turned this into a gadget yet... —TheDJ (talk • contribs) 09:52, 12 April 2022 (UTC)Reply
@TheDJ we probably will, if we can get anyone to agree on which widths are best :) — xaosfluxTalk 10:04, 12 April 2022 (UTC)Reply
Should we make a vector-2022 widening gadget? Any preferred sizes? — xaosfluxTalk 10:27, 26 April 2022 (UTC)Reply
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. — xaosfluxTalk 14: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
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)Reply
@Blaze Wolf: 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). — xaosfluxTalk 13:09, 27 April 2022 (UTC)Reply
@Xaosflux: 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)Reply
@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). — xaosfluxTalk 13:15, 27 April 2022 (UTC)Reply
@Xaosflux: NOpe. And my screen type is a laptop. ― Blaze WolfTalkBlaze Wolf#6545 14:00, 27 April 2022 (UTC)Reply
Thanks, I think the large whitespace is really only a problem for people with wider resolutions. — xaosfluxTalk 15:27, 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#6545 15:59, 27 April 2022 (UTC)Reply
@Xaosflux: 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)Reply
@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). — xaosfluxTalk 18:56, 27 April 2022 (UTC)Reply
Eh I probably won't. I'm not really a fan of 2022 vector. ― Blaze WolfTalkBlaze Wolf#6545 18:57, 27 April 2022 (UTC)Reply
OK, thanks for the feedback so far - sounds like it was a net-positive, when on a wide display, and if using vector-2022. — xaosfluxTalk 18:59, 27 April 2022 (UTC)Reply
Yes definitely. It acts similar to how normal vector scales to different screen sizes. ― Blaze WolfTalkBlaze Wolf#6545 19:06, 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
@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 :) — xaosfluxTalk 14:07, 28 April 2022 (UTC)Reply
Also an improvement, thanks. (Needs a browser tab refresh to take effect.) Certes (talk) 14:11, 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!). — xaosfluxTalk 14: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#6545 14: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. — xaosfluxTalk 17: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
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)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. — xaosfluxTalk 09: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
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)Reply
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)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
Latest comment: 1 year ago2 comments2 people in discussion
Need to be able to hide TOC like the Main Menu ....for more info see Wikipedia:Village pump (technical)#Side bar. Causing readability issues for those who use this on mobile view for full screenMoxy- 19:37, 26 April 2022 (UTC)Reply
Splitting this to a new section, since it isn't about widening. — xaosfluxTalk 10:05, 27 April 2022 (UTC)Reply
Interface-protected edit request on 6 July 2022edit
Latest comment: 1 year ago3 comments2 people in discussion
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
In progress Looking in to this. — xaosfluxTalk 19:47, 6 July 2022 (UTC)Reply
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)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. — xaosfluxTalk 13: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). — xaosfluxTalk 15: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). — xaosfluxTalk 16: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). — xaosfluxTalk 17: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
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)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
Interface-protected edit request on 7 March 2024edit
Latest comment: 1 month ago3 comments3 people in discussion
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Interface-protected edit request on 1 April 2024edit
Latest comment: 15 days ago4 comments2 people in discussion
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;}
@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? — xaosfluxTalk 13:51, 9 April 2024 (UTC)Reply
Yes, double the styles is intended for the time being (and these aren't exactly heavy-weight). No, this won't cause FOUCs. @XaosfluxIzno (talk) 16:54, 9 April 2024 (UTC)Reply
19:37, 26 April 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)