This one will probably require a user notice before WMF rollout and maybe even a "do you guys want us to do this" question to the communities.

You shouldn't be opening any pages in a new tab. See https://www.w3.org/TR/WCAG20-TECHS/G200.html

This is T185840 and I will be closing accordingly.

Possibly this discussion also demonstrating the issue.

In T232491#5481717, @BBlack wrote:

Can any previous reporters confirm the same continued breakage, or new success?

I have issues saving in Chrome (Win10) on my work computer but no issue at home on Firefox (Win10). I use WTE2017.

In T232293#5473752, @SerDIDG wrote:

@Izno, please check one more time, where nowrap class is implemented: <nowrap>date</nowrap><footnotes> <nowrap>age</nowrap>. Normal space character separates these two pieces and should wrap.

Some of us use VE. Did you check in VE also?

Module:Infocards sets class=nowrap on that element, which has whitespace: nowrap from common.css. The elements are not wrapping accordingly.

Minor note, there is a duplicate listed dependency at 1702 and 1705 of Resources.php.

Discussions closed; dead-url deprecation remains.

@Isarra You might want to put the word back in wide mode.

In T190991#5455572, @gh87 wrote:

Sorry, but the gerrit code didn't fix the problem. The issue still persists as seen below:

This is gadget worthy IMO, not skin worthy. No other skin has it today.

I'd be happy today if I knew what to reset in user CSS for the 'everywhere' option. I have a 1200px res or so, so nothing super high-def (which is the problem case when you start looking at removing the max width). I don't know about other people.

On an aside, I don't entirely understand why mw-datatable and wikitable are two separate sets of styling. :^)

Why would VE be designed to duplicate the skin CSS? Questions that keep me awake at night.

Woops, this was a false alarm for me (in the sense that my bug I do not think is this bug's bug). The template in question is outputting an empty div (besides some inner elements, which themselves contain no content) that Edge/IE treat as an interesting div and consequently assigning that div height. It doesn't seem to be an issue if the div gets some css (display none or float right).

In T175709#5408421, @Dinoguy1000 wrote:

As to the deprecation of any given HTML element in HTML 5 [snip]

Anomie pointed me here from this en.wp topic. I think this one might be the bug causing the issue described there. It affects IE11 as well, though I haven't personally tested that case. However, I tried to set display: none in that case and what I got was the li bullet styles disappearing in Edge instead of the link element.

TemplateStyles cannot fix reasonably the case of substed templates.

In T230220#5405700, @Aklapper wrote:

@Izno: When you write "Load more recent changes" and "Display changes more recent than X"", do you mean "View new changes since..."?

Clearing Mobile.css of TemplateStyles requires the same level of effort as cleaning Common.css, more-or-less. As I've described elsewhere and multiple times over, there are multiple cases (hlist, navbox, infobox classes as examples) where classes are being defined in-page, not in a template, nor remotely near any template, and relying on Common.css to provide the related CSS.

I'd rather just see TEs get editcontentmodel tbh.

(And T217499: add editcontentmodel access to the templateeditor group on testwiki.)

In recent Chrome and Firefox, cannot reproduce the beginning of the chain as I laid out in the original task actually. Trying your way, I cannot reproduce this issue either. I'd put this down to browser version or fixed elsewhere since.

On an aside, this request was also made on T155813: Decide on storage and delivery method for TemplateStyles CSS (there may be other discussion related in that task; I just happened to be reading it because of the discussion about TemplateStyling Template:Documentation):

I am not sure what you're asking there.

T173531: New 'edit source' icon may also be of interest.

Not really? The Minerva icon for edit is a pen; the Minerva icon for view
source is a pen with a lock in the top right.

May also be another issue with T181184.

I've been musing on this problem and I think it's due to some default of some sort on padding, or possibly that the default column width in Timeless doesn't match that of Vector. If I zoom out from 100% just once with the default widths of a responsive reference list on en.WP, the columns become obvious, so it's clear to me the list is getting the columns styling.

One of the bigger issues is that the table headers have no borders for me at least. This is probably bad for poor-sighted users, who need the strucutre of obvious cells.

As for performance gains/losses, that doesn't seem like a good criterion.
In general, I think we should work to get as much out as possible so that
it is obvious to (re)users where our CSS lives. The difficulty is in the
styles that are widespread and not necessarily confined to one template.

Also add the styles to a module subpage if they are invoked from a module.

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.