@Koavf First off, which is the browser/platform of your choice? (Asking because the default browser focus varies widely between browsers and operating systems)
We're talking about the blue 2px wide primary blue border on :focus that you find subtle?

@Huji what is your take here? What's still missing from your point of view?

@Prtksxna These links are not labels in the functional sense, you click them and go to a different page. I'd turn the pattern question: When a checkbox has a clickable form label, it should either be above or behind the checkbox. Here we should not apply this rule as it breaks users expectations, therefore the request in T150079 would be falsely applied UI pattern logic.

https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/52 adds missing imagery provided by @RHo and @cmadeo

PR 51 got reviewed and merged.

First off, although it's already crossed-out, where is the specific patch for setting the main content to justify?

It would probably make more sense to either add the patches for the different topics to the task description or add sub-tasks, as the discussion in such large task becomes hard to follow.

First idea without intense testing: Using position: relative; instead with z-index.

PR50 got merged.

With https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/45 this task is resolved.

@Prtksxna Yes, you're right from my understanding. We still want to achieve the best possible outcome which means our default SVG canvas should be optimized for the biggest use case. That's why we've come up with 20 x 20 px canvas.

I don't see the need for core. With TemplateStyles T164879 on the horizon, is there a remaining necessary use case for this as core style?

@Anomie @Tgr First off, thanks for the great work! :)
Have you considered to and if so, what options would we have to make template styles following CSS coding conventions? I guess one of the thoughts behind was to keep hurdles for template editors low to participate and orientate on lax CSS standard.
Maybe as automated step in sanitizing the files?

@IKhitron Yes, guidelines for migration are:

@Aklapper Thanks and updated (removed link here).

@Liuxinyu970226 Thanks for pointing this out!
By help of automated translation, it seems to me, that the main argument is about replacing the class needs editors work best by help of a bot. It doesn't say, that people are opposing the change generally, correct? Maybe @dchan or @chelsyx could help reassuring this?

Captured in https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/50

In de-emphasizing we might consider to put also Charis into the imagery example and just refer to Charter from a typographic-historical perspective in the text.

@Jdrewniak has prepared https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/37 with a slightly different approach taken by @Nirzar.
Two things are missing, that we should add:

• Clear indicators (headings), which meta group the color swatches (“Base”, “Accent”…) belong to
• Still show RGB and HSB values on :hover to make extending the palette simpler for average users.

This has been established as a task combining mixed topics on different products. We've been successfully tackling the technical parts of it, testing and documentation don't need this as umbrella task any further.

@Pginer-WMF's PR is reviewed & merged.

@cmadeo @RHo @Pginer-WMF PR is merged thanks to Jan. Please either provide me with the other images in Sketch file format or –even better– update the now available Sketch file with it as further pull request.
I've put the artboards on a grid (pages are rows, all starting at x+1000px/y+540px) to make overview easier for users. Also the artboards must have lowercased and hyphenated labels to make exported imagery names web-compatible.

@Jdlrobson The li:before would currently not solve anything. With negative left it still puts the bullets (which are circles and not squares) outside the paragraph possibly leading to hidden bullets on small screens like iPhone. Devs note: It also needs position: relative; set on li items.

@Prtksxna Please add a before/after screenshot table to the task description.

Changing over to TagMultiseletWidget as we're planning to T169292: Deprecate & remove CapsuleMultiselectWidget

There's also “16sp text is rendered as 16px” in Typography section that needs to be unified.

Multiple enhancements proposed in https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/48:

• Adding imagery Sketch file to resources
• Adding automatic build step for SVGs and fallback @2x PNGs of all provided images
• Introducing grunt-svgmin for saving around ~200kBs of unnecessary over-the-wire data by default Sketch exported SVGs

Tested applied styles in IE 7 (looks completely the same):

@Nirzar I've started with the implementation of the sketch imagery collection file you've provided (also uploaded here).
Images yet missing:

@Jdlrobson The corresponding task was T155128: Incorporating the webfonts into style guide and it's implementation as it's currently in use at WikimediaUI Style Guide can be found at https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/5

Related: T170329 (@matmarex expected fallback to work there)

@matmarex When exactly does ResourceLoaderImageModule provide fallbacks? Which icons are necessary to backfill then?
Mass copying would simplify the task.

@Nirzar We should definitely use pt for print. It's yet to be defined how we're translating our Style Guide content, which currently has solely focus on screen to something like print.

@matmarex Yes, I was more referring to a concept like DraggableGroupWidget in the demo than any role on those mixins.

It seems most appropriate to have a draggable with role=list and elements with listitem.

There might be elder browser/screen reader combinations where not setting aria-expanded=false as default might mislead. We probably need to re-open this after testing thoroughly.