IRC log of fx on 2017-11-07

Timestamps are in UTC.

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