@Demian From the [[ URL | patch demo ]] linked by you above in latest Chrome/macOS:

@Jdlrobson No, that's far too risky with our plethora of interfaces – special pages, gadgets other user generated content.

Resolved in https://github.com/wikimedia/wvui/pull/34

Additional screen from demo to show the expected mid-term outcome (as long as personal menu isn't in place):

Sharing here instead of T256373, with patch https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/585629 in:

Any slotted content is risky to me, we don't want a button that can carry an iframe to make the most extreme example.
What do we expect for a button to contain. Nothing interactive, nothing block.

We'll also need to update VE ('s toolbar) to make up for the toolbar not leaning against a border any more…

@JTannerWMF Sure. That task and its patch are follow-ups to T214477, have linked the wrong task in the patch last night. Let me know if you need any further clarification.

@Huji Are you thinking in context of link colors, I'd assume? This would apply to work done in Desktop Improvements project. Please also consider T153043 as related task.

Figma's Storybook integration needs to be in our focus as well, this could be very powerful for upcoming WVUI work.

@Sarai-WMDE Note, the updated progress bar styles with box-shadow have been rolled out with v0.39.2 and are live.

Thanks @Sarai-WMDE and @schoenbaechler for the inputs here.
It'd be interesting to hear about the “felt” performance on larger Figma files from @Sarai-WMDE @Charlie_WMDE …?

There truly are. In Product we adhere to WCAG 2.0/2.1 level AA as baseline.

Putting aside some thoughts about ideation and contributions to that task (see description history and patch set history), repeating, what means "give credit", what is the expectation here?

In T254195#6265724, @Demian wrote:

In T254195#6265218, @gerritbot wrote:

Change 601497 merged by jenkins-bot:
[mediawiki/core@master] mediawiki.mixins: Add .mixin-clearfix()
https://gerrit.wikimedia.org/r/c/mediawiki/core/ /601497

@Jdrewniak It was forgotten to give credit to my work in this patch. Now that the commit message cannot be modified, what do you suggest to make up for that missing bit?

@Legoktm Thanks for the pointer, vaguely remembering reading through the comments in 2014-15:
There were two different questions discussed:

1. Do normalize style rules belong into core
2. Does normalize as external component suffice core's requirements to be added as library

Could one expand: “The most performant byte sizes and rendering. This derisks a major concern for the project as much as possible.” What risk do we have when relying on RL? How big is it, where are the byte size comparisons for this? Is this a known shortcoming? Asking as this should be flagged elsewhere (MediaWiki-ResourceLoader) if it hasn't already been.

Status quo:

@Demian In both of your demos, float and flexbox the indicator shrink with overlong titles.

@Iniquity I agree with you, but bumping up the font-size would be a too-narrow solution, as those buttons have all kinds of issues, including not following any Style Guide any more, nor any of our interface guidelines. But given that MediaWiki community is a different one than Wikimedia, it would need an agreement from a lot of stakeholders to move this forward and this task would need to have widened its scope or be part of a larger task addressing above.

@Demian Please don't reassign tasks and don't add to resolved tasks. That's an anti-pattern! And with “please” I mean don't do this. It makes them really hard to set into specifc timely context and leads to unnecessary confusion. If there's additional work needed we can always open another similar one and link to the original.

Flexbox doesn't seem acceptable to me from current browser support matrix.
Even in IE 11 the support is more than wonky. IE 9 & 10 would be put into graceful degradation position instead of solid support or progressive enhancement, which is our preferred approach with CSS.

@Nikki This tab navigation is workable with arrow keys. This is mentioned in the ARIA Authoring Practices for Tabs in keyboard navigation as desired behavior.
With no further arguments in, I'll declare this “invalid”.

Adding some notes: The sectioning element header now features label and sidebar navigation mw-sidebar before the sectioning header, which should be the logo. This is currently necessary to achieve a logical tab order. But we should keep this on the radar if there is a solution around this having logo first and then tabbable sidebar button connected to sidebar contents.

From the task description, there seems to be a misunderstanding in what *-system-sans refers to resulting in a misdirected request for consistency:

@font-family-serif -> @font-family-system-serif
@font-family-monospace -> @font-family-system-monospace

serif in font-family-serif refers to the generic font family, that is chosen by the web browser and writable by the user. Some browser rely on so called web fonts that are system-independent for historic reasons, like Arial or Times/Times New Roman.
*system-sans refers to specifically chosen font stack of Operating System sans serif fonts that are stacked up so a user in a browser on each of the major (more specifically mobile) operating systems should see the site first in its system sans serif font, not a generic one.
Therefore renaming @font-family-monospace to @font-family-system-monospace is misleading!

@Niedzielski Please expand on ”Component can wrap any slotted content.“ What functionality do you have in mind?

@Demian We need to toggle a dynamic -active class for the button additionally to the keyboard treatment. Currently it's not completely off without through the button icon change, but it's also not very friendly UX.

Have shared on patches, will repeat here: From my perspective, custom scrollbars are a no-go. In contrast to everything within the canvas, scrollbars belong to the operating system and shouldn't be customized in wide-ranging project with most diverse audiences like ours ever.
It's a nice proof-of-concept, but we would sign up for a) confusion for average users seeing the otherwise rarely customized scrollbars and b) even the browser support is so low that it ends up as a customization that only shows up for users in one browser and as soon as they change device they need to re-orient themselves with something essential like a scrollbar.

@Jdlrobson @matmarex I'd be in for this, but it's also clear that all Desktop Improvements have priority for me over this and we basically have just 1.5(?) weeks left…

@Demian, the sidebar button is a custom element and is supposed to follow our own WikimediaUI focus styles as seen in OOUI/WMUI theme button demo for example.

Thanks @Bkudiess-msft! :)

@Jdforrester-WMF Yes, OOUI v0.39.2 – upcoming.

Putting on low, as there doesn't seem to be agreement by core maintainers on how and what way to proceed and given the refocus of resources, it doesn't seem appropriate to leave this as 'high'.

@Bkudiess-msft If you write "Bug: Task number", here "Bug: T253406" in the line before change id, Phabricator task will be automatically notified of the patch. Then you don't need to ping @Aklapper with the patch manually. I'll update the patch for your future reference. :)

My open questions in T253598#6193715 remain, the approach of preferring proprietary high contrast mode over any other mode and environment isn't sufficient for our scope and reach. If we can't address high contrast mode focus differently (and without a lot of extra code), taking away custom focus behavior will not be merged at current understanding.

Thanks @Iniquity for the proposal. It would be helpful to have this comparison also for a mobile canvas (375px).

@Krinkle Given that the release cut branch for REL1_35 is around the corner (July 13th), it seems preferable to wait for the final go until then to me.

In T254851#6220117, @Demian wrote:

Although not focused, the<label> element also applies label:focus {...} styles when the <input> is focused. Reasonable, but can be misleading.

@Bkudiess-msft Is this role=option behaviour applying to Narrator only? Or across products?

Thanks for taking care of it, @MusikAnimal!

If you look into the child tasks T255229 and T255230, you'll already see patches, that are similar to what's needed to go further. Do you have more questions?

I'd think in certain processes a simpler handover to development could be also a benefit. What Zeplin tried to cover.

The modifier colors have been added to WikimediaUI components overview in https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/378

Hi @Abhir-24, thanks for reaching out. Have you already read through https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker and made yourself comfortable with our environments?

I'd prefer an OOUI release tomorrow.

Repeating from patch set, @Bkudiess-msft please expand a bit more on the role parent > child relationship and what is missing, what would be gained and how to tailor this to the general library and Tool applications. With that patch we would change <a> to role=option and this is not allowed for <a> elements. Was too quick in my comment on patch with contradiction of <a> and role="option". It's actually allowed, which preceeded ARIA 1.1 and were now allowed. Though we might have tools not carrying <a> as element.
See for example VisualEditor's use of tools in the toolbar. https://en.wikipedia.org/wiki/Front_end?veaction=edit