/irc-logs / w3c / #css / 2009-07-15 / end

Options:

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

The end :)