Searching for
method: 'alert' yields 0 results
method: confirm yields 0 results
method: 'prompt' yields 0 results

It seems useful to me to add role=alert to errors, warnings seem more to be cautious when we alert screenreader users, as it completely stops the page or task flow.
With OOUI MessageDialogs labelled under “Quick alert” in the demos, it seems necessary to look into current applications before adding such disruptive behaviour. A lot of those in-production could actually backfire when changed upstream.

Thanks @Rxy!

Thanks @alexhollender for clarification. In case I've been unclear in the task description I see a flat hierarchy currently as best option too – because we're installing a level that we barely explain in the components itself, nor is it usually used in context of applying our components. But the expanded variant seemed to be my understanding of our conversation as alternative option as well.

@Etonkovidova Please give this another take. @Nikerabbit and myself have resolved this side-by-side.

@alexhollender I saw your comment above too late, the step proposed by @Pginer-WMF made sense to me and has been merged via https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/300 and deployed.
We need to fix the question on flat vs extra structure level before moving on with further changes.

That sounds like a good intermediate step, it needs more thinking with T237781 altogether.

The section has been published in https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/298.
Putting this on resolved and will take further, unresolved inputs over to a follow-up task.

In T228764#5578733, @schoenbaechler wrote:

Thanks @Volker_E, configuring it with svgo.json sounds like an excellent idea!

Rightful settings files' content captured in

From conversation with @alexhollender, he reviewed exemplified Links:

Somewhat related T232395

With the latest updates of the Design Style Guide repository, I'll close this mock.
The Sketch overview file of the “Resources” section is the source of truth together with its SVG copy/companion.
Instead of keeping this up-to-date, please subscribe to the GitHub repository.

This also implies bumping up h4s, h5s and h6s slightly, while we're coming close to h3s 13pt with the current patch…

From conversation with @cmadeo, she reviewed exemplified Checkboxes:

• Use clearer in-image labels for checkboxes “selected”/“unselected” vs “neutral point”
• Does “Designing” make sense in the current structure when it's a repetition of introductory paragraph?

From my POV we also would like to provide an overview of some of the main design decisions without getting to abstract in order to share openly the design, internationalization, usability and accessibility thoughts behind…

@cmadeo Should it follow the same logic like the ones underneath and be full width on these canvas sizes or all smaller and centered?

Fixed in https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/279. Deployed earlier today.

A more future-proof solution has been added in https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/281 with a Grunt replace task, ensuring sans-serif fallback across components.

How's the behavior on tablet? Same?

The repo has finally deployed after ~2weeks being stuck in T235677.

We should follow general guidelines in such presentations, as Design team we need to follow a minimum of guilded “care” on officially published documents IMO.

Are we sure this is helping readability and current use cases of these pages? Could we eventually add a user icon to make this simpler scannable?

Is forced line break or overflow ellipsis better for summary/titles? How are we dealing with information “loss” when ellipsis is used?

@alexhollender For completion, here are manuals how to inspect print styles in Firefox or Chrome https://stackoverflow.com/questions/47877112/firefox-57-quantum-emulate-print-styles/56182372#56182372

For me the question remains, if the context for using the 'check' icon is sufficient as metaphor for Publish in Japanese or Korean. In contrast to a checkbox, this use case seems to have the potential to be confusing. I'd defer to a quick user test in affected languages.

This ^!

@alexhollender Picking this up again after the ping today:

@Pginer-WMF Inlined icons and colors are now available for review at https://design.wikimedia.org/style-guide/components/text-inputs-and-textarea.html

Same here, both @mmodell and @Dzahn have provided valuable input and hands-on help extensively.

It would be very good to get clarification if Git LFS is going to be supported long-term or not. @20after4 @akosiaris

Related T232494

ToggleSwitches should only be used in settings where instant effect is possible. Unlike AMC mode

Thanks @Pikne for reporting!

Fixed in https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/274

@cmadeo Your turn, please.

Thanks @Dzahn and @mmodell!

There has been somewhat related discussions to make “normal” Vector search's a) OOUI b) autocomplete more useful. This got stopped AFAIK with search team priority changes. Advanced Search was developed by WMDE and integrated a few of the newer experience features, that were discussed, but Vector search is still lacking.
Right now it seems this task is touching too many things to be workable. @Jdlrobson Do you think that

• normal Vector search should disappear if advanced search is browsed or
• normal Vector search is missing better autocomplete?

@Rxy Thanks for your patches, would you provide a before/after screenshot?

Note: 'indeterminate' has been reflected in latest update to Style Guide https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/268 – it's now available in Components overview Sketch file and SVG and will be available at https://design.wikimedia.org/style-guide/components/checkboxes.html once T235677 is resolved.