Repository navigation
[css-display] Define interaction of display:contents and replaced elements #540
Description
https://drafts.csswg.org/css-display/#box-generation
It was not clear to me from the spec what the expected result of applying display:contents to replaced elements is. The added test for replace contents matches what Gecko implemented.
The implemented behavior seems to be that display:contents on replaced elements and form controls (not all of those are actually replaced elements) is ignored, as far as I can tell.
cc @rune-opera @tabatkins @fantasai
Activity
MatsPalmgren commentedon Sep 28, 2016
We ignore
display:contentsin a few cases where it doesn't make sense, such asfor replaced elements. (I can dig up the exact conditions if you need it.)
So I think this change is basically wrong:
c65b958
rather than referring to literal
displayvalues, it would be better to use more general terms,e.g. "when the element has a principal box, use its size, otherwise use the computed value"
fantasai commentedon Jan 24, 2017
The CSSWG decided to treat
display: contentsasdisplay: inlineon replaced elements and form controls. Edited in c588376 by making it compute toinlineon such elements. Please let me know if you'd rather do something more magical.zcorpan commentedon Jan 25, 2017
LGTM
MatsPalmgren commentedon Feb 10, 2017
I fully agree with bz in #1024 (comment)
The spec should say that
contentscomputes tocontentsbut the used value isinlinefor these elements.In general, adding new spec language that makes a computed value depend on layout stuff such as box construction is pretty much always bad.
tabatkins commentedon Feb 22, 2017
WG discussed this today.
Problem with making it "behaves as" is that there are plenty of other properties that care about the box that the element will generate; it's generally very significant whether something generates an inline, block, or no box at all. So we can't just push this to used-value with the "behaves as" language; this is fundamentally a computed-value issue.
So impls either need to bite the bullet and allow this computed value to depend on form-control-ness (as, according to François, Firefox already does?), or shoot for a simpler resolution, like making
display:contentssuppress the box like normal (and, as a side-effect of being a form control, and thus half-replaced, also suppress its children's boxes, likedisplay:none).37 remaining items
AmeliaBR commentedon Mar 16, 2017
Not really, see: https://w3c.github.io/html-aam/#el-progress
Although there's still open debate about how best to expose
meteras something different fromprogress, they are both expected to be exposed as atomic widgets, with the actual numerical properties mapped to the accessibility API equivalents. The text content wouldn't be exposed through the API in a supporting browser. It's only there for older browsers.Yes for
applet(I had to look it up, it works likeobject). No forembed(which is void, no child/fallback).But regardless, my main point was : ideally, try to be as consistent as possible, rather than special rules for each different element type. But I recognize that we don't live in an ideal world.
astearns commentedon May 2, 2017
We went through the issue list in the new section at the Tokyo meeting. If there's anything remaining to go over, please re-add the agenda+ tag.
tabatkins commentedon May 15, 2017
We edited in all the f2f resolutions.
Please let us know if this is satisfactory, or if further work is required. A response would be appreciated @zcorpan @AmeliaBR @bzbarsky
bzbarsky commentedon May 16, 2017
Delegating to @MatsPalmgren.
zcorpan commentedon May 16, 2017
I discussed with @rune-opera, at first we thought
objectandimgcould show the children when they're not replaced elements. Butobjectloading depends on the style of the element -- it doesn't load fordisplay:none. So then it could be a new race condition (if the style is async-loaded in some manner, which I believe is something web devs do these days) and be pretty confusing forobject, if it ends up as display:none or rendering the children. So always display:none does seem better.So LGTM for resolving this bug. Further work could include upstreaming some of the logic to HTML, writing web-platform-tests, filing browser bugs... 😊
bzbarsky commentedon May 16, 2017
@zcorpan I'm not sure I follow. What sort of style are you envisioning async-loading?
zcorpan commentedon May 16, 2017
I mean something like https://github.com/filamentgroup/loadCSS
bzbarsky commentedon May 16, 2017
Yes, I understand what async-loading is. What I'm not sure is what you think is racing against what. As in, what specific rules are being async-loaded, and what does the DOM look like?
zcorpan commentedon May 16, 2017
Oh, ok.
If the behavior of
display: contentswere to act likedisplay: nonewhenobjectis a replaced element but render the children whenobjectis showing fallback, then the end result would depend on which happens first: loading of the resource vs. applying the style. If it's first loaded, then the end result would be display: none. If the style is applied first, then theobjectelement doesn't generate a box, so it's not "being rendered", and thus doesn't load anything, but continues to render the children.http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5186 for object first
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5187 for style first
bzbarsky commentedon May 17, 2017
Hmm. Do UAs actually implement that "being rendered" requirement across the board? I'm pretty sure Gecko doesn't unless the type is a plug-in type (and even then, I think it may only affect plug-in instantiation, not the actual load, since the type is not known until you do the load), so both your testcases render the image in Gecko.
Per the letter of the spec, every time an , or any ancestor, gets toggled to display:none and back it should redo the fetch for its
dataattribute, which seems like a really weird behavior. I filed whatwg/html#2692