19:59:46 <RRSAgent> RRSAgent has joined #fx
19:59:46 <RRSAgent> logging to https://www.w3.org/2017/11/07-fx-irc
20:00:07 <dbaron> [note there's a bit of backlog prior to the RRSAgent-recorded log that's on logs.csswg.org ]
20:00:09 <chrishtr> topic:https://github.com/w3c/csswg-drafts/issues/1944
20:00:20 <chrishtr> topic:https://github.com/w3c/csswg-drafts/issues/1950
20:00:25 <chrishtr> github:https://github.com/w3c/csswg-drafts/issues/1950
20:01:12 <chrishtr> trchen:showing example of isolation:isolate parent with two 3d children with different z coordiante
20:01:15 <chrishtr> coordinate
20:03:02 <chrishtr> smfr: ED spec says that if the parent has content in its plane, then:
20:03:25 <chrishtr> smfr: in the same way that negative z-index children paint in front of the stacking context's background, but behind its foreground
20:04:40 <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
20:05:39 <chrishtr> smfr: all content with any z-index is drawn together into the same plane
20:05:52 <chrishtr> smfr: all content without any 3D, that is
20:06:13 <chrishtr> trchen: then an element with preserve-3d will extend the 3d context to the parent
20:06:53 <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
20:07:05 <chrishtr> smfr: so the proposal here might have compat problems
20:07:55 <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
20:08:43 <chrishtr> trchen: chromium currently does the paint effect thing
20:09:03 <chrishtr> marakow: not sure about edge behavior with an example. card-flip cases had compat issue in the path
20:09:04 <chrishtr> past
20:09:41 <chrishtr> smfr: we need to do testing and choose based on compat concerns
20:10:12 <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
20:11:03 <chrishtr> trchen: flattening is really very related to stacking context, so it's hard to define things
20:12:13 <chrishtr> trchen: all elements have a screen transform matrix of some kind
20:12:52 <florian> florian has joined #fx
20:14:22 <chrishtr> smfr: isolation implies flattening, so 3D children should be flattened into its plane
20:14:53 <chrishtr> trchen: but then how is the rendering matrix for those 3D children defined, since the containing block is above the isolation element?
20:16:01 <chrishtr> smfr: doesn't seem necessary to compute the root-relative matrix. can compute relative to its 3d context root only
20:17:52 <chrishtr> chrishtr: can we make the isolation element a containing block for 3d children?
20:18:06 <chrishtr> various: what about filters, opacity, etc?
20:18:18 <chrishtr> chrishtr: filter is already a containing block for all children in Mozilla
20:19:12 <dbaron> mozilla filter containing block changes were in https://bugzil.la/1125767 and https://bugzil.la/1187851
20:20:31 <chrishtr> smfr: should be able to compute the geometry one way or another
20:20:51 <chrishtr> gregwitworth: what are we trying to solve here?
20:20:59 <chrishtr> chrishr: ED spec is ill-defined, need to define somehow
20:21:34 <chrishtr> dbaron: spec should be clear. should keep things aligned with compat and developer expectations as much as possible
20:22:14 <chrishtr> smfr: web compat in this area may be bad enough that we can make what decision seems best
20:23:27 <chrishtr> ericwilligers: is it too late to make containing block and stacking context agree?
20:23:34 <chrishtr> trchen: too late to fix this
20:23:46 <chrishtr> smfr: containing block is for geometry, stacking context is for rendering
20:24:46 <chrishtr> marakow: these things may be corner cases, but web developers may be depending on them accidentally
20:25:20 <chrishtr> trchen: but they will get divergent behavior across browsers if they don't agree on compat
20:25:23 <smfr> i filed
20:25:24 <smfr> https://github.com/w3c/csswg-drafts/issues/1951
20:25:40 <chrishtr> github:https://github.com/w3c/csswg-drafts/issues/1951
20:26:08 <chrishtr> marakow:testcases are critical
20:28:24 <chrishtr> trchen: back to discussion about how to do overflow clip flattening without stacking context
20:28:47 <chrishtr> trchen: how should flattened result of 3d children sort against other children?
20:31:57 <mwoodrow> q+
20:33:06 <chrishtr> mwoodrow: in Mozilla in these cases, the overflow hidden element does not have preserve-3d on it
20:33:13 <chrishtr> mwoodrow: so it does not sort anything
20:34:54 <chrishtr> mwoodrow: in mozilla, the 3d child flattens itself
20:35:28 <chrishtr> mwoodrow: mozilla looks at the DOM parent to determine whether to avoid flattening
20:35:50 <Rossen> Rossen has joined #fx
20:37:01 <smfr> i filed https://github.com/w3c/csswg-drafts/issues/1952 on the no-op div issue
20:37:21 <leaverou> leaverou has joined #fx
20:37:21 <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
20:37:51 <plinss> plinss has joined #fx
20:37:59 <chrishtr> smfr: making no-op parents flatten seems to be a breaking change
20:38:12 <chrishtr> mwoodrow: maybe not? Not aware of issues against Mozilla due to this behavior
20:39:06 <chrishtr> trchen: perhaps we can change transform-style to apply only if it's a stacking contet
20:39:09 <chrishtr> context
20:39:09 <bradk> bradk has joined #fx
20:40:30 <chrishtr> trchen: fourth topic: coplanar planes is a computationally intractable issue
20:40:40 <chrishtr> trchen: because of floating-point accuracy issues
20:41:20 <smfr> filed https://github.com/w3c/csswg-drafts/issues/1953 on coplanar elements
20:41:23 <chrishtr> ericwilligers: found the animation example here compelling: don't want one frame of an animation where "coplanar" returns true
20:41:30 <chrishtr> github:https://github.com/w3c/csswg-drafts/issues/1953
20:41:59 <chrishtr> trchen: doesn't make sense to specify the epsilon for coplanarity, because of implementation difficulty
20:42:01 <dbaron> drawing #4 on the flipchart is https://lists.w3.org/Archives/Public/www-archive/2017Nov/att-0007/IMG_20171107_123911.jpg
20:42:24 <chrishtr> marakow: is the recommendation to say the behavior is undefined?
20:42:28 <chrishtr> trchen: yes
20:42:56 <chrishtr> marakow: should be able to define an epsilon
20:43:42 <chrishtr> trchen: two planes that are extremely close to the epsilon threshold may result in floating-point accuracy issues
20:44:08 <chrishtr> marakow: unspecified behavior does not achieve compat
20:44:28 <chrishtr> trchen: the ED spec has a TODO item to define subtree planes
20:44:54 <chrishtr> trchen: webkit and blink create a plane if there is any 3D transform.
20:45:08 <chrishtr> trchen: mozilla looks at the final matrix to see if there is 3D
20:45:45 <bradk_> bradk_ has joined #fx
20:46:14 <chrishtr> dbaron: thought the spec already said this?
20:46:30 <chrishtr> dbaron: seems good to match webkit/blink behavior for defining planes
20:47:41 <chrishtr> smfr: on coplanar: a good example of making things coplanar on purpose is a flipping card
20:47:56 <chrishtr> smfr: one way to implement is two elements, one of which flips relative to the other
20:48:07 <chrishtr> smfr: this will result in coplanarity numerical issues
20:48:20 <chrishtr> smfr: another way to do it is to put the transform on the container instead and flip it
20:49:25 <chrishtr> marakow: hit bugs where authors failed to specify backface-visibility:hidden and ended up with fighting/coplanar problems
20:49:51 <chrishtr> trchen: coplanar is not even what developers would want because it results in one thing always being on top
20:50:14 <chrishtr> trchen: I think we should make it undefined, and advise developers to not draw plans within these epsilons
20:51:15 <chrishtr> gregwhitworth: need to make things as specified as possible
20:51:44 <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
20:52:53 <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
20:53:45 <chrishtr> github-bot:end topic
20:55:07 <AmeliaBR> AmeliaBR has joined #fx
21:13:16 <florian> florian has joined #fx
21:25:58 <florian> florian has joined #fx
21:28:41 <florian_> florian_ has joined #fx
21:36:21 <zcorpan> zcorpan has joined #fx
21:43:24 <florian> florian has joined #fx
21:45:05 <smfr> smfr has joined #fx
21:45:30 <smfr> smfr has left #fx
21:47:06 <florian> florian has joined #fx
22:34:41 <florian> florian has joined #fx
22:35:09 <Zakim> Zakim has left #fx
22:47:16 <florian> florian has joined #fx
22:48:20 <florian> florian has joined #fx
23:28:30 <bradk_> bradk_ has joined #fx
23:35:48 <zcorpan> zcorpan has joined #fx
23:36:37 <zcorpan> zcorpan has joined #fx
23:37:26 <zcorpan> zcorpan has joined #fx
23:44:40 <florian> florian has joined #fx
23:53:53 <florian> florian has joined #fx
23:55:49 <florian> florian has joined #fx
23:59:47 <florian> florian has joined #fx
00:01:45 <florian> florian has joined #fx
00:02:17 <zcorpan> zcorpan has joined #fx
00:30:53 <florian> florian has joined #fx
00:38:29 <florian> florian has joined #fx
01:02:15 <florian> florian has joined #fx
01:04:17 <florian> florian has joined #fx
01:24:45 <florian> florian has joined #fx
01:58:16 <florian> florian has joined #fx
01:58:43 <florian> florian has joined #fx
02:08:49 <florian_> florian_ has joined #fx
06:37:58 <florian> florian has joined #fx
06:39:37 <florian_> florian_ has joined #fx
07:23:21 <zcorpan> zcorpan has joined #fx
07:25:33 <florian> florian has joined #fx
08:08:27 <florian> florian has joined #fx
08:10:12 <florian> florian has joined #fx
11:00:36 <florian> florian has joined #fx
14:27:48 <Rossen> Rossen has joined #fx
14:29:19 <leaverou> leaverou has joined #fx
14:29:49 <plinss> plinss has joined #fx
16:26:34 <florian> florian has joined #fx