@Pginer-WMF We could think about this and I have thought about it, for now the patch is just amending the current status. There's a few open questions I would like to clarify with my OOUI peers first, it would be a pretty stupid widget and it's not clear where to deliver it from performance perspective pov. And there's also T163879 , which we should have clarified and resolved first as well.

CodePen now also includes small variant and variant with inverted colors for dark background usage.

@Ryasmeen Although I've already put this on resolved, please have a look after next OOUI release (next or second-next week).

@ovasileva I appreciate the flexibility and the communication which led to above decision. We'll be able to use @alexhollender's icons in a different context. Here, the problem statement and the status quo of grouping links is not fully clear as the current interwiki grouping seems arbitrary at best and the proposed solution would confuse majority of our readers.

@jmatazzoni To be very clear, we're talking about this occurrence of the sentence:

Resolved by https://github.com/wikimedia/WikimediaUI-Style-Guide/commit/043edc9559024eb4ad56d2cf2da36de85c7aa823

Resolved by merging https://github.com/wikimedia/WikimediaUI-Style-Guide/commit/043edc9559024eb4ad56d2cf2da36de85c7aa823.

Merged by @Ladsgroup.

Patch at https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/132

From today's Design Review meeting, we'll stay for now with the current layout and iterate if necessarily of the indentation or a possible new line alternative. Problem with indentation solution is, it would be language-dependent, and not i18n friendly.

@Nirzar “Visual Style – Overview #5” is missing in the description (newspaper and citation). Also “Visual Style – Overview #4“ (style tile) seems to use a low-contrast type.

One small question: Dealing with indentation, separate line and indentation of text description?

In T195053#4417888, @matmarex wrote:

In T195053#4417543, @stjn wrote:

2. Is CSS-based solution entirely accessible? Here it says that IE11 doesn’t read CSS content.

I don't have Jaws or NVDA, but with Windows Narrator, it indeed doesn't read it. I am not sure if it is worth the effort to support this browser.

We should probably add role="button" to the <input type="checkbox"> though!

Another update with the overview palette not showing the shortened color titles only giving a mood – overthrowing my own earlier take in T167190#4394683
I've tried several ways to reduce the number but nothing makes a real nice overview, as we also shouldn't repeat the mood representation of “Visual Style” the third time.

@Prtksxna The redirect of https://livingstyleguide.wmflabs.org/wiki/Main_Page is incorrect as it results in a 404: https://design.wikimedia.org/style-guide/wiki/Main_Page

@Hagarshilo There's this related task T166560: Consider changing :hover tools and menu background to use Accent90 – we could pick it up again and implement it in course of the tutorial. In any case we should stay with the library's default styles as much as possible in order to lower implementation and maintenance cost of the tutorial and also make it reflect the library defaults as good as we can.

Points 1 & 2 have been resolved since this task was originally filed.

@Qgil There's no clear consensus on

• where such grid (helpers) should live (MW core probably, but then again where and as what),
• what technology to build on top as there has been massive standard support improvement additions in providing more powerful (Flexible Box Layout) or simpler (CSS Grid Layout) solutions in this area
• and last but not least, who's to implement & maintain it given the multitude of necessities to care about and test against

I've taken this as motivation to update T75972 and amend the code/design template. Note that we were also providing product owners/designers a choice between different loading indicator base sizes (16px vs 12px).

A follow-up note on mobile app discussion at T75972#845549
Apps should make use of the OS specific loading indicators if any possible.

Related task: T95137: The progress bar should accelerate as it nears completion

Hidden by display: none provides nothing. From my expertise in recent years, search engine crawlers ignore hidden elements (or even go beyond and tag it as spam and assistive technology completely hides it to their users. Even dynamically shown elements might run into both issues depending on crawler or AT.

@Petar.petkovic Above patch only partially converted the extension. There's another form under showCredentials() which hasn't been updated yet.

Ok, I think Base30 is a good compromise as long as designers are aware of the context and consider upping contrast if indicator is used on a dark(er) background in order to stay well recognizable for affected users.

@Jan_Dittrich The moving dots are currently our default loading element for in-page view loading content, but it's not part of OOUI as widget. Please see also T75972 for general loading indicator discussion.

From a conversation in Contributors Design meeting this week, let's declare the 3 dots animation our in-view loading animation.
One small amendment that we should be making is increasing the contrast slightly, from @colorGray12 (#c8ccd1) currently to #54595d in order to ensure visibility.
We can still revisit this later for improvements or alternative animation proposals.

I've been able to reproduce this on Firefox/Windows 10.

Another comparison:

Before	After

(Button appearance not yet completely optimized, border-radius, 0 margins missing)

@Ryasmeen This has been improved by @matmarex and made it into OOUI v0.27.2. Would you compare the task description with current implementation on https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:Preferences&ooui=1