I'm not actually sure what the intended behavior is supposed to be. I'm assuming that the full-width toggle is supposed to be hidden when JavaScript is disabled because that's what happens if you just visit other pages (like article pages, or user preferences), unless that is also a bug.

@Jcubic hi, thanks for filing this bug. The CSS you point to lives in the WikibaseMediaInfo extension in the mediainfo-filepage.less file. Since I can see this whitespace on both legacy Vector and Vector 2022, I don't think it's related to Desktop Improvements (Vector 2022).

This issue is more complex than that it might seem at first, but I think we could investigate possible solutions.

This issue can be solved by implementing the solution proposed in T323141 - Combine mainMenu and toc grid areas into columnStart grid areas. That would provide this sidebar area with a more semantic wrapper element and provide the "sticky container" for the TOC. We can probably remove the .vector-sticky-pinned-container element when we do this too.

@Xaosflux thanks for raising this issue, there was a fix for this merged last week https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/917887 so it should be rolling out to all major wikis by this thursday.

Thanks @Edtadros I've made a ticket for the coordinates issue https://phabricator.wikimedia.org/T336876 other than that, the following are non-issues so I think this ticket can be signed off.

• The very wide TOC is intentional. We made the dropdown TOC able to be very wide to accommodate talk-page better (which typically have longer headings).
• The Village pump template is also a non-issue. It looks like the template on beta is outdated, and the village pump template in production is actually quite responsive.

Regarding the banner looking too small, it does have a 12px font-size (which is inherited from legacy Vector) which looks tiny in certain scripts like Arabic:

The awkwardness is due to the new gray background in Zebra. The yellow banners position has not changed, and the font-size is the same as in pre-zebra and Legacy Vector:

Given we've done testing with Zebra via T335907, I think this can skip QA and go into signoff.

This is relatively safe, single line CSS change, but I've changed the description to note that padding between menu items is different than the line-height between lines of text.

Just FYI I'm attaching any bug fixes related to newly found Zebra bugs to this ticket. The patch above resolved a horizontal scrolling issue found by @Jdlrobson on the Zebra ToC.

@Esanders thanks for filing this issue. I certainly underestimated the risk of changing specificity when structuring the Zebra module in this way. These unconventional scoped imports were designed to let us ship both the new Zebra update alongside the existing styles to production, allowing us to debug the new design as well as run an AB test. We'll explore different ways of achieving that next time.

@Tacsipacsi this looks like an intentional change coming from mediawiki core in this patch mediawiki.skinning: Use Codex DS tokens for colors & border-colors as such I'm not sure if it should be considered a bug.

Thank you for bringing this to the Web team's attention. I did some digging into this bug and it looks like it was introduced in this patch : Work around browser inconsistencies with 'clear' + 'margin-top'. Previous to that patch, the top margin of the #siteSub element was pushing down the indicators as well. Afterwards it wasn't, and I'm not really sure why. Regardless, adding the same margin to indicators independently seems like a more robust solution.

I can confirm that this was introduced in the following patch: Refactor - Prepare existing styles for zebra module.

Most articles on Wikipedia are not written in a way that require the reader to read each section sequentially (in fact most people don’t read entire articles, they skim to a specific section). In this scenario, I don’t see how the position of a specific section in the article (visualized by enumeration) provides much value to most people.

@Jonesey95 It looks like the conversation in T307316 is still ongoing. Although I see the value in numbering the ToC in certain situations, we're not planning on introducing enumeration in this iteration.

Noting that this might be addressable with the required attribute on the input element, <input required/>

@bwang thank you for getting this initial implementation over the finish line!

@Punith.nyk thank you for the contribution, yeah, the phantomjs dependency is pretty bad, it was added to created png fallbacks for the SVG files (7 years ago) and can certainly be removed now, although the SVG output will have to be refactored. There's an epic related to that but no specific task T277404 (I could create one if you're interested).

Per design review with @KieranMcCann,

• Column layout: ToC column & Page tools column should be symmetrical (per the new 24 column grid layout spec, it should be 4 (toc) / 16 (article) / 4 (tools) )
• Header should have a reduced height
• grid gap should be 24px
• ToC height is too big (should have space at bottom equal to grid gap)
• On lower resolutions, content padding should be reduced, but gray background should still be visible

I looked through the repo and found no traces of Storybook left.

Per the A/C I was able to see the new header design on beta with the feature flag turned on:

Out of curiosity (and per @bwang's suggestion) I'm measuring the bytesize of the CSS payload before the excess code is removed.

This fix (finally) went out last week.

I've tried my best to summarize the issues with the event logging in the following ticket T332612. Changing the section ID values to a static value as @Jdlrobson suggests is right way to go, but I ran into some issues just by changing the HTML, so I think the fix might be more complicated than that.