15:54:15 <RRSAgent> RRSAgent has joined #CSS
15:54:15 <RRSAgent> logging to http://www.w3.org/2009/07/15-CSS-irc
15:54:20 <glazou> Zakim, this is Style
15:54:20 <Zakim> ok, glazou; that matches Style_CSS FP()12:00PM
15:54:48 <hyatt> hyatt has joined #css
15:55:54 <dino> dino has joined #css
15:58:23 <cesar_acebal> cesar_acebal has joined #css
15:58:26 <Zakim> + +1.858.216.aabb
15:58:45 <plinss> zakim, +1.858.216 is me
15:58:45 <Zakim> +plinss; got it
15:59:03 <Zakim> + +1.281.419.aacc
15:59:26 <hyatt> zakin, 1.281.419 is me
15:59:35 <hyatt> zakim, 1.281.419 is me
15:59:35 <Zakim> sorry, hyatt, I do not recognize a party named '1.281.419'
16:00:00 <plinss> zakim, +1.281.419 is hyatt
16:00:00 <Zakim> +hyatt; got it
16:00:13 <Zakim> +[Microsoft]
16:01:37 <Zakim> +[Mozilla]
16:01:40 <dbaron> Zakim, [Mozilla] has dbaron
16:01:40 <sgalineau> sgalineau has joined #css
16:01:40 <Zakim> +dbaron; got it
16:01:47 <ChrisL> ChrisL has joined #css
16:02:03 <dbaron> Zakim, who is on the phone?
16:02:03 <Zakim> On the phone I see +95089aaaa, plinss, hyatt, [Microsoft], [Mozilla]
16:02:04 <Zakim> [Mozilla] has dbaron
16:02:25 <Zakim> + +34.60.940.aadd
16:02:48 <sgalineau> sgalineau has joined #css
16:02:50 <cesar_acebal> zakim, +34.60.940 is me
16:02:50 <Zakim> +cesar_acebal; got it
16:03:04 <sgalineau> Zakim, [Microsoft] has sylvaing
16:03:04 <Zakim> +sylvaing; got it
16:03:24 <Zakim> + +1.408.588.aaee
16:03:38 <Zakim> +Bert
16:03:45 <Zakim> + +39.524.9.aaff
16:03:49 <Zakim> +fantasai
16:03:57 <ChrisL> zakim, +39 is me
16:03:57 <Zakim> +ChrisL; got it
16:04:06 <Zakim> -cesar_acebal
16:04:19 <dbaron> Zakim, who is on the phone?
16:04:19 <Zakim> On the phone I see +95089aaaa, plinss, hyatt, [Microsoft], [Mozilla], dino, Bert, ChrisL, fantasai
16:04:22 <Zakim> [Mozilla] has dbaron
16:04:26 <Zakim> [Microsoft] has sylvaing
16:04:28 <Zakim> + +1.650.766.aagg
16:04:43 <ChrisL> zaki, where is +95?
16:04:49 <ChrisL> zakim, where is +95?
16:04:49 <Zakim> country code 95 is Burma (Myanmar)
16:04:50 <Zakim> +cesar_acebal
16:05:43 <szilles> szilles has joined #css
16:06:40 <Zakim> +SteveZ
16:06:51 <ChrisL> zakim, drop +95
16:06:52 <Zakim> +95089aaaa is being disconnected
16:06:52 <Zakim> - +95089aaaa
16:06:53 <sgalineau> scribenick: sylvaing
16:07:27 <glazou> yep
16:07:51 <Zakim> + +95089aahh
16:07:53 <glazou> glad to see you too ChrisL :)
16:07:57 <dbaron> Zakim, aahh is glazou
16:07:57 <Zakim> +glazou; got it
16:08:16 <sgalineau> http://lists.w3.org/Archives/Member/w3c-css-wg/2009JulSep/0006.html
16:08:29 <sgalineau> Gabriele Romanato as invited expert ?
16:13:43 <sgalineau> http://lists.w3.org/Archives/Member/w3c-css-wg/2009JulSep/0003.html
16:13:56 <dbaron> Zakim, who is noisy?
16:14:07 <Zakim> dbaron, listening for 10 seconds I heard sound from the following: 12 (65%), glazou (5%), fantasai (15%)
16:14:13 <sgalineau> hyatt describes his HTML5 datagrid request
16:14:27 <dbaron> Zakim, who is on the phone?
16:14:27 <Zakim> On the phone I see plinss, hyatt, [Microsoft], [Mozilla], dino, Bert, ChrisL, fantasai, +1.650.766.aagg, cesar_acebal, SteveZ, glazou
16:14:30 <Zakim> [Mozilla] has dbaron
16:14:30 <Zakim> [Microsoft] has sylvaing
16:14:35 <sgalineau> fantasai: i don't think the wg is against it, but do we have enough to work on it ?
16:15:04 <sgalineau> hyatt: we don't need a module since we don't know exactly what to put in yet but it should be on the wg's radar screen
16:15:49 <sgalineau> hyatt: i'm prepared to champion it but I want to fix the HTML spec first
16:16:04 <sgalineau> fantasai: I think we consider it to be in scope but the issue now is resources
16:16:32 <sgalineau> http://lists.w3.org/Archives/Public/www-style/2009Jul/0025.html
16:17:33 <sgalineau> Issue 128: display:run-in clarifications
16:18:06 <sgalineau> hyatt: I agree with Boris' proposed solution for run-in issues
16:18:15 <sgalineau> fantasai: we need more details for the spec though
16:18:25 <sgalineau> http://lists.w3.org/Archives/Public/www-style/2009Jun/0121.html
16:18:42 <sgalineau> (Moving to transitions since hyatt and dean are present)
16:18:47 <glazou> jdaggett: ping
16:19:34 <sgalineau> [css3-transitions] suppression of transition starting, inheritance
16:20:08 <sgalineau> dbaron: I don't have a useful proposal for this nor have i seen a solution that i like
16:20:34 <sgalineau> dbaron describes webkit implementation
16:20:57 <sgalineau> chrisl: do you expect the transitions to run in parallel ?
16:21:03 <sgalineau> dbaron: not sure
16:21:19 <sgalineau> hyatt: that's what I expect. 
16:21:28 <ChrisL> i would expect them to run in parallel, yes
16:22:43 <sgalineau> dbaron: the hard question is what if one of the descendants also has a different transition on the inherited propery
16:23:02 <sgalineau> chrisl: SMIL addressed this.
16:23:43 <sgalineau> dean: SMIL does not have the concept of a computed style. 
16:24:40 <sgalineau> hyatt: not sure webkit is running transitions are running sequentially. inner transitions keep restarting as the outer one is inherited
16:25:21 <sgalineau> hyatt: do we want to special-case the inheritance of an animated value ?
16:25:56 <sgalineau> dean: currently we don't know whether the value changes due to animation or inheritance
16:26:39 <fantasai> dean: ... behavior can be helpful at times ... you don't want to have to turn transitions off to start the drag
16:26:47 <fantasai> dean: wnat to quickly reset transitions in work
16:26:55 <fantasai> dbaron: I don't quite understand the dragging example
16:27:13 <fantasai> dean: What our impl doing incorrectly.. in hte inner value with the inherited color value
16:27:23 <fantasai> dean: you're getting zillions of transitions starting one for every step of the parent
16:27:34 <fantasai> dean: ... child says now I can run to completion
16:27:40 <fantasai> dean: that's what happens when you're interactively moving things around
16:27:51 <fantasai> dean: say you move something w/ mouse 10px and it starts a transition
16:28:00 <fantasai> dean: it starts a transition every millisecond
16:28:12 <sgalineau> Zakim, [Microsoft] has arronei,alexmog
16:28:12 <Zakim> +arronei, alexmog; got it
16:28:13 <fantasai> dbaron: what do you mean it restarts the transition every time the outer transition kicks forward
16:28:30 <fantasai> dbaron: how does it end up so that it's running the transition of the child when the .... all thte way at the beginning value
16:28:36 <fantasai> hyatt: You always transition where you are
16:28:53 <fantasai> hyatt: it starts inheriting the animated values, and it thinks its transitioning from start to the value
16:29:06 <fantasai> hyatt: it's never really getting a chance to move 'cuz it transitions over and over again
16:29:23 <fantasai> hyatt: when the outer elmeent ends its transition, you have to start almost from the beginning 
16:29:42 <fantasai> hyatt: when you change the outer element, it's resetting and triggering a transition on the inner element over and over 
16:29:57 <fantasai> dbaron: we don't want to initiate transitions from changes that initiate from other sources
16:30:12 <fantasai> dbaron: e.g. if there's a SMILE element moving something gradually and there's a transition in there, we suppress the transition there
16:30:18 <fantasai> hyatt: you mean you can't do nested transitions?
16:30:32 <fantasai> hyatt: that doesn't actually bother me... I don't think this behavior is what you'd want even remotely
16:30:35 <fantasai> hyatt: so I'd be fine with that.
16:30:43 <fantasai> dbaron: Well there's cases where it breaks things that you want
16:31:06 <fantasai> dbaron: if we say we ignore the nested transition, then if you have a 5s transition on the color property and a 100ms transition on the ancestor
16:31:24 <fantasai> dbaron: you have discontinuity between no transition and really short transition (/)
16:31:34 <fantasai> hyatt: is the second one inheriting its color from the outer?
16:31:52 <fantasai> dbaron: yes. But if you suppress the color transition then the inner one transitions too fast
16:32:23 <fantasai> hyatt: then suppress the transition only while the outer one is running
16:32:34 <fantasai> dbaron: my impl does that [but it's weird]
16:32:52 <glazou> what's that bzzzzzzz loud sound ?
16:33:22 <fantasai> hyatt: ... the inner element ... should just start its own transition
16:33:30 <alexmog> alexmog has joined #css
16:33:37 <fantasai> hyatt: you should include the end value in that and not do the 5s animation after the 100ms one
16:34:05 <sgalineau> would it help if inner elements only saw/inherited the end value of the parent's transition ?
16:34:13 <fantasai> ?: I think what you're saying is while the outer transition is running the inner one is not affected
16:34:17 <fantasai> ...
16:34:36 <fantasai> dean: spec says once you start a transition the transition value are locked
16:34:56 <fantasai> dean: if you poke the inner one then you aren't inheriting anymore
16:35:06 <fantasai> ...
16:35:11 <fantasai> dbaron: I think that seems reasonable enough
16:35:27 <fantasai> dbaron: in that it's better than anything else we've thought of
16:35:34 <fantasai> dbaron, can you please type the summary?
16:36:18 <fantasai> everyone seems to agree on the agreement, which hopefully will be typed in the minutes shortly :)
16:36:39 <dbaron> tentative resolution is that something inheriting a transitioning value (including at the start of the transition) doesn't start its own transitions
16:36:50 <dbaron> and that dean will put something about it in the spec
16:36:56 <sgalineau> hyatt: if you inherit a currently animating value you won't run a transition until that transition is complete ?
16:36:57 <fantasai> hyatt: basically what you're saying is if you inherit a currently-animating value, you won't transition on the animating value
16:37:00 <dbaron> (yeah, transitioning value or animating due to other animations)
16:37:15 <sgalineau> http://lists.w3.org/Archives/Public/www-style/2009Jun/0338.html
16:37:23 <sgalineau> [css3-transitions] animation of shadows
16:38:11 <fantasai> transparent
16:38:17 <fantasai> we never use currentColor in shadows
16:38:33 <fantasai> the default color is UA-defined, usually some variant of gray or black
16:38:59 <fantasai> chris suggests padding with a shadow of zero offsets and black
16:39:03 <ChrisL> suggest a default 0 0 0 0 rgba(0,0,0,0)
16:39:10 <ChrisL> so transparent black
16:39:41 <ChrisL> s/and black/and transparent black/
16:39:44 <fantasai> dean: Someone asked a question about animating colors through different color spaces
16:40:08 <fantasai> dean: We did some experiments, and we all thought that it would be better to animate through hsl
16:40:21 <fantasai> dean: when you animate through rgb you sometimes wind up with a sort of gray color
16:40:33 <fantasai> chrisl: it should give you better results
16:40:39 <fantasai> chrisl: can have a property to choose
16:41:02 <fantasai> dean: we didn't think it was necessary, hsl just usually gives better results
16:41:14 <dbaron> dean: animating in hsl() space sometimes look really wrong; animating in rgb() space generally looks reasonable, although sometimes dull
16:41:54 <dbaron> Zakim, who is on the phone?
16:41:54 <Zakim> On the phone I see plinss, hyatt, [Microsoft], [Mozilla], dino, Bert, ChrisL, fantasai, +1.650.766.aagg, cesar_acebal, SteveZ, glazou
16:41:57 <Zakim> [Mozilla] has dbaron
16:41:57 <Zakim> [Microsoft] has arronei, alexmog
16:42:05 <dbaron> Zakim, aagg is Brad_Kemper
16:42:05 <Zakim> +Brad_Kemper; got it
16:42:07 <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."?
16:42:26 <fantasai> :)
16:43:31 <fantasai> hyatt: Issue 7 and 8 are related
16:43:38 <fantasai> hyatt: can we change the spec to say it applies to all elements
16:44:11 <dbaron> Bert, I don't think we want that
16:44:12 <hyatt> for shadows, pad the shorter list with 0 0 0 0 rgba(0,0,0,0.0)
16:44:33 <fantasai> plinss: can you ask for a formal resolution on these issues, one by one?
16:44:36 <dbaron> Bert, although I suppose it's possible
16:45:16 <fantasai> Brad?: You're saying that you setting the default shadow .. are you also going to default blur radius and offset?
16:45:20 <fantasai> hyatt: yeah, to zero
16:45:29 <ChrisL> yes, that was my suggestion, 0 0 0 0
16:46:07 <fantasai> chrisl: i think it's a good default, and if people want something else they can ask for it explicitly
16:46:37 <fantasai> RESOLVED: default shadow is 0 0 0 0 rgba(0, 0, 0, 0.0) for transitions where the shadows don't match
16:47:12 <fantasai> in #of shadows
16:47:55 <fantasai> dean: I believe we also had a resolution that transition properties apply to all elements  (?)
16:48:15 <fantasai> Any objections or is this resolved?
16:48:21 <fantasai> *pokes the chair*
16:48:29 <sgalineau> RESOLVED: transitions apply to all elements, not just block and inline re: http://lists.w3.org/Archives/Public/www-style/2009Jun/0479.html
16:48:32 <fantasai> hyatt: Webkit doesn't run transitions on pseudoelements at all
16:48:39 <fantasai> hyatt: And we don't do it for inherited :first-line styles either
16:48:50 <sgalineau> http://lists.w3.org/Archives/Public/www-style/2009Jun/0478.html
16:48:56 <fantasai> hyatt: I'm not convinced it's what we should do, but our implementation dodges those questions
16:49:30 <fantasai> hyatt: It seems reasonable to run transitions on certain pseudo-elements. :first-line is trickier because the same object has multiple styles
16:49:42 <fantasai> dbaron: We might want to restrict the spec to tree-like pseudo-elements
16:49:51 <fantasai> dbaron: e.g. apply to :before/:after, but not :first-line
16:50:35 <fantasai> hyatt: I say you wouldn't transition on styles resulting from :first-line etc.
16:50:41 <fantasai> ...
16:50:57 <fantasai> 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
16:51:03 <fantasai> dbaron: e.g. a span,
16:51:09 <fantasai> dbaron: the span there has two different colors
16:51:24 <fantasai> dbaron: If the span has a transition color, and you set a transition on the paragraph
16:51:28 <fantasai> dbaron: what transitions?
16:51:49 <fantasai> hyatt: in the webkit impl the first-line style will just snap, and the transition runs on everything else
16:51:58 <fantasai> dbaron: Bert said something interesting on IRC 10 min ago
16:52:09 <fantasai> dbaron: he suggested transitions should only be triggered on non-inherited values
16:52:46 <fantasai> hyatt: you could make a case for e.g. user hits cmd+ to increase font-size and you want that to transition
16:53:03 <fantasai> dbaron: it would make this issue disappear
16:53:14 <fantasai> dbaron: :first-letter, :first-line, and ::selection can all span multiple elements
16:53:27 <fantasai> hyatt: I am totally fine with a first cut of this saying it doesn't apply to pseudo-elements at all
16:53:49 <fantasai> dbaron: from impl experience the next piece of code I was going to write was te redo this bit, so I don't have experience on this issue yet
16:54:05 <fantasai> hyatt: these types of pseudos have lots of special-cased code to handle these pseudos
16:54:15 <fantasai> hyatt: running a transition on each of these requires extra code
16:54:32 <fantasai> hyatt: how valueable is it to transition these? if nobody really cares, we shouldn't worry about it for a first cut
16:54:43 <fantasai> ?: Would prefer if before/after animate but not the others
16:54:53 <dbaron> s/?:/Brad:/
16:54:54 <fantasai> hyatt: that would work. THey're the most straightforward
16:55:10 <fantasai> dbaron: I don't think it's a question of :before/:after content animate
16:55:25 <fantasai> dbaron: question is can you trigger a transition on the pseudo
16:55:33 <fantasai> I think :before/:after should behave just like normal elements
16:55:44 <fantasai> dean: I don't see why that should not work
16:56:14 <fantasai> hyatt: I think you can transition on :before/:after and not on others
16:56:40 <fantasai> brad: tree-like pseudo-elements, to capture future elements that work that way/
16:57:11 <fantasai> dbaron: say :before/:after for now but then future pseudos can say which properties apply to them
16:57:22 <fantasai> I think we should just define a term "tree-like pseudo-elements" and use that
16:57:36 <fantasai> then it's easier to plug in new pseudos
16:57:44 <fantasai> Selectors is still Last Call, I can add it in as an editorial change
16:57:58 <fantasai> dbaron: I think coming up with a term is ok
16:58:21 <fantasai> hyatt: what about pseudos for e.g. datagrid? I'm not sure we want to transition those, even though they're probably tree-like
16:58:27 <fantasai> hyatt: I'm not sure tree is the right category
16:58:47 <fantasai> dbaron: There are pseudo-elements that are tree-like and contain elements, tree-like and don't contain elements, and not-tree like
16:59:04 <fantasai> dbaron: we don't have any in the second category, but we discussed some with the Forms wg
16:59:13 <fantasai> hyatt: so let's just say :before/:after explicitly
16:59:46 <fantasai> peter is concerned about conflicts in the specs
16:59:52 <dbaron> s/tree-like and contain elements, tree-like and don't contain elements/tree-like and don't contain elements, tree like and contain elements/
16:59:56 <fantasai> peter: Phrase it carefully
17:00:25 <fantasai> WAIT
17:00:28 <Zakim> -dino
17:00:29 <Zakim> -ChrisL
17:00:30 <Zakim> -[Mozilla]
17:00:31 <Zakim> -Brad_Kemper
17:00:32 <Zakim> -[Microsoft]
17:00:34 <Zakim> -SteveZ
17:00:34 <fantasai> GRRRR
17:00:34 <Zakim> -hyatt
17:00:38 <Zakim> -glazou
17:00:39 <fantasai> we're missing formal resolutions on a couple issues
17:00:41 <dino> dino has left #css
17:00:43 <Zakim> -Bert
17:00:48 <Zakim> -cesar_acebal
17:00:51 <fantasai> The color space issue for example
17:00:55 <dbaron> fantasai, I'm not sure that we need formal resolutions on all of these... it's a pretty early draft.
17:01:06 <dbaron> fantasai, the color space one also wasn't on the agenda
17:01:20 <fantasai> we discussed it, if there was agreement it should be noted
17:01:38 <fantasai> esp since I don't think I minuted it correctly
17:02:02 <Zakim> -plinss
17:02:27 <dbaron> fantasai, well, what we agreed on was what the spec already says
17:02:28 <plinss> Are you referring to the discussion of how color values are animated? (in RGB space or HSL space?)
17:02:33 <fantasai> yes
17:02:43 <dbaron> fantasai, and given that no issue was raised about it and the spec is ok, I don't think we need a resolution
17:02:49 <fantasai> RESOLVED: transitions apply to all elements except pseudos other than :before/:after
17:03:08 <dbaron> I'd say "all elements and the :before and :after pseudo-elements"
17:03:21 <fantasai> ok, then can I get a summary? "we agree hsl is better" "we agree rgb is better" "neither one is better" "we dont' care"
17:03:24 <fantasai> etc.
17:03:57 <dbaron> Animations are component-wise in rgb() color space.
17:04:35 <fantasai> ok
17:04:39 <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
17:04:48 <dbaron> I think I raised that as an issue but it wasn't on today's agenda
17:05:21 <fantasai> so did I mistype dean's comments on that issue?
17:05:28 <alexmog> alexmog has joined #css
17:05:52 <dbaron> there was one line that I re-minuted right after you minuted it
17:06:01 <fantasai> yeah, got that
17:06:20 <hyatt> dbaron: i believe our implementation just animates each value individually
17:06:24 <hyatt> the r the g the b and the a
17:06:32 <dbaron> "<fantasai> dean: we didn't think it was necessary, hsl just usually gives better results" got it backwards
17:06:52 <fantasai> I'm referring to < fantasai> dean: Someone asked a question about animating colors through different color spaces
17:06:55 <fantasai> 16:40 < fantasai> dean: We did some experiments, and we all thought that it would be better to animate through hsl
17:06:58 <fantasai> 16:40 < fantasai> dean: when you animate through rgb you sometimes wind up with a sort of gray color
17:07:02 <Zakim> disconnecting the lone participant, fantasai, in Style_CSS FP()12:00PM
17:07:06 <Zakim> Style_CSS FP()12:00PM has ended
17:07:07 <Zakim> Attendees were +95089aaaa, +1.858.216.aabb, plinss, +1.281.419.aacc, hyatt, dbaron, +34.60.940.aadd, cesar_acebal, sylvaing, +1.408.588.aaee, Bert, +39.524.9.aaff, fantasai,
17:07:09 <Zakim> ... ChrisL, dino, +1.650.766.aagg, SteveZ, +95089aahh, glazou, arronei, alexmog, Brad_Kemper
17:07:09 <plinss> I would think animating each value independently would give a better result than pre-multiplying...
17:07:13 <hyatt> oh maybe dean changed our impl
17:07:22 <hyatt> i thought we just animated each value individually though
17:07:26 <dbaron> fantasai, and the one line in that that was wrong was the one I just said
17:07:37 <dbaron> hyatt, but then animating from transparent to a color would make it look black-ish at the beginning
17:08:06 <hyatt> sounds like this needs to be an issue?
17:08:18 <dbaron> hyatt, I think I sent a message about it, but it wasn't on today's agenda.
17:08:23 <hyatt> ah ok
17:08:27 <hyatt> maybe we can talk about it next week or something
17:08:28 <dbaron> but yeah, I think it should be an issue
17:08:40 <fantasai> dbaron, so my conclusion is "sometimes hsl is better and sometimes rgb is better but the spec says rgb and we aren't changing it for now"?
17:08:49 <dbaron> fantasai, no
17:08:51 <hyatt> my original (possibly naive) implementation just animated each value
17:09:01 <dbaron> fantasai, the conclusion was rgb is better
17:09:05 <hyatt> r, g, b, a separately
17:09:16 <dbaron> fantasai, when compared to hsl
17:09:21 <dbaron> fantasai, we're still discussing alpha
17:10:10 <fantasai> so according to my minutes dean originally said hsl was better, and then I missed why it was bad
17:10:22 <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
17:10:26 <dbaron> the alpha issue, that is
17:10:42 <hyatt> yeah we don't pre-multiply
17:10:44 <plinss> no, dean said they tried hsl first, thinking it would be better, but found that it wasn't
17:10:49 <hyatt> we just animate each component
17:10:53 <fantasai> plinss: thank you
17:10:53 <hyatt> each of the 4 components
17:10:53 <dbaron> fantasai, he said he originally thought it would be better, but then did some experiments, which showed that it led to bizarre things
17:11:03 <fantasai> plinss: that's what I needed
17:11:16 <plinss> you get transitions through the hue channel that give weird unrelated colors in the middle...
17:11:36 <dbaron> hyatt, let me write a testcase... I think nonpremultiplied will give bizarre results, though...
17:11:55 <plinss> when moving in saturation or lightness it does work better, but hue gets weird when moving through the 180 degree phase
17:12:58 <plinss> dbaron: I would guess that non-premultiplied would actually give better results, but willing to be proven wrong...
17:13:01 <dbaron> hyatt, though I guess the author can get what they want by specifying different forms of transparent
17:14:11 <fantasai> plinss, e.g. from blue to yellow, you transition through green?
17:14:58 <fantasai> http://en.wikipedia.org/wiki/HSL_and_HSV
17:15:40 <fantasai> I like HSL diagrams, they're pretty... You've got several options there, could transition aroudn the edges of the circle, or straight through the shortest path
17:15:48 <fantasai> but I'm not sure what calculations it would take
17:19:33 <plinss> yeah, you could go through green (which would make sense), or through red depending on which edge you go through (based on subtleties of end points) 
17:26:13 <plinss> Was there anything else you needed?
17:26:34 <fantasai> not immediately, can you check back a bit later maybe?
17:26:42 <fantasai> I'll either post the minutes, or I'll have questions
17:26:48 <plinss> sure
17:27:04 <fantasai> This was the hardest discussion to minute in a very long time I think
17:28:38 <fantasai> RRSAgent: make logs public
18:14:07 <sgalineau> sgalineau has joined #css
18:25:10 <sgalineau> fantasai, I think of transitions as really no different from any other property change wrt computed styles; just like start/end are the only DOM events you can handle in the current proposal, start and end values would be the only values you see through the DOM as well as the only values that can inherit. All transitions effectively do at this level is timing the value change. What happens in between is display-only. Conversely, if intermediate prop values d
18:28:05 <fantasai> sgalineau: your comment got cut off after intermediate prop
18:28:41 <sgalineau>  Conversely, if intermediate prop values do inherit then I'd expect the DOM to reflect that and I don't know that it's desirable for webdevs or implementors. Caveat: this means nested transitions would always run sequentially.
18:29:03 <fantasai> I'm not sure I understand that last part
18:29:13 <sgalineau> the caveat ?
18:29:34 <fantasai> yeah
18:29:50 <fantasai> I'm not really a transitions expert, though.
18:30:05 <sgalineau> if a child doesn't inherit until the parent's transition is complete then it won't start its own transition until then
18:30:07 <hyatt> we do let you get the current animated value in getComputedStyle
18:30:09 <sgalineau> same thing for its child etc
18:30:16 <fantasai> ah, right
18:30:19 <hyatt> so you can see what's going on with the animation in the DOM
18:30:24 <fantasai> I don't think that's wanted
18:30:27 <fantasai> er
18:30:28 <hyatt> i am sure it's wanted
18:30:32 <sgalineau> so it'd all be stepwise
18:30:35 <fantasai> s/I/sgalineau, I/
18:30:39 <hyatt> ah ok :)
18:32:56 <sgalineau> well they can't run all at the same time *and* inherit. that's what you're doing now and it keeps resetting the nested transitions over and over until the parent is done right ? so effectively, you get some weird sequential thing
18:34:01 <sgalineau> so you either 'suspend' inheritance or you hide the intermediate stages imo
18:35:04 <hyatt> you don't suspend inheritance... you just don't start a transition based off an inherited value.
18:35:47 <hyatt> off an inherited animating value
18:36:31 <hyatt> that was the proposed resolution at least
18:36:33 <sgalineau> ok. but once the transition completes, then the end value inherits right ? aren't we getting to the same outcome ?
18:36:45 <hyatt> yeah but that won't start a transition
18:37:03 <hyatt> basically include the start/end values in the special casing
18:37:23 <fantasai> that's much clearer now
18:37:29 <sgalineau> oh, ok. that's the obvious bit i missed. so if the property is changed by inheritance then no transition ?
18:38:30 <sgalineau> or no transition if the inherited value was set by a transition ?
18:39:04 <sgalineau> (this stuff must be fun to code...jealous...)
18:40:01 <fantasai> Minutes sent
18:40:19 <fantasai> hyatt: take a look, and if I've missed anything please send a note in response
18:40:28 <fantasai> s
18:41:04 <hyatt> ok
18:41:08 <fantasai> thanks :)
18:41:14 <sgalineau> re-reading, it sounds like the latter i.e. if a property is updated by a transition, it will not trigger transitions for the elements that inherit its animated value(s)
18:41:14 <hyatt> sgalineau: yeah that was the suggested resolution
18:41:20 <hyatt> although that is going to be hell to implement
18:41:20 <sgalineau> ok
18:41:33 <hyatt> we really have no way of knowing that in webkit
18:42:01 <sgalineau> well, how about my suggestion ?
18:43:10 <sgalineau> end value may start transition on descendants ?
18:43:13 <Zakim> Zakim has left #CSS
18:44:01 <sgalineau> as you hover on something, you may want a short sequence of transitions to happen. nesting them seems natural.
18:44:47 <fantasai> Bert: any progress on publishing flexbox or css3-images?
18:45:28 <fantasai> ChrisL: any ETA on the border-image box-shadow masking text?
18:53:13 <MoZ> MoZ has joined #css
18:56:10 <hyatt> yeah interesting
18:56:43 <hyatt> that does not seem correct to me
19:18:12 <MoZ> MoZ has joined #css
19:21:45 <dbaron> dbaron has joined #css
19:26:31 <sgalineau> sgalineau has joined #css
19:41:22 <plinss> actually, WebKit's behavior seems more logical to me, how can something that's transparent cast an opaque shadow?
19:42:08 <hyatt> people don't really connect the two
19:42:20 <hyatt> we've already had a bug filed for example about fully transparent text not casting a shadow
19:42:30 <hyatt> that's one trick people want to be able to do that works in firefox
19:49:38 <plinss> I get that there are effects that some people might want that are precluded in WebKit's implementation, it's just one of those things that doesn't work like that in the real world. The shadow is, after all, being cast by the text. Were this an actual shadow, being cast by real light, the opacity of the text would most definitely affect the shadow...
19:51:04 <hyatt> yeah, CSS has kind of consistently come down on the side of these being more like decorative effects though than actual shadows
19:51:10 <hyatt> especially with box-shadow
19:51:35 <plinss> If the designer really wanted the shadow more opaque, they could theoretically specify an opacity for it greater than 1... 
19:51:48 <hyatt> opacity is clamped to 0,1
19:52:06 <plinss> I know, that's why I said "theoretically".
19:52:12 <hyatt> also i believe this was resolved already (that fully transparent text still cast a shadow)
19:52:16 <hyatt> seems like this issue has come up already
19:52:26 <hyatt> would have to dig through history to see though
19:52:45 <hyatt> but i seem to recall mozilla bringing this up as an issue
19:52:50 <hyatt> when they found out we didn't cast a shadow for transparent text
19:53:06 <hyatt> and authors keep filing bugs on us about that one
19:53:08 <hyatt> so they expect it to work
19:53:11 <plinss> understood, I'm not proposing changing it, just pointing out that it makes more sense to me the other way, so i presume there are others that will see it that way too...
19:53:16 <hyatt> yeah
19:54:15 <plinss> BTW, I'm glad you made the call today. I hope you can join us on a more regular basis...
19:55:29 <hyatt> yeah was good to hammer out some transitions stuff
20:20:03 <sgalineau> sgalineau has joined #css
20:37:09 <hyatt> i changed webkit btw to not clip border-image to border-radius
20:37:12 <hyatt> and that shipped in safari 4
20:39:17 <fantasai> nice
20:40:44 <fantasai> did you implement the box-shadow masking thing you and roc were talking about?
20:40:53 <hyatt> nope
20:41:05 <hyatt> would be cool to try that
20:41:19 <hyatt> right now i'm fixing our embarrassing display:run-in bug
20:41:23 <fantasai> heh
20:41:24 <hyatt> that made bz go "you suck"
20:41:56 <fantasai> if you get to working on the masking thing before chrisl writes his spec text let me know, maybe I'll just interrogate you about it instead :)
20:42:43 <fantasai> it's the last thing we need to go to last call
20:46:07 <hyatt> oh really
20:46:29 <hyatt> i can't remember what i suggested
20:47:47 <hyatt> so much work to do to bring webkit up to the latest version of that spec
20:52:07 <fantasai> then maybe we'll hit CR so you won't have to implement -webkit2-border-image :)
20:54:13 <hyatt> well at LC i think i'm willing to implement non-prefixed
20:54:26 <hyatt> unless you think that's dangerous
20:54:39 <fantasai> I think it really depends on the LC
20:55:14 <fantasai> in this case, the last WD was effectively an LC
20:55:31 <hyatt> it feels very close to "done" to me
20:55:36 <fantasai> yeah
20:56:42 <fantasai> we could have published the last as an LC, but I wanted the formal LC period to be smoother so we published as WD to elicit a round of comments before LC
20:57:51 <hyatt> btw http://www.satine.org/archives/2009/07/11/snow-stack-is-here/ not sure if people had seen that yet
20:59:26 <fantasai> no
20:59:42 <fantasai> although I shouldn't play that on this comp; flash crashes on this system every time :/
21:00:01 <hyatt> http://img269.yfrog.com/img269/3224/benchmark.jpg <-- the best part lol
21:08:50 <alexmog> alexmog has joined #css
22:03:19 <MoZ> MoZ has joined #css
22:19:18 <myakura> myakura has joined #css
22:33:35 <MoZ> MoZ has joined #css
23:14:48 <sgalineau> sgalineau has joined #css
23:21:29 <MikeSmith> MikeSmith has joined #css
23:25:19 <dbaron> dbaron has joined #css