In T50274#5135349, @Esanders wrote:

The above patch stops the first item being highlighted automatically. You can test the effect on live by pasting ve.init.target.saveDialog.editSummaryInput.lookupHighlightFirstItem = false; into the console after the save dialog has opened.

In T181184#5182941, @Isarra wrote:

Okay fine I hate you all I'll fix this.

I fixed the direct issue with the template. This report may be a particular instance of T11996: Multiline tags in lists should be output more intelligently otherwise, but I'm going to close this one and you can follow that one if desired.

It is neither of the two.

This is somewhere between a High and a UBN given how destructive the result is onwiki (and while en.wp has prevention in place via filter, not all wikis will). (I have taken into consideration the Phabricator project management guideline, just to preempt you, Aklapper. :) )

Sometimes #time is used in further calculation, which <time> would prevent.

In T222741#5168362, @Niharika wrote:

In T222741#5166057, @Izno wrote:

Why is this an entirely separate task to those proposed in the community poll?

It's not. This was wish #5 in the Community Wishlist Survey.

In T102502#4613434, @Aklapper wrote:

I'm missing a use case why someone would like to follow only HTML-5 related tasks.

I faced some resistance when I advocated removing this wikitext at WT:WP Accessibility/Archive 6#Status of table summaries.

Why is this an entirely separate task to those proposed in the community poll?

All seems draconian seeing as there are many editors who put pretty colors on their user pages in the page title.

Which does have its downsides, e.g. the resurrected b and s elements (which following either WHATWG or W3C would not have saved us).

As for which to prefer, the nicety of the W3C is that it is versioned. The living spec you would need maybe to fork the WHATWG version on github just to have a baseline and then update periodically.

There are other differences in semantics between the two specifications e.g. <cite> where at least en.WP has in fact influenced the W3C toward a more permissive use for the element.

Regarding useskin=mobile, you can do that today with useskin=minerva.

In T50274#5136148, @Esanders wrote:

In T50274#5135937, @Izno wrote:

BTW since you're in the area there's a TODO there that was waiting on what is now a task that you closed a week or two ago.

Sorry, I'm not sure what you're referring to, can you provide a link?

In T50274#5135349, @Esanders wrote:

The above patch stops the first item being highlighted automatically. You can test the effect on live by pasting ve.init.target.saveDialog.editSummaryInput.lookupHighlightFirstItem = false; into the console after the save dialog has opened.

In T49544#4124808, @ssastry wrote:

Once Tidy is replaced with RemexHtml (T89331: Replace HTML4 Tidy in MW parser with an equivalent HTML5 based tool), I expect this will be fixed. Let us revisit after that happens.

I like it, but I think I'd also like it gone because having to look behind it drives me nuts. =)

(Which is nonexistent?)

In T50274#5107874, @Whatamidoing-WMF wrote:

(In the meantime, the workaround is to hit the Escape key.)

I agree, this is well done.

This is not core software problem, in Cite or otherwise. The incompatibility is in the gadget. (It has other known incompatibilities.)

This looks a lot like T132288: Create tool to identify plain references and offer a fix.

The original report looks to have been fixed and right now my second issue looks to have been fixed.

Ah nope, Internet fart. Pasting worked fine just now.

A significant contributor to empty bullets is T6281: Allow users to set a starting digit in ordered lists (and I think what was my duplicate, T202083). Fixing that would make it possible to setup a linter for the rest and then removal of the CSS/class emission, since I don't know of valid cases otherwise for empty bullets (or possibly we would find that there are other cases that need to be supported).

In T199534#5043356, @stjn wrote:

In T199534#5038543, @Framawiki wrote:

I suppose a full extension allows revert protection feature to work even without javascript, and in the common case of a click done by the user before the full page load with its scripts.

(@Izno: Localisation can be done for gadgets, and small wikis usually just copy the code from bigger ones.)

In T199534#4422963, @stjn wrote:

Can’t you just do a gadget please? I seriously don’t understand why all of this development is even needed.

We already have a tag for this ( Accessibility ). I would actually recommend this task get closed with new tasks opened for each of the bullets in the original, as appropriate.

In T50274#5012835, @gerritbot wrote:

Change 495451 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/VisualEditor@master] Edit summary autocomplete

https://gerrit.wikimedia.org/r/495451

Okay, I've triaged as lowest. No objection if you want to decline also.