I'd set the priority to Low, the code isn't too hacky. Also, I feel (and might be wrong), that extending MessageDialog to do this might make the code more complex than it is now.

In T145163#3381575, @Volker_E wrote:

• (Re-)moving “Eye”/“EyeClosed” icons out of pack (prob to accessibility). @Prtksxna Are there any detailed plans on using those in FileAnnotations still?

From the description

Per a chat with @Nirzar today, maybe we should have actual text labels, hidden except for screen reader software, for buttons which only have icons/indicators? Or, in other words, maybe we should force always having a label and sometimes just not display it.

If I understand this correctly, no amount of setTimeouts will resolve this chain reaction. We'll just have to not run the resize handlers if an input is in focus?

Apparently, on Android, on both Chrome and Firefox, when a layout change is made on the resize event of the window the input loses focus. So when the focus is set, the keyboard appears, triggering the resize event and making the input lose focus, and the keyboard disappears.

Do we want to add grunt-contrib-less to core to do this, is there another way? We'd probably also need mw.message for the labels inside the widget to work properly. This is what the preview looks like after only adding the scripts:

Need some guidance with this. Have we done something like this before, is there a patch I can refer to?

In T167671#3348215, @Volker_E wrote:

One thing, that's definitely wrong in your code proposal, is changing the inherent role of input type=checkbox to listitem. You shouldn't change inherent role of the element as it carries checkbox per default.

From The Roles Model: Group:

A set of user interface objects which are not intended to be included in a page summary or table of contents by assistive technologies.

Understood, that makes sense. Thanks for the explanation @cscott .

Pasting part of an email conversation I had with @matmarex here since its related:

@Volker_E does this need to be closed as invalid too (like T91572)?

In T138401#3321419, @Jdlrobson wrote:

Let's resume this conversation. @Jhernandez has written an excellent comparison of jsduck vs jsdoc here: https://www.mediawiki.org/wiki/User:JHernandez_(WMF)/JS_documentation_tools

@Lydia_Pintscher which operating system are you on?

https://test.wikipedia.org/wiki/Main_Page is working fine for me too (tested on FF and Chrome on MacOS)

@Krinkle any update on this?

In T145458#3240894, @cscott wrote:

Hey, did you guys look at https://annotorious.github.io/ for the UI at all? I wonder if they've solved some of these UI issues...

In T145458#3240894, @cscott wrote:

Hey, did you guys look at https://annotorious.github.io/ for the UI at all? I wonder if they've solved some of these UI issues...

In T146397#3241037, @cscott wrote:

If a wikidata item is shown, a second drop down box shows up, prefilled with the property type describing the relationship between the image region and the wikidata item. A default relation (P18, "image of") is selected, but you could drill down and be more precise. For example, a link to Q42 Douglas Adams may in fact be P1442 an image of his grave (not an image of the person). This relationship dropdown is populated from the "see also" property of P18.

In T144302#3240898, @cscott wrote:

Note that the W3C annotation spec includes an API component: https://www.w3.org/TR/annotation-protocol/

It would be great if we could publish our annotations in this standard way.

Discussed ways to archive this content with @Quiddity, here are some options:

1. Create a PDF of the unique pages and put them up on Phab or Commons. I say unique pages because some of the pages on that wiki are copies of the OOUI documentation on mediawiki.org.
2. Keep a zip dump on phabricator or private server. [DONE]
3. Replicate relevant bits on mediawiki.org on a single long page and mark it as archived.

Here is the dump from php dumpBackup.php --full:

In T166012#3305452, @Volker_E wrote:

@Prtksxna That's what I've thought too. But I'd like to wait for a little more and make a local archive copy of the contents.

@demon/@hashar could you:

Thanks a ton @demon! Could you do the same for T166055: Sunset Skin:Blueprint.

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained

The skin is no longer maintained.

The skin is no longer maintained.

The skin is no longer maintained.

The skin is no longer maintained.

The skin is no longer maintained.

In keeping with T108178: Update livingstyleguide.wmflabs.org to latest mw alpha we should remove mediawiki from livingstyleguide.wmflabs.org and just keep a simple HTTP redirect.

The skin is no longer maintained.

The skin is no longer maintained.

Is removal from Gerrit required?

This extension is not deployed anywhere, and is no longer maintained.

Explain what the input required using aria-describedby

The user interface resembling HotCat is already in core - mw.widgets.CategoryMultiselectWidget - and supports the different types of search offered by HotCat - mw.widgets.CategoryMultiselectWidget.SearchType.