Csswg-drafts: [css-transforms-2] Explicitly specify that a transform is a containing block for all descendants

[smfr]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328

Comment: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328
Comment: http://www.w3.org/mid/[email protected]

Also
Comment: https://www.w3.org/mid/[email protected]
Comment: https://www.w3.org/mid/[email protected]

[mikemcguire]

WOAH! moving issues to github, +1 for that and +1 for resolving this issue

[tomasdev]

Are there any plans on fixing this?

http://jsbin.com/jazuwus/edit?html,css,output

[asiljan]

+1

[chrishtr]

Is this issue removing transform as a containing block for fixed-position elements? I don't think
that is a good idea, as it:

• makes clipping and filter effects hard to define and implement, and in general ill-defined because
  it's impossible to "filter" across multiple 2d planes.
• introduces difficult and complex code to implement compositing
• makes it hard to provide clean fast paths for transforms

[mikemcguire]

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.

[RByers]

I believe #1945 tracks doing exactly that - updating the spec to match Chrome's behavior. Merged.

[RByers]

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.

[tegtmeier]

+1

[chasebank]

Is there a separate issue to clarify the behavior of fixed positioning?

Because if I'm reading this right, it doesn't quite cover that concern.

[HandsomeMedia]

Possible workaround: use position:sticky instead. I found a few cases where this worked (in Chrome).
And expanding on that - why would position:sticky behave as expected and fixed not? Seems like both should behave similarly in terms of containing block...

[fantasai]

@HandsomeMedia Technically, position: sticky is more similar to position: relative than position: fixed.

[huan]

+1

[matthew-dean]

Is this issue removing transform as a containing block for fixed-position elements? I don't think
that is a good idea, as it:

makes clipping and filter effects hard to define and implement, and in general ill-defined because
it's impossible to "filter" across multiple 2d planes.
introduces difficult and complex code to implement compositing
makes it hard to provide clean fast paths for transforms

None of the "implementation is really difficult" argument seems relevant in terms of what makes sense in consistency of the language. position: fixed should always maintain that element in relation to the viewport. Setting a transform should not make it "steal" a fixed-positioned element from the viewport and inject it into its own context as if it's position: absolute. Algorithmically, you should still be able to scale/translate/rotate a fixed-positioned element based on it's original "viewport" position without changing what its height/width/top/left values initially mean.

[koko236]

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 position: fixed becomes completely unreliable and writing in any current spec or guide that fixed has anything to do with the viewport is simply misleading.

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:

The element is removed from the normal document flow; no space is created for the element in the page layout. Instead, it is positioned relative to the screen's viewport and doesn't move when scrolled.

Then later it's casually added that:

When an ancestor has the transform, perspective, or filter property set to something other than none, that ancestor is used as the container instead of the viewport

As this breaks probably each reasonable use case for fixed I'd put much more emphasis on it and mark clearly fixed as half broken.

[jonjohnjohnson]

In all honesty, better terminology needs to be created for how a fixed positioned elements containing block is defined, beyond just transform...

• Firefox and blink are also affected by perspective not set to none, which makes sense in line with transform.
• Firefox is affected by filter not set to none, making a leap from just informing the stacking context or isolation.
• Safari (desktop) only uses transform not set to none, yet perspective not set to none will still create a stacking context and there is no mention of this in the spec.
• Not as intimate with or sure of how Edge relates to this?

I understand that moving relationships of elements around different representations of the tree isn't easy and this issue isn't about removing transform affecting fixed (has anyone else seen iOS Safari juttering fixed elements when they are nested inside -webkit-overflow-scrolling: touch?), but there are serious compatibility issues that should be ironed out or at least...

...documented within css-position#fixed-pos.

[jonjohnjohnson]

Tangential -> #2717 - anything that creates a stacking context should sort in the positioned descendants z-ordering list

• The WG resolved that filter should be a containing block for abs-pos and fixed-pos descendants.
• Test for property declaration scenarios that create a stacking context (aside but still relevant for containing block discussions) from @dbaron.

[dirkschulze]

@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

[css-meeting-bot]

The Working Group just discussed Explicitly specify that a transform is a containing block for all descendants, and agreed to the following:

• RESOLVED: transform establishes a containing block for all elements.

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/w3c/csswg-drafts/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