W3C home > Mailing lists > Public > www-style@w3.org > September 2015

[CSSWG] Minutes Paris F2F 2015-08-27 Part I: FXTF Meeting Part I; SVG Resources, SVG Images Without Intrinsic Size, Matrix Interpolation Revisited, SLERPing and 0deg angles [SVG] [css-animations] [css-transitions] [css-transforms]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 14 Sep 2015 13:58:47 -0400
Message-ID: <CADhPm3tF-tBQMwhOWRAYN-L+rVPhX-_xAa6ynKGa57Ue4HMywA@mail.gmail.com>
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


  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

  Daniel Glazman
  Anton Prowse

  general agenda: https://wiki.csswg.org/planning/paris-2015#agenda
  agenda for 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
  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
  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
  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
  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
  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

  <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
  shane: We did send a list of the issues.
Received on Monday, 14 September 2015 17:59:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:24 UTC