[CSSWG] Minutes Tokyo F2F Thu 2017-04-20 Part II: Transforms [css-transforms]

   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


   - 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.


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



   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: 
   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
   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
   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
   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

   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
   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
   TabAtkins: That is the most reasonable way to intuit author
              preference here.
   smfr: Right.
   <no one disagrees>
   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?

   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?

   RESOLVED: No change to current getComputedStyle behavior, but we
             hope that CSS typed OM will return a function for

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
   birtles: We implemented it.
   <birtles> Gecko intent to ship has some background:
   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
   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> actually 
   [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
   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
   flackr: And this happens with normal layout too, right?
   TabAtkins: Yeah, everyone settles on displaying the scrollbar

   <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

   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
   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