IRC log of css on 2011-04-13

Timestamps are in UTC.

15:42:40 [RRSAgent]
RRSAgent has joined #css
15:42:40 [RRSAgent]
logging to http://www.w3.org/2011/04/13-css-irc
15:42:45 [glazou]
Zakim, this will be Style
15:42:45 [Zakim]
ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 18 minutes
15:42:50 [glazou]
RRSAgent, make logs public
15:48:37 [dbaron]
dbaron has joined #css
15:56:12 [mihara]
mihara has joined #css
15:56:23 [Zakim]
Style_CSS FP()12:00PM has now started
15:56:30 [Zakim]
+ +1.858.216.aaaa
15:56:39 [plinss]
zakim, aaaa is me
15:56:39 [Zakim]
+plinss; got it
15:59:13 [TabAtkins_]
TabAtkins_ has joined #css
15:59:16 [oyvind]
oyvind has joined #css
15:59:17 [jdaggett]
jdaggett has joined #css
15:59:28 [TabAtkins_]
TabAtkins_ has joined #css
15:59:46 [Zakim]
+??P18
15:59:52 [glazou]
Zakim, ??P18 isme
15:59:52 [Zakim]
I don't understand '??P18 isme', glazou
15:59:58 [Zakim]
+ +1.650.214.aabb
15:59:58 [glazou]
Zakim, ??P18 is me
15:59:59 [Zakim]
+glazou; got it
16:00:00 [johnjan]
johnjan has joined #css
16:00:03 [glazou]
thanks Ms2ger
16:00:04 [TabAtkins_]
Zakim, aabb is me
16:00:04 [Zakim]
+TabAtkins_; got it
16:00:15 [bradk]
bradk has joined #css
16:00:16 [danielweck]
danielweck has joined #css
16:00:33 [stearns]
stearns has joined #css
16:00:38 [Zakim]
+ +1.619.846.aacc
16:00:42 [Zakim]
+ +1.425.707.aadd
16:00:52 [johnjan]
Zakim, Microsoft is johnjan
16:00:52 [Zakim]
sorry, johnjan, I do not recognize a party named 'Microsoft'
16:01:02 [Zakim]
+Bert
16:01:02 [hober]
Zakim, +1.619.846.aacc is me
16:01:02 [Zakim]
+hober; got it
16:01:07 [gsnedders]
Regrets, am about to run away now.
16:01:08 [Zakim]
+ +1.650.275.aaee
16:01:17 [Zakim]
+David_Baron
16:01:18 [gsnedders]
(Sorry for being so last minute, but I was expecting to make it)
16:01:22 [Zakim]
+[Microsoft]
16:01:23 [arronei_]
zakim, microsoft has me
16:01:24 [Zakim]
+arronei_; got it
16:01:30 [glazou]
Zakim, why don't you recognize old friends of the spec?
16:01:30 [Zakim]
I don't understand your question, glazou.
16:01:43 [johnjan]
zakim, microsoft has me
16:01:44 [Zakim]
+johnjan; got it
16:01:54 [Zakim]
+??P36
16:02:14 [bradk]
zakim, aaee is me
16:02:14 [Zakim]
+bradk; got it
16:02:21 [kojiishi]
zakim, ??P36 is me
16:02:21 [Zakim]
+kojiishi; got it
16:02:26 [Cathy]
Cathy has joined #css
16:02:31 [Zakim]
+??P35
16:02:44 [smfr]
smfr has joined #css
16:02:48 [Zakim]
-kojiishi
16:02:52 [bradk]
zalim has altzheimers
16:03:02 [Zakim]
+??P30
16:03:05 [jdaggett]
zakim, ??P35 is me
16:03:07 [Zakim]
+jdaggett; got it
16:03:15 [kojiishi]
zakim, ??P30 is me
16:03:15 [Zakim]
+kojiishi; got it
16:03:25 [Zakim]
+ +1.206.675.aaff
16:03:30 [Zakim]
+ +1.408.636.aagg
16:03:36 [Zakim]
+??P43
16:03:41 [smfr]
Zakim, aagg is me
16:03:42 [glazou]
Zakim, who is on the phone ?
16:03:43 [plinss]
zakim, aadd is johnjan
16:03:46 [Zakim]
+smfr; got it
16:03:52 [Zakim]
On the phone I see plinss, glazou, TabAtkins_, hober, +1.425.707.aadd, Bert, bradk, David_Baron, [Microsoft], jdaggett, kojiishi, +1.206.675.aaff, smfr, ??P43
16:03:55 [danielweck]
Zakim, ??P43 is me
16:03:57 [stearns]
Zakim, aaff is me
16:03:58 [Zakim]
[Microsoft] has johnjan
16:04:02 [Zakim]
+johnjan; got it
16:04:07 [Zakim]
+danielweck; got it
16:04:14 [Zakim]
+stearns; got it
16:04:24 [Zakim]
+[IPcaller]
16:04:33 [glazou]
Zakim, aaff is stearns
16:04:36 [Zakim]
sorry, glazou, I do not recognize a party named 'aaff'
16:04:38 [dbaron]
Zakim, who is on the phone?
16:04:42 [Zakim]
On the phone I see plinss, glazou, TabAtkins_, hober, johnjan, Bert, bradk, David_Baron, [Microsoft], jdaggett, kojiishi, stearns, smfr, danielweck, [IPcaller]
16:04:47 [Zakim]
[Microsoft] has johnjan
16:04:48 [Bert]
infobot, area code 206?
16:04:51 [Zakim]
+??P13
16:04:55 [vhardy]
IPCaller is vhardy
16:05:06 [dbaron]
Zakim, ??P13 is fantasai
16:05:07 [Zakim]
+fantasai; got it
16:05:11 [glazou]
Zakim, [IPcaller] has vhardy
16:05:11 [Zakim]
+vhardy; got it
16:05:19 [Zakim]
+SteveZ
16:05:31 [TabAtkins_]
ScribeNick: TabAtkins_
16:05:52 [TabAtkins_]
plinss: Any last-minute additions?
16:05:58 [TabAtkins_]
kojiishi: Can I talk about epub response?
16:06:00 [TabAtkins_]
plinss: Sure.
16:06:04 [Zakim]
+ +1.206.324.aahh
16:06:22 [sylvaing]
sylvaing has joined #css
16:06:37 [TabAtkins_]
plinss: There's nothing to discuss about 2.1 this week!
16:06:46 [TabAtkins_]
arronei_: Hey, we moved to PR.
16:06:53 [TabAtkins_]
plinss: Yes, the PR transition call went very well.
16:07:08 [TabAtkins_]
glazou: We'll probably make a tshirt for the occasion.
16:07:23 [Bert]
(Excellent work by Peter on PR telcon, especially explaining the tests!)
16:07:51 [TabAtkins_]
plinss: Elika wanted to talk about the website.
16:07:53 [fantasai]
http://csswg.inkedblade.net/staging/redesign/index-divya.html
16:07:59 [Zakim]
+cathy_
16:08:45 [bradk]
If Elika is talking, we can't hear
16:08:56 [fantasai]
New website design
16:09:06 [fantasai]
from Divya Manian
16:09:25 [fantasai]
Based on structure from old design by Jason Cranford Teague and myself
16:09:28 [Bert]
I'd like to use the design, but it will take some work, because it was made for different mark-up.
16:09:31 [fantasai]
Do we want to adopt this design?
16:09:35 [smfr]
there's a missing image after "News"
16:09:36 [fantasai]
I fixed the markup
16:09:43 [Bert]
I saw Elika already did some adaptation.
16:10:05 [Zakim]
+ +1.415.832.aaii
16:10:06 [TabAtkins_]
glazou: My concern is still the legibility of the blue links in the blue header.
16:10:11 [TabAtkins_]
glazou: Other than that I think it's wonderful.
16:10:15 [TabAtkins_]
bradk: Same concern from me.
16:10:16 [jdaggett]
yeah, the dark blue links have poor legibility
16:10:26 [fantasai]
easy to fix, just suggest a color code :)
16:10:36 [nimbupani]
oh hai.
16:10:36 [arno]
zakim aaii is arno
16:10:52 [fantasai]
Overview and Current Work both list modules
16:10:55 [TabAtkins_]
glazou: Are we listing the modules somewhere, or is that under "current work"?
16:11:04 [TabAtkins_]
Bert: The structure isn't changing, just the markup/style.
16:11:09 [fantasai]
It's done
16:11:14 [nimbupani]
we could use aliceblue for the dark banner
16:11:18 [fantasai]
It only uses <time> element, which is ignorable
16:11:19 [bradk]
I sent a mockup suggestion picture, fantasai. Did you get it?
16:11:28 [bradk]
for the blue on blue issue
16:11:32 [glazou]
BUT IS IT NATIVE HTML5 ????
16:11:42 [howcome]
howcome has joined #css
16:11:44 [TabAtkins_]
plinss: So, consensus on adopting this for the site?
16:11:44 [nimbupani]
:)
16:11:51 [TabAtkins_]
RESOLVED: Accept the new site design.
16:12:19 [TabAtkins_]
plinss: Next topic, f2f.
16:12:22 [kojiishi]
http://wiki.csswg.org/planning/japan-2011-venues
16:12:28 [TabAtkins_]
kojiishi: I have a few candidates at this link.
16:12:38 [TabAtkins_]
kojiishi: The only good candidate is the Kyoto Research Park.
16:12:55 [TabAtkins_]
kojiishi: Fujisawa-san from the SVGWG seems to be fine to do it there too.
16:13:08 [TabAtkins_]
jdaggett: That sounds good to me.
16:13:29 [stearns]
howcome - I will drop again for you :)
16:13:35 [Zakim]
-stearns
16:13:42 [alexmog]
alexmog has joined #css
16:13:55 [glazou]
full again???
16:14:01 [Zakim]
+ +47.21.65.aajj
16:14:02 [glazou]
Zakim, who is on the phone ?
16:14:02 [Zakim]
On the phone I see plinss, glazou, TabAtkins_, hober, johnjan, Bert, bradk, David_Baron, [Microsoft], jdaggett, kojiishi, smfr, danielweck, [IPcaller], fantasai, SteveZ, sylvaing,
16:14:06 [Zakim]
... cathy_, +1.415.832.aaii, +47.21.65.aajj
16:14:07 [Zakim]
[Microsoft] has johnjan
16:14:07 [Zakim]
[IPcaller] has vhardy
16:14:29 [glazou]
hmmm, we should already have more slots than that
16:14:31 [glazou]
thanks stearns
16:14:37 [TabAtkins_]
kojiishi: The kyoto reserach park currently has som econditions for the place.
16:14:47 [glazou]
stearns: can you try to rejoin, just to check if another slot is available ?
16:14:58 [stearns]
ok
16:15:04 [TabAtkins_]
kojiishi: The place has internet, but not wifi - we can bring a router.
16:15:20 [TabAtkins_]
kojiishi: Lunch delivery is available but there are other lunch options close by.
16:15:40 [TabAtkins_]
szilles: 5 mins walking distance from kyoto station, or the subway station?
16:15:45 [sylvaing]
not sure that was clear as the sound is bad on my end; Microsoft Japan can sponsor lunches and dinner if necessary. Google being the original host, it's up to them though
16:15:49 [TabAtkins_]
kojiishi: from the subway station - 1 stop from kyoto
16:15:59 [stearns]
"the conference is full"
16:16:07 [glazou]
stearns: sigh, sorry for that
16:16:09 [TabAtkins_]
plinss: This is where SVG will meet the following week?
16:16:18 [TabAtkins_]
kojiishi: Yeah, and they're considering having a joint meeting.
16:16:32 [glazou]
Bert: I thought Chris asked for more slots..
16:16:43 [TabAtkins_]
TabAtkins_: Not sure what the progress is on that yet.
16:17:26 [TabAtkins_]
sylvaing: SVG is planning June 6-9, so starting on Monday.
16:17:39 [TabAtkins_]
jdaggett: I think they were maybe talking about coming on Saturday.
16:18:41 [boblet]
boblet has joined #CSS
16:18:48 [TabAtkins_]
TabAtkins_: Google can still do dinner, but I'll have to check about lunches.
16:18:53 [TabAtkins_]
jdaggett: Who's coordinating the router?
16:19:02 [TabAtkins_]
kojiishi: ??? (I missed the name.)
16:19:09 [TabAtkins_]
jdaggett: So you'll coordinate with him?
16:19:11 [TabAtkins_]
kojiishi: Yes.
16:19:29 [kojiishi]
http://buffalo.jp/products/catalog/network/wzr-hp-ag300h/
16:19:34 [mihara]
NTT will bring the router and projector.
16:20:50 [TabAtkins_]
kojiishi: So are we all fine with kyoto research park, or are we sticking with tokyo?
16:20:59 [TabAtkins_]
jdaggett: I think we should resolve on kyoto research park.
16:21:10 [dbaron]
KRP sounds good
16:21:14 [TabAtkins_]
[several] seems fine
16:21:36 [TabAtkins_]
plinss: Any issues with relocating the other workshop to Tokyo?
16:21:56 [TabAtkins_]
kojiishi: That's fine - we already have the place in KRP reserved on june 1st.
16:22:53 [TabAtkins_]
sylvaing: So wednesday for the workshop, and thu-fri-sat for the meeting, + sat for joint svg meeting.
16:22:56 [Zakim]
-cathy_
16:23:03 [Zakim]
+cathy_
16:23:04 [TabAtkins_]
RESOLVED: Relocate f2f to Kyoto.
16:23:43 [kojiishi]
http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-contentdocs.html#sec-css-profile
16:24:06 [TabAtkins_]
kojiishi: epub is curious is we're recommending that they use a prefix for properties that aren't in CR state.
16:25:28 [TabAtkins_]
smfr: From an impl perspective, *not* using prefixes is potentially dangerous. A browser may want to use the same rendering engine for both epub and webpages. If there are differences between an unprefixed epub property and a final unprefixed CSS property, this would cause a problem.
16:25:37 [TabAtkins_]
kojiishi: epub is willing to respond to changes in working drafts.
16:25:45 [kojiishi]
http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-contentdocs.html#sec-css
16:25:45 [TabAtkins_]
kojiishi: In section 3, there's a note...
16:26:08 [TabAtkins_]
kojiishi: ...about how this is still a work in progress and may change in incompatible ways.
16:26:39 [TabAtkins_]
smfr: Right, so that says that if an epub user uses an unprefixed property, the page may break when the reader is implemented.
16:26:52 [TabAtkins_]
smfr: It also means that the unprefixed property is exposed to arbitrary web content too.
16:27:21 [fantasai]
If you use prefixes, you are versioning anyway.
16:27:32 [fantasai]
Just a different trigger for versioning
16:27:47 [fantasai]
Having to support two different behaviors is a problem.
16:27:47 [TabAtkins_]
kojiishi: epubs have a version number, so you can key off that for the differing behavior if necessary.
16:28:01 [TabAtkins_]
TabAtkins_: Versioning has never worked on the web, unfortunately.
16:28:35 [TabAtkins_]
smfr: It would mean we have to support two version of the same thing, which we don't do right now. This becomes a huge implementation reader as time goes on.
16:29:07 [TabAtkins_]
kojiishi: Isn't the criteria the same, though? epub readers would have to support both prefixed and unprefixed properties.
16:29:30 [TabAtkins_]
smfr: We already have the situation where we'll have to support prefixed properties indefinitely. That's easier than having to handle two version of the property with different syntax/meaning.
16:29:52 [Zakim]
-fantasai
16:30:20 [Zakim]
+fantasai
16:30:23 [TabAtkins_]
plinss: I agree in general with the arguments for having a prefix.
16:30:40 [TabAtkins_]
smfr: Something with an epub prefix may have different behaviors between epub UAs.
16:31:08 [TabAtkins_]
fantasai: If epub spec tracks what we're doing, what behavior is being associated with the prefixed property? Behavior now, behavior a month from now, ...?
16:31:23 [TabAtkins_]
fantasai: There's no clear description of what the behavior would be, so it just forks the spec.
16:31:31 [TabAtkins_]
smfr: It'll be whatever they expect.
16:31:32 [sylvaing]
sylvaing has joined #css
16:31:36 [Zakim]
-SteveZ
16:31:51 [TabAtkins_]
smfr: They'll author in whatever UA they have around.
16:32:10 [Zakim]
-jdaggett
16:32:44 [TabAtkins_]
fantasai: It's not analogous - the author can have multiple UAs which have different behaviors under the same "-epub-" prefix.
16:32:55 [Zakim]
-hober
16:33:18 [Zakim]
-danielweck
16:33:19 [Zakim]
+??P0
16:33:35 [TabAtkins_]
fantasai: Any impl that wants to read epub will have to read epub syntax. That's just forking the spec, even if they have the same behavior between the two.
16:33:37 [jdaggett]
zakim, ??P0 is me
16:33:37 [Zakim]
+jdaggett; got it
16:33:44 [Zakim]
+hober
16:33:53 [Zakim]
+??P4
16:34:03 [TabAtkins_]
fantasai: I think we should just subset the properties we think are stable and finish the spec.
16:34:05 [danielweck]
Zakim, ??P4 is me
16:34:05 [Zakim]
+danielweck; got it
16:34:15 [danielweck]
(SIP drop)
16:34:17 [TabAtkins_]
fantasai: There's not much in the way of epub content out there when they release the spec.
16:34:32 [TabAtkins_]
jdaggett: The problem here is that authors will be using properties that aren't in CR.
16:34:50 [TabAtkins_]
jdaggett: If we use unprefixed properties, we're assuming that no differences in behavior will occur.
16:35:05 [TabAtkins_]
fantasai: let's suppose that moz decides to support epub content in 2 years.
16:35:15 [TabAtkins_]
fantasai: They'll have to parse all the epub properties, but they won't want two codepaths.
16:35:30 [TabAtkins_]
fantasai: So, for the most part, they can get away with this.
16:35:57 [TabAtkins_]
jdaggett: After a while, epub can publish a revised spec that includes unprefixed props once the specs are stable.
16:36:15 [danielweck]
Bert: I use the "Telephone" SIP app on Mac OS X, I use the free Ekiga VoIP service...I get dropped every 30 minutes.
16:36:30 [TabAtkins_]
smfr: Authors should use both vendor and unprefixed properties, like they do right now.
16:36:49 [TabAtkins_]
plinss: Assuming it hasn't changed.
16:37:09 [TabAtkins_]
fantasai: I don't understand how that's different from using unprefixed properties.
16:37:53 [TabAtkins_]
smfr: We won't be exposing the unprefixed property to the web at large.
16:38:15 [TabAtkins_]
TabAtkins_: So the compat problems are the same, but the overall web can't play with it and make it worse, just epub.
16:38:31 [TabAtkins_]
jdaggett: So the problem is that epub is trying to lock down things that aren't finished yet in the spec.
16:39:57 [TabAtkins_]
fantasai: Given the explanations, recommending that authors use both -epub- and unprefixed would work.
16:40:53 [TabAtkins_]
bradk: That still has compat problems, though.
16:41:39 [TabAtkins_]
sylvaing: A prefix lets you at least reference one version of a property.
16:41:56 [TabAtkins_]
TabAtkins_: Generally, we're not going to want multiple versions of a property. We want only one codepath.
16:42:15 [TabAtkins_]
fantasai: Some may be okay with different codepaths, but others aren't.
16:43:15 [TabAtkins_]
plinss: I think we should have epub reference a specific version, and guarantee that epub readers implement that specific version.
16:43:25 [Martijnc]
Martijnc has joined #css
16:44:42 [TabAtkins_]
fantasai: webkit won't want to specifically implement different versions of vertical text, for example.
16:45:43 [fantasai]
+1 to Tab
16:45:51 [TabAtkins_]
fantasai: Epub has decided that they want to track the spec, not freeze on a particular version.
16:46:18 [TabAtkins_]
plinss: That's fine. I think we should recommend they do the opposite.
16:47:09 [TabAtkins_]
TabAtkins_: I disagree. If we want to treat epub as part of the web, it's bad to have them snapshot, and it's a bad precedent for other new web-type technologies.
16:47:54 [jdaggett]
the bad precedent is basing new technologies on *WD* versions of specs
16:47:56 [TabAtkins_]
plinss: I think epub should fix on a revision, and set it with a version on themselves.
16:48:33 [TabAtkins_]
I agree, jdaggett, but it's an unfortunate consequence of the fact that we are *just now* addressing the typographic conventions of a significant percentage of the world.
16:48:44 [TabAtkins_]
plinss: How often is epub revving?
16:48:47 [TabAtkins_]
fantasai: I don't know.
16:48:57 [kojiishi]
http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-contentdocs.html#sec-overview-versioning
16:49:01 [TabAtkins_]
dbaron: I don't think they should snapshot if they want to track.
16:49:18 [TabAtkins_]
dbaron: Then we're just encouraging epub and web content to diverge.
16:49:50 [fantasai]
+1 to dbaron
16:49:52 [TabAtkins_]
dbaron: If the impls converge slowly enough that they don't have tons of interop before we reach CR, we're okay.
16:51:18 [fantasai]
dbaron: If they create testcases and drive interop to a snapshot, then they're encouraging a fork
16:52:00 [jdaggett]
"addressing the typographic conventions of a significant percentage of the world" == vertical text?
16:52:02 [TabAtkins_]
plinss: Things about the properties will change. They shouldn't be basing their impl on non-CR stuff.
16:52:31 [TabAtkins_]
fantasai: I think we should keep it fuzzy until we either decide that there's no need to fork, or a fork is imminent.
16:53:03 [TabAtkins_]
plinss: It would be ideal if nobody forked the spec.
16:53:28 [Ms2ger]
It would be ideal if these specs were in CR
16:53:28 [TabAtkins_]
fantasai: The solution you're advocating is more likely to lead to a fork.
16:53:49 [TabAtkins_]
plinss: yes, but we aren't forking, they are.
16:54:16 [TabAtkins_]
fantasai: By advocating they fork the spec, it's our responsibility. We're the ones forking things as well.
16:54:50 [TabAtkins_]
plinss: I'm saying that if epub wants to add a property that's not yet part of CSS, they should own the property themselves, so that when CSS defines the property it can be unprefixed across everyone.
16:55:20 [TabAtkins_]
fantasai: Then we have multiple implementations that have to support multiple behaviors, when it might not even be necessary.
16:55:37 [TabAtkins_]
sylvaing: We already do that, like webkit's stuff.
16:55:48 [TabAtkins_]
fantasai: And they want to avoid doing it more.
16:56:11 [TabAtkins_]
smfr: We are okay with maintaining multiple versions of simple things like gradients, but not core layout primities like vertical text.
16:56:22 [fantasai]
We have four minutes remaining.
16:56:37 [TabAtkins_]
smfr: We never want forked behavior for unprefixed properties.
16:56:50 [TabAtkins_]
plinss: I think I'm hearing consensus that they should prefix their properties.
16:56:56 [TabAtkins_]
[several]: yes
16:57:00 [Bert]
(Best might be to encourage them to make a version 3.0 without vertical, send their engineers to CSS to work on vertical, and make 3.1 half a year later.)
16:57:23 [TabAtkins_]
plinss: What I'm hearing dissent on is what the unprefixed version means.
16:57:24 [fantasai]
(Bert, that won't help anyone. What are their engineers going to do to help?)
16:57:42 [fantasai]
(We have to write the spec. It's unlikely that they can do that for us.)
16:58:39 [TabAtkins_]
plinss: Anything else on this topic?
16:58:41 [Bert]
(Elika, help you with tests and impl. reports?)
16:58:42 [fantasai]
plinss: They're their own working group. We can make recommendations. If they decide not to prefix, they don't prefix and the only thing we can do is get mad about it.
16:58:49 [fantasai]
(Yes, that would be great :)
16:58:57 [TabAtkins_]
jdaggett: Any resolution here?
16:59:10 [dbaron]
didn't plinss say "prefixed version" rather than "unprefixed version"? ("what the ... means", above)
16:59:11 [TabAtkins_]
plinss: No formal resolution yet. We're just in agreement that they should prefix properties that aren't in CR.
16:59:22 [TabAtkins_]
jdaggett: Is that our formal recommendation.
16:59:36 [TabAtkins_]
Yes, dbaron, typo on my part.
17:00:30 [TabAtkins_]
bradk: We could provide them with examples of spec that have changed drastically between WD and CR.
17:00:33 [TabAtkins_]
fantasai: They know that already.
17:01:08 [TabAtkins_]
RESOLVED: Epub should use prefixed versions of properties that aren't yet in CR. What this prefixed property means is undecided.
17:01:13 [Zakim]
-jdaggett
17:01:14 [Zakim]
-johnjan
17:01:16 [Zakim]
-glazou
17:01:18 [Zakim]
-smfr
17:01:18 [Zakim]
-hober
17:01:19 [Zakim]
-howcome
17:01:19 [Zakim]
-[IPcaller]
17:01:20 [Zakim]
-sylvaing
17:01:21 [Zakim]
-[Microsoft]
17:01:24 [Zakim]
-David_Baron
17:01:26 [Zakim]
-TabAtkins_
17:01:27 [Zakim]
-kojiishi
17:01:27 [Zakim]
-danielweck
17:01:29 [Zakim]
-cathy_
17:01:31 [Zakim]
-bradk
17:01:33 [Zakim]
-Bert
17:01:35 [Zakim]
-plinss
17:01:39 [Zakim]
- +1.415.832.aaii
17:01:47 [Zakim]
-fantasai
17:01:48 [Zakim]
Style_CSS FP()12:00PM has ended
17:01:50 [Zakim]
Attendees were +1.858.216.aaaa, plinss, +1.650.214.aabb, glazou, TabAtkins_, +1.425.707.aadd, Bert, hober, +1.650.275.aaee, David_Baron, arronei_, johnjan, bradk, kojiishi,
17:01:55 [Zakim]
... jdaggett, +1.206.675.aaff, +1.408.636.aagg, smfr, danielweck, stearns, fantasai, vhardy, SteveZ, +1.206.324.aahh, sylvaing, cathy_, +1.415.832.aaii, +47.21.65.aajj, howcome
17:02:55 [arno1]
arno1 has joined #css
17:04:13 [TabAtkins_]
TabAtkins_ has joined #css
17:12:49 [smfr]
smfr has joined #css
17:17:03 [arno]
arno has joined #css
17:31:10 [smfr]
smfr has left #css
18:06:46 [arno]
arno has joined #css
18:31:17 [arno]
arno has joined #css
18:37:04 [arno]
arno has joined #css
18:39:10 [fantasai]
away
19:09:10 [Zakim]
Zakim has left #css
19:18:08 [TabAtkins_]
TabAtkins_ has joined #css
20:27:59 [nimbupani]
nimbupani has left #css
20:54:06 [kennyluck]
kennyluck has joined #css
21:05:18 [karl]
karl has joined #CSS
21:06:32 [arno]
arno has joined #css
22:01:46 [arno1]
arno1 has joined #css
22:45:36 [homata_]
homata_ has joined #CSS
22:55:25 [homata]
homata has joined #CSS
23:27:03 [dbaron]
dbaron has joined #css
23:28:58 [boblet]
boblet has joined #CSS
23:33:22 [homata]
homata has joined #CSS