+1 to Base90

Replace images (:

Before	Initial proposal

…and https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/143

Sounds reasonable!

If I understand @alexhollender's last comment correctly, some of the sites (Facebook, Yelp, Pinterest) use not one, but two of their brand colors. #eee is not part of our color palette, I'd consider #eaecf0, see https://design.wikimedia.org/style-guide/visual-style_colors.html#base-colors

See https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/142

@ovasileva It's already on the way, https://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences
will be rolled-out on normal deployment train starting next Tuesday to the wiki near you.

@TheDJ Could you refine? We have implemented them in the way they were in old interface with correct ARIA roles, see T148030: OOUI indexed dialogs (IndexLayout) / tabbed navigation (TabPanelLayout) is not accessible

There's the discussion of “Signature“ being renamed, we could consider moving it there and depending of MW showing real name as label addendum.
The bigger issue in my opinion is, that it's not even clear in the out-of-box experience where it's used for.

@Jdforrester-WMF It were still an issue for out-of-the-box installations. For my understanding, how would T203727 resolve this?

@Dvorapa Thanks for pointing those out.
Apart from T65987#4594520 where I've commented just now, other ones are either possibly more complex refactorings and/or in need for further user testing and are not blockers for the important OOUI transformation task T117781. Nonetheless, work on subtasks here will continue, for example on T203727 or T203992.

See also related task T203727: Restructure and improve 'Basic information' section, which aims at refining separation of concerns of this salmagundi of options within “Basic information”. Currently, I don't see any of the proposals for renaming as clear advantageous over “Basic information” in regards to meta title “User profile”.
“Account management”, “Account details” or “Account information” have the same weakness as “Basic information” – there's information and options underneath one word umbrella, but the options further down like “Signature” would also work underneath the same title, no matter which one we chose.
I'm inclined closing this in favor of T203727 if no further arguments are brought forward.

@Slaporte Initial commit can be found at https://github.com/Volker-E/wikilovesmonuments_2018

@matmarex The point was that it should be hidden on non-keyboard devices, not on mobile (when f.e. you connect a hardware keyboard)!

@Pginer-WMF Could you pixel-optimize (snap-to-pixel) the SVG logos?

@alexhollender It's a double-sided issue. Providing keyboard accessibility to the settings without further refinement would mean an extra tab to go to the next tabbable element each and every time, having a negative impact on navigation for keyboard-users only.
We'd need to come up with an easy way to let keyboard users access settings probably just once per page…?!

Hot from the press: https://github.com/you-dont-need/You-Dont-Need-Momentjs

In T203470#4578589, @Esanders wrote:

Sorry, forgot you put that, but even so I don't think we should hack in a downstream media query to transform left align to top align.

@alexhollender There's two different things happening, the transformation of Special:Preferences to OOUI, a subtask of T180538: Improve Special:Preferences UI/UX. @Ryasmeen went through all settings to capture inconsistencies and the italicized text was one. You can preview it at https://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences?ooui=1

In T164449#4579551, @Nikerabbit wrote:

There is a known usability issues on edits translatable wiki pages, but when that is improved, you would get those improvements too without extra effort.

What's the issue(s)?

@Niedzielski @Krinkle Have added the ones written down, there's at least one argument left out on the .eslintignore advantages, please update the description accordingly.

@Izno The patch above is just removing italicized text, as we would negatively impact the layout of current Special:Preferences by putting it on one line. We'll pick the remaining parts up after OOUIfied rollout is done.

Related to this, the overhaul of the 'help' icon was seen as the biggest “disruption” in T177432 and as such a rather small one altogether. Still there have been requests for a more clear help icon and we've provided 'helpNotice' in v0.28.2 of OOUI.
I had RevisionSlider together with RCFilters T204165 (you can also see it in action there) in mind when adding it to the library.
Please consider it and give me feedback, I'd propose a patch.

OOUI update wasn't my word choice (nor @iamjessklein's) ;), but definitely in need for a reuse of our TextInputWidget standard look.

Not convinced if this is the same issue as the one you merged into? The linked task is talking about context title and description? Or did you check all of them?

@Esanders

In T203470#4575305, @Volker_E wrote:

One thing I'd like to note is, the labels and widgets should align top & bottom in 320px to 481px media query range.

From today's front-end developer group meeting:

@Nikerabbit might be able help us here: We would like to ensure possible connectivity with translatewiki.net before putting more developer time into a solution like Hugo. Are there possibilities to do so?

Can be set to 'resolved' from my pov…

Ok, turns out Homebrew installation of PHP on MacOS has fileinfo extension activated.
That became clear after some trying back and forth.

The two most prominent places where we're going to make use of such icon are
RCFilters

Ok, ARIA 1.0 was requiring listbox, ARIA 1.1 combobox is only requiring textbox or searchbox:

@Ryasmeen @Jdforrester-WMF and myself narrowed the horizontal shift down to a Vector behaviour when scrollbars are appearing and has been the case before. With that we'll file a task and this can be set to “resolved” successfully.

That looks and works much better in my opinion, also given that it's just three options.
One thing I'd like to note is, the labels and widgets should align top & bottom in 320px to 481px media query range. That would circumvent weird px breakout in next line and make labels like “Automatic padding” which got weirdly translated to “Automatische Auffüllung” (<= I have no idea what that should refer to as German native speaker) stay in one line
Status quo in German:

@Deskana To repeat once more, in a technically perfect world we would be able to have handles to differentiate between hardware-keyboard featuring devices and no-keyboard devices, but we don't have the handles (yet).

Putting on “stalled” as we need clarification on layout and multingual quality of the 75 character rule.

Updated screenshot in the task description. Going for standard vertical alignment of labels and inputs for the time being.

It's not only weirdly italicized, it's also a <p> which shouldn't be a child element of a label.

@Ryasmeen Can't reproduce this.