New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-transforms-2] Explicitly specify that a transform is a containing block for all descendants #913

Closed
smfr opened this Issue Jan 13, 2017 · 18 comments

Comments

Projects
None yet
@mikemcguire

This comment has been minimized.

mikemcguire commented Jan 13, 2017

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

@smfr smfr changed the title from Use of “containing block” does not match CSS2.1 definition to [css-transforms-2] Use of “containing block” does not match CSS2.1 definition Jan 13, 2017

@tomasdev

This comment has been minimized.

tomasdev commented Sep 13, 2017

Are there any plans on fixing this?

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

@asiljan

This comment has been minimized.

asiljan commented Oct 6, 2017

+1

@chrishtr

This comment has been minimized.

chrishtr commented Nov 6, 2017

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

This comment has been minimized.

mikemcguire commented Nov 6, 2017

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

This comment has been minimized.

Contributor

RByers commented Nov 15, 2017

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

@RByers RByers changed the title from [css-transforms-2] Use of “containing block” does not match CSS2.1 definition to [css-transforms-2] Explicitly specify that a transform is a containing block for all descendants Nov 15, 2017

@RByers

This comment has been minimized.

Contributor

RByers commented 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.

@tegtmeier

This comment has been minimized.

tegtmeier commented Nov 17, 2017

+1

@chasebank

This comment has been minimized.

chasebank commented Nov 29, 2017

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

This comment has been minimized.

HandsomeMedia commented Feb 1, 2018

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

This comment has been minimized.

Contributor

fantasai commented Feb 2, 2018

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

@huan

This comment has been minimized.

huan commented Feb 18, 2018

+1

@matthew-dean

This comment has been minimized.

matthew-dean commented Feb 28, 2018

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 comment has been minimized.

koko236 commented Apr 13, 2018

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

This comment has been minimized.

jonjohnjohnson commented Apr 13, 2018

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.

@dirkschulze

This comment has been minimized.

Contributor

dirkschulze commented Jun 26, 2018

@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

This comment has been minimized.

Member

css-meeting-bot commented Jul 3, 2018

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//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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment