Options:
- # Session Start: Thu Dec 19 00:00:00 2013
- # Session Ident: #css
- # [00:03] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
- # [00:06] * Parts: jcraig (~jcraig@public.cloak) (jcraig)
- # [00:06] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
- # [00:06] * Joins: rhauck (~Adium@public.cloak)
- # [00:06] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
- # [00:08] * Joins: rhauck (~Adium@public.cloak)
- # [00:20] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
- # [00:49] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
- # [00:50] * Joins: dwim (~dwim@public.cloak)
- # [01:32] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
- # [01:33] <astearns> fantasai: is you're going for LC for backgrounds, you may want to address http://lists.w3.org/Archives/Public/www-style/2013Nov/0429.html before it becomes a LC comment
- # [01:34] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
- # [02:20] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
- # [02:29] * Quits: jet (~junglecode@public.cloak) (jet)
- # [02:44] * Joins: zcorpan (~zcorpan@public.cloak)
- # [02:51] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
- # [02:58] * Joins: lmcliste_ (~lmclister@public.cloak)
- # [03:01] * Joins: rhauck (~Adium@public.cloak)
- # [03:10] * Joins: jet (~junglecode@public.cloak)
- # [03:16] * Quits: jet (~junglecode@public.cloak) (jet)
- # [03:34] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
- # [03:34] * Joins: dwim (~dwim@public.cloak)
- # [03:40] * Quits: plh (plehegar@public.cloak) (Ping timeout: 180 seconds)
- # [03:40] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
- # [04:35] * Joins: plh (plehegar@public.cloak)
- # [05:23] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
- # [05:23] * Joins: dwim (~dwim@public.cloak)
- # [05:26] * Joins: jet (~junglecode@public.cloak)
- # [05:32] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
- # [05:32] * Joins: dwim (~dwim@public.cloak)
- # [05:36] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
- # [05:36] * Joins: dwim (~dwim@public.cloak)
- # [05:36] * Quits: plh (plehegar@public.cloak) (Ping timeout: 180 seconds)
- # [06:02] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
- # [06:06] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
- # [06:06] * Joins: dwim (~dwim@public.cloak)
- # [06:18] * Quits: jet (~junglecode@public.cloak) (jet)
- # [06:46] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
- # [06:46] * Joins: dwim (~dwim@public.cloak)
- # [07:01] * Joins: jet (~junglecode@public.cloak)
- # [07:15] * Quits: jet (~junglecode@public.cloak) (jet)
- # [07:33] * Joins: teoli (~teoli@public.cloak)
- # [07:47] * Joins: nvdbleek (~nvdbleek@public.cloak)
- # [08:03] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
- # [08:04] * Joins: dwim (~dwim@public.cloak)
- # [08:09] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
- # [08:09] * Joins: dwim (~dwim@public.cloak)
- # [08:28] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
- # [08:31] * Joins: zcorpan (~zcorpan@public.cloak)
- # [08:39] * Joins: nvdbleek (~nvdbleek@public.cloak)
- # [09:01] * Joins: jet (~junglecode@public.cloak)
- # [09:09] * Joins: Ms2ger (~Ms2ger@public.cloak)
- # [09:11] * Quits: jet (~junglecode@public.cloak) (jet)
- # [09:35] * Joins: jet (~junglecode@public.cloak)
- # [09:44] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
- # [09:45] * Quits: jet (~junglecode@public.cloak) (jet)
- # [09:50] * Joins: nvdbleek (~nvdbleek@public.cloak)
- # [09:55] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
- # [09:56] * Joins: dwim (~dwim@public.cloak)
- # [10:03] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
- # [10:09] * Joins: nvdbleek (~nvdbleek@public.cloak)
- # [10:10] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
- # [10:12] * Joins: teoli (~teoli@public.cloak)
- # [10:12] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
- # [10:42] * Joins: teoli (~teoli@public.cloak)
- # [10:54] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 180 seconds)
- # [11:12] * Joins: antonp (~Thunderbird@public.cloak)
- # [11:56] * Joins: plh (plehegar@public.cloak)
- # [12:00] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
- # [12:10] * Joins: darktears (~darktears@public.cloak)
- # [12:18] * Joins: nvdbleek (~nvdbleek@public.cloak)
- # [12:56] * Quits: plh (plehegar@public.cloak) (Ping timeout: 180 seconds)
- # [13:06] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
- # [13:09] * Joins: nvdbleek (~nvdbleek@public.cloak)
- # [13:58] * Joins: plh (plehegar@public.cloak)
- # [14:12] * Joins: michou_ (~sid17024@public.cloak)
- # [14:12] * Joins: teoli (~teoli@public.cloak)
- # [14:13] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
- # [14:20] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 180 seconds)
- # [14:21] * Joins: nvdbleek (~nvdbleek@public.cloak)
- # [14:38] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
- # [14:50] * Joins: teoli (~teoli@public.cloak)
- # [14:51] * Joins: teoli_ (~teoli@public.cloak)
- # [14:51] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
- # [15:00] * Quits: shepazu (schepers@public.cloak)
- # [15:05] * Quits: plh (plehegar@public.cloak) ("Leaving")
- # [15:06] * Joins: shepazu (schepers@public.cloak)
- # [15:06] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
- # [15:12] * Joins: plh (plehegar@public.cloak)
- # [15:37] * Joins: zcorpan (~zcorpan@public.cloak)
- # [15:38] * Joins: nvdbleek (~nvdbleek@public.cloak)
- # [15:38] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
- # [15:38] * Joins: darktears (~darktears@public.cloak)
- # [15:44] * Joins: lmcliste_ (~lmclister@public.cloak)
- # [15:47] * Joins: jet (~junglecode@public.cloak)
- # [15:48] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
- # [15:50] * Quits: jet (~junglecode@public.cloak) (jet)
- # [16:00] * Joins: glenn (~gadams@public.cloak)
- # [17:11] * Quits: teoli_ (~teoli@public.cloak) (Client closed connection)
- # [17:20] * Joins: teoli (~teoli@public.cloak)
- # [17:20] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
- # [17:47] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
- # [17:53] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
- # [18:20] * Joins: rhauck (~Adium@public.cloak)
- # [20:34] * RRSAgent excuses himself; his presence no longer seems to be needed
- # [20:34] * Parts: RRSAgent (rrsagent@public.cloak) (RRSAgent)
- # [21:04] * Joins: rhauck1 (~Adium@public.cloak)
- # [21:09] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
- # [21:35] * Joins: zcorpan (~zcorpan@public.cloak)
- # [22:24] * Quits: rhauck1 (~Adium@public.cloak) ("Leaving.")
- # [22:24] * Joins: rhauck (~Adium@public.cloak)
- # [22:45] * Joins: sgalineau (~sgalineau@public.cloak)
- # [22:50] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
- # [22:54] * Joins: rhauck (~Adium@public.cloak)
- # [23:12] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
- # [23:12] <astearns> TabAtkins: in your reply to me, you said that we should avoid another value stage for <position> values, but then
- # [23:12] <astearns> in your reply to fantasai, you agreed that we should specify the serialization of getComputedStyle should not serialize the computed value
- # [23:12] <astearns> that seems like another stage to me
- # [23:13] <TabAtkins> astearns: Not quite. What she's saying (and I'm agreeing with) is that "serialization of the computed value" is a different concept from the computed value itself; the latter can be much more abstract.
- # [23:13] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
- # [23:13] * Joins: rhauck (~Adium@public.cloak)
- # [23:13] <TabAtkins> The serialization has to be something that can be fed back in as a declared value.
- # [23:13] <TabAtkins> But in many cases a computed value is something weird internally that doesnt' directly map to something you'd write.
- # [23:13] <astearns> when there's a mismatch like this, where does it get specified?
- # [23:14] <TabAtkins> Ideally, in the spec.
- # [23:14] <astearns> OK, then that's still left to be done for css-backgrounds
- # [23:14] <TabAtkins> In practice, often nowhere, because we're terrible about specifying serialization.
- # [23:14] <TabAtkins> Yeah.
- # [23:16] <astearns> TabAtkins: any instances of good specification of serialization you could point me to? I'd like to do it right for <basic-shape>s
- # [23:17] <TabAtkins> Hm, I had a bunch of serialization in Images, but instead just deferred it all to CSSOM with some clarifications.
- # [23:17] <TabAtkins> Which is honestly a cop-out, I think.
- # [23:18] <TabAtkins> But here's what I have, at least: http://dev.w3.org/csswg/css-images/#serialization
- # [23:19] <astearns> thanks, that's helpful
- # [23:19] <TabAtkins> We still haven't really worked out a good cross-spec way to talk about all of this, with a minimum of duplicated text. :/
- # [23:19] <astearns> another unanswered question from the list - should computed values generally fill in implicit values?
- # [23:20] <astearns> some do, some don't
- # [23:20] <TabAtkins> Depends on how you want to handle it. I generally do, I think.
- # [23:20] * Quits: sgalineau (~sgalineau@public.cloak) (Ping timeout: 180 seconds)
- # [23:20] <TabAtkins> "Computed value" is just a spec fiction to let you talk about the values, so do what's most convenient.
- # [23:20] <astearns> and it appears that the ones that do, do so because someone noticed they had to in order to make it animatable :)
- # [23:22] <TabAtkins> Heh, possibly.
- # [23:23] <TabAtkins> For example, I could describe a <position> computed value as a set of all the possible offsets, with a flag if they were actually set by a style.
- # [23:23] <TabAtkins> So you'd have top, left, block-start, inline-start, page-top, and page-outside offsets.
- # [23:24] <TabAtkins> Or just as a set of the offsets that were actually set.
- # [23:24] <TabAtkins> Whatever seems most convenient.
- # [23:26] <astearns> but then it's more difficult to serialize the computed value for getComputedStyle in such a way that it can be fed back in as a declared value
- # [23:27] <TabAtkins> Which one are you referring to?
- # [23:29] <astearns> not referring to any value in particular. It just seems that there's a tension between computed value as an animation conveyance versus computed value as an input for serialization for getComputedStyle
- # [23:29] <TabAtkins> When necessary, throw serialization under the bus and just specify it explicitly.
- # [23:30] <astearns> right, but at that point you're really talking about yet another value stage :)
- # [23:30] <TabAtkins> Nah, you're just converting the computed value back into a declared value.
- # [23:30] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
- # [23:30] <TabAtkins> (Modulo the fact that it's a string rather than parsed value, whatever.)
- # [23:31] <TabAtkins> Always consider serialization as just a way to turn something back to a declared value with equivalent effects.
- # [23:36] <astearns> It would have been much easier to say that <basic-shape>s aren't animatable
- # [23:36] * astearns makes a note to not let krit talk me into so many traps
- # [23:36] <TabAtkins> That's just a copout, though.
- # [23:37] <astearns> I agree. Just grumping
- # [23:37] <TabAtkins> Heh. ^_^
- # [23:37] <krit> astearns: hm, my later requests should have made animation easier :P
- # [23:37] * krit doesn’t want to read the whole discussion though
- # [23:37] <astearns> krit: yes, but those are copouts too
- # [23:39] <krit> astearns: just say calc(<basic-shape1> <basic-shape2>) the implementation shall resolve at rendering time
- # [23:39] <krit> astearns: and magic will happen
- # [23:39] <astearns> that definitely sounds like a trap
- # [23:40] <krit> :D
- # [23:40] <TabAtkins> calc()ing is definitely a trap. ^_^
- # [23:40] <TabAtkins> Although...
- # [23:40] <TabAtkins> It's basically equivalent to the interpolate() idea, just cast slightly more mathy.
- # [23:40] <TabAtkins> instead of interpolate(val1 20%, val2 50%, val3) you have calc(val1 * .2 + val2 * .5 + val3 * .3)
- # [23:41] <TabAtkins> With some additional magic about what happens when you under/overshoot 100%.
- # [23:41] <astearns> TabAtkins: re: your last www-style email, grammar can avoid mixing origins within a declaration but doesn't avoid the problem of interpolating from physical to logical in two separate declarations
- # [23:41] <TabAtkins> astearns: Oh, that's your confusion? I keep saying that the origins have to match to interpolate.
- # [23:41] <TabAtkins> You simply can't go from "bg-pos: left 50px;" to "bg-pos: inline-start 100px;".
- # [23:42] <TabAtkins> At least, not in a smooth transition.
- # [23:42] <astearns> how do you know which is which?
- # [23:42] <TabAtkins> What do you mean?
- # [23:42] <astearns> the computed value of the first has an implicit 'left'
- # [23:42] <astearns> what do you add to the right to carry the 'logical' meaning?
- # [23:43] <TabAtkins> I still don't get it. The fact that you're using an "inline-start" offset means it's a logical offset.
- # [23:44] <astearns> bg-pos: left 50px under the current spec text has a computed value that's something like (0% + 50px), (0% + 0px)
- # [23:44] <astearns> no left or top in there
- # [23:45] <astearns> (or I guess the vertical dimension would actually be 50%)
- # [23:45] <TabAtkins> Yes, because at the moment we don't have to distinguish. The offsets are always physical.
- # [23:45] <astearns> so when you use inline-start, you need to add something to the computed value to disambiguate that value from the physical one
- # [23:45] <TabAtkins> When we do need to distinguish, the computed value will be clearer about where each of the offsets is from.
- # [23:45] <TabAtkins> Yes.
- # [23:46] <TabAtkins> Right now we're just implicitly tagging the two offsets with top/left.
- # [23:46] <astearns> that's what I'm asking. what's the future plan
- # [23:46] <TabAtkins> Okay, so I'm confused because I've explained the future plan at least twice in email. ^_^
- # [23:47] <astearns> I thought the future plan you described kept left, top in the current computed value
- # [23:47] <TabAtkins> "If we also allow logicals, then it would be *either* a pair of
- # [23:47] <TabAtkins> physical offsets or a pair of logical offsets (or a pair of page
- # [23:47] <TabAtkins> offsets, etc). Then animating only works if you have the same type of
- # [23:47] <TabAtkins> offsets."
- # [23:47] <TabAtkins> It might! Depends on if we need to allow mixing offset types (and then resolving which to use).
- # [23:47] <astearns> I do understand the animation plan. I was just asking about the computed value
- # [23:48] <TabAtkins> If we dont' need to allow mixing, then the computed value is always a pair of offsets, and we know what the offsets are. They're either top/left, or inline-start/block-start, or page-top/page-outside, or whatever.
- # [23:48] <TabAtkins> The plans are the same.
- # [23:48] <TabAtkins> They are one plan.
- # [23:48] <TabAtkins> (It's very clear that we're miscommunicating somewhere and each assuming things the other doesn't realize.)
- # [23:49] <astearns> I agree :)
- # [23:50] <astearns> so, in a strict future, you would not be able to mix origin types in an @keyframe? I look at the from and to as two separate declarations that might have different origin usage
- # [23:51] <astearns> do you evaluate the @keyframe as a whole?
- # [23:52] <astearns> or do you need a computed value that will carry the origin type information so that you can tell whether it's OK to animate between two separate values?
- # [23:52] <TabAtkins> Wait, I'm confused. How is this situation any different than a property that can't animate between px and a keyword? We don't do anything special with the keyframe, it just flips instead of animating.
- # [23:53] <astearns> sure, but you can tell whether the animation flips or interpolates just from the computed values, correct?
- # [23:54] <TabAtkins> Yeah.
- # [23:54] <TabAtkins> (That's always true, by definition.)
- # [23:54] <TabAtkins> (Since you animate, or don't, over computed values.)
- # [23:54] <astearns> I'm trying to see how you'd determine whether two <position>s can interpolate using information extracted only from their computed values
- # [23:55] <astearns> so it seems to me that the origin type needs to be included in the computed value
- # [23:55] <astearns> (if we add logical origins)
- # [23:55] <TabAtkins> What I'm confused about is why this isn't plainly obvious, since you need to know the origin type just to *have a value that makes any sense at all*.
- # [23:55] <TabAtkins> If you just have a naked pair of numbers with no origin information, you have no clue what axises they're along.
- # [23:56] <astearns> that's what's defined now
- # [23:56] <astearns> since we can assume physical origins
- # [23:56] <TabAtkins> Yes.
- # [23:56] <TabAtkins> And it wont' be enough once we move past that.
- # [23:56] <TabAtkins> So we'll have to make sure the value specifies it.
- # [23:57] <TabAtkins> That has nothing to do with animations, though, it's just part of "adding the ability to specify logical offsets".
- # [23:57] <astearns> so my question has been, how will we do that?
- # [23:57] <TabAtkins> In one of the ways I've talked about already.
- # Session Close: Fri Dec 20 00:00:01 2013
The end :)