Also on the styling front, we just need to merge Special:ListFiles conversion to OOUI, see T117743. The table presentation of results should generally be amended IMO.

Would you do this for Special:Unblock as well?

Prepared all imagery that is unaltered in SVG and pushed to the repo in order to move on and provide mobile users a better experience for the images that already work.

@Nirzar This is for everyone picture is currently missing in Imagery file.

For technical reference on why to put role=img on SVG <img> images, see https://css-tricks.com/accessible-svgs/

@Jayprakash12345 The params now is part of $formdescriptor and comes before the hidden title field. It shouldn't have any impact in this specific case. Wonder if you could leave out title hidden field at all though as there's functionality part of HTMLForm.

stijn, thanks for your open words!
As much as we've been focussing and improving our WikimediaUI interfaces (Vector, MobileFrontend with MinervaNeue skin) on a variety of levels (consistency, usability or accessibility) we're also aware of being careful about change in order not to disrupt long-term users, especially editors, workflow.
Enforcing a change on them is not the way we're choosing, but being careful of remaining in a maintable and product-feature rich environment, there are compromises that they have to be willing to make.
I don't think proceeding here, gains us a lot. We rather long for explaining the advantages of switching over to a modern interface.

In T192181#4132671, @Prtksxna wrote:

From https://design.wikimedia.org/style-guide/

Play around
Download Wikimedia Design Style Guide

Not sure if play around is a relevant heading for downloading the zip file.

Play around in the context of download and then play (and modify).

Two PRs at

• https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/104 &
• https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/105

I'd suggest to separate concerns here, let's start with the 'clear styling' icon and separate the 'remove link' into another task.

@Mooeypoo Would you look into this?

@Prtksxna With only button progressive left, this should be merged in, yes!

@Deskana One of the pillars in the icon overhaul T177432 was to look into existing icons and evaluate them against the principles, like universality.
Closest visual similarity, which big number of people might have been exposed to is probably https://duckduckgo.com/?q=no+parking&iax=images&ia=images But it's not working as design axiom for “clear”.

There seems to be a misunderstanding, which globe I was referring to, I was referring to the alternative with just two inner latitudes.
As comparison the Firefox Mobile one, that I think is working very well:

We've been also design-team internally talking about that we need to be careful with the clear icon on link dialog and I've thought about removing it from above screenshots, but it gives a better rounded picture on the topic, even if we gonna go only for the menu item's icon.

@JHunterH Gerrit patch set against this task is fine.

@JHunterH $submitDiv from the task description in mmv/ui/mmv.ui.viewingOptions.js left untouched. Do you plan on amending this?

@Jayprakash12345 What's happening with the checkbox + label (mis)alignment in the “Generated thumbnails” section?

Was partly reverted in T182398: Special:Undelete contains egregious white space after OOUI update

We could consider even adding a bundlesize test, like in https://gerrit.wikimedia.org/r/#/c/406837/2/package.json

@Jayprakash12345 Yes, OOUI\HtmlSnippet. One simple example is Special:MobileOptions.

@Jayprakash12345 As I've said above, “quiet progressive” and destructive buttons seem to be a better choice here altogether.

@Pginer-WMF Few comments:

• user rights: I agree with Ed, the cog on user rights is really hard to identify, even in a 30x30 canvas
• global: As I've added in a different channel, I think the globe's inner latitudes could be centered a tad more, similar to Firefox mobile's globe. (We should also rename the icon to 'globe')
• edit-user-talk/flow-mention/flow-post-edited Old representation has advantage of emphasizing more people have been involved in action, newer has advantage of featuring less detail. No strong preference in one or other direction from my side…
• flow-post-edited and changes still feature “old” pencil

@Aklapper The conversation went on at Gerrit.
@JHunterH Congratulations, good work!

@Deskana Agreed. :)

T191031: Use OOUI icons in WikiEditor is related.

This has been resolved by T191031: Use OOUI icons in WikiEditor \o/

Reproducible for me on Chrome 65.0.3325.181

This has already been exemplified in “Creating Illustrations” imagery implementation…

break-all

`word-wrap: break-all` for browsers following CSS Text Module Level 3 WD
`word-wrap: break-word` for Webkit/Blink

@Arlolra Yes, word-wrap: break-word seems sensible here, together with hyphens. We've got a core LESS .hyphens() mixin for this use case.

@cmadeo Invitation for a controlling look from your pov: https://design.wikimedia.org/style-guide/visual-style_illustrations.html

@cicalese Just to voice it, I value and appreciate @Jayprakash12345's recent work on OOUIfication of interfaces and you reviewing it. There's a good number done in little time.
The case here is, that we're turning all “normal” buttons into “primary action” buttons, which is an issue from a user-experience point of view. Understanding the uses cases of all forms is sometimes hard. In this specific case, where I've seen this form for the first time in the screenshots above, I'd agree with you, a real design process invoked wouldn't end up in such form representation. Nevertheless let's achieve what we can achieve while we're at changing it over to OOUI and amending the buttons falls for me into necessary and possible achievements category. :)