Repository navigation
[css-contain] Is it ok that contain:layout is a CB for fixpos/abspos descendants but doesn't establish a stacking context? #2942
Description
The containment spec for contain:layout:
- says that
contain:layoutestablishes a containing block for absolutely positioned and fixed positioned descendants, but - does not say that it establishes a stacking context.
This is the first feature in CSS that I'm aware of with this combination. I think it's worth some consideration of whether this combination is sensible. Do the painting rules for abspos and fixpos elements contained by such an element work in a reasonable way?
/cc @MReschenberg
Activity
tabatkins commentedon Jul 20, 2018
The combination wasn't on purpose; I just didn't realize that the two were tied together like that.
dbaron commentedon Jul 20, 2018
I'm not sure how tied together they are -- but if we're going to keep it this way, somebody needs to think it through.
dholbert commentedon Jul 20, 2018
RE how tied together they are:
Right now, the CSS painting order algorithm has three different mentions of a special category which gets special painting behavior at different parts of the algorithm:
Fun fact: up until now, this category has basically been 100% equivalent to the set of all elements that establish a containing block for abs-pos descendants. (Please correct me if I'm wrong, but I'm pretty sure these are 100% equivalent.)[EDIT: Actually, per @chrishtr's correction below, I think this category (is-positioned-or-forms-stacking-context) is a superset of the set of elements that establish a CB for abs pos descendants.
opacityis one example of something in the former category but not the latter.]However -- with the current contain:layout spec-text, these two categories will now be slightly disjoint. Specifically,
contain:layoutelements will be in the latter category (they establish a containing block for abs-pos descendants) but they might not be in the former category (they're not necessarily positioned themselves, nor do they create a stacking context).So I think the questions here are:
contain:layoutelements to be included or excluded from the pieces about "positioned descendants and descendants which actually create a new stacking context"? (And to what extent does this matter?)dbaron commentedon Jul 21, 2018
And @dholbert wrote comments 13 through 16 of bug 1472919 that show that Gecko code currently assumes this combination doesn't exist, and behaves incorrectly as a result.
frivoal commentedon Jul 21, 2018
As we're not trying to introduce any new complicated thing here, I'd be perfectly fine with creating a new stacking context as well even if it isn't strictly necessary, if that makes things simpler, which seems to be the case in Gecko.
Is that OK for blink? @eaenet @mrego
chrishtr commentedon Jul 26, 2018
It's not true that containing block, positioning, and stacking context imply each other. Some of the stacking context triggers do not imply containing block for abs pos. Opacity is one example.
However, I think what you might have meant to say is that the set of element which are treated in the special category by the painting algorithm is positioned elements + stacking contexts, and that this is a good invariant to keep in order to avoid code complexity in the engines and reduce developer confusion. This is also what @dbaron proposed resolving in the first bullet of this comment: #2717 (comment). I added some notes in the end of that other issue regarding various kinds of replaced content that don't fit this model.
However, I think that making contain:layout a stacking context would be a good change, since I agree
that it would simplify implementations and be less confusing for developers. Let's resolve this, and
I will try to make the change happen in Chromium.
dholbert commentedon Jul 26, 2018
Ah, thank you - that's a good counterexample. So the two groups aren't 100% equivalent as I'd initially stated, but rather: one group is a subset of the other. Let me restate my observed "rule" more carefully, with that in mind:
[Observed rule]: Up until now, if an element forms a containing block for abs pos descendants, then that always implies it is in this special "is positioned or forms stacking context" category that's referenced several times in the painting spec. (And there are a few other things in that category, too, like "opacity" as you noted.)
contain:layoutwould be the first (I think?) exception to this "rule" -- it forms an abs pos containing block, but it's not in the special "is positioned or forms stacking context" category.Great! I'm glad we're in agreement. Thanks for chiming in.
mrego commentedon Jul 26, 2018
I agree with the idea and I think it should be fine to implement it in Chromium.
BTW, I realized that despite paint containment is creating a stacking context in Chromium, it's doing it more than expected even for elements where paint containment doesn't apply. See https://crbug.com/868102
[css-contain] layout containment causes stacking contexts
frivoal commentedon Jul 28, 2018
Made a PR for this (#2962). Standing ready to merge if we resolve in favor.
css-meeting-bot commentedon Aug 2, 2018
The Working Group just discussed
Is it ok that contain:layout is a CB for fixpos/abspos descendants but doesn't establish a stacking context?, and agreed to the following:RESOLVED: Accept the PR that corrects this oversiteThe full IRC log of that discussion
<dael> Topic: Is it ok that contain:layout is a CB for fixpos/abspos descendants but doesn't establish a stacking context?<dael> github: https://github.com//issues/2942
<dael> florian: contain layout sets the element to be a containing block for lots of things, but didn't say it establishes stacking. This would be a first time we would have something liek this that's not stacking, so let's do it
<dael> TabAtkins: And it wasn't intentional, accidental tying concepts and didn't realize
<dael> astearns: Not seeing obj in issue
<dael> astearns: Obj?
<dael> RESOLVED: Accept the PR that corrects this oversite
dbaron commentedon Aug 2, 2018
I updated my big stacking context test to reflect this resolution.
frivoal commentedon Aug 2, 2018
@dbaron is this something you expect to extract individual test cases from and submit to wpt?
chrishtr commentedon Aug 2, 2018
Yes we need testcases submitted to WPT, combined with changes to implementations to adopt
this resolution. I can get that done for Chrome. Can Gecko please implement in parallel?
MReschenberg commentedon Aug 2, 2018
Gecko WIP can be found here https://bugzilla.mozilla.org/show_bug.cgi?id=1472919
mrego commentedon Aug 2, 2018
I have these tests from my experiments in Chromium: web-platform-tests/wpt#12269
frivoal commentedon Sep 6, 2018
test cases available in wpt
[css-contain] Make contain:layout a stacking context