IRC log of CSS on 2010-01-20

Timestamps are in UTC.

16:29:52 [RRSAgent]: RRSAgent has joined #CSS
16:29:52 [RRSAgent]: logging to http://www.w3.org/2010/01/20-CSS-irc
16:29:58 [glazou]: Zakim, this will be Style
16:29:58 [Zakim]: ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 31 minutes
16:48:19 [oyvind]: oyvind has joined #css
16:49:33 [glazou]: RRSAgent, make logs public
16:52:28 [dbaron]: dbaron has joined #css
16:57:39 [sylvaing]: sylvaing has joined #css
16:58:06 [Zakim]: Style_CSS FP()12:00PM has now started
16:58:13 [Zakim]: + +1.206.324.aaaa
16:58:21 [sylvaing]: Zakim, aaaa is sylvaing
16:58:21 [Zakim]: +sylvaing; got it
16:58:58 [Zakim]: + +1.617.650.aabb
16:59:25 [smfr]: smfr has joined #css
16:59:36 [Zakim]: +glazou
17:00:20 [Zakim]: + +1.408.636.aacc
17:00:31 [smfr]: Zakim, aacc is smfr
17:00:40 [Zakim]: +smfr; got it
17:00:41 [bradk]: bradk has joined #css
17:00:56 [Zakim]: +[Mozilla]
17:00:59 [dbaron]: Zakim, [Mozilla] has David_Baron
17:00:59 [Zakim]: +David_Baron; got it
17:01:03 [Zakim]: + +1.650.275.aadd
17:01:10 [Zakim]: + +1.858.216.aaee
17:01:14 [plinss]: plinss has joined #css
17:01:17 [Zakim]: + +1.281.712.aaff
17:01:31 [dethbakin]: dethbakin has joined #css
17:01:47 [plinss]: zakim, +1.858.216 is me
17:01:47 [Zakim]: +plinss; got it
17:01:53 [bradk]: Zakim, 1.650.275.aadd is me
17:01:53 [Zakim]: sorry, bradk, I do not recognize a party named '1.650.275.aadd'
17:02:05 [glazou]: Zakim, aadd is bradk
17:02:05 [Zakim]: +bradk; got it
17:02:25 [Zakim]: +SteveZ
17:02:37 [TabAtkins]: Zakim, aaff is me.
17:02:37 [Zakim]: +TabAtkins; got it
17:03:32 [Zakim]: +fantasai
17:03:39 [smfr]: wow
17:03:41 [smfr]: is someone on a train?
17:04:55 [Zakim]: +Hakon_Lie
17:05:04 [Zakim]: +Bert
17:05:14 [howcome]: howcome has joined #css
17:05:24 [TabAtkins]: scribenick: TabAtkins
17:05:36 [krijnh]: krijnh has joined #css
17:06:00 [smfr]: Zakim, aabb is dethbakin
17:06:00 [Zakim]: +dethbakin; got it
17:06:11 [TabAtkins]: glazou: extra agenda items?
17:06:15 [TabAtkins]: (silence)
17:06:21 [TabAtkins]: glazou: Action items from last week!
17:06:31 [TabAtkins]: glazou: First was on me to respond that Tab's response was official. Done.
17:07:05 [TabAtkins]: glazou: Second action was on Tab to summarize pt/px.
17:07:25 [TabAtkins]: TabAtkins: Did so last night; David Singer's was mostly correct. I just added implementation experience.
17:07:35 [TabAtkins]: glazou: Third was on Simon for dbaron's rules?
17:07:39 [glazou]: yes
17:07:43 [TabAtkins]: smfr: Done.
17:08:01 [TabAtkins]: glazou: Bert, review style-attr issues.
17:08:06 [Zakim]: +[Microsoft]
17:08:36 [TabAtkins]: glazou: Any further action on any of the items? Tab?
17:08:53 [TabAtkins]: TabAtkins: Everybody agrees, so all we neeed to do is think on Brad's suggestion and then integrate into a spec.
17:09:04 [arronei]: zakim, [Microsoft] is me
17:09:04 [Zakim]: +arronei; got it
17:09:18 [TabAtkins]: smfr: Everyone needs to read mine and see if they agree. We also need to see if we want to allow scinot in numbers, which will affect the grammar.
17:09:35 [TabAtkins]: glazou: Second item - test suite!
17:09:55 [TabAtkins]: glazou: We were expecting some things last week.
17:10:28 [TabAtkins]: glazou: fantasai said that Boris still had so solve some issues and contribute something, and by the end of the week she should be ready to be published to the test suite.
17:10:42 [TabAtkins]: fantasai: Yup, still gathering them right now. Mozilla also gathered a bunch of tests.
17:10:47 [TabAtkins]: glazou: After the 15th deadline?
17:10:54 [TabAtkins]: fantasai: Dont' remember exactly, but somewhere around then.
17:11:01 [TabAtkins]: dbaron: I submitted them on the 14th.
17:11:22 [TabAtkins]: glazou: We need to stop accepting tests. So let's gather tests, publish it, and show w3c that we're moving.
17:11:33 [TabAtkins]: dbaron: Boris submitted his run-in tests late.
17:11:51 [TabAtkins]: dbaron: Did *not* submit them late.
17:12:03 [smfr]: Here is my suggested amendment to CSS Numbers: http://lists.w3.org/Archives/Public/www-style/2010Jan/0319.html
17:12:24 [TabAtkins]: glazou: css3 values issues. There's a bunch.
17:12:27 [glazou]: http://lists.w3.org/Archives/Public/www-style/2009Dec/0234.html
17:13:01 [TabAtkins]: dbaron: I don't think this needs much discussion; I think it's just an error that we didn't allow whitespace in calc just inside the parens.
17:13:22 [TabAtkins]: glazou: Resolved - add spaces.
17:13:30 [glazou]: http://lists.w3.org/Archives/Public/www-style/2009Dec/0236.html
17:13:56 [TabAtkins]: dbaron: Some properties, like width, have negative values as parse errors.
17:14:06 [TabAtkins]: dbaron: In calc you can't always determine if a result is negative at parse time.
17:14:21 [TabAtkins]: dbaron: 1) Does the restriction on the individual values change what's allowed for each value inside calc?
17:14:31 [TabAtkins]: dbaron: 2) What do you do when the calc gives a negative result?
17:15:01 [TabAtkins]: dbaron: When you're parsing a calc, you're looking for individual values that are acceptable for the value. If it accepts length, you look for length.
17:15:26 [TabAtkins]: dbaron: But we shouldn't disallow negative values *inside* the calc, so width: calc(50% - 2px); should still be valid, even though -2px isn't valid.
17:15:40 [TabAtkins]: dbaron: Second, what to do when the calc gives a value outside the range, clamp it to the range.
17:15:49 [TabAtkins]: dbaron: So for width, a negative value would become 0.
17:16:13 [TabAtkins]: howcome: That would make the behavior different from normal behavior. width: -2px; is just ignored, right?
17:16:16 [TabAtkins]: dbaron: Yes.
17:16:23 [TabAtkins]: howcome: You're not proposing to change the non-calc case?
17:16:56 [TabAtkins]: dbaron: No.
17:17:08 [TabAtkins]: howcome: Is there a way to keep it ignoring?
17:17:19 [TabAtkins]: TabAtkins: I think the clamping behavior is virtually *always* the expected behavior.
17:17:35 [TabAtkins]: dbaron: It also makes it more complicated to fail it rather than clamp it.
17:17:52 [TabAtkins]: howcome: Is there any way to make the clamping the default behavior, so width:-2px; is the same as width:0;?
17:18:00 [TabAtkins]: dbaron: I don't think that's web-compatible at this point.
17:18:13 [TabAtkins]: glazou: You said it's more complicated to fail rather than clamp.
17:18:33 [TabAtkins]: glazou: But is it really? Clamping requires knowledge of the property's range.
17:18:49 [TabAtkins]: dbaron: You'd need to carry around extra cascade information, since you might not know if it shoudl fail until after layout.
17:19:10 [TabAtkins]: szilles: Is it obvious there's a clamp value that works for everything?
17:19:16 [TabAtkins]: dbaron: I beleive in current css there is.
17:19:35 [TabAtkins]: dbaron: We don't have any float-valued properties that accept only positive values. Integer values, yes, but not floats.
17:20:08 [TabAtkins]: smfr: Does opacity affect negative values?
17:20:27 [TabAtkins]: smfr: Isn't that a float value that is restricted to positive values?
17:20:33 [TabAtkins]: dbaron: Nah, it accepts 0
17:20:56 [TabAtkins]: szilles: Somewhere that assumption should be documented, just so we don't accidentally create a float-valued property that only accepts positive values.
17:21:03 [TabAtkins]: szilles: Probably in thee Values spec.
17:21:17 [TabAtkins]: glazou: Resolved and accepted.
17:21:25 [glazou]: http://lists.w3.org/Archives/Public/www-style/2009Dec/0237.html
17:21:46 [TabAtkins]: dbaron: Whole bunch of followups, and I still need to reply to the last one.
17:21:57 [glazou]: http://lists.w3.org/Archives/Public/www-style/2009Dec/0238.html
17:22:02 [TabAtkins]: dbaron: I can give a full description, but I'd like to defer it until I write up what I'm trying to implement.
17:22:05 [TabAtkins]: glazou: Okay, deferred.
17:22:13 [TabAtkins]: dbaron: I think we agreed in the past to add min and max to calc.
17:22:20 [TabAtkins]: dbaron: This is a proposal for how to do that in the grammar.
17:22:47 [TabAtkins]: dbaron: I don't know that there's much to discuss, as long as other people agree with my memory that we should add min/max.
17:22:54 [TabAtkins]: howcome: Yeah, it's in the minutes.
17:23:12 [TabAtkins]: howcome: Are we adding any circular dependencies that need to be resolved somehow?
17:23:27 [TabAtkins]: dbaron: I'm not seeing how. It's just min/max of values. Say, "larger of 3em or 20px".
17:23:28 [fantasai]: min & max added to calc: http://www.w3.org/blog/CSS/2009/07/30/resolutions_73
17:23:36 [TabAtkins]: howcome: So min/max takes comma separated values?
17:23:38 [TabAtkins]: dbaron: yes.
17:23:47 [TabAtkins]: szilles: What about max(50%)?
17:23:57 [TabAtkins]: dbaron: Yes, frex, max(50%,200px).
17:24:08 [TabAtkins]: dbaron: If that's a problem, it's a problem with % to begin with.
17:24:36 [TabAtkins]: bert: It doesn't look like the grammar disallows going over numbers, frex, max(1,2). Is that intentional?
17:24:48 [TabAtkins]: dbaron: Intentional, but only becuase I didn't see much reason for it. If people want it for symmetry, that's fine.
17:25:03 [TabAtkins]: bert: If you divide 2em by 2em, you'll end up with the number 1.
17:25:17 [TabAtkins]: dbaron: That ties into the previous issue, that I wanted to skip over for now.
17:25:37 [TabAtkins]: bert: You're saying you can only divide by number, not units?
17:25:45 [TabAtkins]: dbaron: Not quite what it actually says, but I think what it meant to say.
17:26:03 [TabAtkins]: szilles: Is there a usage of min/max to guarantee that you end up with an integer?
17:26:22 [TabAtkins]: szilles: floor/ceiling, that is, in the number case.
17:26:43 [TabAtkins]: dbaron: floor and ceiling with lengths are more complicated, as you have to figure out what unit it should be relative to.
17:27:05 [TabAtkins]: dbaron: In the grammer I'd like to end up with, the result of a division would always be a lenght, not a number.
17:27:55 [TabAtkins]: glazou: I have a case. Frex, if you want to have the full width, 100%, divided into columns of 200px, you could do calc(100%/200px) and would get a column-count value.
17:28:07 [TabAtkins]: dbaron: What's hard about that is figuring out what to do with division by 0.
17:28:18 [TabAtkins]: dbaron: The spec currently says that division by zero in calc is a parse error.
17:28:26 [TabAtkins]: dbaron: Which is fine as long as you only allow division by number.
17:28:42 [TabAtkins]: dbaron: But if you allow division by values, you have to be able to compute all values at parse time, which isn't possible.
17:29:09 [TabAtkins]: dbaron: Preventing division by values prevents that case. The grammar currently says that, but I"m not ceretain if that was the intention.
17:29:14 [TabAtkins]: bert: I recall that was the intention.
17:29:34 [TabAtkins]: szilles: You want a parse error so you can do fallback, right?
17:29:36 [TabAtkins]: dbaron: yes.
17:30:02 [TabAtkins]: dbaron: I can implement the division by zero case, I just don't know what I should do with it.
17:30:15 [TabAtkins]: plinss: Use animation/transforms and do a swirling black hole.
17:30:32 [TabAtkins]: szilles: Make the entire screen blue. It's well established.
17:30:48 [TabAtkins]: glazou: We'll keep that in mind. Let's move on with David's proposal.
17:30:57 [TabAtkins]: glazou: Objections to min/max proposal?
17:31:04 [Bert]: (Before we decided to add min() and max(), the calc() was a fancy notation for a 4-tuple: a px + b em + c cm + d %. The a b c d could be calculated at parse time.)
17:31:11 [TabAtkins]: szilles: If we allow division by values, does that affect min/max?
17:31:23 [TabAtkins]: dbaron: If we allow it, there's more reason to allow min/max on numbers, rathere than just units.
17:31:31 [TabAtkins]: dbaron: It's a syntax thing.
17:31:46 [TabAtkins]: dbaron: But in the next issue, I think we need to rework the whole grammar anyway.
17:31:53 [Zakim]: -fantasai
17:32:13 [TabAtkins]: dbaron: It's just details, but I don't think it's worth discussing the details of the productions too much given the other issue we're skipping right now.
17:32:32 [TabAtkins]: szilles: Why do you require two expressions in min/max?
17:32:57 [TabAtkins]: dbaron: I don't care which way, whether we do 2-or-more or 1-or-more.
17:33:28 [TabAtkins]: TabAtkins: I say 1-or-more. It makes sense and is simple.
17:33:33 [TabAtkins]: several: agree
17:33:38 [TabAtkins]: glazou: Resolved, one or more.
17:33:45 [dbaron]: (Bert also suggested it should either be 1-or-more or exactly 2)
17:33:49 [dbaron]: (for minutes)
17:33:49 [glazou]: http://lists.w3.org/Archives/Public/www-style/2009Dec/0239.html
17:34:32 [TabAtkins]: dbaron: There are a bunch of examples in the spec of calc using both lengths and %. but the grammar says it only uses lengths. Not %, not angles, not time,s not frequencies.
17:34:59 [TabAtkins]: dbaron: I think we should say that the values allowed in calc should match with the values for the property in some way. Units as appropriate for the property.
17:35:08 [TabAtkins]: glazou: That would be useful for rotations, frex.
17:35:23 [TabAtkins]: glazou: I support that. Other opinions?
17:35:30 [TabAtkins]: several: Yeah.
17:35:50 [TabAtkins]: szilles: So, the syntax isn't going to limit what's there, other than that the value that calc produces must be of the right kind.
17:36:17 [TabAtkins]: dbaron: We want to limit it so that the value is right for the property, but we probably want to limit it in some way. We may not want arbitrary keywords, frex. We may also not want integers.
17:36:21 [TabAtkins]: bert: And colors as well?
17:36:24 [TabAtkins]: dbaron: Right.
17:37:01 [TabAtkins]: bert: Do you suggest we write 3 or 4 grammars, all the same except for the atomic unit? Or one grammar with some explanatory text saying that the end value has to be of the right kind?
17:37:20 [TabAtkins]: dbaron: Yeah, one grammar, with a production referring to some text that defers to the property, restricting it to values that calc allows.
17:37:33 [TabAtkins]: szilles: If you allow division by values, writing a syntax for it would be very difficult.
17:37:41 [TabAtkins]: dbaron: Yeah, that's part of the followups to the message we skipped.
17:38:08 [TabAtkins]: dbaron: The current grammar has some weird cases where it allow a*b/c or when parenthesized one way, but not parenthesized another way.
17:38:37 [TabAtkins]: szilles: Basically, i was trying to say "Keep the grammar simple, and put the explanation in the text"
17:39:03 [TabAtkins]: dbaron: Yes, that was one of my suggestions in te thread. But then there's questions of what we want the restriction to be. But I think we're better off putting the unit restrictions in the text, not the grammar.
17:39:49 [TabAtkins]: szilles: And this relates to both the divide-by-zero and the limit thing? Basically it says "when you use calc you won't get a parse error unless it's really a parse error". You'll get an invalid value instead.
17:40:19 [TabAtkins]: dbaron: Nah, sometimes you'll get a parse error, like if you put a unit in calc that doesn't match what the property expects. Or a unit mismatch, like an em plus a number.
17:40:38 [TabAtkins]: szilles: But you might have two angles that produce a unitless number, which could be allowed.
17:40:54 [TabAtkins]: dbaron: Yeah, that's part of what we skipped. I'm tempted to say we don't allow it for the first version.
17:41:18 [TabAtkins]: szilles: How about defining incommensurate expressions, like numbers to lengths, and saying these are disallowed, but everything else is allowed? And the result must be of the correct type?
17:41:45 [TabAtkins]: dbaron: One possibility is that you track units all the way down for each operation. And then at the top you check that the answer has the right unit type: length, frequency, etc.
17:42:07 [TabAtkins]: szilles: It seems to me that is the right way to do it, and if we find specific combinations that should be disallowed, put them in explicitly.
17:42:36 [TabAtkins]: dbaron: One possibility is to forbid any unit that's not a valid type for the property.
17:42:44 [TabAtkins]: szilles: I want to avoid that, because it doesn't make sense in the long term.
17:42:52 [TabAtkins]: szilles: Like taking the ratio of two angles to decide a length.
17:43:05 [TabAtkins]: dbaron: I'm okay with that, but it requires we deal with division by zero.
17:43:10 [TabAtkins]: szilles: But we have to do that anyway, right?
17:43:33 [TabAtkins]: dbaron: Depends. If we disallow division by values, then it works out.
17:43:47 [TabAtkins]: plinss: What about clamping div-by-0 to the maximum allowed value?
17:43:54 [TabAtkins]: dbaron: There really isn't one.
17:44:07 [glazou]: problems with my phone, logging off and rejoining , hold on
17:44:12 [TabAtkins]: szilles: Yeah, you may be doing infinite-precision arithmetic. I think we need to do a different thing for div-by-0 anyway.
17:44:21 [Zakim]: -glazou
17:44:39 [TabAtkins]: szilles: It seems to me that it should *work* like a parse error, but without keeping the fallbacks.
17:44:48 [TabAtkins]: dbaron: Yah, just compute to the initial value is an option.
17:44:52 [Zakim]: +glazou
17:44:53 [glazou]: back
17:45:10 [TabAtkins]: szilles: Inherited value is inherited, initial value isn't inherited. (? Not sure about this.)
17:45:38 [TabAtkins]: szilles: The same as if there *were* no other fallback. If there was nothing else setting the property, you get the initial value.
17:45:56 [TabAtkins]: plinss: But that's a different problem then negative numbers, where we clamp.
17:46:32 [TabAtkins]: plinss: as you approach division by zero, your value approaches infinity.
17:46:38 [TabAtkins]: szilles: Not with 0/0
17:46:46 [TabAtkins]: TabAtkins: That's undefined.
17:46:51 [TabAtkins]: plinss: We can define it.
17:47:08 [TabAtkins]: dbaron: You don't know the sign of the infinite value, because you don't know if you approached 0 from above or below.
17:47:23 [TabAtkins]: szilles: Is it so bad to have a discontinuity when you divide by 0?
17:47:40 [sylvaing]: (said zero could even come from previously mentioned clamping...)
17:47:43 [TabAtkins]: plinss: but it won't be hardcoded, it'll be computed, and then you'll have a discontinuity.
17:48:18 [TabAtkins]: dbaron: Where a division-by-0 happens anyway probably isn't important for authors anyway, as it's probably not usually doing something that they actually intend.
17:48:47 [TabAtkins]: szilles: You can use min/max to prevent the divide-by-zero.
17:49:26 [TabAtkins]: szilles: There are ways to work around it.
17:49:27 [alexmog]: alexmog has joined #css
17:49:37 [TabAtkins]: plinss: If the author finds out about it.
17:49:38 [glazou]: wb alexmog
17:50:04 [TabAtkins]: TabAtkins: But the value will blow up before it hits div-by-0, and if the case is at all likely, the author will find it anyway and can stop it.
17:50:19 [TabAtkins]: glazou: Doesn't sound like this is getting resolved.
17:50:27 [TabAtkins]: dbaron: Sounds like the will of the group is that we want division by values.
17:50:31 [TabAtkins]: several: Yes.
17:51:02 [TabAtkins]: dbaron: Then the question is what to do in the div-by-0 case.
17:51:16 [TabAtkins]: dbaron: I'm partial to falling back to initial value.
17:51:18 [fantasai]: I would also prefer inherit-or-initial
17:51:27 [TabAtkins]: dbaron: Then should we do initial, or inherit-or-initial?
17:51:31 [TabAtkins]: several: inherit-or-initial.
17:51:32 [Lachy]: Lachy has joined #css
17:51:41 [TabAtkins]: dbaron: It might be harder to implement, but I'll think about it and see.
17:51:56 [TabAtkins]: ACTION: dbaron update proposal for min/max and divisions
17:51:56 [trackbot]: Created ACTION-205 - Update proposal for min/max and divisions [on David Baron - due 2010-01-27].
17:52:08 [sylvaing]: so if the value is out of range we clamp, if it can't be computed we fallback to initial/inherited ?
17:52:22 [dbaron]: it includes one of my favorite spelling mistakes, though :-)
17:52:22 [glazou]: http://lists.w3.org/Archives/Public/www-style/2009Dec/0256.html
17:53:02 [TabAtkins]: glazou: A proposal of mine to allow differently-sized columns.
17:53:19 [TabAtkins]: glazou: Right now colunn-width takes one argument. Proposal is to allow property to take multiple values.
17:53:40 [TabAtkins]: fantasai: I think it's a very interesting idea, and we want to look at it in the future. But I don't think it's right for right now.
17:54:10 [TabAtkins]: fantasai: We already have lots of pagination problems, and ROC says that some implementations will have trouble with columns of different widths, just as they currently have trouble with pages of different widths.
17:54:26 [TabAtkins]: fantasai: So until we get better page-layout architecture, I think we should file it away for the future.
17:54:34 [TabAtkins]: glazou: That's fine with me.
17:54:44 [TabAtkins]: howcome: It's an easy change in the grammar, but it's a complex change for implementors.
17:55:06 [TabAtkins]: howcome: We've just gone to CR, and have several impls that do the same thing, so I think it's too much for right now. But I do see it being useful in the future.
17:55:40 [TabAtkins]: szilles: When XSL did this, they were using a * system also, because sometimes you dont' want explicit values for the column width, but distribute.
17:56:00 [TabAtkins]: szilles: It's not quite percentages, but you want to be able to say, "This column should be twice as wide as that one".
17:56:17 [TabAtkins]: glazou: Okay, we'll keep it for the future. Peoplee at leaest agree that the feature is interesting.
17:56:37 [TabAtkins]: glazou: I don't think we can discuss any of the remaining issues in 4 minutes?
17:56:45 [TabAtkins]: dbaron: 2nd transitions comment should be trivial.
17:56:55 [TabAtkins]: smfr: I thought we already talked about this and agreed it was a mistake in the spec?
17:57:12 [TabAtkins]: dbaron: I think we all agree it's a mistake in the spec, and we can solve it in two minutes.
17:57:30 [TabAtkins]: dbaron: The transition spec has a rule to interpolate visibilty.
17:57:46 [TabAtkins]: dbaron: The intent is that it's visible at all points between, and hidden at the end. But it says the opposite.
17:57:51 [TabAtkins]: glazou: Resolved, accepted.
17:58:02 [glazou]: http://lists.w3.org/Archives/Public/www-style/2009Nov/0328.html
17:58:18 [TabAtkins]: smfr: This is related to having transition-delay apply to all properties.
17:58:29 [TabAtkins]: smfr: I think it's already related to Dean's proposal of a stepwise timing function.
17:58:46 [TabAtkins]: smfr: It would allow applying transitions to all properties, since you'd just snap between values.
17:58:59 [TabAtkins]: szilles: Is this related to the discussion when you restart transitions?
17:59:28 [TabAtkins]: [clarification of szilles's point]
17:59:32 [TabAtkins]: smfr: No, not related to that.
17:59:59 [TabAtkins]: smfr: I think it's a reasonable proposal, but I'd have to think more about it and implement it to see if it gets out of hand.
18:00:19 [TabAtkins]: smfr: There's a risk that you're saving transition information about everything on the page, which may have performance implications.
18:00:25 [Lachy]: Lachy has joined #css
18:00:39 [TabAtkins]: smfr: I won't have time to try it out in my impl for a few weeks.
18:00:47 [TabAtkins]: dbaron: I think we also want to discuss this with Dean's proposal.
18:00:53 [Zakim]: -[Mozilla]
18:00:54 [Zakim]: -smfr
18:00:54 [Zakim]: -Hakon_Lie
18:00:55 [Zakim]: -arronei
18:00:55 [Zakim]: -sylvaing
18:00:56 [Zakim]: -dethbakin
18:00:57 [Zakim]: -TabAtkins
18:00:58 [Zakim]: -glazou
18:01:00 [Zakim]: -plinss
18:01:06 [Zakim]: -SteveZ
18:01:08 [Zakim]: -Bert
18:01:10 [TabAtkins]: Argh, crick in my neck from holding the phone.
18:02:14 [Bert]: A comfortable headset is indispensable for teleconferences. :-)
18:02:42 [TabAtkins]: Indeed.
18:06:08 [Zakim]: disconnecting the lone participant, bradk, in Style_CSS FP()12:00PM
18:06:12 [Zakim]: Style_CSS FP()12:00PM has ended
18:06:13 [Zakim]: Attendees were +1.206.324.aaaa, sylvaing, +1.617.650.aabb, glazou, +1.408.636.aacc, smfr, David_Baron, +1.650.275.aadd, +1.858.216.aaee, +1.281.712.aaff, plinss, bradk, SteveZ,
18:06:15 [Zakim]: ... TabAtkins, fantasai, Hakon_Lie, Bert, dethbakin, arronei
18:07:36 [fantasai]: TabAtkins: I think I have the http://www.plantronics.com/north_america/en_US/products/home/cordless-phone-headsets/m214c
18:07:57 [fantasai]: TabAtkins: which is fairly inexpensive, comfortable, and works well
18:08:01 [TabAtkins]: I used that when i was tech support. It is a pretty comfy one.
18:17:35 [SteveZ2]: SteveZ2 has joined #css
18:21:55 [fantasai]: TabAtkins: when you're documenting resolutions, a) use RESOLVED: and b) document what was resolved
18:22:10 [TabAtkins]: gotcha, sorry.
18:51:03 [arronei]: arronei has joined #CSS
19:07:01 [krijnh]: krijnh has joined #css
19:19:16 [plinss]: plinss has joined #css
19:34:02 [Zakim]: Zakim has left #CSS
19:35:54 [smfr]: smfr has left #css
21:16:33 [jdaggett_]: jdaggett_ has joined #css
21:24:08 [TabAtkins]: fantasai: Should I use RESOLVED: by itself on a line?
23:55:00 [fantasai]: TabAtkins: yes
23:55:13 [TabAtkins]: kk
23:55:49 [fantasai]: See, e.g. http://lists.w3.org/Archives/Public/www-style/2010Jan/0341.html
23:55:56 [fantasai]: "RESOLVED: Tab's response is official"