- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 07 Nov 2017 20:53:47 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `https://github.com/w3c/csswg-drafts/issues/1950`. <details><summary>The full IRC log of that discussion</summary> <chrishtr> topic:https://github.com/w3c/csswg-drafts/issues/1950<br> <chrishtr> github:https://github.com/w3c/csswg-drafts/issues/1950<br> <chrishtr> trchen:showing example of isolation:isolate parent with two 3d children with different z coordiante<br> <chrishtr> coordinate<br> <chrishtr> smfr: ED spec says that if the parent has content in its plane, then:<br> <chrishtr> smfr: in the same way that negative z-index children paint in front of the stacking context's background, but behind its foreground<br> <chrishtr> smfr: a natural extension to 3D is that the background of the parent is painted, then the "Foreground" content is a plane which is intersected with 3D child planes before flattening<br> <chrishtr> smfr: all content with any z-index is drawn together into the same plane<br> <chrishtr> smfr: all content without any 3D, that is<br> <chrishtr> trchen: then an element with preserve-3d will extend the 3d context to the parent<br> <chrishtr> smfr: it's common for sites to have a "card flip animation" effect in their UX. it looks wrong if that card intersects the background of the container, and maybe also the foreground<br> <chrishtr> smfr: so the proposal here might have compat problems<br> <chrishtr> smfr: alternate possibility is that the depth component is simply dropped and transforms become a "paint effect" that changes the output of its content<br> <chrishtr> trchen: chromium currently does the paint effect thing<br> <chrishtr> marakow: not sure about edge behavior with an example. card-flip cases had compat issue in the path<br> <chrishtr> past<br> <chrishtr> smfr: we need to do testing and choose based on compat concerns<br> <chrishtr> smfr: if you really want sorting of any kind with 3D transforms, use preserve-3d, otherwise we need to do something reasonable for compat<br> <chrishtr> trchen: flattening is really very related to stacking context, so it's hard to define things<br> <chrishtr> trchen: all elements have a screen transform matrix of some kind<br> <chrishtr> smfr: isolation implies flattening, so 3D children should be flattened into its plane<br> <chrishtr> trchen: but then how is the rendering matrix for those 3D children defined, since the containing block is above the isolation element?<br> <chrishtr> smfr: doesn't seem necessary to compute the root-relative matrix. can compute relative to its 3d context root only<br> <chrishtr> chrishtr: can we make the isolation element a containing block for 3d children?<br> <chrishtr> various: what about filters, opacity, etc?<br> <chrishtr> chrishtr: filter is already a containing block for all children in Mozilla<br> <dbaron> mozilla filter containing block changes were in https://bugzil.la/1125767 and https://bugzil.la/1187851<br> <chrishtr> smfr: should be able to compute the geometry one way or another<br> <chrishtr> gregwitworth: what are we trying to solve here?<br> <chrishtr> chrishr: ED spec is ill-defined, need to define somehow<br> <chrishtr> dbaron: spec should be clear. should keep things aligned with compat and developer expectations as much as possible<br> <chrishtr> smfr: web compat in this area may be bad enough that we can make what decision seems best<br> <chrishtr> ericwilligers: is it too late to make containing block and stacking context agree?<br> <chrishtr> trchen: too late to fix this<br> <chrishtr> smfr: containing block is for geometry, stacking context is for rendering<br> <chrishtr> marakow: these things may be corner cases, but web developers may be depending on them accidentally<br> <chrishtr> trchen: but they will get divergent behavior across browsers if they don't agree on compat<br> <smfr> i filed<br> <smfr> https://github.com/w3c/csswg-drafts/issues/1951<br> <chrishtr> github:https://github.com/w3c/csswg-drafts/issues/1951<br> <chrishtr> marakow:testcases are critical<br> <chrishtr> trchen: back to discussion about how to do overflow clip flattening without stacking context<br> <chrishtr> trchen: how should flattened result of 3d children sort against other children?<br> <mwoodrow> q+<br> <chrishtr> mwoodrow: in Mozilla in these cases, the overflow hidden element does not have preserve-3d on it<br> <chrishtr> mwoodrow: so it does not sort anything<br> <chrishtr> mwoodrow: in mozilla, the 3d child flattens itself<br> <chrishtr> mwoodrow: mozilla looks at the DOM parent to determine whether to avoid flattening<br> <smfr> i filed https://github.com/w3c/csswg-drafts/issues/1952 on the no-op div issue<br> <chrishtr> trchen: chromium flattens if the parent has positioning, is a stacking context or has clips, but not otherwise. this is a consequence of the implementation more than anything else<br> <chrishtr> smfr: making no-op parents flatten seems to be a breaking change<br> <chrishtr> mwoodrow: maybe not? Not aware of issues against Mozilla due to this behavior<br> <chrishtr> trchen: perhaps we can change transform-style to apply only if it's a stacking contet<br> <chrishtr> context<br> <chrishtr> trchen: fourth topic: coplanar planes is a computationally intractable issue<br> <chrishtr> trchen: because of floating-point accuracy issues<br> <smfr> filed https://github.com/w3c/csswg-drafts/issues/1953 on coplanar elements<br> <chrishtr> ericwilligers: found the animation example here compelling: don't want one frame of an animation where "coplanar" returns true<br> <chrishtr> github:https://github.com/w3c/csswg-drafts/issues/1953<br> <chrishtr> trchen: doesn't make sense to specify the epsilon for coplanarity, because of implementation difficulty<br> <dbaron> drawing #4 on the flipchart is https://lists.w3.org/Archives/Public/www-archive/2017Nov/att-0007/IMG_20171107_123911.jpg<br> <chrishtr> marakow: is the recommendation to say the behavior is undefined?<br> <chrishtr> trchen: yes<br> <chrishtr> marakow: should be able to define an epsilon<br> <chrishtr> trchen: two planes that are extremely close to the epsilon threshold may result in floating-point accuracy issues<br> <chrishtr> marakow: unspecified behavior does not achieve compat<br> <chrishtr> trchen: the ED spec has a TODO item to define subtree planes<br> <chrishtr> trchen: webkit and blink create a plane if there is any 3D transform.<br> <chrishtr> trchen: mozilla looks at the final matrix to see if there is 3D<br> <chrishtr> dbaron: thought the spec already said this?<br> <chrishtr> dbaron: seems good to match webkit/blink behavior for defining planes<br> <chrishtr> smfr: on coplanar: a good example of making things coplanar on purpose is a flipping card<br> <chrishtr> smfr: one way to implement is two elements, one of which flips relative to the other<br> <chrishtr> smfr: this will result in coplanarity numerical issues<br> <chrishtr> smfr: another way to do it is to put the transform on the container instead and flip it<br> <chrishtr> marakow: hit bugs where authors failed to specify backface-visibility:hidden and ended up with fighting/coplanar problems<br> <chrishtr> trchen: coplanar is not even what developers would want because it results in one thing always being on top<br> <chrishtr> trchen: I think we should make it undefined, and advise developers to not draw plans within these epsilons<br> <chrishtr> gregwhitworth: need to make things as specified as possible<br> <chrishtr> marakow: still think this should be specified, but ok to have a note in the spec that it's not a good idea to depend on exact behavior<br> <chrishtr> marakow: all of the items in the explainer are real and good to fix. but we need to do a lot more discussion based on testing and additional research to resolve them<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1953#issuecomment-342618645 using your GitHub account
Received on Tuesday, 7 November 2017 20:53:52 UTC