Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-transforms-2] Explicitly specify that a transform is a containing block for all descendants #913
changed the title from
Use of “containing block” does not match CSS2.1 definition
[css-transforms-2] Use of “containing block” does not match CSS2.1 definition
Jan 13, 2017
Is this issue removing transform as a containing block for fixed-position elements? I don't think
Im not going to pretend to understand the difficulties in implementing the client code cause I'm completely unqualified. But want to put my two cents in. When I ran into this issue I sat stumped forever. While this issue is now well documented on the web, it took me forever to actually figure out that the transform is what was causing the issue and thus being able to find the chrome bug filed and eventually the original Bugzilla spec bug to request an update.
It seems counter-intuitive to not update the spec with what seems to be a universal expectation to accommodate the Chrome team. Especially since other browsers are accommodating what seems to be universally expected.
Additionally, while the spec for positioned elements outlines this issue, I find it difficult to understand the language used in the spec. Front-end devs could potentially waste a lot of time looking for a fix, and possibly explains a lack of interest for this issue. I personally find that the transforms spec more clearly outlines the behavior than the positioning spec.
referenced this issue
Nov 15, 2017
I verified that Firefox, Edge (14 and 16), Chrome and Safari all behave the same here. Only IE appears not to create a containing block for a transform. So definitely we just need to update the spec and web-platform-tests for this.
For the record, here's the relevant chromium issue.
None of the "implementation is really difficult" argument seems relevant in terms of what makes sense in consistency of the language.
This is nonsense. Is there any reliable explanation of why is this implemented the way it is beside assumptions? With the spread of CSS transforms
What makes me go crazy is that it's an issue from 2012 or earlier and you still read about viewport e.g. in Mozilla Web Docs:
Then later it's casually added that:
As this breaks probably each reasonable use case for
In all honesty, better terminology needs to be created for how a
I understand that moving relationships of elements around different representations of the tree isn't easy and this issue isn't about removing
...documented within css-position#fixed-pos.
@smfr transforms 1 still has an issue referencing this one. Is it still relevant for level 1? https://drafts.csswg.org/css-transforms/#issue-4e97f62c
referenced this issue
Jun 26, 2018
The Working Group just discussed
The full IRC log of that discussion<Rossen> Topic: Explicitly specify that a transform is a containing block for all descendants
<Rossen> github: https://github.com//issues/913
<ericwilligers_> dirk: because of the compositing model of many browsers, much the same reason as for filter effects
<ericwilligers_> rossen: this means it will also be a containing block for fixed?
<ericwilligers_> rossen: is there interop?
<birtles> dbaron has a test for some of these cases https://dbaron.org/css/test/2018/stacking-context-z-order
<ericwilligers_> ericwilligers: motion path and individual transform properties explicitly create a containing block and stacking context.
<ericwilligers_> rossen: seems like transform in Edge and Chrome and Firefox is considered a containing block.
<ericwilligers_> brian: transform-style flat creates a stacking context in the spec but not implementations.
<ericwilligers_> dirk: some developers don't like the behavior - some want fixed-pos to not create a containing block even if there is a transform.
<ericwilligers_> dbaron: it is a little late to change that.
<ericwilligers_> dbaron: I tried this on 4 engines. Notes at the bottom of test linked above.
<ericwilligers_> dbaron: This is testing many different things. Green means it does the thing, red means it does not. Sometimes does not correspond to pass/fail.
<ericwilligers_> crossed out means the engine does not implement property.
<ericwilligers_> dirk: confirm WebKit behaves same as Edge and Chrome and Firefox in creating a containing block.
<ericwilligers_> dirk: will we resolve for filter too?
<ericwilligers_> RESOLVED: transform establishes a containing block for all elements.
<dino> ericwilligers_: Didn't we resolve to add a few options for transform-box?
<dino> ericwilligers_: it's already in the spec
<dino> ericwilligers_: i'm just noting that there have been differences since the most recent publication