It appears that, in order to bypass the no-wrap behaviour of the OOUI button in this (or any) special page, we'd have to write separate style modules each time. It is unclear if this is a fair trade-off to solve potential edge cases (we're trying to cover for all localizations in minimal viewport sizes). From a UX perspective, it sounds reasonable to anticipate and prevent experience and layout issues, but the impact of the fix appears quite small compared to the effort. We require a product decision from @Lydia_Pintscher here.

Answering in line based on recent decisions/actions:

This looks good and matches the latest specifications described in https://phabricator.wikimedia.org/T165870#8854823. Thank you!
There's only a last change needed: in order to prevent the button from overflowing the layout due to the length of the copy in certain languages, we wanted to allow its label to wrap. This might be a matter of removing the property white-space: nowrap;. Would that be feasible?

Hey @Iniquity. The table tried to list some of the main styles in production and provide their closer equivalent in the new typographic scale. All in order to validate the convenience of the new styles. I think that the body font size in the latest version of prototype is just an exploration of another initiative (the possibility of increasing the article body font size from 14px to 16px). This would be enabled by the system's styles if desired, but the final informed decision will need to be made by the Web team.

Thanks for the feedback, @Manuel! I was actually planning to reach out to you about this. With "always active", are you referring to the pulsating animation? We can define how many iterations we want the animation to have. For example, it could only pulsate twice, then become idle. The popover is only displayed on hover. It's very similar to the icon in that sense, but if you're concerned about potentially creating a distraction (very valid point) we could definitely go for the static icon.

Hello there! I have a couple of questions related to the pulsating dot onboarding pattern, which we'll be reusing soon in the context of Wikidata. Thanks already to whoever jumps in to help 🙏🏻

@noarave as discussed in an off-line conversation, I wonder if it would be possible to remove the license text from the first step and only include it in the last part, rather than dynamically changing the copy. After all, as Itamar mentioned, no changes are actually being applied until that last screen is reached. This sounds like a simpler solution.
The copy of said message would be: "By clicking "Publish changes", you agree to the terms of use, and you irrevocably agree to release your contribution under the Creative Commons CC0 License."
Please let me know whether this sounds feasible. Thank you!

Hi @AAlhazwani-WMF! The Card component demo is actually displaying the correct border color (border-color-base). Unfortunately, the specs weren't updated to reflect that design decision. I'll correct that right now in both the exploration file (a new v7 of the component will be added) and the component library. Thanks so much for the catch!

This is how the current component looks on mobile (Chrome on iOS) due to the missing icons:

Pending efforts related to this topic. We should:

In T165870#8822927, @ItamarWMDE wrote:

Task Breakdown Notes;

• Is it actually a user requirement to have different copy depending on the context of the Wikibase instance? @Sarai-WMDE @Manuel (In reference to the note by Lucas)

Thanks, @Nikki and @thiemowmde, for your input on the button label wrapping. I agree with your points and thus updated the task description accordingly. Heads-up to @Manuel.

I created a subtask to fix the placement of the language button in the Query builder on mobile devices. This should prevent the logo from overlapping with it in smaller viewports: T335596: Query Builder: Language button should move below logo on mobile devices.

Unsure of what to do about this parent ticket now that all related tasks have been resolved: should validation happen after the component has been released and is available in the Query Builder?
Let us know your thoughts whenever you have time, @Arian_Bozorg. Thank you!

Verification done: The issue is not reproducible in master.

All issues seem fixed. The verification of mobile LanguageSelector was done in master with help from @noarave.

Validation done. The Language Selector component is displaying the correct visual style and mirroring behavior depending on language directionality 💯
Tested in Safari 15.6, Firefox and Chrome 112 on macOS Monterey.

In T329488#8782147, @Sarai-WMDE wrote:

Keyboard navigation appears to work correctly. The specified keyboard shortcuts were tested in Netlify (https://894028--clicky-sparqly.netlify.app/) using Chrome v112, Safari v15.6 and Firefox v111 on macOS 12.5.1.

Nevertheless, the tested version of the component doesn't allow selecting an option from the menu on click (see gif below). In all browsers, the menu also presents a scroll bar that shouldn't be there (this is a known issue).

These issues should probably be reported in separate tickets (in case they don't exist yet).

All issues appear to have been fixed.

The issues seem to be fixed! I was unable to reproduce them in Safari 15.6, Firefox 112 and Chrome 112 on MacOS Monterey.