Izno is right. Bite the bullet. Vector.js should apply only to Vector 2010, and Vector-2022.js should apply only to Vector 2022. Common.js should apply to all skins. Just make the change now, before the situation becomes more entrenched.

In T328719#8671077, @Edtadros wrote:

@Jdlrobson I'm trying to recreate this in prod to make sure I'm testing it correctly. Every link I try seems to not have an issue highlighting text. Am I missing something or is this already in enwiki?

In T328133#8662171, @Jdlrobson wrote:

T328133 is for enabling the sticky header in all namespaces.

I think so, as long as T329673 makes progress.

I have read that essay. I understand my part of it, which is called "How I can influence what is worked on?" I have done all of those things. I do QA and bug reporting. I have tried to participate in the Community Wishlist Survey, which is a wildly discouraging process. I respond to requests for feedback from WMF staff on en.WP. I track down MediaWiki.org discussion pages and wade through the unusual interface to try to be helpful. I try to be polite and to provide clear, concise examples on Phabricator so that developers can replicate and fix a problem. I believe that I have performed my role correctly. Now it is time for developers to fix a bug.

Is there a reason that this bug report is stalled? It is over two years old?

Is there a reason that this bug is stalled? Tidy font link errors are listed as "high-priority" errors by the Wikimedia developers, but this bug has not received high-priority attention.

This problem is still happening. See https://en.wikipedia.org/w/index.php?title=User:Anomalocaris/sandbox/Lint_Test&oldid=1142213749 for another example with a stripped span tag.

In T325219#8641856, @bwang wrote:

The original spacing between the header and the page title is per design, I believe there should be 24px between the header, page title, and site notice (when its not empty). If I recall correctly we implemented the spacing this way because we ran into some cases where wikis defined site notices with empty elements. This made styling a bit trickier, so we ended up applying margins on the site notice regardless of if its empty or not, taking advantage of margin collapsing.

I was going to try to add to the table in the task description, but I thought it would be more clear to add a better description here:

Please see detailed notes in the duplicate task.

Possibly related: T329174.

FWIW, AntiCompositeNumber's signature-checking tool at https://signatures.toolforge.org/reports/en.wikipedia.org, which was created as part of the "enforce signature requirements" project, reports p and br tags as errors.

See also T329785, which may be related. The duplicated text is some or all of a signature that contains disallowed p tags.

In T328875#8606867, @Jhawkinson wrote:

I'm not sure that the examples @Jonesey95 listed are the same – it seemed like those were conditions that were corrected by a purge, which this was not.

Something is a little bit wrong with "Add interlanguage links" in the "tall TOC" screen shots. It is a little bit too far to the left, and the left edge of "A" and "l" are being cut off.

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_202#Image_thumbnail_bug was less than a month ago.

I performed action=purge while trying to troubleshoot this problem, and it did not fix the problem.

This is also replicable on article pages where there are not enough headers to generate a TOC, such as https://en.wikipedia.org/wiki/Star_Trek_Star_Fleet_Technical_Manual

Of note: This file was most recently updated on 5 July 2018. It appears that some of these cached images are almost five years old.

It is also disabled on the Watchlist, the page I visit the most. I would love to be able to see the sticky header, especially my notifications, as I scroll down the Watchlist.

Here's a screen shot of https://fa.wikipedia.org/wiki/%D8%AD%D9%85%D9%84%D9%87_%D8%A8%D9%87_%D8%B3%D9%81%D8%A7%D8%B1%D8%AA_%D8%AC%D9%85%D9%87%D9%88%D8%B1%DB%8C_%D8%A2%D8%B0%D8%B1%D8%A8%D8%A7%DB%8C%D8%AC%D8%A7%D9%86_%D8%AF%D8%B1_%D8%AA%D9%87%D8%B1%D8%A7%D9%86

Rant acknowledged, TheDJ. I'm just a regular middle-aged person with no known disabilities and a somewhat old Macbook Pro, and I can't see the difference in background color. There are millions of readers out there with worse computers than mine (this one cost $2000+ new). If the developers wanted to show me a background color, it didn't work, and it won't work for those millions. The Vector 2010 sidebar background color works well on my computer.

When the Vector 2022 watchlist star is in the filled-in "watched" state and I click on it, it fills in but does not rotate.

Thanks for the demo. It helps to see work in progress. Here's what I noticed in a quick comparison:

The above explanation does not account for https://en.wikipedia.org/wiki/Wikipedia:Catalogue_of_CSS_classes?useskin=vector-2022&safemode=1 working reasonably when I enable limited-width mode, but being very wide when I disable limited-width mode.

Contrary to my earlier hypothesis, I am able to make this happen on a few pages with limited width mode enabled. It happens much less often, though, FWIW.

This is a somewhat urgent problem. I have found that it is affecting between 1 in 20 and 1 in 10 pages that I visit. The scroll width is up to 10x the width of my browser window.

This is happening in safe mode as well. See https://en.wikipedia.org/wiki/Wikipedia:Catalogue_of_CSS_classes?useskin=vector-2022&safemode=1

?setskin=vector-2022 or something similar may do the trick. The functionality needs to be tested under multiple circumstances in which the link is visible, such as following a #Sectionlink or viewing a diff page.

?setskin=vector or something similar may do the trick. The functionality needs to be tested under multiple circumstances in which the link is visible, such as following a #Sectionlink or viewing a diff page.

To be clear: the request was for the sticky header to be enabled on ALL pages, not just all talk namespace pages. It should also show when I scroll down a diff page like this one. If it is going to be useful, it needs to appear where it is needed, which is pretty much everywhere.

Is it possible to make these metrics publicly viewable? The link above goes to a Wikimedia Developer login page.

Yes! Thank you for taking care of this. I checked in Vector 2010 and Vector 2022, and the links are aligned perfectly.

This task needs to be increased in priority now that Vector 2022 is the default skin. Being unable to see the TOC when I click Edit on a long page means that I have to use Find or scrolling to navigate, both of which can be tedious and imprecise.

This problem was caused by Linter errors (missing end tags, mostly). I have fixed them with this edit.

This may be a duplicate of T327714.

Yes, with a few mysterious exceptions like "Edit interlanguage links", the padding and font size are consistently too large in all of the sidebar groups. If the size and padding assignments are all in one place, fixing them should be straightforward. You have set yourself up for a quick win.

A similar-looking problem has been reported with Preview and the 2017 Wikitext Editor: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&curid=3252662&diff=1135371060&oldid=1135370646#Preview_broken_on_2017_wikitext_editor

In T324877#8540834, @TheDJ wrote:

Can we get just a tad more separation between the menu levels ?
I feel this is just still awfully close, even with the line in between.

I don't know it feels too clumped together still and I have trouble identifying the separate areas. There is no 'mental break' here for my brain.

I believe that this is blocking T302073 from being completed.

I believe that this is blocking T302073 from being completed.

This was happening to me as well, but it was fixed for me after the deployment of page tools today.

This is replicable when the new page tools sidebar is visible, but not when the Tools items are hidden in the Tools menu. It looks like a change to the grid may have caused this. This one should be an urgent fix (or maybe rollback the page tools temporarily, given the other problems that have been reported).

Please don't add to the already excessive white space in these menus without first decreasing the excessive padding between list items and fixing the font size. See T327732 for some details.

For me, the new page tools sidebar text is actually larger (14px) than the body (12.25px) text.

This needs to get bumped up in importance now that the menu/sidebar has been deployed.

Also, the font size and padding in the sidebar and menu are too large. If they were reduced, the sidebar could take less horizontal space. See https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements#Upcoming_Page_Tools_sidebar:_font_size_and_line_spacing_too_large where I reported this problem three days ago.

This is also happening with the LintHint tool (https://en.wikipedia.org/wiki/User:PerfektesChaos/js/lintHint). Its output, which is supposed to appear in the grid section that contains the article title, is appearing in the upper right. Something has maybe changed in the grid; I can't tell if the grid has a bug or if all of these tools need to be told to put their output in a new place.

In the screen shot, the icon is not being overlapped. There appears to be one pixel of white space between the edge of the blue box and the Watchlist icon.

Are you planning to measure the percentage of Vector 2022 users who opt out of the limited width mode? (using Preferences, not the toggle)

Where should I provide feedback on the new page tools sidebar?

This bug report is about anonymous users, who, as it has been made clear hundreds of times in the last day or two by commenters on en.WP, do not have access to preferences. Disabling wide mode for them would go a long way toward improving acceptance of this new skin.

This may be related to the grid/column work proposed in T323141.

It appears that recent changes (possibly in today's deployment?) to the CSS column-gap value, and probably some underlying reorganization, have made this spacing consistent. In safemode, full width, I'm seeing 44px in the left margin, between the TOC and the content, and in the right margin (see screen shot). That's still too much white space for me, but consistency is what this ticket was about. I'm OK to make further adjustments using personal CSS.

While waiting for a resolution to this widespread problem, please simply make the limited-width mode opt-in for all users and let them adjust their browser window width manually (for a persistent narrower view) or click the toggle (on individual pages that they want narrower).

Or just listen to the voluminous feedback on Vector 2022 and make the wide layout the default? That would be a very quick and significant win for readers.

In T326887#8540797, @alexhollender_WMF wrote:

In T326887#8540781, @TheDJ wrote:

I still think 1200 is the best cutoff, as that is where the margin increases and creates space for it.

on articles with a table of contents, assuming the table of contents is pinned (which is the default) the toggle wouldn't do anything at 1200px

The article video above includes a TOC on the left. The toggle should appear for less-wide pages that are not showing the TOC.

This confusing setup is continuing to confuse editors. Here's one from today: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1134608194#%22More%22_panel

This task appears to be stalled. There are currently 188 editors listed on https://signatures.toolforge.org/reports/en.wikipedia.org and that report is limited to editors who have posted on discussion pages in the previous three months. What needs to happen to eliminate non-compliant signatures?

Let's not forget about Option 1, putting the link in the More menu. We can probably get away with it since it is a gadget.

Thanks. Reclaiming wasted white space in Vector 2022 is a significant project that I urge developers to continue work on.

Option 4 looks wrong to me.

See also T21567.

Here's load.php in Vector:

The first one is interesting. The "edit the lead section link" is a gadget for now (pending a real implementation of the 2004 feature request), so putting something in the More menu is not a bad option.

Changing grid-template-columns to 254px in my common.css fixes this padding problem.

Thank you for the detailed fix for my personal situation. That code has added "Tools" to my pinned User menu. I note that the "Tools" link is in a different place (at the bottom) in the sticky menu and it appears at the far left of the menu instead of below the other links (i.e. there is no "blank icon" space as shown in the screen shot). So there is still some inconsistency here.

It appears that the Watchlist has been moved out of the initial version of the rendered menu, but it still appears in the user menu in the pinned banner that appears when you scroll. Related: T289619 and T325124.

My default font, and the one shown in my screen shot, is 14px Lucida Grande, FWIW. I also have a minimum font size of 11px set, if it matters. My browser is Firefox 107 for Mac OS. Thanks for digging into the root cause of this issue.

The difference in the screen shots is that TheDJ's edit link immediately follows the section title instead of being (sensibly, IMO) aligned at the right side of the page. I have enabled the en.WP gadget called "Move section [edit] links to the right side of the screen" because I like to know where the edit link is going to be for every section instead of hunting left and right for it. In any event, TheDJ's screen shot shows the same thing as mine, which is that the lead section edit link, confusingly, appears higher in the page than the whole-page edit link.

Legacy Vector (good placement):

WIthout TOC showing:

Possibly related to this, when the TOC is hidden and button that should show the TOC is displayed, that button should simply show the TOC when it is clicked, not pop up a menu and then force the reader to carefully navigate to the text-only link called "move to sidebar". The current behavior is very different from what web users are accustomed to.

Numbers are helpful on pages like https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Guild_of_Copy_Editors/Requests and https://en.wikipedia.org/wiki/Wikipedia:Templates_for_discussion#Current_discussions, where it is helpful to see how many open requests or discussions are pending in a given section.

For anyone looking to restore this behavior, this code in your common.css file works for me:

Yes, bogus file options is the correct category for this. Thanks. Fixing Lint is (almost) all about removing backwards compatibility for hacks and workarounds and errors that are no longer accepted.

In T246403#8455705, @Sbailey wrote:

If you just edit a page with the wikitext editor, and then view it with the normal page read view, that doesn't require parsoid to reparse the page, and thus until parsoid parses it, the linter errors will not be updated. One way I trick the page into being reparsed, instead of just being in a job queue that is delayed, is by switching between wikitext and VE and back, which forces a reparse for VE to display the page. At least on my local machine this works, and I suspect it also works on production.

My understanding is that the Reply, Edit, and Subscribe links are being brought into compliance with the MediaWiki style guide at https://design.wikimedia.org/style-guide/components/buttons.html#type-quiet-buttons. If you have a style guide, you should either follow it, change it, or get rid of it. If you have one and don't follow it, it is useless.