@Krinkle I'd preferably get rid of the whole .TablePager class and just overwrite .mw-datatable in TablePager.less if it were loaded in the right order in RL. It's such schematic mess and after staring at all code applied I see 0 to maximal minimal (!) use cases for it.

Also, let's state clear that .mw-datatable changes should probably go into a feedback process with community, but we can use .TablePager as testbed for possible changes.

@alexhollender It might be advantageous to leave a slight touch of purple in the table headers in order to not fall for only grey and blue in those data tables. #eaeeff seems like a good choice to me.
Example of current mw-datatable usage (enwiki): https://en.wikipedia.org/wiki/Special:Tags
Example of current mw-datatable TablePager usage (enwiki): https://en.wikipedia.org/wiki/Special:AllMessages

We should not only do this for TablePager, but for .mw-datatable as a whole.

Alternatively, we could stay with normal running text color Base20 for now:

Can build on top of several findings from T117737: Convert Special:Log to OOUI here.

Current browser implementations seem to have serious appearance flaws, for example browser stylesheet appearance can't be unset, therefore putting on stalled.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress

@Jdforrester-WMF The other possibility were to use same repo icon under other pack as well…

Added feedback on the patch about unnecessary link appearance differences on desktop/mobile and padding…

@Krinkle title can be used for [[ User agents may, however, for example, display the ‘title’ element as a tooltip, as the pointing device moves over particular elements. Alternate presentations are possible, both visual and aural, which display the ‘desc’ and ‘title’ elements but do not display ‘path’ elements or other graphics elements. | tooltips or alternative presentation like in a screen reader ]].

Coming from Design Review, we'll follow last comment to improve readability of 'musicalScore' and go with alternative here…

@Jdforrester-WMF Could you provide a bit more detail on this?

Might be a Chrome specific issue. Don't have the time to deep-dive into it right now. Definitely the fill <g> wrapping <title> and all paths seemed to have thrown it off, even though the spec says differently (example of a g wrapping a title

Moving 'layouts' out to explicit page would reduce DOM nodes of widgets from more than ~6300 to around ~5100.
Sounds like a useful next step.

@Mooeypoo Quick insight on why second rule exists. That's a workaround for SVG issues, first one should load PNG, second one SVG only in browser that support this (except IE 9, which also get's fallback). It's a little bit a joke here, as the selector includes ::before which makes this rule ignored as invalid by everything aside IE 9 anyways). Have to dig deeper on what's going wrong here though.

@Huji Take note, that we currently are not yet using Accent50 (#36c) for normal links on Vector and the argumentation might therefore need to be adapted.

An issue I'd careful with is putting the blockquotes underneath “list”. It's often close to the lists in other interfaces, but I wonder if people will actually assume or find it there. I wouldn't. Point taken, that it might be one of the least used features anyways.

To the icon: Blockquote command is basically done in every Rich Text Editor GUI (email/web) with the beginning (English!) quotes “ that we use for “Cite” function in VE.
Gmail as example

To be more clear, ARIA 1.1 and WD 1.2 are defining role=combobox related HTML concept to be select.
While the button and haspopup should work for majority of screen readers to navigate dropdowns sufficiently, a native OS select field would be read out as combobox as identified by @matmarex use of Narrator in T212186#4834710 when the screen reader software actually follows the spec.
Therefore a combobox with added attributes and a readonly textbox role that exposes the default or currently selected value.

That's confusing as the originals were not aligned and cut off as they overflowed the 20x20 canvas and I've (thought to?) set up 'snap to pixel' option. Thanks for double-checking.

Lingo updated as well.

In T209259#4753319, @Greta_Doci_WMDE wrote:

@Jan_Dittrich @Volker_E  I pulled https://gerrit.wikimedia.org/r/473155.

I checked the look of the item page with Jan, we noted that the pencil icon was changed which is fine. In the issue description you also mention Save and Cancel icons, seems that they have not changed. Is this correct?

Save/Cancel

Edit

Thanks @Etonkovidova for the screenshots.
Answering (1): That's our current standard interaction pattern, Accent10 for actively clicked/selected/toggled interaction elements, Accent50 for primary, progressive buttons.

Turns out, there's a ton of icons of wikibase-toolbar, that are better tackled in a task on its own: T209259: Wikibase toolbar features outdated icons

Above patch was mistyped, doesn't belong here.

Button misses type=button

Result assumingly from I2d1213c69b03d4ef4d32438867033d98aa187a11.

@matmarex First guess, some forms are searching for the first button instead of the submit button when 'enter' is pressed. Now that Dropdown features a 'button' internally, 'enter' is activated on that.

@Ladsgroup Dialogs seems one of the biggest concerns, what other issues do you have in mind?

Thanks @SamanthaNguyen!