W3C home > Mailing lists > Public > www-style@w3.org > February 2017

[CSSWG] Minutes Seattle F2F 2017-01-12 Part I: FX Breakout - Transforms [css-transforms]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 13 Feb 2017 20:58:07 -0500
Message-ID: <CADhPm3s7Q58KTT9rBA8vSG_owMaYbsSkSYk-16TQafoQAd_a7Q@mail.gmail.com>
To: 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
----------

  - shane will investigate fixing the quaternation algorithm to
      address issue 33
(https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-33)
      and the interpolation algorithm to address issue 40
      (https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-40)
  - RESOLVED: For animation/rendering purposes, canonicalize
              perspective(0) to perspective(inf).
  - RESOLVED: Add transform-origin-x/y/z to the level 2 spec. (Issue
              29:
https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-29)
  - RESOLVED: Close issue 31
(https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-31)
              no change, as the relevant feature has been removed
              already.
  - RESOLVED: Issue 32
(https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-32)
              is closed due to Sydney resolution, change has already
              been made to V&U.
  - RESOLVED: A zero-degree rotate() is treated like an identity
              transform, relative to other rotation functions.
              (Similar to how perspective(0) is now being treated.)
              Issue 34
(https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-34).
  - RESOLVED: Issue 38
(https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-38)
              - just accept that transitions will run whenever the
              functions differ, even if the endpoints are
              functionally identical.
  - RESOLVED: Reject issue 41
(https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-41).
  - RESOLVED: Issue 42
(https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-42)
              - respond that while this does look better, for web
              compat reasons we can't change, and we'll continue to
              push things that make it easier to avoid matrix
              interpolation.
  - Discussion on naming identity function will happen over github.
  - RESOLVED: Close issue 43
(https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-43)
              as invalid, now that all transforms decompose with a
              4x4 matrix.
  - RESOLVED: Issue 45
(https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-45)
              is a Geometry issue, with a warning that this function
              doesn't work with flattening anyway and should be
              dropped.
  - RESOLVED: The scale described in issue 44
              (https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-44)
              doesn't belong in the transform specification as it
              isn't used by CSS transforms - instead the fairly
              simple functions that describe how to extract a scale
              from a matrix should be described directly in SVG.
  - RESOLVED: Issue 46
(https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-46)
              - change the spec to instead use a UA stylesheet rule
              to give SVG elements a default transform-box value of
              view-box (rather than trying to map border-box to
              view-box).
  - Issue 48 (https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-48)
      had several resolutions:
      - RESOLVED: Static transforms that overflow parent bounds do
                  cause a scrollbar.
      - RESOLVED: An animation that is in fill (finished, or not yet
                  started) is treated same as static, for purposes
                  of transform/bounds/scrollbars computation.
      - RESOLVED: Animated transforms that go out of bounds MAY show
                  a scrollbar during the animation.
      - There was a proposed resolution of "Overflow bounds are
          computed at end of layout, can be increased but not
          decreased by the effects of paint-level things like
          transforms." but the group decided to discuss over the
          lunch break.

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/seattle-2017
Note: The group split the morning of the 12 January on two
      tracks: FX and Text.

Present:
  Rachel Andrew, Invited Expert
  Rossen Atanassov, Microsoft
  David Baron, Mozilla
  Bert Bos (W3C)
  Dave Cramer, Hachette Livre
  Emil A Eklund, Google
  Elika Etemad, Invited Expert
  Simon Fraser, Apple
  David Grogan, Google
  Koji Ishii, Google
  Peter Linss, Invited Expert
  Myles C. Maxfield, Apple
  Simon Pieters, Opera Software
  Naina Raisinghani, Google
  Melanie Richards, Microsoft
  Hiroshi Sakakibara (BPS, Beyond Perspective Solutions)
  Jen Simmons, Mozilla
  Geoffrey Sneddon, Invited Expert
  Alan Stearns, Adobe
  Surma, Google
  Jet Villegas, Mozilla
  Greg Whitworth, Microsoft
  Steve Zilles, Adobe

Scribe: TabAtkins

FX Track
++++++++

Transforms
==========

  Transforms issue list:
https://drafts.csswg.org/css-transforms-1/issues-wd-2013

perspective(0)
--------------

  <smfr> https://github.com/w3c/csswg-drafts/issues/886
  <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=1009150
  smfr: We should revisit the perspective(0) issue.
  jet: Our Nightly code had clamping to float epsilon; we were
       testing our old code previously which made it invalid.
  dbaron: There was a site that needed perspective(0) to work.
  TabAtkins: But wk/blink has dramatically different behavior than a
             float-epsilon clamp.
  dbaron: They just needed the transform to be valid to hide the
          element with a big translate. It didn't matter that it got
          super skewed.

  smfr: So do we think this one example is enough to change our
        decision from yesterday?
  smfr: Clamping is a behavior change, because it makes things
        skewed that weren't skewed before.
  smfr: Have we seen people animate to it?
  RachelNabors: I've seen perspective get animated.
  smfr: To/from 0?
  RachelNabors: Dunno.
  <smfr> https://bugzilla.mozilla.org/show_bug.cgi?id=1316236
  <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=1009150#c2
           says m.clippercard.com had transform:perspective(0)
           translate(-260px, 0);
  <smfr> lots of perspective(0) in http://s.imgur.com/min/global.css

  TabAtkins: So it looks like people need perspective(0) to be
             valid, but don't particularly care what it *does*.
  TabAtkins: So the imgur bug is them setting to perspective(0).
             Firefox previously made it invalid, which was fine; wk/
             blink make it no-op, which is fine; new Firefox
             clamping behavior is what makes it glitch.
  smfr: So that's a point against.
  TabAtkins: Yeah, one each way.
  dbaron: Looks like they're using perspective(0) just to pad out
          their transform lists.
  <dbaron> some of it was, not all
  <dbaron> just based on looking at
https://bugzilla.mozilla.org/show_bug.cgi?id=1316236#c15
  <smfr> https://jsfiddle.net/97smsycy/
  <smfr> https://jsfiddle.net/97smsycy/1/

  TabAtkins: We can evangelize to tell them to use
             perspective(100000in), same effect.
  TabAtkins: Their current code will start looking wrong once we fix
             our perspective() animation bug, which we resolved on
             yesterday. Their animations will start going to
             wacky-distortion-land before finally becoming normal.
  dbaron: How about treating perspective(0) like an identity
          function?
  smfr: That would preserve the current wk/blink animation behavior
        after we fix our perspective animation behavior.
  TabAtkins: It's still numerically discontinuous, but not
             behaviorally discontinuous in any given example. It's
             not ideal, but it's ok if we can't avoid it.

  RESOLVED: For animation/rendering purposes, canonicalize
            perspective(0) to perspective(inf).

  <gregwhitworth> regarding dbaron comment - Rachel and I don't
                  think id() is the best name for this function. Now
                  is probably not the best time to bikeshed - but it
                  would be good to open an issue once id() is
                  specified. cc: TabAtkins smfr shane

  Rossen: Do we still need to worry about the clamping part of
          yesterday's resolution?
  TabAtkins: Yes, that's needed to give calc() a defined behavior -
             when it results in an invalid value, it instead gets
             the min or max, and "first number larger than zero"
             doesn't exist; the clamping gives us an actual min
             value.
  smfr: So perspective(0) gets treated as perspective(inf), but
        perspective(calc(0)) is treated as perspective(epsilon)?
  TabAtkins: Yes.
  smfr: Weird.

Issue 29 - should transform-origin-x/y be in the spec?
------------------------------------------------------

  Rossen: Issue 29 - should transform-origin-x/y be in the spec?
  TabAtkins: And -z?
  smfr: If background-position has -x/y, we should match.

  RESOLVED: Add transform-origin-x/y/z to the level 2 spec. (Issue
            29:
https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-29)

Issue 31 - exact definition of origin argument to rotate()
----------------------------------------------------------

  smfr: Issue 31 is talking about something that's been removed.
  TabAtkins: Looks like rotate() at some point had an optional
             rotation origin?
  RESOLVED: Close issue 31
(https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-31)
            no change, as the relevant feature has been removed
            already.

Issue 32 - Unitless zero rotation
---------------------------------

  smfr: Issue 32, unitless zero in rotate()
  TabAtkins: Against my better judgment, the WG resolved that all
             units have unitless-zero.

  RESOLVED: Issue 32
(https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-32)
            is closed due to Sydney resolution, change has already
            been made to V&U.

  <shane> resolution for unitless angles in these minutes:
          https://lists.w3.org/Archives/Public/www-style/2016Mar/0205.html
  <shane> the resolution was "RESOLVED: Angles can drop unit when
          value is 0"

Issue 33 - Make Rotation Less Weird in 3D transforms
----------------------------------------------------

  TabAtkins: So issue 33 is a 3d transform issue - there's a
             division by 0 in quaternion slerping in one particular
             case.
  <TabAtkins> https://software.hixie.ch/utilities/js/live-dom-viewer/?<!DOCTYPE%20html>%0A<body>%0A<p>foo%0A<style>%0A%40keyframes%20foo%20%7B%0A%20from%20%7B%20transform%3A%20rotate3d(0%2C%201%2C%200%2C%200deg)%3B%20%7D%0A%20to%20%7B%20transform%3A%20rotate3d(0%2C%20-1%2C%200%2C%200deg)%3B%20%7D%0A%7D%0Ap%20%7B%20animation%3A%20foo%202s%20alternate%20infinite%3B%20perspective%3A%20200px%3B%20background%3A%20red%3B%20width%3A%20100px%3B%20height%3A%20100px%3B%20%7D%0Ap%3Ahover%20%7B%20%20%7D%0A<%2Fstyle>%0A<script>%0Aw(getComputedStyle(document.querySelector("p")).transform)%3B%0A<%2Fscript>
  <TabAtkins> https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4803

  ACTION Shane to figure out wtf is up the the quaternion algo and
         see what needs fixing.
  <trackbot> Created ACTION-96

  TabAtkins: That algo is super broken anyway. It's clamping wrong (
             always sets the product to -1), it's using
             uninitialized vars (dot), it's got a zero division...

Issue 34 - Reduce matrix decomposition when rotation axis has zero
           coordinates
------------------------------------------------------------------

  shane: Issue 34.
  shane: In the example in the email, rotate3d(1, 0, 0, 0deg) to
         rotate3d(0, 0, 1, 2.25turn).
  shane: Per spec, these have non-matching axises, so they should
         matrix and decompose, resulting in a 1/4 turn around the z
         axis.
  shane: Firefox does this. WebKit/Blink instead snap the first axis
         to 0,0,1 and then interpolate numerically.
  smfr: Transforms 2 says there's a matrix decomp if the axises
        don't match.
  <smfr> https://drafts.csswg.org/css-transforms-2/#interpolation-of-transform-functions
  shane: So the example:
  shane: Given the previous values, you'll end up doing a
         quarter-turn around the z-axis.
  shane: But if you interrupt it partway, the intermediate value is
         a rotation around the z-axis.
  shane: Reverse it, and you'll continue rotating around z back to
         0deg.
  shane: Then interrupt and resume going to the original endpoint,
         and *now* the axises match, so you get the full 2.25 turn
         and it starts rotating wildly.
  shane: This *only* happens when one of the endpoints is a zero-deg
         rotation. Positive rotation gives you axis interpolation.
  shane: Proposal is to have a zero-deg endpoint just use the other
         endpoint's axis, so you get consistent behavior.
  <smfr> fiddle for this: http://jsfiddle.net/2vLyydzv/4/

  dbaron: Would this be just for the rotate property, or also the
          rotate3d() function?
  shane: Might as well do both.
  shane: And the id() function *must* take the other end-point's
         axis.
  smfr: Like perspective(0) being id().
  shane: Right, like that. Any zero-deg rotation acts like the id()
         function.
  dbaron: Id() relative to other rotates (e.g., rotate3d, rotateX,
          etc.), not to translate/etc?
  shane: Yes.

  RESOLVED: A zero-degree rotate() is treated like an id()
            transform, relative to other rotation functions. (
            Similar to how perspective(0) is now being treated.)
            Issue 34.

Issue 38 - Transform interpolation problem
------------------------------------------

  RESOLVED: Issue 38 - just accept that transitions will run
            whenever the functions differ, even if the endpoints are
            functionally identical.

Issue 40 - Bugs in interpolation algorithm
------------------------------------------

  ACTION smfr figure out issue 40 / GH #483 edits.
  <trackbot> Created ACTION-97

Issue 41 - Matrix Interpolation
-------------------------------

  Shane: Issue 41, I was proposing that instead of matrix
         interpolation we do a 50% flip. But I think we have to
         reject it, it's too late.

  RESOLVED: Reject issue 41.

Issue 42 - Use better matrix interpolation method
-------------------------------------------------

  shane: Issue 42 - we could maybe do this, if it gives similar
         results for matrix interpolation people are already using,
         and better results in places people are avoiding due to
         terribleness.
  <bradwerth> benoit example live at
https://lists.w3.org/Archives/Public/public-fx/2014JanMar/att-0084/transform-animation-not-covariant.html
  shane: As a non-binding question, say we showed up in April with a
         survey of matrix decomposition cases, and examples of how
         they'd change. If they were 90% equal or positive, would be
         adopt a new interpolation algorithm, or would we say it's
         too much effort?
  smfr: We're stuck by CoreAnimation, so if we did change we'd have
        to wait for it to update anyway.
  smfr: Generally authors shouldn't be doing matrix interpolation
        anyway.

  RESOLVED: Issue 42 - respond that while this does look better, for
            web compat reasons we can't change, and we'll continue
            to push things that make it easier to avoid matrix
            interpolation.

  <br dur=10min>

  RachelNabors: So what is id() specifically?
  TabAtkins: The transform that does nothing.
  smfr: A wildcard that auto-matches functions in another list when
        animating.
  smfr: So if you have "rotate(10deg)" and "rotate(20deg) scale(2)",
        that won't match - you'll get matrix interpolation.
  smfr: But if you write the first one as "rotate(10deg) id()",
        it'll match up and you'll get numerical interpolation.
  RachelNabors: Ah, "id" doesn't speak to me that way. Too much
                alternate meanings in the web platform.
  <smfr> one option is identity()
  (move to GH for bikeshedding)
  <RachelNabors> From the CSS perspective, I kinda expect inherit in
                 place of id(). Means something different, but at
                 the same time, is understood.

Issue 43 - Matrix Decomposition
-------------------------------

  shane: This is 4 years old. I think it predates the spec change
         that uses the same interpolation method for 2d and 3d
         transforms. So this would just be closed invalid.
  smfr: I think this came from when the spec allowed impls to only
        implement 2d transforms.
  shane: The spec currently uses the same 3d decomposition for 2d
         matrixes.
  smfr: Should the 2d level even mention 4x4 matrices?
  TabAtkins: In my abandoned split, I left the 3d math alone - too
             annoying to avoid mentioning 3d math.
  smfr: Agreed.

  RESOLVED: Close issue 43 as invalid, now that all transforms
            decompose with a 4x4 matrix.

Issue 45 - getTransformToElement needs more detail
--------------------------------------------------

  <smfr> https://www.chromestatus.com/feature/5736166087196672
  TabAtkins: SVG had a getTransformToElement() method. It was
             underdefined, and they removed it. It looks like it may
             have been moved to Geometry at some point, but it's no
             longer there.

  RESOLVED: Issue 45 is a Geometry issue, with a warning that this
            function doesn't work with flattening anyway and should
            be dropped.

Issue 44 - Include Tagaki-san's definition of linear scale
----------------------------------------------------------

  (looking over the issue)
  shane: I don't think he's asking for a change in behavior. He's
         looking for an editorial addition of how to generate a
         unified scale value for a new SVG feature (non-scaling
         objects).
  (Rossen demonstrates Tagaki-san's proposal.)
  Rossen: Looks good to me. Seems to make it look better.
  <smfr> https://svgwg.org/svg2-draft/coords.html#VectorEffects
  smfr: So this is a behavior change for SVG?
  shane: I don't think this really belongs in Transforms. We don't
         use it in the spec, and it's trivial to describe how to
         recover the unified scale from the matrix.
  shane: So they can just describe it in SVG.
  <smfr> dbaron: https://bugzilla.mozilla.org/show_bug.cgi?id=1318208
  <dbaron> smfr: yes, but the feedback on dev-platform in the intent
           thread was interesting...
  <dbaron> smfr,
https://groups.google.com/d/topic/mozilla.dev.platform/T_7HTTdt-Es/discussion

  RESOLVED: The scale described in issue 44 doesn't belong in the
            transform specification as it isn't used by CSS
            transforms - instead the fairly simple functions that
            describe how to extract a scale from a matrix should be
            described directly in SVG.

Issue 46 - transform-box values & correspondence to SVG vs CSS
--------------------------------------------------------------

  <smfr> DOC says to see also https://drafts.fxtf.org/paint/#fill-origin
  <smfr> https://drafts.csswg.org/css-transforms-1/#transform-box
  TabAtkins: We already have a consistent mapping between CSS *-box
             terms and SVG ones.
  TabAtkins: Mapping border-box to view-box for this one property
             would be bad - it's consistently mapped to stroke-box
             for SVG.
  TabAtkins: Instead we can just use the UA stylesheet to set the
             default SVG transform-box value to view-box.
  <TabAtkins> svg|* { transform-box: view-box; }

  RESOLVED: Issue 46 - change the spec to instead use a UA
            stylesheet rule to give SVG elements a default
            transform-box value of view-box (rather than trying to
            map border-box to view-box)

Issue 48 - Impact of transforms on scrollable area (multiple threads)
---------------------------------------------------------------------

  Rossen: So say you have a 100x100 box, fits in its container, no
          scrollbars.
  Rossen: Then you scale(5), it overflows, you get a scrollbar.
  TabAtkins: But wk/blink don't do that *during a transition* - it
             you animate from scale(1) to scale(5), you won't pop
             scrollbars until the animation is over.
  Rossen: Edge does add scrollbars as soon as it overflows.
  <gregwhitworth> http://jsbin.com/diwufurito/edit?html,css,output
  <Rossen> http://jsbin.com/diwufurito/edit?html,css,output
  <gregwhitworth> http://jsbin.com/diwufurito/edit?html,css,output
  <dbaron> Gecko attempts to update scrollbars every 200ms during a
           transform animation on the compositor.

  shane: Looks like Windows!Chrome and Android!Chrome update
         scrollbars live, but Mac!Chrome doesn't do scrollbars at
         all - animations don't update the geometry at all.
  TabAtkins: So it looks like, aside from Mac!Chrome, animated
             transforms do affect the scrollable area, so we should
             spec that.
  smfr: WebKit only updates at the end of the transition.
  Rossen: So in the non-animated transform case, we all agree -
          scrollable area is affected.
  Rossen: So if you translate an element out of bounds, you can
          scroll to it.
  Rossen: Question is what if you animate a transform that would pop
          a scrollbar at some point in the interpolation.
  <smfr> https://www.w3.org/mid/CAOp6jLZZrmwZ1xZG2AzF+VTzn+zFUFa0EpSXp1T-fSc7ZhNa7A@mail.gmail.com
  <smfr> https://bug1236386.bmoattachments.org/attachment.cgi?id=8703469

  (talking about scale-down transforms)
  TabAtkins: So you've got a small parent. A large child which would
             overflow, but it's scaled down to not visibly overflow.
             Scrollbars or not?
  TabAtkins: Roc says it shouldn't pop scrollbars.
  TabAtkins: My argument that scrollbars should happen is that if
             the large child has a sibling, it's positioned relative
             to the original geometry, outside of the parent's
             bounds, and scrollbars pop. It's weird to me that the
             first child's geometry causes a scrollbar if something
             else is around, but not if it's by itself.
  shane: I don't think that's a big deal.
  TabAtkins: I'm fine with that, it was just my original argument.
             I'm fine with taking roc's argument.
  Rossen: Another scenario: small parent. Child is width:auto, big
          height, then it's scaled down to fit inside the parent.
  <TabAtkins> Exact numbers: parent is 100x100, child is autox200,
              then scale(.5) is applied. Is the child 50px wide, or
              42px (100 - 16px scrollbar / 2)?
  smfr: This is a separate issue entirely. Rossen, file a GH issue?
  smfr: Popping stack, do scrollbars depend on union of
        pre-transform and post-transform geometry, or just
        post-transform?
  Rossen: Popping more: static transform that causes overflow,
          scrollbars or not?
  TabAtkins: Everyone agrees on that.
  Rossen: So let's resolve on that.

  RESOLVED: Static transforms that overflow parent bounds do cause a
            scrollbar.

  <gregwhitworth> I threw together rossen's testcase:
                  https://jsfiddle.net/gpqkzth1/

  TabAtkins: Next case - a forward-fill animation that transforms to
             out of bounds.

  RESOLVED: An animation that is in fill (finished, or not yet
            started) is treated same as static, for purposes of
            transform/bounds/scrollbars computation.

  TabAtkins: So next - an animated transform that goes out of bounds
             at some point - scrollbars or no?
  shane: Behavior is inconsistent between browsers. Most Chrome
         platforms show them, Firefox shows them throttled in time,
         WebKit doesn't show them at all until animation is done.
  Rossen: So, MAY sounds good?

  RESOLVED: Animated transforms that go out of bounds MAY show a
            scrollbar during the animation.

  <smfr> https://jsfiddle.net/gpqkzth1/1/

  PROPOSED RESOLUTION: Overflow bounds are computed at end of
      layout, can be increased but not decreased by the effects of
      paint-level things like transforms.

  (Discussing over break.)
  <br type=lunch><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
	<tr>
        <td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
		<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
		</td>
	</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>
Received on Tuesday, 14 February 2017 01:59:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 14 February 2017 01:59:13 UTC