W3C home > Mailing lists > Public > www-style@w3.org > July 2009

[CSSWG] Minutes and Resolutions 2009-07-15

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 15 Jul 2009 10:40:00 -0700
Message-ID: <4A5E1470.4030904@inkedblade.net>
To: www-style@w3.org
Summary:

   - Hyatt proposes a CSS module for styling HTML5 datagrid. The
     CSSWG agrees it is in scope, but not that we have resources
     for it.

   - Long discussion of nested transitions and inheritance.
     TENTATIVE RESOLUTION: Something inheriting a transitioning
     value (including at the start and end of the transition)
     doesn't start its own transitions.

   - RESOLVED: For transitions where number of shadows doesn't
     match, shorter shadow list is padded with 0 0 rgba(0,0,0,0.0).

   - Discussed color spaces for color transitions: Webkit experimented
     with transitioning through hsl but concluded rgb is better.

   - RESOLVED: transitions apply to all elements and :before/:after
     (but not other pseudo-elements)

   - Open issue: whether rgba() transitions premultiplied or not.

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

Present:
   CÚsar Acebal
   David Baron
   Bert Bos
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   David Hyatt
   Dean Jackson
   Brad Kemper (Invited Expert)
   Chris Lilley
   Peter Linss


<RRSAgent> logging to http://www.w3.org/2009/07/15-CSS-irc
Scribe: sylvaing

Administrative
--------------
   <sgalineau> http://lists.w3.org/Archives/Member/w3c-css-wg/2009JulSep/0006.html

HTML5 datagrid
--------------

   <sgalineau> http://lists.w3.org/Archives/Member/w3c-css-wg/2009JulSep/0003.html
   hyatt describes his HTML5 datagrid request
   fantasai: i don't think the wg is against it, but do we have enough resources
             to work on it ?
   hyatt: we don't need a module right now since we don't know exactly what to
          put in yet but it should be on the wg's radar screen
   hyatt: i'm prepared to champion it but I want to fix the HTML spec first
   * dbaron hasn't looked at the HTML5 datagrid
   fantasai: I think we consider it to be in scope but the issue now is resources

CSS2.1 Issue 128: display:run-in clarifications
-----------------------------------------------

   http://wiki.csswg.org/spec/css2.1#issue-128
   <sgalineau> http://lists.w3.org/Archives/Public/www-style/2009Jul/0025.html
   hyatt: I agree with Boris' proposed solution for run-in issues
   fantasai: we need more details for the spec though
   (Moving to transitions since hyatt and dean are present)

Suppression of transition starting and inheritance
--------------------------------------------------

   http://lists.w3.org/Archives/Public/www-style/2009Jun/0121.html
   dbaron: I don't have a useful proposal for this nor have i seen a solution
           that i like
   dbaron describes webkit implementation
   chrisl: do you expect the transitions to run in parallel ?
   dbaron: not sure
   hyatt: that's what I expect.
   <ChrisL> i would expect them to run in parallel, yes
   dbaron: the hard question is what if one of the descendants also has a
           different transition on the inherited propery
   chrisl: SMIL addressed this.
   dean: SMIL does not have the concept of a computed style.
   hyatt: not sure webkit is running transitions are running sequentially.
          inner transitions keep restarting as the outer one is inherited
   hyatt: do we want to special-case the inheritance of an animated value ?
   dean: currently we don't know whether the value changes due to animation
         or inheritance
ScribeNick: fantasai
   dean: ... behavior can be helpful at times ... you don't want to have to
         turn transitions off to start the drag
   dean: ... quickly reset transitions in progress
   dbaron: I don't quite understand the dragging example
   dean: What our impl doing incorrectly.. in the inner value with the inherited
         color value
   dean: you're getting zillions of transitions starting one for every step of
         the parent
   dean: when parent is done, the child says now I can run to completion
   dean: that's what happens when you're interactively moving things around
   dean: say you move something w/ mouse 10px and it starts a transition
   dean: it starts a transition every millisecond
   dbaron: what do you mean it restarts the transition every time the outer
           transition kicks forward
   dbaron: how does it end up so that it's running the transition of the child
           when the .... all the way at the beginning value
   hyatt: You always transition where you are
   hyatt: it starts inheriting the animated values, and it thinks its
          transitioning from start to the value
   hyatt: it's never really getting a chance to move 'cuz it transitions over
          and over again
   hyatt: when the outer element ends its transition, you have to start almost
          from the beginning
   hyatt: when you change the outer element, it's resetting and triggering a
          transition on the inner element over and over
   dbaron: we don't want to initiate transitions from changes that initiate
           from other sources
   dbaron: e.g. if there's a SMILE element moving something gradually and
           there's a transition in there, we suppress the transition there
   hyatt: you mean you can't do nested transitions?
   hyatt: that doesn't actually bother me... I don't think this behavior is
          what you'd want even remotely
   hyatt: so I'd be fine with that.
   dbaron: Well there's cases where it breaks things that you want
   dbaron: if say we ignore the nested transition, then if you have a 5s
           transition on the color property and a 100ms transition on the ancestor
   dbaron: you have discontinuity between no transition and really short transition
   hyatt: is the second one inheriting its color from the outer?
   dbaron: yes. But if you suppress the color transition then the inner one
           transitions too fast
   hyatt: then suppress the transition only while the outer one is running
   dbaron: my impl does that [but it's weird]
   hyatt: ... the inner element ... should just start its own transition
   hyatt: you should include the end value in that and not do the 5s animation
          after the 100ms one
   <sgalineau> would it help if inner elements only saw/inherited the end value
               of the parent's transition ?
   ?: I think what you're saying is while the outer transition is running the
      inner one is not affected
   ...
   dean: spec says once you start a transition the transition value are locked
   dean: if you poke the inner one then you aren't inheriting anymore
   ...
   dbaron: I think that seems reasonable enough
   dbaron: in that it's better than anything else we've thought of
   <fantasai> dbaron, can you please type the summary?
   * fantasai lost a few lines there
   * fantasai has also lost microphone
   everyone seems to agree on the agreement, which hopefully will be typed in
   the minutes shortly :)
   <dbaron> tentative resolution is that something inheriting a transitioning
            value (including at the start of the transition) doesn't start its
            own transitions
   <dbaron> and that dean will put something about it in the spec
   hyatt: if you inherit a currently animating value you won't run a transition
          until that transition is complete ?
   <dbaron> (yeah, transitioning value or animating due to other animations)

   <Bert> About transitions and inheritance, maybe something like: "A change in
          a property's value only triggers a transition if the new value is due
          to the cascade, not if it is due to inheritance."?
   <dbaron> Bert, I don't think we want that
   <dbaron> Bert, although I suppose it's possible


Animation of shadows
--------------------

   <sgalineau> http://lists.w3.org/Archives/Public/www-style/2009Jun/0338.html
   ChrisL suggests padding the shorter list with zero offsets and black
   dbaron: Shouldn't it be transparent? Do we really want black?
   <fantasai> transparent
   <fantasai> we never use currentColor in shadows
   <fantasai> the default color is UA-defined, usually some variant of gray
              or black
   <ChrisL> suggest a default 0 0 0 0 rgba(0,0,0,0)
   <ChrisL> so transparent black
   Brad: You're saying that you setting the default shadow .. are you also
         going to default blur radius and offset?
   <fantasai> hyatt: yeah, to zero
   <ChrisL> yes, that was my suggestion, 0 0 0 0
   ChrisL: i think it's a good default, and if people want something else they
           can ask for it explicitly
   RESOLVED: default shadow is 0 0 0 0 rgba(0, 0, 0, 0.0), pad shorter shadow list
             for transitions where the shadows don't match

Color spaces for animation
--------------------------

Scribe: plinss+fantasai+dbaron
   dean: Someone asked a question about animating colors through different
         color spaces
   dean: we all thought that it would be better to animate through hsl, so we
         did some experiments
   peter: when moving in saturation or lightness it does work better, but hue
          gets weird when moving through the 180 degree phase
   dean: when you animate through hsl, you sometimes get transitions through
         the hue channel that give weird unrelated colors in the middle
   dean: when you animate through rgb you sometimes wind up with a sort of
         gray color, but nothing weird
   chrisl: it should give you better results
   chrisl: can have a property to choose
   dean: animating in hsl() space sometimes look really wrong; animating in
         rgb() space generally looks reasonable, although sometimes dull
   * fantasai missed all that


Elements affected by animations and transitions
-----------------------------------------------

Scribe: fantasai
   hyatt: Issue 7 and 8 are related
   hyatt: can we change the spec to say transition applies to all elements
   dean: I believe we also had a resolution that transition properties apply
         to all elements
   RESOLVED: transitions apply to all elements, not just block and inline re:
             http://lists.w3.org/Archives/Public/www-style/2009Jun/0479.html
   hyatt: Webkit doesn't run transitions on pseudoelements at all
   hyatt: And we don't do it for inherited :first-line styles either
   <sgalineau> http://lists.w3.org/Archives/Public/www-style/2009Jun/0478.html
   hyatt: I'm not convinced it's what we should do, but our implementation
          dodges those questions
   hyatt: It seems reasonable to run transitions on certain pseudo-elements.
          :first-line is trickier because the same object has multiple styles
   dbaron: We might want to restrict the spec to tree-like pseudo-elements
   dbaron: e.g. apply to :before/:after, but not :first-line
   hyatt: I say you wouldn't transition on styles resulting from :first-line etc.
   Brad asks what the problem is
   dbaron: The problem with :first-line is that you can have an element that
           is partly in the first line and partly out of it
   dbaron: e.g. a span,
   dbaron: the span there has two different colors
   dbaron: If the span has a transition color, and you set a transition on the
           paragraph
   dbaron: what transitions?
   hyatt: in the webkit impl the first-line style will just snap, and the
          transition runs on everything else
   dbaron: Bert said something interesting on IRC 10 min ago
   dbaron: he suggested transitions should only be triggered on non-inherited
           values
   hyatt: you could make a case for e.g. user hits cmd+ to increase font-size
          and you want that to transition
   dbaron: it would make this issue disappear
   dbaron: :first-letter, :first-line, and ::selection can all span multiple
           elements
   hyatt: I am totally fine with a first cut of this saying it doesn't apply
          to pseudo-elements at all
   dbaron: from impl experience the next piece of code I was going to write was
           to redo this bit, so I don't have experience on this issue yet
   hyatt: these types of pseudos have lots of special-cased code to handle them
   hyatt: running a transition on each of these requires extra code
   hyatt: how valueable is it to transition these? if nobody really cares, we
          shouldn't worry about it for a first cut
   Brad: Would prefer if before/after animate but not the others
   hyatt: that would work. THhey're the most straightforward
   dbaron: I don't think it's a question of :before/:after content animate
   dbaron: question is can you trigger a transition on the pseudo
   <fantasai> I think :before/:after should behave just like normal elements
   dean: I don't see why that should not work
   * fantasai could not hear that
   hyatt: I think you can transition on :before/:after and not on others
   brad: tree-like pseudo-elements, to capture future elements that work that way
   dbaron: say :before/:after for now but then future pseudos can say which
           properties apply to them
   <fantasai> I think we should just define a term "tree-like pseudo-elements"
              and use that
   <fantasai> then it's easier to plug in new pseudos
   <fantasai> Selectors is still Last Call, I can add it in as an editorial change
   dbaron: I think coming up with a term is ok
   hyatt: what about pseudos for e.g. datagrid? I'm not sure we want to transition
          those, even though they're probably tree-like
   hyatt: I'm not sure tree is the right category
   dbaron: There are pseudo-elements that are tree-like and don't contain elements,
           tree like and contain elements, and not-tree like
   dbaron: we don't have any in the second category, but we discussed some with
           the Forms wg
   hyatt: so let's just say :before/:after explicitly
   peter is concerned about conflicts in the specs
   peter: Phrase it carefully
   RESOLVED: transitions apply to all elements and :before/:after (but not other
             pseudo-elements)
Meeting closed.

<dbaron> Animations are component-wise in rgb() color space.
<dbaron> Based on what we said about transparent, I think they are
          component-wise (r, g, b, a) in *premultiplied* rgba() color
          space, but I'd like to check that with other people
<dbaron> I think I raised that as an issue but it wasn't on today's agenda
<hyatt> dbaron: i believe our implementation just animates each value
         individually
<hyatt> the r the g the b and the a
<plinss> I would think animating each value independently would give a
          better result than pre-multiplying...
<hyatt> oh maybe dean changed our impl
<hyatt> i thought we just animated each value individually though
<dbaron> hyatt, but then animating from transparent to a color would make
          it look black-ish at the beginning
<hyatt> sounds like this needs to be an issue?
<dbaron> hyatt, I think I sent a message about it, but it wasn't on today's
          agenda.
<hyatt> ah ok
<hyatt> maybe we can talk about it next week or something
<dbaron> but yeah, I think it should be an issue
<hyatt> my original (possibly naive) implementation just animated each value
<hyatt> r, g, b, a separately
<dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jul/0004.html was
          where I raised this... but I now think I got it backwards
<dbaron> the alpha issue, that is
<hyatt> yeah we don't pre-multiply
<dbaron> hyatt, let me write a testcase... I think nonpremultiplied will give
          bizarre results, though...
<plinss> dbaron: I would guess that non-premultiplied would actually give
          better results, but willing to be proven wrong...
<dbaron> hyatt, though I guess the author can get what they want by specifying
          different forms of transparent
Received on Wednesday, 15 July 2009 18:40:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:19 GMT