- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 13 Feb 2017 20:58:07 -0500
- 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