@aude, the first h4(?) in the notification has padding enabled, adding too much vertical space on top. We should tackle this for a harmonious layout.

Coming to the designs first time when reviewing the patch, we've added the non-inline progress bar as a drop in replacement for OOUI's. Which is a single page application similar use case – visible when loading VisualEditor.
The new design does move away from such ability of positioning it seamlessly. Has this use case been incorporated into the design process?

I only saw this ticket in aftermath of the already merged patch: I don't understand the advantage of the many messages states. I have the fear, that they are more acting as banner ads, then as real system messages. Having folks just ignoring them altogether instead of setting apart from the banners in our environment.
Also in the past we settled to limit "progressive" to interactive elements, while it's now used as static emphasized color.

@Sneha vertical-align: middle is a bit wonky from implementation. I guess you won't be super satisfied with the desktop result either. Maybe we should consider tackling desktop/mobile different. I've merged the patch now, as we might also need to add a small refinement patch on it after next Codex release.

On MinervaNeue we've had the OS font stack back 5 years ago and I assume it got lost with the introduction of Codex design tokens as replacement and internal discussions to set it accordingly for both, Vector and MinervaNeue (Vector 2022 launched about the same time as the Codex design tokens as mediawiki.skin.variables.less architecture and I vaguely remember that we wanted to identify using the OS stack on Vector 2022 (TypeaheadSearch was one of the pillars there) after dust has settled.

In T418504#11687979, @DTorsani-WMF wrote:

@Volker_E thanks for all the additional information.

For Minerva, when you say "changing this first", are you referring to removing the custom setting of @font-family-base to @font-family-system-sans? We can't do this until we the second acceptance criteria item.

Reminder 2nd acceptance criteria is "Update @font-family-base to point to @font-family-system-sans"
That's not quite true. The tokens system in MediaWiki enables us to set certain properties specifically for skins, so we can set Minerva Neue to the OS specific sans-serf.

Regarding your note on inherit, this is a good point, but currently in Codex, we rarely are setting a font-family on components to anything other than inherit. So are you suggesting we should explicitly set font-family on all components to @font-family-base once we do the second acceptance criteria item?

@Talhasajid849 In case you won't have time this week to address the few open needs on the patch, Foundation Reader Experience team would take over and finish the patch (with you remaining as co-author).

@Sneha So it should be the same position (baseline? the images shared don't make it look like baseline) in both mobile and desktop? Or different?

Invalid for removing user banner UI T418478: Implement gray bar changes for Vector 2022

@Sneha Shouldn't the center of "B"eta be on the mean line of saved pages?

The patches should have been on a sub-task, visualizing how many different inconsistent angles have accumulated in Codex and tokens application downstream:
Other just discovered issue is that CdxTooltip (+its demo) and WordbreakDemo both use system-sans without further explanation/documentation.

To the other pieces and questions here:

• We actually had the OS specific font choice. We've HAD enabled it in MinervaNeue before with WikimediaUI Base (the Codex design tokens predecessor). Even though I gave a +1 on https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/886931 I don't remember if the OS specific choice was replaced to sans-serif due to browser or i18n quirks. Maybe @Jdrewniak or @Jdlrobson could shed a light if there were unintended consequences.

@DTorsani-WMF For completion: there was one more thought about the token structure back then. There might be skins, that want to have serif as default. So we would define both a serif choice and a sans-serif choice that is not the fallback sans-serif but something like 'Helvetica Neue', 'Helvetica', 'Liberation Sans', 'Arial', sans-serif;. And reference this in the font-family-base.
The deprecation came mainly out of downstream users getting it wrong and directly referencing font-family-sans instead of base.

@DTorsani-WMF In my experience it's simpler to reduce similarities before going into making design and code impactful changes in order for orienting reviewers faster and gathering acceptance for such changes. But it's just a proposal from me.

Before answering your first question, I want to start outlining best way to untangle this historic hairball:
My 1. attempt would be to remove the deprecated font-family-sans as it's a duplication of font-family-sans--fallback to simplify the conversation. I'd add this as acceptance criteria here. Refer also to T331403: Replace legacy value tokens in Codex, OOUI and downstream; originated in WikimediaUI Base
If we look at the current usages in Wikimedia deployed places Vector "typography.less' and print stylesheets in both, legacy and Vector 2022 are the only places where it's in use.

• One idea was to have a print font-family token (actually a number of tokens separate from screen tokens, but that would mean a bigger change and I don't see the budget right now.
• We could also replace the deprecated token with the new equal value token --fallback in print stylesheets with a comment about future print tokens task, and consider evaluating base token vs sans token value in typography.

To lighten up this divergence historically:

1. the OS stack @font-family-system-sans: -apple-system, 'BlinkMacSystemFont', 'Segoe UI', 'Roboto', 'Inter', 'Helvetica', 'Arial', sans-serif, preferred from Design System point of view, has resulted in some unintended side-effects and community confusion once tried.
2. In MinervaNeue it has had the biggest impact with least community slashback, hence we tried to include it there early.
3. For certain environments (not only, but also Vector) @font-family-sans--fallback: sans-serif was important to provide to be error-safe.
4. Deprecated @font-family-sans: 'Helvetica Neue', 'Helvetica', 'Liberation Sans', 'Arial', sans-serif was the historic alternative to more modern @font-family-system-sans
5. We've never had the time to really pull the trigger on making Vector follow the OS stack due to needed involvement of community liasons and a process to make community understand its improvement with other design priorities in bigger need, but that has still been the outset design system goal.

@Talhasajid849 Thanks for your patch, as I've stated on the patch itself, the rendering is already favorable to the status quo.
I've provided a few code quality and hygiene inputs on Gerrit for your attention.

This has been published in the first iteration at https://www.mediawiki.org/wiki/Readers/Contributing_to_Readers_Projects_in_MediaWiki

For completion, pls note that Extension:VueTest has been archived in the meantime too. https://www.mediawiki.org/wiki/Extension:VueTest

I had a short exchange with @Jdlrobson-WMF by the issue raised by @Jdforrester-WMF 7 days ago. For repos Popups and MobileFrontend the external dependency is completely obsolete with Storybook tooling gone. For this and the mismatch question, I'd see both questions as new tasks.

@Jdforrester-WMF Yes, but not as part of this task. :}
What does "good/approved version" mean on the libup overview page?