Re-opening this as new take on T117749 made me think about this.
The dropdowns there are indeed overly long. We could

• use display: inline-block as general rule to make them always only current selected option wide, negative outcome here is that the width changes with each different selected option and might get very small with a short option or
• add a config option to enable inline-block on per product owner selection

Also in contrast to a similar, abandoned attempt for Special:NewPages a while ago, picking a few wikis as examples, showing that the intro text is never very long not distancing the page's headline from the form much:

• https://en.wikipedia.org/wiki/Special:AllMessages
• https://de.wikipedia.org/wiki/Spezial:MediaWiki-Systemnachrichten
• https://ja.wikipedia.org/wiki/%E7%89%B9%E5%88%A5:%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E4%B8%80%E8%A6%A7
• https://commons.wikimedia.org/wiki/Special:AllMessages

@Jayprakash12345 With my primary progressive comment on the patch I meant both flags, primary and progressive resulting in such

Similar to T117740, with T157642: Graduate New Filters UX out of beta on Recent Changes on ALL wikis finished, the scope of this task is now limited to a very small number of cases – as a result readjusting priority.

Not to forget about when form is transformed from HTMLForm to OOUI: First button should not be a primary button, but solely a progressive one.

A red button is not the right approach, if necessary I'd rather put a notice message atop of the button (even though that's sounds like a bad user-interface as well form first look on).

Nevermind my last message, should be done in a follow-up.

It would be a useful addition to rename the button label to “Convert”…

@Charlie_WMDE I'd suggest to put the down icon and the pin icon with a default right distance of 8px in order to not make the help icon be too close to the right edge either in the after patch setting.

@Jayprakash12345 Yes, should definitely be a primary button instead!

Closing this mock after successful rollout of the icons.

They have jump markers, it's just that they only target to # currently

@mmodell I mean to one of the comments in the mock, not in the text. If, as designer, you want to link out to just one comment (out of four) because for example you want to transfer this into a task, currently you can't.

Related to T78022: in pholio mockups it is not possible to reply in-line to a comment

Looking at https://github.com/wikimedia/mediawiki-extensions-UploadWizard/search?p=3&q=flickr&type=Commits
this – https://github.com/wikimedia/mediawiki-extensions-UploadWizard/commit/c5977bbacc0366c280e9229904c5529a5c9b4988 – looks like a possible candidate
@matthiasmullie might know more…

Looking through the code, I did find a few minor issues though, that are additionally complicating the applied colors in Notifications. Will prepare a patch to streamline this.

This is a double-edged request. All our icon interface elements, which are disabled, currently receive 0.51 opacity resulting in #7d7d7d (in Chrome) and a 4.12:1 contrast ratio, being sufficient for WCAG 2.0 AA conformance for large text, which applies to our default icon size of 20x20px.
The reason I've went this specific opacity is, that our interfaces feature icon only elements which might be disabled, but have no other additional representation like a label drawing them insufficiently recognizable for people with visual impairments.

Related: T209018: Language label disconnected from language select and should feature long-form of language title

In T206463#4730646, @iamjessklein wrote:

It's the iphone xs with firefox - so just under 3inches.

The flow diagram is a nice start @iamjessklein! Out of interest to reproduce layouts, which screen size did you use (especially width) for it?

@Etonkovidova Thanks, truely helpful. Those are from a different task, T208930

@Jdlrobson Clear yes from my side.

First patch was too optimistic, resulted in T208898.

Re-assigning this as you've already shared the direction.