- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 14 Sep 2015 13:58:47 -0400
- To: www-style@w3.org
- Cc: public-fx@w3.org
FXTF Meeting (part 1)
=====================
SVG Resources
-------------
- There was interest in allowing secure animated mode, though
there were concerns about the browsers having locked down
security too much to allow it.
SVG Images Without Intrinsic Size
---------------------------------
- There was implementation differences for how to handle SVG
images without intrinsic size. Rossen said he would write test
cases and use those to form an agreed behavior.
Matrix Interpolation Revisited
------------------------------
- shans brought his proposal to change the handling of when two
transform lists didn't match. He suggested having them flip at
50% progress to indicate that they're clearly broken.
- There was concern that this would cause significant breakage and
a feeling that browsers could do something smarter.
- Ultimately it was decided that there was a need for more data
before a decision could be made.
SLERPing and 0deg angles
------------------------
- RESOLVED: Treat all 0deg rotate3d() as a single equivalent
identity transform
- RESOLVED: Treat rotate3d() with anti-parallel axis as
interpolatable
===== FULL MINUTES BELOW ======
Present:
Rachel Andrew
Nikos Andronikos
Rossen Atanassov
Tab Atkins
David Baron
Brian Birtles
Bert Bos
Tantek Çelik
Dave Cramer
John Daggett (phone)
Erik Dahlström
Elika Etemad
Rob Flack
Simon Fraser
Jihye Hong
Koji Ishii (phone)
Dael Jackson
Dean Jackson
Brian Kardell
Ian Kilpatrick
Tomoaki Konno
Chris Lilley
Peter Linss
Cameron McCormack
Edward O'Connor
Simon Pieters
Liam Quin
Matt Rakow
Florian Rivoal
Andrey Rybka
Hiroshi Sakakibara
Simon Sapin
Dirk Schultz (phone)
Hyojin Song
Elliott Sprehn
Alan Stearns
Shane Stephens
Lea Verou
Sam Weinig
Greg Whitworth
Johannes Wilm
Steve Zilles
Regrets:
Daniel Glazman
Anton Prowse
general agenda: https://wiki.csswg.org/planning/paris-2015#agenda
agenda for FX:
https://wiki.csswg.org/planning/paris-2015#proposed-agenda-topics-fx
scribe: dael
FXTF Meeting
============
SVG Resources
-------------
<smfr> https://svgwg.org/specs/integration/#secure-animated-mode
smfr: People like SVG as CSS images. We think people that would
benefit from the resources, possibly only margin resources.
The current behavior is given by the processing modes.
smfr: The approach used in SVG modes is this one (link above). We
think there's a use case for having a secure animated mode.
smfr: We should have to figure out what resources are.
tantek: What are the use cases?
dino: You want to link to a style sheet.
smrf: Right now if you want to import you have to do as a div.
tantek: A new mode?
smfr: I don't know.
tantek: We recently added CSS 3 UI cursor property where you can
do SVG cursor.
smfr: I think that's a special one.
Florian: We referred to a spec in SVG.
tantek: Secure animated mode. It's a client of that mode. My
preference is that stay the same for that reason. If you
have a strong reason for just secure animated mode... I'm
open to being convinced otherwise.
<tantek> CSS3 UI is a client of secure animated mode,
specifically, the cursor property
heycam: If whatever reason is still legit, we have the option of
having those external resources referenced. If there's an
iFrame or something like that where we have a place to
specify a location.
dino: Doing it on the image element, would you put an extra
parameter on the URL?
heycam: I really want to do this, I think this was the original
intent of SVG.
dino: I think the intention was that, yes, but the browsers
locked down the security as much as they could and no one
remembers exactly why we wanted to disallow that.
heycam: Do you know if each mode might not allow some resources?
Can you explain why?
smfr: What's the best way to move forward?
heycam: I'll talk to the people in a couple weeks. In principle
that will be good until now.
tantek: One practice that has been common is using sprites on
pages. That would be a use case for not logging terms.
<tantek> specifically, using data URLs for encoding SVG images as
sprites on pages
<tantek> or icons etc.
SVG Images Without Intrinsic Size
---------------------------------
dino: This is an edge case that's being discussed internally and
TabAtkins has an opposite opinion. I don't know what else to
say, this is an instance where we want to encourage people
not to use intrinsic size in their SVG, but when there's a
border you need to know intrinsic size.
TabAtkins: You do not. We have some bugs in Chrome but it's
roughly correct. Yours for background is completely
correct, but you used something odd for border.
dino: So you work out the size of the border, rasterize the SVG in
and slice it?
TabAtkins: That's what the spec says. The SVG side of how to
figure out the coordinate space is hard to read.
krit: SVG spec is missing a lot of info on intrinsic sizing.
There's an open issue for this.
TabAtkins: The one that's hard to find is how, given no other
sizing information but being embedded in some other
document, the SVG document takes its coordinate space.
If you set up in a 300px wide, the SVG was 300 units.
It's in the spec, but hard to find. I think it would
have made this more obvious.
TabAtkins: Just making sure this is an issue you'll address.
dino: We have 3 browsers with 3 different implementations all of
which are buggy.
TabAtkins: Chrome and Firefox are consistent.
dino: Firefox is radically different. It was drawing same image in
all cells.
TabAtkins: If it was then yes, I agree. It's odd.
TabAtkins: Rossen, where are you tracking issues?
Rossen: We had to implement this in Edge and we're matching Chrome
mostly, in some cases Firefox where it made more sense. As
part of this came up with a whole bunch of test cases.
I'll record all this, get an agreement, submit test cases
and move on.
dino: Where is it documented?
Rossen: There's the integration spec or it could be in SVG spec.
dino: In the current spec, what's TabAtkins is suggesting there's
a significant difference between SVG that has and does not
have intrinsic size.
TabAtkins: That's what the spec has.
Rossen: There's a bunch of permutations there.
ed_paris: You satisfied?
dino: Yeah.
tantek: Quick question, does it include intrinsic aspect ratio?
TabAtkins: You get that from the view box, it doesn't matter. You
can have width and or height, you can have a viewbox,
you can have both, you can have neither and that gives
you all valid combinations.
tantek: I think we ran into a bunch of these when trying to test
the box sizing.
Florian: I don't know how extensively they've been tested, but
there's more bugs if we poke at it.
tantek: So if you're looking for places with bugs that's a good
place to look.
dino: I think this is where we found the original bug.
Matrix Interpolation Revisited
------------------------------
shane: I wanted to revisit the interpolation for matrices. There's
two cases where we fall into a matrix decomposition. The
first is when applying to matrix components and the other
is interpolation on transform lists that don't match.
shane: I don't think that there are 2 matching. I think we should
not attempt anything clever and adjust to 50% clip.
TabAtkins: Like all the properties that don't have an animation,
they flip at 50% progress.
dino: Webkit is close to Mozilla with the exception of one
interpolation that goes through an undefined case. In that
case the rotation- it's had to say if it's rotation- it goes
in a different direction.
dino: Otherwise in the vast majority of cases it's identical.
shane: The direction of rotation is something different browsers
disagree on.
dino: The algorithm is in the spec.
shane: It's demonstrably incomplete and I don't think anyone
implements what's in the spec.
dino: I implement what's in the spec and dbaron gave us what are
the incompatibilities. I think krit was going to put it in
the spec.
shane: This comes out again and again.
dino: Compat behavior is easy to define. It's 10-20 lines of code.
One person could look at all the browsers and make the
change.
shane: It's been this way for 5+ years.
dino: Because it's such a rare case.
shane: People hit them all the time. There's number of demos.
dino: Let's fix the bug.
shane: So there's matrix to matrix and I think we want to fix the
bugs. There's transform list to transform list and the
issue there is there isn't a meaningful thing to do.
shane: We should be working out the cases where we can augment
transform matching. When it comes to matching transform
matching, doing matrix decomposition doesn't give the
correct result.
dino: It's very well defined.
shane: I disagree because we don't have matching implementations.
dino: We had a whole e-mail thread about what to do and we
implemented it. Yes we could augment the case with two non-
matching transform lists if we could work out what the
authors intended and this is something we could fix, that
seems like an okay theme to follow.
dino: I don't understand why interpolating between two matrices is
a big deal.
shane: This is when the transforms don't match. In that case what
happens is authors will muck around with the transform
lists until they get something and it doesn't look good in
a browser.
shane: So a 50% flip when they don't match is a clear sign
something is wrong.
dino: I think we should enumerate the cases where the browsers
don't match.
shane: We've been doing that for the last 5 years.
dino: We decided on an algorithm.
shane: So there's the rotation issue where you need a short of
long path and this is where you flip. That never made it
into the spec.
dino: krit did we ever agree to put updated matrix interpolation
in the spec?
krit: We agreed to and we did add it, the one for 2D transforms.
dino: 3D transformations?
krit: I think the bigger issue was on 2D, not 3D. We went to 3D
and this was the reason we had the different issues between
browsers.
shane: That's the point.
dino: I think we can come up with an algorithm, this isn't rocket
science. This won't be difficult for browsers to implement
the same.
shane: We could. I'm arguing there isn't compat right now and it's
better to break.
dino: So break existing content instead of have a future where
things work properly. You're saying you want to break matrix
interpolation in all cases.
shane: The space in transforms is evenly populated.
smfr: I think the rotation and scale works just fine. I think
breaking it to address rotations is bad.
shane: We're only hitting this when transformers don't match
anything.
dino: Maybe you should come up with a list that seems broken and
we can evaluate if it's worth breaking everything.
shane: You're asking for a list of sites that are not working
right now.
dino: We've got to choose between two groups of 'working' and
'broken' and that ratio is going to change. We have to
decide which decision will change the amount of broken
content.
shane: I'm happy to go and get that.
dino: And balance that against the overhead.
shane: It's might harder to get the browsers to interoperability
then remove that.
krit: Currently there's 2D and 3D matrix interpolation. There are
differences in 3D. For 2D there were patches to FF and they
didn't accept them. That's why you see many differences.
krit: Blink and webkit aren't identical. The algorithm got into
the spec after the fork.
shane: We've also made fixes both on the browser and render side
and neither of those match the spec.
dino: So leave as-is, fix the spec, or break the content and do
the 50% split? We need data. I like fix the spec, you like
option 3, and we need data to decide.
shane: Fair enough. I did want to raise this issue. There also was
an interest in augmenting where we do list matching. Is
that true?
dino: It would be interesting to see what intelligence you could
gain to see what matches.
shane: There's simple ideas we've had in the past.
dino: I don't know what causes incomparable lists.
shane: Most common is leaving the last component out.
dino: At the moment we say if you do anything from identity you
could fill it in. There's another slightly less complicated
way, but I think we can deal with that. If we did just those
two things we'd remove 90% of the cases.
krit: The interpolation we removed a smarter way and we removed
that for smarter matrices.
krit: If you have 2 lists of transforms and the last element is
missing on the last transform you do not need to fall back
to matrix interpolation. I had to remove that from the spec.
shane: What were the requests?
krit: The spec was updated 2 years ago, so it was 2 years ago.
shane: I will write up something and send it to the list.
krit: And it's somewhere in the older modules.
SLERPing and 0deg angles
------------------------
TabAtkins: Whenever we have two 3D rotations we're transforming
between. We have well-defined behavior if the axises
are identical. If they're different there's no good way
to interpolate. We need to do it using SLERPs. That's
all background.
TabAtkins: If you have an identity 3D rotation pointing in any
direction whatsoever and you're transitioning- that the
axises might be different is irrelevant. In this case
we should basically pretend the axes are aligned if one
is 0deg rotation so we can get proper arguments.
shane: That behavior is what happens already in that the 0deg axis
snaps to the non-0. Rather than a parameter, you get the
shortest path.
TabAtkins: Does anyone object to making that clear in the spec?
That 0deg rotation pretends the axises are aligned. And
does anyone object that anti-parallel works the same?
krit: We can't have lots of special cases. The reason why we
didn't change is certain browser vendors like Safari said
they couldn't change their background for that. Safari
relies on the OS for this calculation.
TabAtkins: Either of these two cases are addressable for massaging
inputs pre-OS.
krit: I'm not against it, but we can't add dozens of special cases.
It makes the code more complex and less readable.
TabAtkins: I think the 0deg is important because when you're going
from an identity transform it shouldn't matter.
krit: Just ID to 3D transform.
TabAtkins: If it's a 0deg rotation, it's an identity transform.
krit: I'm not sure I follow.
TabAtkins: Take a 0deg rotation around the y axis, say that's the
start, end is 720deg around X axis. That you're 0deg
around Y doesn't matter.
TabAtkins: Rotation has this thing where we can only do argument-
based interpolation if the axises match.
<shane> transform: rotate3d(0, 1, 0, 0); to transform: rotate3d
(1, 0, 0, 20);
krit: I see.
MaRakow: Has Chrome prototyped this?
TabAtkins: Yes.
TabAtkins: Objections to treat 0deg as argument interpolatable
with a real rotation?
smfr: What part of the spec will have this?
shane: I think this is best before decomposition.
TabAtkins: This is a matter of figuring out which list of
transforms are matching.
dino: You could probably extend that to be any transform.
TabAtkins: I don't think any of the others have this fiddlyness.
dino: If it's a previous thing where you're making matching
smarter, it seems like it would fall in.
shane: That might not be good because that rotate 0deg might be a
placeholder to interpolate with something else.
shane: How about we do this patch now and we try and come up with
something more complete?
krit: If we say the transform is an identity transform, it might
have a translation +20 and -20?
TabAtkins: If they use rotate that's a semantically meaningful
choice. Going from a rotate to a translate has meaning.
krit: It seems odd that we say for rotate that's the only thing we
do not do that. We say you rotate with 0deg we treat it as
an identity transform, but for the others we say it's
different.
TabAtkins: Might be difference of opinion, but it makes sense that
if we're going 3D to 3D rotate it is acceptable.
shane: There's nothing special, it's that there's a unique identity
for everything except transform. [?]
TabAtkins: So, objections to treating all 0deg rotate3d() as a
single equivalent identity transform?
RESOLVED: Treat all 0deg rotate3d() as a single equivalent
identity transform
TabAtkins: Objections to treating rotate3d() with anti-parallel
axis as interpolatable?
TabAtkins: If you have one rotation 90deg in +x and 45deg in -X,
they are equivalent.
TabAtkins: You don't even need to do a negative axis.
shane: You have to choose a direction to rotate in this case and
we should make this work as close to spec as possible.
TabAtkins: So should we agree on that, or do we want propose text.
smfr: It's okay.
dino: We can agree.
RESOLVED: treat rotate3d() with anti-parallel axis as
interpolatable
<dbaron> re "RESOLVED: treat all 0deg rotate 3D as a single eq. ID
transform" -- presumably the rotate3d() is only
compatible with other rotate3Ddfunctions, and not an
identity relative to arbitrary other transform functions?
<MaRakow> dbaron I think it would be compatible with rotateX/Y/Z
too, right?
<dbaron> MaRakow, I think that's implied by the primitives stuff
krit: In the future it would be better to come with a demo for
that.
shane: We did send a list of the issues.
Received on Monday, 14 September 2015 17:59:44 UTC