w3 :: #fx

20 Apr 2017
00:07dbarontrackbot, start meeting
00:07* trackbot is preparing a teleconference.
00:07RRSAgentlogging to http://www.w3.org/2017/04/20-fx-irc
00:07trackbotRRSAgent, make logs world
00:07RRSAgentI have made the request, trackbot
00:07trackbotZakim, this will be 3983
00:07Zakimok, trackbot
00:07trackbotMeeting: CSS-SVG Task Force Teleconference
00:07TabAtkinsRachelNabors: The network?
00:07trackbotDate: 20 April 2017
00:09dinoScribeNick: dino
00:09Rossentrackbot, start meeting
00:09* trackbot is preparing a teleconference.
00:09trackbotRRSAgent, make logs world
00:09RRSAgentI have made the request, trackbot
00:09trackbotZakim, this will be 3983
00:09trackbotMeeting: CSS-SVG Task Force Teleconference
00:09trackbotDate: 20 April 2017
00:10Zakimok, trackbot
00:10surmapreset+ Surma, Google
00:11RossenRossen Atanassov, Microsoft
00:11shaneShane Stephens, Google
00:11flackrRob Flack, Google
00:11BogdanBrinzaBogdan Brinza, Microsoft
00:11dinoDean Jackson, Apple
00:12smfrSimon Fraser, Apple
00:12dinoRossen: Can we get Amelia to join? Is she awake and available?
00:12dinoRossen looks for Amelia
00:12dinoTopic: Status
00:12dinosmfr: there are 9 issues that need discussion on Transforms Level 1. I've been splitting the L1 and L2 tests out. I'm also looking over the L1 test suite to work out gaps in coverage.
00:13dinosmfr: i'l report in a week or two. So far I've just moved any 3d stuff into another directory. I'm going to move SVG stuff into a new directory too.
00:13dinosmfr: i'll talk to gsnedders about what directory structure WPT prefers
00:13smfrGithub topic: https://github.com/w3c/csswg-drafts/issues/933
00:13* github-bot OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/933
00:14dbaronGithub topic: none
00:14* github-bot OK, I won't post this discussion to GitHub
00:14dinoTopic: Effect of transforms on background attachment fixed
00:14smfrGithub topic: https://github.com/w3c/csswg-drafts/issues/933
00:14* github-bot OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/933
00:15dinodbaron: there are some mozilla tests in the mozilla/import directory. you should look there too.
00:15dinosmfr: ok. and they have metadata?
00:15dinodbaron: yes, but might need updating
00:15dinosmfr: this issue doesn't need discussion because florian just commented
00:16dinosmfr: long ago we resolved that b-a:fixed behaves like b-a:scroll if any ancestor has a non-none transform
00:16dinosmfr: florian had a concern that maybe authors wanted to do something special. he now says he is ok.
00:16dinoRossen: have we already resolved?
00:17dino<we look for a link to minutes... maybe from Hamburg>
00:17dinosmfr: i think what we spec is what all browsers implement
00:17dinodbaron: it might be weird to people if they use a translate and break b-a:fixed but i&#39;m ok with it
00:17dinoRESOLVED: Close this issue without any change
00:18smfrlist of issues with needs-discuss: https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-transforms-1+label%3A%22Needs+Group+Input%2FDecision%22
00:19dinoTopic: Comments on Scaling Stroke
00:19* github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/933
00:19dinoGithub Topic: https://github.com/w3c/csswg-drafts/issues/930
00:19* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/930
00:19dinoalso https://github.com/w3c/csswg-drafts/issues/929
00:19dinosmfr: two similar issues
00:20dinosmfr: current implementations draw nothing when the matrix is non-invertible
00:20dinosmfr: this is just for svg&#39;s non-scaling stroke
00:20dinosmfr: some comments want *something* to be drawn, but that would be a change to SVG
00:20dinosmfr: suggest keeping the current behaviour of drawing nothing
00:20dinoTabAtkins: agree
00:21dinodbaron: i agree too. we&#39;d need to work out what to draw.
00:21dinoRossen: is this a spec change?
00:21dinosmfr: current spec doesn&#39;t say anything about non-scaling stroke
00:21dinosmfr: not sure where that should be covered
00:22dinoRossen: sounds like we don&#39;t need to make a change in L1. Any change would have to be in the SVG specification.
00:22dinosmfr: SVG 2 has some things to control the behaviour ^^
00:23dinoRossen: I can&#39;t see anything in the non-scaling stroke text about this.
00:24dinoRossen: OK. Seems that the consensus is that the Transforms L1 text doesn&#39;t need to mention this. If there is a change to SVG, it will happen elsewhere
00:24dinoRESOLUTION: Close both 930 and 929 with no change to transforms spec
00:24* dbaron fixed the two mozilla-central-reftests tests that need to be updated for the spec split, and posted a patch for review from SimonSapin
00:25dinoTopic: Same discussion for 929
00:25* github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/930
00:25dinoGithub Topic: https://github.com/w3c/csswg-drafts/issues/929
00:25* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/929
00:25dinoRESOLUTION: Close both 930 and 929 with no change to transforms spec
00:25dbaronbut see the longer comment in 930
00:25dinoRossen: It might be nice to add a non-norm note to Transforms Level 1 explaining this
00:25dinosmfr: yes
00:26dinoTopic: Smarter interpolation of truncated lists
00:26* github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/929
00:26dinoGithub Topic: https://github.com/w3c/csswg-drafts/issues/927
00:26* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/927
00:27dinosmfr: we talked about this in seattle a bit. we suggested adding a special name that can match anything. e.g. identity or none.
00:27dinosmfr: should we add this to level 1?
00:27dinosmfr: there are some side-effects of not doing it - e.g. rotations greater than 360
00:27dinosmfr: i don&#39;t like that it is a behaviour change, so suggest deferring
00:27dinoTabAtkins: I&#39;m ok with deferring any behaviour change
00:28dinoRossen: there was a lot of discussion on this. Have you played with it?
00:28dinosmfr: we haven&#39;t implemented.
00:28dinoRossen: what is the fear of compatibility risk?
00:28dinosmfr: they might get different animations
00:29dinodbaron: since people have to manually write this, there is no compat risk
00:29dbaron(assuming they do, at least)
00:29dinosmfr: this issue is also asking for magical matching (inserting identity transforms)
00:30dinosmfr: it&#39;s saying that it uses the common prefix for as much as possible, then smoosh together the rest into a matrix
00:30dinodbaron: there is more compat risk there
00:30dinodbaron: not sure how much interop there is here, since we&#39;ve changed it a lot
00:31dinoTabAtkins: better behaviour would be nice, but yes there is a compat risk
00:31dinosmfr: could we change this behaviour in level 2?
00:31dinoRossen: more risky
00:31dinodbaron: if we want to change, do it in level 1
00:32dinoshane: there is a risk. i don&#39;t think it is a big issue though. i have no data to support it. we&#39;re talking about visual behaviour of an animation
00:32dinoshane: and this is a fallback behaviour that is now hopefully more closely matching the author intent
00:32dinoshane: i think this is only stopping messed up animations from looking messed up
00:33dinobirtles: it&#39;s hard to think of a case where it looks worse
00:34dinosmfr: so change the behaviour for Level 1? As the github issue suggests?
00:34dinoTabAtkins: that is the most reasonable way to intuit author preference here
00:34dinosmfr: right
00:34dino<no one disagrees>
00:35dinodbaron: we&#39;d be hesitant to be first implementation, but if everyone else agrees, then we&#39;re ok
00:35dinoRossen: if we already resolved this, do we need to change anything?
00:35dinosmfr: i can&#39;t find it.
00:35dinoTabAtkins: i don&#39;t think we did
00:36dinosmfr: maybe we resolved this would be a L2 thing
00:36dinoRossen: we can resolve it now
00:36dinoRossen: objections?
00:36dinoRESOLVED: Accept the issue as written.
00:37dinoTopic: getComputedStyle should return a list of transform functions
00:37* github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/927
00:37dinoGitHub Issue: https://github.com/w3c/csswg-drafts/issues/891
00:38dinosmfr: implementations are always returning a matrix or matrix3d. Authors want a list of functions.
00:38dinodbaron: this will cause breakage
00:39dinoTabAtkins: the CSS Typed OM should return the functions
00:40dinodino: Suggested resolution - no change to current getComputedStyle behaviour, but we hope that CSS typed OM will return a function for computedStyleMap
00:40dinos/function/list of functions/
00:40dinoRossen: objections?
00:40dinoRESOLVED: no change to current getComputedStyle behaviour, but we hope that CSS typed OM will return a function for computedStyleMap
00:41dinoTopic: transform-origin: 0% != 0px
00:41dinoGithub Topic: https://github.com/w3c/csswg-drafts/issues/895
00:41* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/895
00:41dinodbaron: it&#39;s only different for SVG?
00:41dinosmfr: yes
00:42dinoChrisL: it&#39;s not that crazy to have the UA stylesheet do different things for SVG and CSS
00:42dinoGithub Issue: https://github.com/w3c/csswg-drafts/issues/895
00:43dinodbaron: it&#39;s only different for SVG?
00:43dinosmfr: yes
00:43dinoChrisL: it&#39;s not that crazy to have the UA stylesheet do different things for SVG and CSS
00:45dinosmfr: auto is one proposal. or a keyword &#39;viewport&#39;
00:45dinoRossen: i&#39;d prefer &#39;auto&#39; as a magic keyword. And this might be our only option.
00:45dinoRossen: other comments?
00:45dinoTabAtkins: I like &#39;auto&#39;
00:47dinoTabAtkins: proposal is that the current 0% becomes &#39;auto&#39;, and then we change 0% to be the same as 0px
00:48dinosmfr: so &#39;auto&#39; would be different for CSS and SVG?
00:48dinoTabAtkins: I don&#39;t care about that as much as having 0% and 0px using the same base.
00:50dinotransform-origin will now accept an &#39;auto&#39; value which will be the initial value. For CSS, that is equivalent to 50% 50%. For SVG, it&#39;s equivalent to 0px 0px. And, from now on, in SVG, % are in the same base as px, so relative to the element.
00:52dino<discussion of what % means for CSS properties in SVG>
00:53dinoChrisL: I want to make sure that we&#39;re not clipped to 0-100% for CSS in SVG stuff.
00:53dinodino: definitely not for transform-origin
00:54dinosmfr: there is also a proposal for transform-box, which would affect what % are resolved against
00:54dinosmfr: this is in level 1, but i&#39;m not sure there are implementations
00:54dinobirtles: we implemented it
00:56Rossendino: if we all implement the box values there is no need have the percentages change
00:56birtlesGecko intent to ship has some background: https://groups.google.com/forum/#!topic/mozilla.dev.platform/ssV6H4_3WGU
00:57dinobirtles: Blink has it implemented behind a flag
00:57birtlesBlink bug: https://bugs.chromium.org/p/chromium/issues/detail?id=595829
00:58dinoproposed resolution: no need to change anything for this issue. implementations just need to add transform-box, or behave as if you do implement it
00:59dinoRESOLUTION: no need to change anything for this issue. implementations just need to support transform-box
00:59BogdanBrinzaEdge doesn&#39;t have plans for (at least) next release or two since we don&#39;t support CSS transforms on SVG boxes yet, so the problem doesn&#39;t exist for us
00:59dinosmfr: so we think that heycam&#39;s comments are all addressed by transform-box
00:59dinodbaron: yes
01:00TabAtkinsScribeNick: TabAtkins
01:00TabAtkinsTopic: More %s
01:00* github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/895
01:00TabAtkinsGitHub Topic:
01:00TabAtkinsGitHub Topic: https://github.com/w3c/csswg-drafts/issues/892
01:00* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/892
01:00TabAtkinssmfr: Does transform-box resolve this one as well?
01:01TabAtkinsTabAtkins: Yeah, should be.
01:02TabAtkinssmfr: transform-box doesn&#39;t have a definitio nfo the gradient &quot;size&quot; tho. Perhaps it&#39;s not something you should be able to do.
01:02TabAtkinsChrisL: There&#39;s a default clip-path on the SVG root that&#39;s set to its bounding box.
01:03TabAtkinsRossen: Would the bounding box change if the clip-path was shrunk?
01:03TabAtkinsChrisL: No.
01:03TabAtkinsRossen: So no, there&#39;s no way to target the clip-path box.
01:03TabAtkinssmfr: So a no-change?
01:04TabAtkinsTabAtkins: Seems like it yes. Everything is either handled by transform-box already, or doesn&#39;t have a use-case.
01:04TabAtkinsRESOLVED: no change
01:05TabAtkinsTopic: border-box vs view-box in transform-box
01:05* github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/892
01:05TabAtkinsGitHub Topic: https://github.com/w3c/csswg-drafts/issues/857
01:05* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/857
01:05TabAtkinsTabAtkins: I have an action to review the CSS <=> SVG box keyword mappings and find a consistent mapping between them.
01:06TabAtkinsTabAtkins: This one (border-box = view-box) is particularly bad; border-box normally equals stroke-box.
01:07* dbaron moved to the other room
01:07TabAtkinsTabAtkins: I suspect it was done solely to give us an initial value that captured the diff between CSS and SVG.
01:07TabAtkinsRossen: So is that a spec bug?
01:08TabAtkinsTabAtkins: Yeah. We should make border-box work properly. Then add a new initial value (auto?) that still captures the dual-behavior we want.
01:08TabAtkinsRossen: Objections?
01:09TabAtkinssmfr: Ah yeah, they&#39;re bending what border-box means right now.
01:11TabAtkinsRESOLVED: Add &quot;auto&quot; as initial value for transform-box, give it the current border-box/view-box dual behavior
01:12TabAtkinsTabAtkins: Further issue here - spec maps fill-box to border-box. That violates the mapping used elsewhere in CSS, where border=stroke and padding/content=fill.
01:12TabAtkinsTabAtkins: Suspect it was just because there&#39;s only use-cases for those two, and they&#39;re close enough that they wer ejust mapped for convenience. But that&#39;s inconsistent and bad for the platform.
01:12TabAtkinsTabAtkins: Should we add the additional box keywords and set up a proper mapping?
01:14TabAtkinsRESOLVED: Add stroke/padding/content-box, and set up the proper mappings between them for transform-box.
01:15TabAtkinsTopic: Transforms on root SVG element
01:15TabAtkinsGitHub Topic: https://github.com/w3c/csswg-drafts/issues/894
01:15* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/894
01:15* github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/857
01:18Rossen<room reads the issue>
01:18TabAtkinsTabAtkins: Hm, initial comment claims that bg&borders work on the root SVG of a standalone SVG doc?
01:20ChrisL<tr id=&quot;j&quot;><td class=&quot;prop&quot;>h<td>A<td>B<td>C<td>D<td>E<td>F<td>G<td>H<td>I<td>J<td>K<td>L<td>M<td>N<td>O<td>P<td>Q<td>R<td>S<td>T<td>U<td>V<td>W<td>X<td>Y<td >Z<td>a<td>b<td>c<td>d<td>e<td>f<td>g<td>h<td>i<td class=&quot;test&quot;>j<td>k<td>l<td>m<td>n<td>o<td>p<td>q<td>r<td>s<td>t<td>u<td>v<td>w<td>x<td>y<td>z</tr>
01:20ChrisL<svg xmlns=&quot;http://www.w3.org/2000/svg&quot; viewBox=&quot;0 0 100 100&quot; style=&quot;border: 5px solid red&quot;>
01:20ChrisL<rect width=&quot;100&quot; height=&quot;100&quot; fill=&quot;green&quot;/>
01:21dinoactually data:image/svg+xml,<svg%20xmlns=&quot;http://www.w3.org/2000/svg&quot;%20width=&quot;20&quot;%20height=&quot;20&quot;%20style=&quot;border:%203px%20solid%20red&quot;><circle%20cx=&quot;10&quot;%20cy=&quot;10&quot;%20r=&quot;10&quot;/></svg>
01:25TabAtkins[Result: standalone SVG&#39;s root element is a CSS box in all impls. Chrome/WebKit have a bug that it treats the transform-origin as the top-left; everyone else just does the standard CSS behavior.]
01:25TabAtkinsTabAtkins: So I think we can just agree, and let Amelia draft the language as she offered?
01:27TabAtkinsRESOLVED: The root SVG element of a standalone is a CSS box, and the standard implications fall out of that.
01:27TabAtkinsTopic: How transforms affect overflow geometry
01:27* github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/894
01:27TabAtkinsGitHub Topic: https://github.com/w3c/csswg-drafts/issues/901
01:27* github-bot OK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/901
01:29TabAtkins[we all lament not having github-bot previously]
01:30TabAtkinsRossen: [draws example on whiteboard]
01:33TabAtkinsRossen: Opposite, start with something small with a 50% width, scale it large to overflow and trigger a scrollbar, do we trigger a scrollbar and resize the box?
01:34TabAtkinsRossen: Edge flips the scrollbar on once, that&#39;s it, nd doesn&#39;t recompute the sizes.
01:35TabAtkinsChrisL: A common problem is one that would fit except that the scrollbars are there.
01:35TabAtkinsRossen: That only happens if you&#39;re throwing transforms around.
01:36TabAtkinsflackr: In this example it&#39;s just something that was big beforehand.
01:36TabAtkinsflackr: And this happens with normal layout too, right?
01:36TabAtkinsTabAtkins: Yeah, everyone settles on displaying the scrollbar somehow.
01:39TabAtkins[reviews the minutes of the reoslutions for issue 48]
01:39TabAtkinsRossen: So in this example (example scaled down) the layout bounds are still tall and trigger scrollbars.
01:40TabAtkinssmfr: Is that the same as saying that overflow bounds are the union of the untransformed and transformed boxes?
01:41TabAtkinssmfr: More detail - in a tree of transforms, you compute a bounding box without transforms, and one with transforms, and take the union.
01:43TabAtkinsRossen: Corollary: if you discover your transform bounds fit entirely in your box, you can omit the scrollbars.
01:43TabAtkinsTabAtkins: No, that violates the &quot;can increase bounds, not decrease&quot;.
01:44TabAtkinsRESOLVED: Overflow bounds that are computed at the end of layout can increase (but not decrease) by paint-level effects such as transforms.
01:46TabAtkinssmfr: I&#39;m concerned about the issue in the mail I just posted - if perspective can cause overflow bounds to increase, it might result in horizontal scrollbars in some cases that aren&#39;t there today.
01:46TabAtkinssmfr: But apparently Firefox already does that, so maybe we&#39;re okay.
01:48TabAtkinsRossen: Anyway, this is a level 2 issue, since it&#39;s a 3d issue. We&#39;re good for level 1.
01:49TabAtkinsTopic: finishing up
01:49* github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/901
01:49TabAtkinsRossen: So next steps?
01:49TabAtkinssmfr: Not sure how to split up the matrix math. Previously was always a 4x4.
01:50TabAtkinssmfr: Would be nasty to change it.
01:50TabAtkinsTabAtkins: Seems fine to just keep it as 4x4 in the 2d case. Math works out the same.
01:51TabAtkinssmfr: There&#39;s a bunch of needs-edits with the SVG label. I think I can get Amelia to help with those.
01:52TabAtkinssmfr: So handling the publishing of level 1 vs 2.
01:53TabAtkinsChrisL: No need for a FPWD on level 1, we effectively just punted bits of the spec to level 2.
01:53TabAtkinsChrisL: Need a good changes section that describes what was punted, and a good DoC.
01:54ChrisLand fpwd of Tranforms 2
01:54TabAtkinsChrisL: What sort of tests are these?
01:54TabAtkinssmfr: Should all be reftests.
01:55TabAtkinssmfr: Stuff that&#39;s easy to test has good coverage, hard to test has poor coverage.
01:55TabAtkinssmfr: Probably a lot of duplicate tests on easy stuff.
02:07dbaronTopic: break
02:20* dbaron github-bot, status
02:20* github-bot I currently have data for the following channels:
02:20* github-bot #css (1 lines buffered on &quot;break&quot;)
02:20* github-bot no GitHub URL to comment on
02:20* github-bot #fx (1 lines buffered on &quot;break&quot;)
02:20* github-bot no GitHub URL to comment on
04:57* Zakim excuses himself; his presence no longer seems to be needed
05:21* dbaron github-bot, status
05:21* github-bot I currently have data for the following channels:
05:21* github-bot #css (42 lines buffered on &quot;Tatek Yoko Award&quot;)
05:21* github-bot no GitHub URL to comment on
05:21* github-bot #fx (no topic data buffered)
06:13* dbaron github-bot, status
21 Apr 2017
No messages
Last message: 156 days and 8 hours ago