Open Loirooriol opened 1 year ago
For the record, WebKit might implement this particular case correctly, but has similar issues, see bug 186882.
Oh, though that was fixed, at some point, so nvm then. WebKit still fails this test tho :)
Blink implements it partially: the testcase above is good, but adding this breaks it [...]
Thanks, landed a fix for this now. (https://crbug.com/1399755).
[general issue]
The current spec intentionally has no special case directly on display:none, and instead delays dealing with that until container-query-evaluation time (via having a principle box or not). This is to get a "stable" container situation in display:none. I.e. the container (which is an element, not a layout box) is always the "intended" container, and not a "random" container outside of display:none.
A related point is that container selection intentionally doesn't care whether an element has a pricinple box or not. I.e. we can select the right container without building the layout tree. This is important for Blink, since we need to know if something is a container or not sufficiently early in the pipeline. (This may be besides the point of this issue, but who knows where the discussion will lead).
Firefox skips #inner-container and thinks that the query container is #outer-container.
I think we should avoid this behavior for the reasons I said. (#outer-container is not the intended container).
Maybe elements inside display: none subtrees should be considered to not have any container?
That on the other hand seems probably OK? Although gCS would be worse than it needs to be when only the querying element (and not the container) is in display:none. And it's possibly unfortunate for style queries. But at least it's stable.
Maybe elements inside display: none subtrees should be considered to not have any container?
That on the other hand seems probably OK? Although gCS would be worse than it needs to be when only the querying element (and not the container) is in display:none. And it's possibly unfortunate for style queries. But at least it's stable.
Yeah, I think it sounds counter-intuitive for style queries to stop them from having effect inside display:none when other styles match as usual.
The CSS Working Group just discussed [css-contain] Container queries within display:none are difficult to implement
, and agreed to the following:
RESOLVED: elements within a display:none subtree have no parents that container queries can access
The query container for
#target
is#inner-container
, since it has the rightcontainer-type
. However, it generates no box since it's inside adisplay: none
subtree, sowidth >= 0
should be unknown and--x: BAD
should not apply.This is tricky to implement, though, because browsers typically avoid computing the style of elements inside
display: none
subtrees. So when collecting the rules for#target
, we may not know thecontainer-type
for#inner-container
, and thus not know whether to apply--x: BAD
.Currently,
#inner-container
and thinks that the query container is#outer-container
.In https://phabricator.services.mozilla.com/D164113 @emilio says