trackbot, start meeting

present+

Topic: transforms

present+

Present+

present+

scribenick: AmeliaBR

smfr: This is the 12-page explainer we're reviewing. (link above)

... do we need basic explainer, or can we jump into the issues?

(consensus: jump in)

smfr: Issue 1, overflow as a grouping property

... Spec currently says that overflow causes a flattening, which limits many things like parallax effects.

... It's related to causing containing block. Transform style flows through dom tree. Maybe it would be better to flow through the containing block layout tree, so then a transform wouldn't need to force containing.

chrishtr: That doesn't sound right. Overflow:hidden should clip all descendents that can be contained within it, so the two go together. Transforms may not be same as abs pos, but it acts similar for painting.

... Compare A and B in Simon's example (Codepen link above)

smfr: top one, overflow isn't clipping B; bottom one it is

chrishtr: Isn't that because of the position: absolute?

smfr: Oh, that my break my demo...

smfr: So, unless we want to change the behavior of transform things, we need to change something.

chrishtr: But the issue is that if overflow is grouping, that implies flattening, which implies a stacking context, but overflow doesn't create a stacking context.

smfr: But unless you do flattening, I don't think you can clip. The elements are into 3D space.

AmeliaBR: Could you possibly partially flatten sections after dividing elements by stacking layer? It's a bit of a mess, but there's no sane way to mix 3D z-ordering and z-index.

mattwoodrow: Also, as I comment there, how do you decide what is the scrolling region without first flattening?

... it's particularly problematic with `preserve-3d`, since the used style still gets forced to flat.

chrishtr: So we'd need to make overflow: hidden/scroll part of the transform-style, in that it is always the end boundary. It changes to flat *and* forces a stacking context.

TabAtkins: So only in that combination, would it all happen.

mattwoodrow: It's still pretty confusing in the `transform-style` three-value syntax

chrishtr: So, what does `auto` mean?

Amelia: flatten under various conditions, e.g. stacking context or overflow hidden, but pass through 3D context if it is not complicated. `preserve-3d` says pass through even if the current element has transforms, which would usually trigger flattening.

chrishtr: So, can we do what Matt said?

dbaron: we're discussing what triggers flattening

chrishtr: we can assume every element for now, then focus on developer ergonomics

Sorry, scribing failure. I was offline without realizing it.

smfr: So you're saying that when "cube" is rendering into its ancestor, you flatten. In WK we flatten when rendering the children.

smfr: But that results in the same rendering at the end.

AmeliaBR: Would the behavior differ if there was a second cube?

smfr: WK will depth-sort these all together in that case.

dbaron: ARe you sure you're reading this correctly?

dbaron: Two sibling cubes both with preserve-3d

mattwoordrow: Right, their *parent* doesn't ahve p-3d, so the cubes themselves establish 3d rendering contexts.

TabAtkins: So is *anyone's* current behavior actually described in a spec?

smfr: No. Current WK behavior is the result of someone bolting CG 3d support into the web, and me trying to write up a model into a spec.

mattwoodrow: Right. I think there's a lot of confusion here. I think Firefox's behavior is simple to understand, and it mostly works for web content.

TabAtkins: So Firefox does what the spec originally was written to say - the highest element with p-3d establishes a 3d scene; descendants have to say p-3d to stay in that scene

chrishtr: Simon, sounds like Gecko's model is osmething we might bea ble to adopt, assuming compat works?

smfr: It's different from the conceptual model we had before...

smfr: If we ignore the property values right now, but describe things in terms of establishing 3d and participating in 3d, do we still have a clear model of clipping and 3d contexts?

chrishtr: So what about the following model:

chrishtr: Adjacent things with p-3d are in the same 3d scene. p-3d always establishes a stacking context, so you can't mix z-ordering and 3d transforming.

chrishtr: Any of the grouping properties in the ED spec, when combined with a specified style of p-3d, will cause a used value of flat.

chrishtr: After the flattening, apply the property's effect (clipping, etc)

smfr: Sounds like ED + this explainer?

AmeliaBR: Sounds like would be most helpful to have this written down by people.

Rossen: Going back to adjacent p-3d elements... What about when they're intertwined with non-p-3d elements?

smfr: So if we have a non-3d sibling between the cubes, the non-3d renders into the 2d plane of the parent...

AmeliaBR: Under Gecko's model, is it useful to have perspective on non p-3d elements?

TabAtkins: No, it won't do anything.

mattwoodrow: We might have a different model here too - perspective on an element with a 3d transform by itself, will cause the perspective to happen

dbaron: If you think about the process as oing leaves-up, perspective is the only things that happens *after* scrolling but *before* scroller-caused flattening.

smfr: So part of the reason I went from ED to WD format is I coudln't get ED format to have a consistent model.

smfr: But maybe it does require putting p-3d on all ancestors, tho I fear the webcompat implications of that.

TabAtkins: Apparently it works for Firefox.

AmeliaBR: Spamming p-3d across the tree until it works is a common authoring style in my experience.

mattwoodrow: I can put together an explainer for Gecko in the next week or two.

smfr: One of the diffs in our bheavior is if you have an element with a simple 3d transform, does it start intersecting with the plane it's in? Safari does that, maybe unexpected.

TabAtkins: Yeah, unexpected to me without p-3d; I thought it would transform and flatten when painting into the parent.

AmeliaBR: Focus on logical model first, then what properties and what value to control that.

smfr: Reftest strategy: clippath to only show a chunk of the interior, or exterior, so you avoid antialiasing on edges

Topic: backface-visiblity

smfr: Simple case, element is flipped over. With b-f: off, the element disappears.

smfr: If there's an element inside of it with the b-f, does it stop rendering?

dbaron: Is the outer flattened?

dbaron: Speaking directly from ideas, if the outer element flattens, the child's b-f won't matter when you flip the parent.

mattwoodrow: Almost. Actual imp is that b-f creates a pseudo-stacking context

mattwoodrow: [missed explanation ;_;]

mattwoodrow: Spec says the prop applies ot the element and not its descendants

mattwoodrow: Case: 3d rendering root with 2 children

mattwoodrow: Back face is flipped around, so it's 3d and a stackign context. Front face doesn't have anything, so it's not a stacking context.

mattwoodrow: So when you flip around the parent, the "front" face doesn't have its backfaces hidden.

mattwoodrow: It looks like WK doesn't flatten positioned descendants of a b-f:no element.

mattwoodrow: I would prefer to say b-f:hidden creates a stacking context.

mattwoodrow: I dont' think some children popping out and not getting hidden is a desirable thing.

s/b-f:/backface-visibility:/

smfr: b-f is a cargocult property pages sometimes do to trigger compositing

smfr: Another option is to say only works if it has a transform, or participates in a 3d rendering context.

mattwoodrow: Harder to explain.

smfr: When we see b-v:hidden we do a compositing thing. We look at preserve-3d on the stacking context.

smfr: So it's really if it's doing 3d rendering. It does nothing if it's not participating in 3d.

smfr: I'd prefer b-v triggering *new* side effects, but I'd be willing to have it causing less side effects.

mattwoodrow: Will a stackign context break things?

smfr: Right now we only do it when it's in 3d.

mattwoodrow: I think we can specify that.

smfr: I think the spec is also wrong... talkinga bout computing the amtrix relative to the nearest 3d rendering context.

smfr: People really want it relative to the view/window

AmeliaBR: If there's flattening somewhere it's relative to that, otherwise it'll be relative to the view, basically.

AmeliaBR: Can we take this explainer and turn it into GH issues so people can comment?

smfr: We could. Not sure this is a great distillation of the issues.

smfr: We should def clean up existing issues, and make sure any new issues from this are raised.

AmeliaBR: I'm thinking of some people that do experiementation with 3d and know the bugs...

smfr: We should get them into the WG.

smfr: I'll sign up to clean up the GH issues.

AmeliaBR: Let me know when you do and I'll set Ana Tudor on it.

Rossen: So what about b-v issue?

smfr: We decided we wanted b-v to apply to things in a 3d rendering context.

Explainer (again): docs.google.com/document/d/1FIQW9qV…ifFOXWWK0-7fXrjlSeYeZN7wHmIHo/edit#

smfr: Something in the explainer... [draws]

smfr: Mixing stacking context and 3d transforms.

<div stacking> <div 3d /> <div stacking> <div 3d /> <div 3d /> </div> </div>

smfr: So all the 3d divs have different z transforms.

dbaron: Isn't isolate a grouping property? It would flatten, so the latter two don't z-sort with the first.

dbaron: Also, after writing up happens, maybe useful to schedule a special telcon, maybe longer than an hour, to go thru all this before the next f2f

Rossen: Agree.

[discussion about editting]

RESOLVED: Move Dean and Tess to former editor, add Matt as current.

trackbot, end meeting