Re: [csswg-drafts] [css-transforms-2] Preserve-3d + backface visibility semantics need to be clarified (#918)

The CSS Working Group just discussed `backface visibility`, and agreed to the following:

* `RESOLUTION: Add a new "pseudo-stacking context" definition and use it to define how backface-visibility works`

<details><summary>The full IRC log of that discussion</summary>
&lt;heycam> Topic: backface visibility<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/918<br>
&lt;heycam> mattwoodrow: current spec says that backface-visibility only applies to the element it's on, not descendants<br>
&lt;heycam> ... doesn't say it would create any plane or layer, which Gecko faithfully implements<br>
&lt;heycam> ... other engines create a plane for all descendants but not positioned descendants<br>
&lt;heycam> ... which is not something there's any precedent for, seems a bit crazy.  would prefer backface-visibility create a stacking context<br>
&lt;heycam> smfr: I think in WebKit it does create a stacking context, not a containing block<br>
&lt;heycam> mattwoodrow: maybe it is that it doesn't create a containing block<br>
&lt;heycam> chrishtr: definitely doesn't create a stacking context<br>
&lt;heycam> smfr: I'd be scared to change hte behavior of backface-visibility...<br>
&lt;heycam> mattwoodrow: so try to find a descroption of what it actually does.  affects itself and non-positioned descendants?<br>
&lt;heycam> chrishtr: self painting layers reset the backface visibility thing<br>
&lt;heycam> mattwoodrow: don't know how to describe it for the spec<br>
&lt;heycam> chrishtr: similar to the set of things dbaron found that caused "painting as if positioned"<br>
&lt;heycam> ... in CSS 2.1, positioned elts paint  later than regular elements<br>
&lt;dbaron> https://dbaron.org/css/test/2018/stacking-context-z-order<br>
&lt;heycam> ... anything that has an effect-y thing on it<br>
&lt;heycam> ... this is exactly what is on self painting layers<br>
&lt;heycam> ... so we could define it that way<br>
&lt;heycam> florian: where else did we run into this?<br>
&lt;heycam> chrishtr: might have been another case yes<br>
&lt;heycam> ... but the thing about hte paint order is one that's not specified properly, is that right?<br>
&lt;heycam> mattwoodrow: most of hte psecs that create stacking ocntext say that.  but they mean create a stacking ocntext and sort it with positioned descendants<br>
&lt;heycam> chrishtr: overflow:hidden, backface-visibility, SVG elements and other atomically replaced elements, ...<br>
&lt;heycam> ... CSS clip probably<br>
&lt;heycam> ... and the rest of them do create stacking contexts<br>
&lt;heycam> ... we should define this, get interop on the table in dbaron's test, then use it for the backface-visibility definition<br>
&lt;heycam> dbaron: I don't think there's a whole lot in there that's not creating a stacking context<br>
&lt;heycam> ... CSS clip only applies to things that are positioned<br>
&lt;heycam> chrishtr: but in terms of the "painting as if positioned"<br>
&lt;heycam> ... I think overflow:clip is the most common<br>
&lt;heycam> dbaron: have we added that yet?<br>
&lt;heycam> chrishtr: I mean overlfow:hidden and scroll<br>
&lt;heycam> ... on the issue in which this table resides, I mention there's a silly quirk in Chrome and probably WebKit, not triggering self painting in some bizarre corner cases of scrolling<br>
&lt;heycam> smfr: WK does not create self painting layers for [...]<br>
&lt;heycam> dbaron: I don't htink Gecko sorts overflow:hidden on to positioned descendants list<br>
&lt;heycam> mattwoodrow: don't think so<br>
&lt;astearns> s/[...]/overflow:hidden/<br>
&lt;heycam> mattwoodrow: overflow:hidden isn't a stacking context, can interleave things inside and outside, so can't go in the positioned descendants list<br>
&lt;heycam> smfr: so is everything on the list make stacking context?<br>
&lt;heycam> mattwoodrow: yes<br>
&lt;heycam> chrishtr: overflow:hidden does not create a self painting layer (in Blink)<br>
&lt;heycam> ... if there's overlfow:scroll but is in effect like overflow:hidden since there's nothing to scroll, then we skip it<br>
&lt;heycam> ... that's something we could change in Chrome<br>
&lt;heycam> ... in any case, is this a good way to spec it?<br>
&lt;heycam> mattwoodrow: yes, I agree the CSS 2.1 spec describes floats [...]<br>
&lt;dbaron> I think Gecko calls this "pseudo-stacking context"<br>
&lt;heycam> RESOLUTION: Add a new "pseudo-stacking context" definition and use it to define how backface-visibility works<br>
&lt;heycam> dbaron: some of this would be easier if there's a spec to put this old CSS 2.1 text to evolve it<br>
&lt;heycam> ... maybe a central painting spec<br>
&lt;heycam> -- break until 4pm --<br>
&lt;TabAtkins> ScribeNick: TabAtkins<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/918#issuecomment-531664750 using your GitHub account

Received on Monday, 16 September 2019 07:12:40 UTC