Adjust display: contents information
#4706
Conversation
This is not intended to be a complete change ready to be accepted, but as a starting point for discussion and negotiation. This commit message at the least should be updated before it’s merged! I’ve removed note 2 from non-Chromium browsers, because it’s wrong: in Chrome, the content is inaccessible, which is indeed serious, but in both Firefox and Safari it was merely the accessibility attributes on the element that were lost—the content was still in the accessibility tree. I’ve marked them as “yes”, as it doesn’t seem severe enough to me to warrant calling it only “partial”: most situations that I’ve encountered where I would like to use `display: contents` are just on a container <div> that exists purely for reasons of hierarchy, not on a <ul> or other such semantic element. This still seemed worth adding another note for. A detail that I contemplated including but didn’t end up mentioning: Firefox was *not* in fact completely fixed in 62, only mostly. https://bugzilla.mozilla.org/show_bug.cgi?id=1500958 tracks fixing it for the remaining cases (e.g. buttons). It’s not immediately obvious to me which cases are fixed and which aren’t, but I’m *guessing* that it’s elements with a special `appearance` that are still affected. Some more notes on things to consider: • The known issue says that iOS Safari 10 and 11 render it as `display: inline`, while claiming support; but the compatibility table says “no” up to 11.2, and “partial” from 11.4 onwards. This needs to be checked, and probably a note added to the “no” for 10–11.2 (if it got fixed in 11.4?). Things claiming support when they don’t actually support it are far more dangerous than things that don’t claim support. • Chrome’s serious bug was fixed on November 20; I’m not sure which final release of Chrome that will correspond to.
|
Pulling in people from #4437 (which led to the “partial” status) that are connected to this: @jensimmons, @meyerweb. It may be that I have misinterpreted the matter of accessibility tree presence in Firefox and Safari. I haven’t verified it at all at this stage. Certainly that needs to be done before this commit should be permitted to be accepted. |
|
It seems that browsers are going through 4 stages of support for accessible content and It looks like Firefox is in stage C, not D (as previously believed). Chrome / Edge 75+ and Safari are in the process of going from B to C. (Sorry, I'm not sure what's shipped when exactly.) None of the browsers have reached D. There are a few debates happening here at once: First, should we update the Can I Use page to explain four stages of 'support', instead of the current three? I believe we should. Thanks @chris-morgan — I agree! Let's do this. Second, should "Stage C" have a fully green color (signaling of YES YOU CAN USE THIS), or just a yellow-green color (signally, well, maybe, sort of). Chris, it looks like you are arguing that sometimes developers can use Third, as always, we want to figure out which browser is at which stage when. And it'd be handy to round up the bug tickets, if we can. The pull request likely has the right info on which browser is at which stage, but I haven't confirmed it. I can help confirm Firefox, easily. Everything else we should double check... or maybe Chris you already have. |
|
Firefox went from Stage B to Stage C with FF52. Here's a Chrome ticket: https://bugs.chromium.org/p/chromium/issues/detail?id=835455 |
|
I believe this PR can be closed as out of date. All browsers now have full support for |
|
Most recent discussion on this has been occurring at #6469 so closing this ticket. |
This is not intended to be a complete change ready to be accepted, but as a starting point for discussion and negotiation.
I’ve removed note 2 from non-Chromium browsers, because it’s wrong: in Chrome, the content is inaccessible, which is indeed serious, but in both Firefox and Safari it was merely the accessibility attributes on the element that were lost—the content was still in the accessibility tree. I’ve marked them as “yes”, as it doesn’t seem severe enough to me to warrant calling it only “partial”: most situations that I’ve encountered where I would like to use
display: contentsare just on a container <div> that exists purely for reasons of hierarchy, not on a <ul> or other such semantic element. This still seemed worth adding another note for.A detail that I contemplated including but didn’t end up mentioning: Firefox was not in fact completely fixed in 62, only mostly. https://bugzilla.mozilla.org/show_bug.cgi?id=1500958 tracks fixing it for the remaining cases (e.g. buttons). It’s not immediately obvious to me which cases are fixed and which aren’t, but I’m guessing that it’s elements with a special
appearancethat are still affected.Some more notes on things to consider:
The known issue says that iOS Safari 10 and 11 render it as
display: inline, while claiming support; but the compatibility table says “no” up to 11.2, and “partial” from 11.4 onwards. This needs to be checked, and probably a note added to the “no” for 10–11.2 (if it got fixed in 11.4?). Things claiming support when they don’t actually support it are far more dangerous than things that don’t claim support.Chrome’s serious bug was fixed on November 20; I’m not sure which final release of Chrome that will correspond to.