In T227689#5321815, @Tgr wrote:

safemode doesn't deactivate inline styles (or inline styles within a template) either. It's purpose is to determine whether the problem is with the standard rendering of the page or with the user's / wiki's custom settings. So the current behavior seems correct to me.

Today (it's a bug), if you want to view a page without TemplateStyles, preview the page using VisualEditor.

In T117279#5315726, @Dinoguy1000 wrote:

@Jdlrobson Not an extension; wikEdDiff is a user script on Wikipedia. =)

On the point of unified diffs, WikEdDiff provides unified view and I almost exclusively read diffs using it rather than 2 column.

T214998: Remove .m. subdomain, serve mobile and desktop variants through the same URL might be relevant.

In T221876#5279833, @Tgr wrote:

Seems like the WHATWG is winning this one.

YYYY-MM is generally insufficient to distinguish from a year range. I think there has been discussion about that particular amount of information on Phab, but it's a regular discussion topic on en.WP.

This is not a problem with the software. You need to fix Template:Citation/core. You should probably leave a note on the talk page there.

In T224741#5228101, @jeblad wrote:

As it happens, jeblad's problem can also be overcome by grouping references, as are presented in T49544. (Of course, that has its own issue... but that's an aside. 😃)

I can't see how this relates… Can you clarify?

And new permitted values.

In T224741#5227187, @Quiddity wrote:

[...]

The page had local interwikis defined. I removed them.

In T198949#4438065, @cscott wrote:

AFAIK google isn't indexing the mobile version of the page, they are indexing Parsoid content. So this should have no effect on SEO for google either way.

In T218511#5215297, @IKhitron wrote:

In T218511#5215295, @Izno wrote:

You should probably provide new instructions to reproduce. I've not had this issue all day today.

Same as in the task description.

In T218511#5215110, @IKhitron wrote:

Pay attention. The wrong data in watchlist problem is resolved, but the original issue of this task, "After opening a diff, entry on Special:Watchlist sometimes stays unread (bold)", isn't.

T157670: Changes to MediaWiki code related to parsing can leave links tables out of date and/or T221795: Refactor Category::refreshCounts logic to a job and simplify are I think the ones of interest? Just merged this to one in fact based on a similar merge that Krinkle did.

In T218511#5210151, @Sario528 wrote:

As of 11:15UTC on en-wiki, watchlist seemed to be functioning normally, with one unexpected behavior: When opening a diff, any older unread diffs of that page become marked as read, even though they were not.

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, and I was actually able to close the former--the parser is generally whitespace sensitive.

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.)