W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2017

Re: [csswg-drafts] [css-transforms-2] Handling of coplanar elements

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
Message-ID: <issue_comment.created-342618645-1510088025-sysbot+gh@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>
&lt;chrishtr> topic:https://github.com/w3c/csswg-drafts/issues/1950<br>
&lt;chrishtr> github:https://github.com/w3c/csswg-drafts/issues/1950<br>
&lt;chrishtr> trchen:showing example of isolation:isolate parent with two 3d children with different z coordiante<br>
&lt;chrishtr> coordinate<br>
&lt;chrishtr> smfr: ED spec says that if the parent has content in its plane, then:<br>
&lt;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>
&lt;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>
&lt;chrishtr> smfr: all content with any z-index is drawn together into the same plane<br>
&lt;chrishtr> smfr: all content without any 3D, that is<br>
&lt;chrishtr> trchen: then an element with preserve-3d will extend the 3d context to the parent<br>
&lt;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>
&lt;chrishtr> smfr: so the proposal here might have compat problems<br>
&lt;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>
&lt;chrishtr> trchen: chromium currently does the paint effect thing<br>
&lt;chrishtr> marakow: not sure about edge behavior with an example. card-flip cases had compat issue in the path<br>
&lt;chrishtr> past<br>
&lt;chrishtr> smfr: we need to do testing and choose based on compat concerns<br>
&lt;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>
&lt;chrishtr> trchen: flattening is really very related to stacking context, so it's hard to define things<br>
&lt;chrishtr> trchen: all elements have a screen transform matrix of some kind<br>
&lt;chrishtr> smfr: isolation implies flattening, so 3D children should be flattened into its plane<br>
&lt;chrishtr> trchen: but then how is the rendering matrix for those 3D children defined, since the containing block is above the isolation element?<br>
&lt;chrishtr> smfr: doesn't seem necessary to compute the root-relative matrix. can compute relative to its 3d context root only<br>
&lt;chrishtr> chrishtr: can we make the isolation element a containing block for 3d children?<br>
&lt;chrishtr> various: what about filters, opacity, etc?<br>
&lt;chrishtr> chrishtr: filter is already a containing block for all children in Mozilla<br>
&lt;dbaron> mozilla filter containing block changes were in https://bugzil.la/1125767 and https://bugzil.la/1187851<br>
&lt;chrishtr> smfr: should be able to compute the geometry one way or another<br>
&lt;chrishtr> gregwitworth: what are we trying to solve here?<br>
&lt;chrishtr> chrishr: ED spec is ill-defined, need to define somehow<br>
&lt;chrishtr> dbaron: spec should be clear. should keep things aligned with compat and developer expectations as much as possible<br>
&lt;chrishtr> smfr: web compat in this area may be bad enough that we can make what decision seems best<br>
&lt;chrishtr> ericwilligers: is it too late to make containing block and stacking context agree?<br>
&lt;chrishtr> trchen: too late to fix this<br>
&lt;chrishtr> smfr: containing block is for geometry, stacking context is for rendering<br>
&lt;chrishtr> marakow: these things may be corner cases, but web developers may be depending on them accidentally<br>
&lt;chrishtr> trchen: but they will get divergent behavior across browsers if they don't agree on compat<br>
&lt;smfr> i filed<br>
&lt;smfr> https://github.com/w3c/csswg-drafts/issues/1951<br>
&lt;chrishtr> github:https://github.com/w3c/csswg-drafts/issues/1951<br>
&lt;chrishtr> marakow:testcases are critical<br>
&lt;chrishtr> trchen: back to discussion about how to do overflow clip flattening without stacking context<br>
&lt;chrishtr> trchen: how should flattened result of 3d children sort against other children?<br>
&lt;mwoodrow> q+<br>
&lt;chrishtr> mwoodrow: in Mozilla in these cases, the overflow hidden element does not have preserve-3d on it<br>
&lt;chrishtr> mwoodrow: so it does not sort anything<br>
&lt;chrishtr> mwoodrow: in mozilla, the 3d child flattens itself<br>
&lt;chrishtr> mwoodrow: mozilla looks at the DOM parent to determine whether to avoid flattening<br>
&lt;smfr> i filed https://github.com/w3c/csswg-drafts/issues/1952 on the no-op div issue<br>
&lt;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>
&lt;chrishtr> smfr: making no-op parents flatten seems to be a breaking change<br>
&lt;chrishtr> mwoodrow: maybe not? Not aware of issues against Mozilla due to this behavior<br>
&lt;chrishtr> trchen: perhaps we can change transform-style to apply only if it's a stacking contet<br>
&lt;chrishtr> context<br>
&lt;chrishtr> trchen: fourth topic: coplanar planes is a computationally intractable issue<br>
&lt;chrishtr> trchen: because of floating-point accuracy issues<br>
&lt;smfr> filed https://github.com/w3c/csswg-drafts/issues/1953 on coplanar elements<br>
&lt;chrishtr> ericwilligers: found the animation example here compelling: don't want one frame of an animation where "coplanar" returns true<br>
&lt;chrishtr> github:https://github.com/w3c/csswg-drafts/issues/1953<br>
&lt;chrishtr> trchen: doesn't make sense to specify the epsilon for coplanarity, because of implementation difficulty<br>
&lt;dbaron> drawing #4 on the flipchart is https://lists.w3.org/Archives/Public/www-archive/2017Nov/att-0007/IMG_20171107_123911.jpg<br>
&lt;chrishtr> marakow: is the recommendation to say the behavior is undefined?<br>
&lt;chrishtr> trchen: yes<br>
&lt;chrishtr> marakow: should be able to define an epsilon<br>
&lt;chrishtr> trchen: two planes that are extremely close to the epsilon threshold may result in floating-point accuracy issues<br>
&lt;chrishtr> marakow: unspecified behavior does not achieve compat<br>
&lt;chrishtr> trchen: the ED spec has a TODO item to define subtree planes<br>
&lt;chrishtr> trchen: webkit and blink create a plane if there is any 3D transform.<br>
&lt;chrishtr> trchen: mozilla looks at the final matrix to see if there is 3D<br>
&lt;chrishtr> dbaron: thought the spec already said this?<br>
&lt;chrishtr> dbaron: seems good to match webkit/blink behavior for defining planes<br>
&lt;chrishtr> smfr: on coplanar: a good example of making things coplanar on purpose is a flipping card<br>
&lt;chrishtr> smfr: one way to implement is two elements, one of which flips relative to the other<br>
&lt;chrishtr> smfr: this will result in coplanarity numerical issues<br>
&lt;chrishtr> smfr: another way to do it is to put the transform on the container instead and flip it<br>
&lt;chrishtr> marakow: hit bugs where authors failed to specify backface-visibility:hidden and ended up with fighting/coplanar problems<br>
&lt;chrishtr> trchen: coplanar is not even what developers would want because it results in one thing always being on top<br>
&lt;chrishtr> trchen: I think we should make it undefined, and advise developers to not draw plans within these epsilons<br>
&lt;chrishtr> gregwhitworth: need to make things as specified as possible<br>
&lt;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>
&lt;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>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 7 November 2017 20:53:54 UTC