Re: [csswg-drafts] [css-transforms-2] transform-style: flat should not create stacking context, and 3D context grouping (#1950)

The CSS Working Group just discussed `3D Transform Interop`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: 3D Transform Interop<br>
&lt;fantasai> mattwoodrow: The current ED is pretyt unclear and seems to not be backwards-compatible with the WEb. We're seeing lots of bugs in Firefox and it's unclera what we're supposed to implement.<br>
&lt;AmeliaBR> Current spec:<br>
&lt;fantasai> mattwoodrow: Wanted to clear up what we want to do, get implementations and spec to match<br>
&lt;fantasai> mattwoodrow: esp transform-style: 3d<br>
&lt;fantasai> astearns: I see a list of issues in the agenda<br>
&lt;fantasai> mattwoodrow: 4-5 are those cover transform-style<br>
&lt;fantasai> smfr: I think all those issues could be duped to a single issue. They're pretty vague<br>
&lt;fantasai> mattwoodrow: targeting individual pieces<br>
&lt;fantasai> smfr: I can summarize state of problems<br>
&lt;fantasai> smfr: You mentioned speccing webkit behavior. But Webkit behavior is not very definite.<br>
&lt;fantasai> smfr: WebKit tries to follow spirit of current spec<br>
&lt;fantasai> smfr: The main issue is that transform-style: flat creates stacking context, but the draft also says that 'overflow: not visible' also triggers transform-style: flat<br>
&lt;florian> q+<br>
&lt;astearns> github:<br>
&lt;fantasai> smfr: Which implies that non-visible overflow creates a stacking context which would be nice but we cna't do that<br>
&lt;fantasai> dbaron: But at this time 'transform-style: flat' doesn't create a stacking context in any implementation<br>
&lt;fantasai> smfr: There's no implementation that has a consistent model for how this all should work<br>
&lt;florian> q-<br>
&lt;fantasai> smfr: So I tried to introduce an auto value to help solve thi issue<br>
&lt;fantasai> ...<br>
&lt;fantasai> q-<br>
&lt;fantasai> AmeliaBR: Background root triggers list, could maybe be adopted as a list of what triggers auto to turn into flat?<br>
&lt;fantasai> smfr: Transforms spec has a list of "grouping properties"... "graphical grouping propeties" should have a master list in a spec somewhere<br>
&lt;fantasai> smfr: Should agree across the specs<br>
&lt;fantasai> smfr: 3D transforms and backdrop-filter<br>
&lt;fantasai> dbaron: When I brought this issue up last year agreed we should have a consistent term<br>
&lt;fantasai> dbaron: Just variation on whether also becoames a contianing block that trasp fixedpos<br>
&lt;fantasai> AmeliaBR: Still in the spec that SVG elements have special behavior in that 2D transforms on SVG elements don't cause stacking and some other things even though they do on CSS boxes<br>
&lt;dbaron> We also need... an above CSS-level-2 spec that can define base terms for this stuff!<br>
&lt;fantasai> AmeliaBR: That's important in SVG because transforms are the main way to do "layout" in SVG, but does complicate the definition<br>
&lt;fantasai> smfr: I thought every element in SVG was a stacking context, did that change when z-index was added?<br>
&lt;mattwoodrow> q+<br>
&lt;fantasai> AmeliaBR: Yes. Hard to get ppl to implement z-index for that reason<br>
&lt;fantasai> AmeliaBR: Do have a definition for it somewhere.<br>
&lt;fantasai> smfr: stacking context introduces a lot of complexity everywhere. Having also in SVG scares me.<br>
&lt;fantasai> mattwoodrow: spearate issue to raise about the draft<br>
&lt;fantasai> mattwoodrow: Current spec for transform-style says to look for containing block<br>
&lt;chris> q+ to mention this is why we resisted adding z-index to SVG for so long<br>
&lt;fantasai> mattwoodrow: Decided to flatten and switch transform-style to flat<br>
&lt;fantasai> mattwoodrow: But can have a stackign context that's not a containing block<br>
&lt;fantasai> mattwoodrow: I think if we changed ? to use the ?<br>
&lt;fantasai> mattwoodrow: Then we could be clear about when we're supposed to flatten<br>
&lt;mattwoodrow> q-<br>
&lt;xfq> ack chris<br>
&lt;Zakim> chris, you wanted to mention this is why we resisted adding z-index to SVG for so long<br>
&lt;fantasai> chris: We've slightly moved past that, but this is why SVG resisted adding z-index for many years<br>
&lt;fantasai> chris: The model with painting in SVG was simpler, didn't add stacking contexts.<br>
&lt;fantasai> chris: Adding z-index brings two models into SVG. Worth doing, but a lot of work.<br>
&lt;fantasai> ...<br>
&lt;fantasai> astearns: Need to resolve that we don't create a stacking context but decide what we do instead?<br>
&lt;fantasai> smfr: So we have a resolution for this issue but not an actual fix<br>
&lt;fantasai> astearns: Anyone have an idea of what we should do?<br>
&lt;astearns> explainer:<br>
&lt;fantasai> mattwoodrow: TienYan Chan from Google who use dto work on this but unfortunately doesn't anymore had a long explainer of these problems with a porposed solution for four different things<br>
&lt;fantasai> chrishtr: This was descussed at a breakout session at tpac 2017, was clear that more work was needed. Some cases we couldn't explain still<br>
&lt;fantasai> chrishtr: afaik this explainer document is the closest we got to figuring out what to do<br>
&lt;fantasai> astearns: Maybe another breakout session this week?<br>
&lt;fantasai> chrishtr: It's 12 pages, so would need to reread it to remember what it says<br>
&lt;fantasai> chrishtr: It does seem there's room on the agenda. is there enough interest?<br>
&lt;fantasai> [scheduling]<br>
&lt;fantasai> astearns: so breakout session tomorrow afternoon. If anything on the agenda then that woudl be problematic, lmk so I can shuffle things around<br>
&lt;fantasai> smfr: Tess can cover dark mode<br>
&lt;fantasai> dbaron: Mozilla is next door, so if can't get a room here can get a room there.<br>
&lt;fantasai> &lt;br type=lunch><br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at using your GitHub account

Received on Monday, 25 February 2019 19:59:11 UTC