Change #1184929 had a related patch set uploaded (by Perryprog; author: Perryprog):

[mediawiki/core@master] tables: remove specificity of responsible tables

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

Change #1184931 had a related patch set uploaded (by Perryprog; author: Perryprog):

[mediawiki/skins/MinervaNeue@master] tables: remove specificity of responsible tables

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

but that's fine since it's just table styling

Mobile users would probably disagree with you.

I actually checked in Edge's IE compatibility mode (best I have for testing grade C right now) and things seemed fine, but I'm happy to be corrected if I missed something. (It's possible that between IE (which isn't even supported but it's what I had in a VM :P) and between supported browsers that there's a browser with more of a problem.)

Grade C desktop was not the concern. Mobile was. The relevant group you're trying to test with is

Safari 10+ (2016), iOS 10+ (2016), Android 5+ (2014)[note 3]

And probably a few others as well (early versions of Firefox/Chrome mobile, and maybe even Edge mobile). None of these versions support :where().[0] The relevant CSS is unfortunately not a progressive enhancement but instead needed to support mobile resolution pretty directly.

[0]

Thanks for the clarification—to be clear I was testing on Edge as a rough proxy for what it would look like on a browser that doesn't support :where(), and I didn't notice any significant issues.

Here's a comparison of what it would look like in Minerva with the rules disabled, as would happen if a user agent didn't support :where:

And here's with the rules enabled:

Then for an example of a too-wide table we would have this (I've scrolled as far right as possible for the first image):

Versus the expected:

So yeah, for the non responsive case it definitely isn't great for grade C browsers, as you said. My understanding though is that because the page content is still readable in a (slightly less) readable manner, and because everything else still functions as expected, that this is acceptable for our compatibility policy.

Yeh using where in this context for tables is a non-starter. It would seriously degrade a lot of the iPad / iPhone traffic we see from older browsers.

Hrm, well shoot—I suppose that is the correct answer (curse doing things the right way...), but that does make this more complicated.

The obvious solution is of course to just increase the specificity on the local side, but this still feels weird to me—like, medawiki end users shouldn't need to worry about having extra specificity for something as simple as a .stuff { display: none; }. I'm not sure if I'm thinking about that in the wrong way, though.

Edit: OH and I just properly read what Jon was saying in that Safari 11.1 is still Grade A. Aaaaaaaaaaaa. Totally missed that.

So I can't think of any way to work around this, since it's not something we can gate with @supports, besides like... just removing the parent .mw-parser-output selector which isn't really a good idea, so I suppose this is something that just needs to be fixed on the local side. I'm not going to close this right away though in case anyone has some other idea that I haven't thought of, or if anyone believes this issue should stay open albeit unfixed for now (e.g., until we have wider support for :where in like ten years or something).

Change #1184931 abandoned by Perryprog:

[mediawiki/skins/MinervaNeue@master] tables: remove specificity of responsible tables

Reason:

What if we didn't break responsiveness for our users? (This approach doesn't seem to be feasible with regard to compatibility.)

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

Change #1184929 abandoned by Perryprog:

[mediawiki/core@master] tables: remove specificity of responsible tables

Reason:

What if we didn't break responsiveness for our users? (This approach doesn't seem to be feasible with regard to compatibility.)

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