This only happens in non Zebra, and will most likely be fixed with https://phabricator.wikimedia.org/T351830

This is fixed

I checked in with @JScherer-WMF and he confirmed that rendering the full form just with disabled radio buttons (https://phabricator.wikimedia.org/F41514107) would be preferrable to a skeleton loader which hides the content. Instead of making a new task for implementing the skeleton loader, I made https://phabricator.wikimedia.org/T351562 for the new disabled radio button design

Thanks for putting this together @JScherer-WMF! The video walkthrough is v helpful for understanding these designs. I had some initial questions/feedback

This is all done except for 'Personal tools'. Instead we use 'user links' and 'user menu' to describe the dropdown. Personally i think 'Personal tools' still makes sense considering thats the original name for that section, I dont really know why we moved away from that naming. However, updating things back to personal tools will be more involved due to the number of classes and the fact that core also uses 'user-menu' in the menu data

@Jdrewniak I also think the more important task is to clarify the naming of all the TOC states, I think thats a far bigger source of confusion. Here's my understanding of the terms we have in our codebase already, and why I think we should use them this way.

@Jdrewniak can this be resolved or updated? I know we dont have the CSS structure you described in the task description, but we do have 3 files for the TOC ATM.
TableofContents.less is equivalent to tableOfContentsBase.less as you described above
layouts/toc/pinned.less contains code for tableOfContentsSidebar.less
layouts/toc/unpinned.less contains code for tableOfContentsHeader.less, tableOfContentsStickyHeader.less & tableOfContentsPinned.less

@Jdlrobson This is fixed in Zebra! Should I just close this then with the assumption we are going to roll out zebra?

I also discussed this with @JScherer-WMF , we identified that the bolding of the pinnable element headers and the pin/unpin buttons from Zebra can stay, as they are improvements to the design.

The alignment also seems to be caused by whitespace next to the nearby and settings text. The new styles dont rely on whitespace to handle spacing.

This has been fixed at some point, not sure when

Other than T323141, these are the other outstanding Zebra tickets. In my opinon they seem to be all low priority, or would not be an issue after the style changes. I.e. T336048 & T343250 will likely not be an issue after the zebra paddings are removed.

@Jdlrobson I think we can just close it, its not a huge benefit. The main benefit is to avoid having a more complicated markup when its not really necessary (i.e. when JS is enabled), but this isnt a huge deal.

@Jdrewniak is this fixed with zebra?

Due to the scope of refactoring included in Zebra that @Jdrewniak already mentioned, it seems unfeasible to move the refactored bits into Vector's styles. It seems far easier to update Zebra to match (or mostly match) the existing styles, and go with Zebra as the default going forward.

In T345653#9167573, @Jdlrobson wrote:

@bwang I was wondering if this code can be cleaned up - do we still need to define the size? Can we at least remove the reference to mw-ui-icon-large?

	// Icon is larger than mw-ui-icon-large
	// Thus we hack it to get it to the size we want.
	.popups-icon::before,
	.popups-icon {
		background-size: contain;
		width: @width-popups-settings-help-icon;
		max-width: none;
		height: @height-popups-settings-help-icon;
		margin: 0;
		padding: 0;
	}

In T344022#9157882, @Jdlrobson wrote:

I'll sign this off tomorrow after the branch cut when I can merge https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/955403

For any icon rendered via JavaScript, use Codex mixins. e.g. skins.minerva.icons.images.scripts.misc and skins.minerva.icons.page.issues.*

@bwang should I open a new task for this? It doesn't look like this was done?