[CSSWG] Minutes Paris F2F 2013-09-11 Wed V: Shapes, Regions, Transforms

Shapes and Regions
------------------

   - RESOLVED: Conditional agreement on taking Shapes to LC; will give final
               yay/nay at telcon in two weeks.
   - Mihai Balan to become test owner for Regions.

Transforms
----------

   Discussed possible syntaxes additions for making transform lists easier
   to interpolate. One idea discussed was using commas to group transforms.
   This had a number of disadvantages, one of which is incompatibility with
   SVG syntax. Another idea was introducing a null transform, which would
   be compatible with all transforms, to use as a placeholder in a list.
   No conclusions, and no changes to this level.

   There was also a brief diversion into the idea of editing only one
   segment of a list-valued property.

====== Full minutes below ======

Shapes
------

   astearns: Shapes draft had a resolution a bit ago that was ??? with
             exclusions.
   astearns: It now only has shape-outside on floats.
   astearns: Since that WD, I've resolved all the issues.
   astearns: I was thinking of a WD and asking for more review, but people
             have pointed out that this usually means you go to LC.
   astearns: So I'm requesting to do so.

   ChrisL: Do you have a list of issues you resolved
   astearns: I have a change list from last draft.
   astearns: All of the issues were tracked in bugzilla.
   ChrisL: Ah, yes, that's what I wanted to know.

   ChrisL: Are there tests?
   ChrisL: That's something we ask during the LC meeting.
   astearns: We have 31 tests.
   astearns: I expect many more.
   ChrisL: Cool. That's a start.

   fantasai: It would be good to have the WG review it deeply, so he
             doesn't have to track those as LC issues.
   glazou: I think it's pointless - they've tracked a bunch of issues
           so far, and resolved them well.
   fantasai: Right, it's just a question of if they want to do multiple
             WDs, or multiple LCs.
   szilles: I still have more issues to bring up on the list.
   chrisl: Do you already have an ED?
   astearns: Yes.
   ChrisL: So you're really asking if you can go to LC in 1-2 weeks?
   astearns: Yeah.
   ChrisL: So we can resolve that.
   plinss: Let's call it 2 weeks.
   astearns: So we decide on publishing LC at the next telcon?
   glazou: Yeah, Sep 25.

   howcome: If you have a floated image, can you get shape-outside from
            itself?
   howcome: can I extract a shape from an image?
   astearns: yes, using an alpha channel threshold
   howcome: I'd rather use luminance
   astearns: maybe in level 2
   astearns: My strategy is that level 2 will have something for that.
             Right now it's just an <image> value. In the future, you
             can use the element() function.
   howcome: That's an answer, yes. Not the one I want, but...
   fantasai: You can use attr(src url).
   <Bert> shape-outside: image(filter(url(foo.jpg), make-white-transparent));
          shape-image-threshold: 0.5;

   glazou: So, conditional agreement on LC, with two weeks review?
   <glazou> YES
   <ChrisL> (no objections)
   RESOLVED: Conditional agreement on taking Shapes to LC; will give final
             yay/nay at telcon in two weeks.

Test Owners
-----------
   astearns: Mihai is going to be the joint test owner for Regions.
   <michou> Mihai Balan would be me :)
   astearns: I think we should have test coordinators for more specs.
   TabAtkins: Yeah, we've said that before. ^_^

CSS Transforms Interpolation
----------------------------
ScribeNick: fantasai

   TabAtkins: Transforms interpolation sucks right now, have a suggestion
              to make it better
   TabAtkins: WebKit has a suggestion of how to improve it in a back-compat
              way as well
   TabAtkins: Here's an example of badly-interpolated transform
   transform: translate(100px) rotate(45deg);
   transform: scale(2) translateX(200px)
   TabAtkins: Right now, the spec says that because these transform lists
              don't match, turn it into a matrix and interpolate that
   TabAtkins: In this particular case, not too terrible, but if rotate(545deg)
   TabAtkins: Lose several turns, also other weird cases
   <ChrisL> conversion to matrix gives you a rotate normalized to 0..360
   TabAtkins: Want better ways to do this

   TabAtkins: Shane and I were talking, came up with several alternate
              suggestions
   TabAtkins: Suggestion now is take tranform list
   TabAtkins: Right now is <transform>+
   TabAtkins: Suggest do <transform>+#

   TabAtkins: Within a group, smart or stupid interpolation
   TabAtkins: But between groups, [do something smart]
   TabAtkins: author can write
   transform: translateX(100px), rotate(545deg);
   transform: scale(2) translateX(200px), null;
   TabAtkins: and that will interpolate sanely

   TabAtkins: Also solves other issues
   TabAtkins: JS has some models that are hard to do in CSS
   TabAtkins: E.g. GreenSock library just exposes translate, rotate,
              scale as separate "properties" in its animation model
   TabAtkins: Can't do arbitrary combinations
   TabAtkins: While this is simpler than our model, can independently
              animate rotation or scale, without affecting other transforms
   TabAtkins: Very difficult in our model, because we can't modify just
              the scale
   TabAtkins: By separating out with comma, can adopt convention to do
              translate,rotate,scale
   TabAtkins: And then whatever generic solution we have for accessing
              list-valued properties will be usable for this

   dbaron: What do you mean?
   TabAtkins: People want to be able to modify one segment of a
              comma-separated list
   dbaron: Have a bunch of use cases where people want to add to, rather
           than replace, a list. Need additive cascade for that.
   TabAtkins: We also have cases where one class ads a rotation, another
              class adds a scale, don't want to list all combinations
   Dirk: additive animations should be handled at a global level, not just
         for transforms
   Dirk: and they are complex, we should ...
   krit: Animations and transforms are complex, even have issues in SVGWG
   krit: Only define animations for scale, translate, etc.

   TabAtkins: Going back to diversion about list-value properties
   dbaron: What are other cases where people want to edit within, rather
           than append?
   TabAtkins: background-image
   dbaron: here you can divide the transforms into categories, less true
           of bgimage
   TabAtkins: I'd have to look through for other cases, but that's the big one

   krit: I would like to have use cases on the ML, so can discuss on ML
   krit: second, comma is not a good separator, and in SVG comma and space
         are interchangeable
   krit: We have content already that uses it
   krit: Lastly, think it's a bigger change than we want to do in this level
   fantasai: Totally agree it's too significant for this level
   hober: Agree the proposal is a neat way of handling this, but not in
          this level

   dbaron: Don't think this makes things that much easier for authors.
   dbaron: Authors can already make their functions line up so they animate
           correctly.
   dbaron: This is just a slightly different way of making their functions
           line up
   dbaron: It could save you a function here or there, but doesn't seem
           like massive improvement to me
   TabAtkins: Does mean you can do less coordinate in base case
   TabAtkins: E.g. have multiple independent classes that apply some
              transform (rotate class, transform class, etc)

   TabAtkins: In base case, need to have sufficient null transforms
   Bert: How long will these lists get?
   TabAtkins: As long as you need to represent your intent
   Bert: Why not just add identity transforms there
   TabAtkins: more complicated cases ...?
   TabAtkins: Combinatorial problem
   fantasai: But this doesn't solve that
   TabAtkins: It makes it more likely to be solved when we solve this
               problem generally
   ChrisL: Probably want null, to be consistent with "null transform"
           terminology commonly used elsewhere
   fantasai: Also, 'none' and identity transform are not identical
   dbaron: No?
   fantasai: stacking contexts and other fun things like that?
   -> null
   fantasai: think it's an interesting idea, not something we should work
             on right this minute. Not convinced it's a great solution
             to all the problems.
   fantasai: If we have generic solution for splicing comma-separated lists,
             maybe revisit then because could be more compelling, but right
             now doesn't seem like enough of an improvement to be worth
             adding [and solving all issues on etc.]

   Bert: Adding null transform seems good enough, don't think most lists
         will be that long anyway
   krit: Could easily just add scale(1) etc.
   krit: Would really like to see use cases first, then have this discussion
   <ChrisL> scale(1) would not match up with a rotate
   TabAtkins: Another comment, if we ever do smarter fixup, this will
              allow us to [...]

   krit: ...
   krit: identity transform on second list
   krit: If identical except one is shorter than other
   TabAtkins: Do you pad beginning? end? Something else?

   fantasai: So, do we want to add a null transform?
   krit: Don't need it, just use identity transforms
   TabAtkins: Then have to match up types, not just indices

   Switching topics, no conclusion

   TabAtkins: Do we want to talk about list-value problem?
   fantasai: Not now? Doesn't seem like that urgent

Meeting closed.

Received on Thursday, 19 September 2013 08:29:19 UTC