- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 26 May 2017 20:48:23 -0400
- To: "www-style@w3.org" <www-style@w3.org>
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
FX Track
++++++++
Transforms
----------
- RESOLVED: Close (https://github.com/w3c/csswg-drafts/issues/933:
"Effect of transforms on background-attachment:fixed" without
any change.
- RESOLVED: Close both https://github.com/w3c/csswg-drafts/issues/930
"Some comments on the non-scaling stroke spec text" and
https://github.com/w3c/csswg-drafts/issues/929 "scale 0
on non-scaling stroke" with no change to transforms spec.
- RESOLVED: Accept https://github.com/w3c/csswg-drafts/issues/927:
"Smarter interpolation of truncated lists" as written.
- RESOLVED: No change to current getComputedStyle behavior, but we
hope that CSS typed OM will return a function for
computedStyleMap (https://github.com/w3c/csswg-drafts/issues/891)
- RESOLVED: No change for https://github.com/w3c/csswg-drafts/issues/895:
"transform-origin: 0% != 0px"; Implementations just
need to support transform-box.
- RESOLVED: No change on https://github.com/w3c/csswg-drafts/issues/892:
Define basis for percentage transform on patterns,
gradients, clipPath; issue handled by transform-box
- RESOLVED: Add "auto" as initial value for transform-box, give it
the current border-box/view-box dual behavior.
Note: This was changed to initial value of view-box the next day.
- RESOLVED: Add stroke/padding/content-box, and set up the proper
mappings between them for transform-box.
Note: Mappings resolved to match fill-stroke fpwd on Friday.
- RESOLVED: The root SVG element of a standalone is a CSS box, and
the standard implications fall out of that.
- RESOLVED: Overflow bounds that are computed at the end of layout
can increase (but not decrease) by paint-level effects
such as transforms.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics
Note: The group split the morning of the 20 April on two
tracks: FX and Text.
Scribe: dino
FX Track
++++++++
Transforms
==========
Status
------
smfr: 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.
<smfr> list 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
smfr: I'll 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.
smfr: I'll talk to gsnedders about what directory structure WPT
prefers.
dbaron: There are some mozilla tests in the mozilla/import
directory. You should look there too.
smfr: ok. And they have metadata?
dbaron: Yes, but might need updating.
background-attachment: fixed
----------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/933
smfr: This issue doesn't need discussion because florian just
commented.
smfr: Long ago we resolved that b-a:fixed behaves like b-a:scroll
if any ancestor has a non-none transform.
smfr: Florian had a concern that maybe authors wanted to do
something special. He now says he is ok.
Rossen: Have we already resolved?
<we look for a link to minutes... maybe from Hamburg>
smfr: I think what we spec is what all browsers implement.
dbaron: It might be weird to people if they use a translate and
break b-a:fixed but I'm ok with it.
RESOLVED: Close this issue without any change.
Comments on Scaling Stroke
--------------------------
Github Topic: https://github.com/w3c/csswg-drafts/issues/930 and https://github.com/w3c/csswg-drafts/issues/929
smfr: Two similar issues:
smfr: Current implementations draw nothing when the matrix is
non-invertible.
smfr: This is just for svg's non-scaling stroke.
smfr: Some comments want *something* to be drawn, but that would
be a change to SVG.
smfr: I suggest keeping the current behavior of drawing nothing.
TabAtkins: Agree.
dbaron: I agree too. We'd need to work out what to draw.
Rossen: Is this a spec change?
smfr: Current spec doesn't say anything about non-scaling stroke-
smfr: not sure where that should be covered.
Rossen: Sounds like we don't need to make a change in L1. Any
change would have to be in the SVG specification.
<smfr> https://www.w3.org/TR/SVG2/coords.html#VectorEffectProperty
smfr: SVG 2 has some things to control the behavior ^^
<Rossen> http://www.w3.org/TR/SVG2/painting.html#non-scaling-stroke
Rossen: I can't see anything in the non-scaling stroke text about
this.
Rossen: OK. Seems that the consensus is that the Transforms L1
text doesn't need to mention this. If there is a change to
SVG, it will happen elsewhere.
RESOLVED: Close both 930 and 929 with no change to transforms spec.
<dbaron> but see the longer comment in 930
Rossen: It might be nice to add a non-norm note to Transforms
Level 1 explaining this.
smfr: Yes.
Smarter interpolation of truncated lists
----------------------------------------
Github Topic: https://github.com/w3c/csswg-drafts/issues/927
smfr: We talked about this in Seattle a bit. We suggested adding a
special name that can match anything. e.g. identity or none.
smfr: Should we add this to level 1?
smfr: There are some side-effects of not doing it - e.g. rotations
greater than 360
smfr: I don't like that it is a behavior change, so suggest
deferring.
TabAtkins: I'm ok with deferring any behavior change.
Rossen: There was a lot of discussion on this. Have you played
with it?
smfr: We haven't implemented.
Rossen: What is the fear of compatibility risk?
smfr: They might get different animations.
dbaron: Since people have to manually write this, there is no
compat risk.
<dbaron> (assuming they do, at least)
smfr: This issue is also asking for magical matching (inserting
identity transforms).
smfr: It's saying that it uses the common prefix for as much as
possible, then smoosh together the rest into a matrix.
dbaron: There is more compat risk there.
dbaron: Not sure how much interop there is here, since we've
changed it a lot.
TabAtkins: Better behavior would be nice, but yes there is a
compat risk.
smfr: Could we change this behavior in level 2?
Rossen: More risky.
dbaron: If we want to change, do it in level 1.
shane: There is a risk. I don't think it is a big issue though. I
have no data to support it. We're talking about visual
behavior of an animation
shane: and this is a fallback behavior that is now hopefully more
closely matching the author intent.
shane: I think this is only stopping messed up animations from
looking messed up.
birtles: It's hard to think of a case where it looks worse.
smfr: So change the behavior for Level 1? As the github issue
suggests?
TabAtkins: That is the most reasonable way to intuit author
preference here.
smfr: Right.
<no one disagrees>
<wait.....>
dbaron: We'd be hesitant to be first implementation, but if
everyone else agrees, then we're ok.
Rossen: If we already resolved this, do we need to change anything?
smfr: I can't find it.
TabAtkins: I don't think we did.
smfr: Maybe we resolved this would be a L2 thing.
Rossen: We can resolve it now.
Rossen: Objections?
<none>
RESOLVED: Accept the issue as written.
getComputedStyle should return a list of transform functions
------------------------------------------------------------
GitHub Issue: https://github.com/w3c/csswg-drafts/issues/891
smfr: Implementations are always returning a matrix or matrix3d.
Authors want a list of functions.
dbaron: This will cause breakage.
TabAtkins: The CSS Typed OM should return the functions
dino: Suggested resolution - no change to current getComputedStyle
behavior, but we hope that CSS typed OM will return a list
of functions for computedStyleMap.
Rossen: objections?
<none>
RESOLVED: No change to current getComputedStyle behavior, but we
hope that CSS typed OM will return a function for
computedStyleMap
transform-origin: 0% != 0px
---------------------------
Github Topic: https://github.com/w3c/csswg-drafts/issues/895
dbaron: It's only different for SVG?
smfr: Yes.
ChrisL: It's not that crazy to have the UA stylesheet do different
things for SVG and CSS.
smfr: Auto is one proposal. Or a keyword 'viewport'
Rossen: I'd prefer 'auto' as a magic keyword. And this might be
our only option.
Rossen: Other comments?
TabAtkins: I like 'auto'
TabAtkins: Proposal is that the current 0% becomes 'auto', and
then we change 0% to be the same as 0px
smfr: So 'auto' would be different for CSS and SVG?.
TabAtkins: I don't care about that as much as having 0% and 0px
using the same base.
TabAtkins: transform-origin will now accept an 'auto' value which
will be the initial value. For CSS, that is equivalent
to 50% 50%. For SVG, it's equivalent to 0px 0px. And,
from now on, in SVG, % are in the same base as px, so
relative to the element.
<discussion of what % means for CSS properties in SVG>
ChrisL: I want to make sure that we're not clipped to 0-100% for
CSS in SVG stuff.
dino: Definitely not for transform-origin.
smfr: There is also a proposal for transform-box, which would
affect what % are resolved against.
smfr: This is in level 1, but I'm not sure there are
implementations.
birtles: We implemented it.
<birtles> Gecko intent to ship has some background:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/ssV6H4_3WGU
dino: If we all implement the transform-box values there is no
need have the percentages change.
birtles: Blink has it implemented behind a flag
<birtles> Blink bug: https://bugs.chromium.org/p/chromium/issues/detail?id=595829
<BogdanBrinza> Edge doesn't have plans for (at least) next release
or two since we don't support CSS transforms on SVG
boxes yet, so the problem doesn't exist for us
Rossen: proposed resolution: no need to change anything for this
issue. implementations just need to add transform-box, or
behave as if you do implement it
RESOLVED: No need to change anything for this issue.
Implementations just need to support transform-box.
smfr: So we think that heycam's comments are all addressed by
transform-box.
dbaron: Yes.
Define basis for percentage transform on patterns, gradients, clipPath
----------------------------------------------------------------------
Scribe: TabAtkins
GitHub Topic: https://github.com/w3c/csswg-drafts/issues/892
smfr: Does transform-box resolve this one as well?
TabAtkins: Yeah, should be.
smfr: transform-box doesn't have a definition for the gradient
"size" though. Perhaps it's not something you should be able
to do.
ChrisL: There's a default clip-path on the SVG root that's set to
its bounding box.
Rossen: Would the bounding box change if the clip-path was shrunk?
ChrisL: No.
Rossen: So no, there's no way to target the clip-path box.
smfr: So a no-change?
TabAtkins: Seems like it yes. Everything is either handled by
transform-box already, or doesn't have a use-case.
RESOLVED: no change
border-box vs view-box in transform-box
---------------------------------------
GitHub Topic: https://github.com/w3c/csswg-drafts/issues/857
TabAtkins: I have an action to review the CSS <=> SVG box keyword
mappings and find a consistent mapping between them.
TabAtkins: This one (border-box = view-box) is particularly bad;
border-box normally equals stroke-box.
TabAtkins: I suspect it was done solely to give us an initial
value that captured the difference between CSS and SVG.
Rossen: So is that a spec bug?
TabAtkins: Yeah. We should make border-box work properly. Then add
a new initial value (auto?) that still captures the
dual-behavior we want.
Rossen: Objections?
smfr: Ah yeah, they're bending what border-box means right now.
RESOLVED: Add "auto" as initial value for transform-box, give it
the current border-box/view-box dual behavior
TabAtkins: 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.
TabAtkins: Suspect it was just because there's only use-cases for
those two, and they're close enough that they were just
mapped for convenience. But that's inconsistent and bad
for the platform.
TabAtkins: Should we add the additional box keywords and set up a
proper mapping?
RESOLVED: Add stroke/padding/content-box, and set up the proper
mappings between them for transform-box.
Transforms on root SVG element
------------------------------
GitHub Topic: https://github.com/w3c/csswg-drafts/issues/894
<room reads the issue>
TabAtkins: Hm, initial comment claims that backgrounds & borders
work on the root SVG of a standalone SVG doc?
<Rossen> https://upload.wikimedia.org/wikipedia/commons/e/e3/Tiger.svg
<ChrisL> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100
100" style="border: 5px solid red">
<ChrisL> <rect width="100" height="100" fill="green"/>
<ChrisL> </svg>
<dino>
data:image/svg+xml,<svg%20width="20"%20height="20"%20style="border:%203px%20solid%20red"><circle%20cx="10"%20cy="10"%20r="10"/></svg>
<dino> actually
data:image/svg+xml,<svg%20xmlns="http://www.w3.org/2000/svg"%20width="20"%20height="20"%20style="border:%203px%20solid%20red"><circle%20cx="10"%20cy="10"%20r="10"/></svg>
[Result: standalone SVG'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.]
TabAtkins: So I think we can just agree, and let Amelia draft the
language as she offered?
RESOLVED: The root SVG element of a standalone is a CSS box, and
the standard implications fall out of that.
How transforms affect overflow geometry
---------------------------------------
GitHub Topic: https://github.com/w3c/csswg-drafts/issues/901
Rossen: [draws example on whiteboard]
Rossen: 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?
Rossen: Edge flips the scrollbar on once, that's it, and doesn't
recompute the sizes.
ChrisL: A common problem is one that would fit except that the
scrollbars are there.
Rossen: That only happens if you're throwing transforms around.
flackr: In this example it's just something that was big
beforehand.
flackr: And this happens with normal layout too, right?
TabAtkins: Yeah, everyone settles on displaying the scrollbar
somehow.
<smfr> https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-48
[reviews the minutes of the resolutions for issue 48]
Rossen: So in this example (example scaled down) the layout bounds
are still tall and trigger scrollbars.
smfr: Is that the same as saying that overflow bounds are the
union of the untransformed and transformed boxes?
smfr: More detail - in a tree of transforms, you compute a
bounding box without transforms, and one with transforms,
and take the union.
<smfr> https://lists.w3.org/Archives/Public/www-style/2015Nov/0167.html
Rossen: Corollary: if you discover your transform bounds fit
entirely in your box, you can omit the scrollbars.
TabAtkins: No, that violates the "can increase bounds, not
decrease".
RESOLVED: Overflow bounds that are computed at the end of layout
can increase (but not decrease) by paint-level effects
such as transforms.
<smfr> https://bug1198135.bmoattachments.org/attachment.cgi?id=8684006
smfr: I'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't
there today.
smfr: But apparently Firefox already does that, so maybe we're
okay.
Rossen: Anyway, this is a level 2 issue, since it's a 3d issue.
We're good for level 1.
Finishing up
------------
Rossen: So next steps?
smfr: Not sure how to split up the matrix math. Previously was
always a 4x4.
smfr: Would be nasty to change it.
TabAtkins: Seems fine to just keep it as 4x4 in the 2d case. Math
works out the same.
smfr: There's a bunch of needs-edits with the SVG label. I think I
can get Amelia to help with those.
smfr: So handling the publishing of level 1 vs 2.
ChrisL: No need for a FPWD on level 1, we effectively just punted
bits of the spec to level 2.
ChrisL: Need a good changes section that describes what was
punted, and a good DoC.
<ChrisL> and fpwd of Transforms 2
ChrisL: What sort of tests are these?
smfr: Should all be reftests.
smfr: Stuff that's easy to test has good coverage, hard to test
has poor coverage.
smfr: Probably a lot of duplicate tests on easy stuff.
Received on Saturday, 27 May 2017 00:48:59 UTC