- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 15 Jul 2009 10:40:00 -0700
- 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 UTC