/irc-logs / w3c / #css / 2010-09-29 / end

Options:

# Session Start: Wed Sep 29 00:00:00 2010
# Session Ident: #css
# [00:03] * Joins: karl (karlcow@128.30.54.58)
# [01:50] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [02:37] * Joins: dbaron (dbaron@63.245.220.240)
# [05:00] <fantasai> hyatt: I think for consistency we should either translate *all* x-y pairs of things, or none of them
# [05:00] <hyatt> yeah i agree with that
# [05:00] <hyatt> i have a lot of comments now having worked on this for a couple of weeks
# [05:00] <hyatt> and testing in WinIE
# [05:01] <hyatt> there's some interesting stuff about the initial containing block
# [05:01] <hyatt> you need it to assume the same block-flow as the document element
# [05:01] <hyatt> kind of common sense if you think about it, but probably needs to be written down
# [05:02] <hyatt> like if i say <html style="logical-height:100px; block-flow:lr">
# [05:02] <hyatt> that block should be on the left with a width of 100px
# [05:02] <hyatt> and in order for that to happen the ICB has to be block-flow:lr too
# [05:02] <fantasai> are you implementing logical-height/margin-start/etc?
# [05:02] <hyatt> already implemented
# [05:02] <hyatt> every last one
# [05:03] <fantasai> wow
# [05:03] <hyatt> i wasn't sure what to do with replaced elements... i ended up making them have a hardcoded block-flow: tb !important basically
# [05:03] <fantasai> how'd you deal with the cascade?
# [05:03] <fantasai> I don't think that's the right thing to do with replaced elements
# [05:03] <hyatt> yeah i wasn't sure
# [05:03] <fantasai> because the margin-start should still be on the start side
# [05:04] <fantasai> the contents should not be rotated
# [05:04] <fantasai> but everything else should be
# [05:04] <hyatt> you think the borders would rotate etc?
# [05:04] <fantasai> no
# [05:04] <fantasai> sorry
# [05:04] <fantasai> not rotated
# [05:04] <fantasai> but, 'start/end' should match the containing block
# [05:05] <fantasai> although, hm, maybe that should be the case for all elements
# [05:05] <fantasai> but yeah, how did you handle the cascade?
# [05:05] <fantasai> because that's one of the major sticking points with speccing those things
# [05:05] <hyatt> maybe give me an example and i can tell you if i handled it? :)
# [05:05] <fantasai> p { margin-left: 2em; margin-start: 3em; }
# [05:05] <hyatt> we just map them into the physical property at style resolution time
# [05:05] <hyatt> so yeah in that example margin-left is 3edm
# [05:05] <hyatt> 3em
# [05:06] <fantasai> p { margin-end: 5em; margin-right: 6em; }
# [05:06] <hyatt> we just look at the element's block-flow and direction
# [05:06] <hyatt> and make a decision
# [05:06] <hyatt> and map it to the physical side
# [05:06] <hyatt> which seems to me to be the sensible way to handle it
# [05:06] <fantasai> when?
# [05:06] <fantasai> what's the result for tha bove?
# [05:07] <hyatt> for the 2nd example, 6em would be the right margin...
# [05:07] <hyatt> assuming tb-lr
# [05:07] <fantasai> right
# [05:07] <fantasai> style resolution means what?
# [05:07] <hyatt> when we first compute the style information for the element
# [05:07] <hyatt> when we examine the rules
# [05:08] <hyatt> we do a first pass to determine certain properties (like font, block-flow, direction)
# [05:08] <hyatt> anything that other properties could depend on
# [05:08] <hyatt> and then in the second pass we can resolve direction-aware logical properties to their physical sides
# [05:08] <fantasai> so you cascade twice?
# [05:08] <fantasai> once for the first et of properties, one for the second?
# [05:08] <hyatt> well the set of properties is mutually exclusive
# [05:09] <fantasai> right
# [05:09] <fantasai> but
# [05:09] <hyatt> so it's just that we figure out the values for block-flow and direction
# [05:09] <hyatt> first
# [05:09] <hyatt> and then knowing those we can resolve margin-end etc. correctly
# [05:09] <fantasai> ok
# [05:09] <fantasai> cool
# [05:09] <fantasai> well
# [05:09] <fantasai> I'm glad to hear that's workingout
# [05:09] <hyatt> which is why i really would not want there to be some kind of mismatch at rendering time
# [05:10] <fantasai> so
# [05:10] <fantasai> for x-y coordinate pairs
# [05:10] <hyatt> like if margin-start for a replaced element needs to match teh containing block's margin start
# [05:10] <hyatt> then i'd prefer it do so by having the block-flow match the containing block's block flow
# [05:10] <fantasai> makes sense
# [05:10] <hyatt> i don't happen to think it does need to match though
# [05:10] <fantasai> I think it does
# [05:10] <fantasai> otherwise that logic isn't useful for determining spacing
# [05:11] <fantasai> if I set margin-start and -end on a replaced element expecting it to space the element from its surrounding contents
# [05:11] <fantasai> your !important rule would break that assumption
# [05:11] <fantasai> I think the contents of replaced elements just shouldn't rotate
# [05:12] <hyatt> that would be fine with me
# [05:12] <hyatt> as long as the block-flow of the replaced element was how i determine margin-start / end
# [05:12] <hyatt> i guess i agree with that conceptually
# [05:12] <hyatt> it's kind of like having an upright glyph
# [05:12] <hyatt> if you think of the replaced element as a "glyph"
# [05:12] <fantasai> yeah
# [05:12] <hyatt> but it would mean the borders rotate if you say border-start
# [05:12] <hyatt> border-end
# [05:13] <hyatt> but that makes sense to me
# [05:13] <fantasai> rotate wrt the image, yes
# [05:13] <hyatt> yes
# [05:13] <fantasai> but if you wanted them physical
# [05:13] <hyatt> ok i like this idea
# [05:13] <fantasai> then you use physical properties
# [05:13] <hyatt> sure
# [05:13] <hyatt> i'll implement the rotation
# [05:13] <hyatt> of the contents
# [05:13] <hyatt> oh the other thing is that blocks with different directionality than their parent
# [05:13] <hyatt> differeent block-flow
# [05:14] <hyatt> should establish a block formatting context
# [05:14] <hyatt> i don't know if the spec says that yet
# [05:14] <fantasai> oh
# [05:14] <fantasai> of course
# [05:14] <fantasai> I don't think it does
# [05:14] <fantasai> I haven't really written up that section yet
# [05:14] <fantasai> it's in my notes somewhere :)
# [05:14] <hyatt> yeah so the iCB, replaced elements, block formatting context
# [05:14] <hyatt> what else did i run into
# [05:14] <fantasai> x-y coordinate pairs
# [05:14] <hyatt> when to apply auto margins is interesting
# [05:14] <hyatt> i matched winie
# [05:15] <fantasai> ?
# [05:15] <hyatt> and kind of agree with them
# [05:15] <hyatt> if a child block has different directoinality than a parent block
# [05:15] <fantasai> what do you mean?
# [05:15] <hyatt> auto margins center you in the containing block's inline direction
# [05:15] <hyatt> but not in the child's
# [05:15] <fantasai> right
# [05:15] <fantasai> that makes sense
# [05:15] <hyatt> which makes sense
# [05:15] <hyatt> another thing
# [05:15] <fantasai> if I have a block with vertical writing mode in a horizontal writing mode container
# [05:16] <hyatt> when a child uses percentages on something like margin/border/padding it is relative to the logical width of the containing block
# [05:16] <fantasai> then it lays out as if it were in a container of fixed height and infinite width
# [05:16] <hyatt> regardless of if the block has a different directionality than the containing block
# [05:16] <fantasai> and its margins participate in its containing block's formatting context
# [05:16] <hyatt> which your draft says
# [05:16] <hyatt> but if a child uses percentages on width/height etc., it's relative to the specific physical axis that matches of the containing block
# [05:16] <hyatt> i don't think the draft is so clear about that
# [05:17] <hyatt> so you can't just say logical width of a child percentage uses logical width of container
# [05:17] <hyatt> i didn't do the infinite width thing for now
# [05:17] <hyatt> i matched winie which uses the viewport height/width instead of infinity
# [05:17] <hyatt> but it's easy to change
# [05:17] <hyatt> i put a big fixme in it
# [05:18] <fantasai> heh
# [05:18] <fantasai> um
# [05:18] <hyatt> this is a crazy project
# [05:18] <hyatt> i'm like
# [05:18] <hyatt> renaming every layout function in the fricking engine
# [05:18] <fantasai> ok, I think I understand what you're saying
# [05:18] <fantasai> haha, yeah
# [05:19] * fantasai is glad krijnh is logging
# [05:20] <fantasai> so, x-y coordinates...
# [05:20] <hyatt> i couldn't make my mind up about them
# [05:20] <fantasai> My preference is to make them logical
# [05:20] <hyatt> mine is too
# [05:20] <hyatt> it was my first impulse at least
# [05:20] <fantasai> and allow physical by use of a flag
# [05:20] <hyatt> i guess i'm kind of falling into the camp of "it should be easy to write code that flips if you just change block-flow on a root"
# [05:20] <fantasai> [physical | logical]? or something
# [05:21] <fantasai> that's been my camp, but it's hard to fall into it when nobody wants to implement logical properties :)
# [05:21] <hyatt> wow i didn't even know there was a debate
# [05:21] <fantasai> but if you're doing it and Antenna House is doing it, then we have the basis for a standard
# [05:21] <hyatt> they're barely any code to implement
# [05:21] <hyatt> they're a joke
# [05:21] <fantasai> The argument is that it adds too many new properites
# [05:21] <hyatt> oh that's just silly
# [05:22] * fantasai laughs
# [05:22] <hyatt> we add properties like popping candy
# [05:22] <hyatt> so yeah
# [05:22] <hyatt> that doesn't bother me
# [05:22] <hyatt> and they aren't real
# [05:22] <hyatt> they just map to the physical
# [05:22] <hyatt> so in terms of extra engine code
# [05:22] <hyatt> it's nothing
# [05:22] <fantasai> it's just storing the property name keys, pretty much
# [05:22] <hyatt> exactly
# [05:22] <hyatt> and writing one little function to resolve the sides
# [05:22] <fantasai> which is what I tried to argue :)
# [05:22] <hyatt> which is easy
# [05:22] <fantasai> but whatever
# [05:22] <hyatt> well 2 impls
# [05:23] <hyatt> roar
# [05:23] <hyatt> i hate the second solution
# [05:23] <hyatt> hate hate hate
# [05:23] <fantasai> ?
# [05:23] <fantasai> which one?
# [05:23] <hyatt> the logical/physical toggle would be so horrible
# [05:23] <hyatt> if you tell me top means something different
# [05:23] <hyatt> now you force me to abstract painting
# [05:23] <hyatt> the 1st solution just forces me to abstract layout
# [05:23] <hyatt> the 2nd one forces me to abstract the physical access for painting
# [05:23] <hyatt> and other non-layout uses
# [05:23] <hyatt> if borderTop doesn't mean borderTop any more that would just be like.... gah
# [05:24] <hyatt> "directional-mode"
# [05:24] <hyatt> gah
# [05:24] <hyatt> no
# [05:24] <fantasai> got it
# [05:24] <hyatt> like that would be so horrible to implement
# [05:24] <fantasai> Well, that makes my job easier
# [05:24] <hyatt> you'd have to introduce indirection into the access of physical properties
# [05:24] <hyatt> from the engine
# [05:24] <fantasai> Don't have to write two different specs before TPAC
# [05:25] <hyatt> yeah the first proposal is fully implemented
# [05:25] <hyatt> i added every single one
# [05:25] <hyatt> heck i even added new properties for our made-up properties!
# [05:25] <hyatt> margin-top-collapse became margin-before-collapse etc
# [05:25] <hyatt> lol
# [05:26] <fantasai> actually, it probably should just be margin-before-collapse
# [05:26] <fantasai> I don't think margin-top-collapse is necessary
# [05:26] <fantasai> margin-top doesn't collapse unless it's in horizontal mode anyway
# [05:27] <hyatt> you're exactly right
# [05:27] <fantasai> so just rename it :)
# [05:27] <hyatt> what i ended up doing is just aliasing top/bottom to before/after
# [05:27] <fantasai> alias the old version if you need to
# [05:27] <fantasai> yeah
# [05:27] <hyatt> for backwards compat
# [05:27] <hyatt> since this is used by safari rss
# [05:28] <hyatt> i did not add a left/right collapse
# [05:28] <hyatt> just before/after are the real one now
# [05:28] <fantasai> nice
# [05:28] <hyatt> i'm working on margin collapsing now
# [05:28] <hyatt> it's complicated
# [05:28] <fantasai> huh
# [05:28] <hyatt> just making sure i get the correct margin is all
# [05:28] <fantasai> ah
# [05:28] <fantasai> can you send me a dump of your property list?
# [05:29] <fantasai> would like to make sure we have everything listed in the spec
# [05:29] <hyatt> i don't have to. it exactly matches the spec.
# [05:29] <hyatt> there may be something we haven't thought of
# [05:29] <fantasai> k
# [05:29] <hyatt> in which case i haven't implemented it yet :)
# [05:29] <fantasai> do you have start/end keywords for background-position?
# [05:30] <hyatt> no i haven't gotten that far
# [05:30] <fantasai> k
# [05:30] <hyatt> no new keywords for anything
# [05:30] <fantasai> k
# [05:30] <hyatt> i'm kind of going from the outside in
# [05:30] <hyatt> so got the view working in LR mode
# [05:30] <fantasai> makes sense
# [05:30] <hyatt> now i'm doing block layout of block children
# [05:30] <hyatt> so that i can actually get some blocks placed
# [05:30] <hyatt> :)
# [05:30] <fantasai> :)
# [05:30] <hyatt> then i'll do lines
# [05:30] <hyatt> then floats/positioning
# [05:31] <hyatt> probably tables after that
# [05:31] <hyatt> then flex boxes, ruby, marquees, argh
# [05:31] <hyatt> columns
# [05:31] <hyatt> printing
# [05:31] <hyatt> this is not small.
# [05:31] <hyatt> :)
# [05:31] <fantasai> I know :)
# [05:31] <hyatt> so antenna house supports the logical properties? that's good news.
# [05:31] <hyatt> since i support them too
# [05:31] <hyatt> who hated them
# [05:32] <fantasai> I'd say at least half the WG
# [05:32] <hyatt> when they start implementing then they can talk.
# [05:32] <hyatt> ;)
# [05:32] <fantasai> :)
# [05:33] <fantasai> For the position ones... I would suggest to use position-before/start/end/after
# [05:33] <fantasai> rather than just before/start/end/after
# [05:33] <fantasai> I wish top/left/right/bottom did the same
# [05:33] <fantasai> but it gets really ambiguous with the new set
# [05:33] <fantasai> what this property means
# [05:33] <hyatt> you mean position: position-before?
# [05:33] <fantasai> no
# [05:33] <fantasai> position-before: 40%
# [05:33] <fantasai> instead of
# [05:33] <fantasai> top: 40%
# [05:33] <hyatt> left:
# [05:34] <hyatt> i see
# [05:34] <hyatt> i'll just wait for you to write something down and then do it
# [05:34] <fantasai> heh
# [05:34] <hyatt> will be a few weeks before i get to positioned elements
# [05:34] <fantasai> I think today I'm going to work on the intro mostly
# [05:34] <fantasai> and text-orientation
# [05:35] <hyatt> what is text-orientation
# [05:36] <hyatt> is it like the glyph-orientation thign?
# [05:36] <hyatt> thing?
# [05:38] <hyatt> like on the logical properties just to give you an idea
# [05:38] <hyatt> it took me about 45 minutes to add them
# [05:38] <hyatt> including writing tests
# [05:38] <hyatt> so i think it's really silly for people to think they are some great burden
# [05:38] <hyatt> :)
# [05:41] <fantasai> 45 minutes for you equals, what, 5 days for anyone else? ;)
# [05:41] <fantasai> text-orientation is like glyph-orientation
# [05:41] <fantasai> except it's smarter about things
# [05:41] <hyatt> ok
# [05:41] * Joins: Figaroo (Figaroo@70.234.3.170)
# [05:41] <fantasai> every value of glyph-orientation except 'auto' is ...
# [05:42] <fantasai> not intelligent about correctly handling things the designer of said property hadn't thought of
# [05:42] <Figaroo> Are there any plans for standardizing webkit's scrollbar psuedoelements?
# [05:45] <hyatt> Figaroo: not really
# [05:45] <hyatt> unless there is a whole lot of interest in them
# [05:46] <Figaroo> It appears twitter is already taking advantage of webkit's implementation, if that's of any significants?
# [05:46] <hyatt> those were primarily added so itunes could get its custom scrollbar look
# [05:46] <hyatt> heh
# [05:46] <hyatt> twitter is? cool
# [05:46] <Figaroo> I misspelled significance*
# [05:46] <hyatt> we never really proposed them since we didn't think anyone cared
# [05:47] <Figaroo> the #newtwitter
# [05:47] <Figaroo> I still feel that the way webkit does things is a little complicated though.
# [05:47] <hyatt> fantasai: another thing i'm kind of terrified about is overflow scrollbars and block-flow
# [05:48] <hyatt> Figaroo: yeah the way webkit does things is to support itunes insanely complicated scrollbar look
# [05:48] <hyatt> there are features no sane person would probably even care about
# [05:49] <Figaroo> So with some tweeking of the spec it would be fantastic!
# [05:49] <hyatt> yeah although we would have to support enough to keep itunes working
# [05:49] <Figaroo> What are you talking about overflow and block-flow?
# [05:49] <hyatt> i'm not sure how scrollbars should render for different block-flow values
# [05:49] <hyatt> or how i should implement it
# [05:50] <Figaroo> I'm not familiar with block-flow, could you give me an example?
# [05:50] <hyatt> http://dev.w3.org/csswg/css3-text-layout/
# [05:50] <hyatt> it's vertical text basically
# [05:51] <Figaroo> Are talking about different block-flow and overflow vallues for each psuedo element in the scrollbar?
# [05:51] <hyatt> nah just about where the scrollbars go in general
# [05:51] <hyatt> brb
# [05:52] <Figaroo> k
# [05:53] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [05:58] <Figaroo> hyatt, when you get back: What concerns do you have with block-flow and scrollbars?
# [06:00] <fantasai> hyatt: I don't think there's anything to be concerned about. scrollbars should be positioned consistently throughout the page, i.e. according to the user's OS settings
# [06:01] <fantasai> hyatt: The only difference is which way they're allowed to scroll
# [06:01] <fantasai> hyatt: you want the origin in the start before corner and allow scrolling down to the end after corner
# [06:10] <fantasai> hyatt: also... I am wondering if we can alter the terms to be more consistent with multicol somehow
# [06:10] <fantasai> hyatt: that uses width and length as logical properties
# [06:11] <fantasai> hyatt: which would mean height and something else as physical properties
# [06:11] * fantasai can't come up with any synonyms for width though. :/
# [06:12] <fantasai> it would make logical variants of width/height less painful to use, though, if they weren't so awkwardly named
# [07:21] * Quits: Figaroo (Figaroo@70.234.3.170) (Quit: Leaving)
# [07:33] <hyatt> fantasai: yeah winie throws the scrollbars on different box sides
# [07:33] <hyatt> fantasai: which i think is nuts
# [08:19] * Joins: nimbupani (nimbupani@24.22.131.46)
# [08:28] * Disconnected
# [08:29] * Attempting to rejoin channel #css
# [08:29] * Rejoined channel #css
# [08:29] * Topic is 'CSS Working Group discussion'
# [08:29] * Set by fantasai on Mon Aug 02 00:49:50
# [08:32] * Joins: jdaggett (jdaggett@202.221.217.73)
# [09:31] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [10:40] * Quits: karl (karlcow@128.30.54.58) (Ping timeout)
# [10:41] * Joins: karl (karlcow@128.30.54.58)
# [10:44] * Quits: arronei (arronei@131.107.0.69) (Ping timeout)
# [10:49] * Joins: anne (annevk@83.85.115.123)
# [10:50] * Joins: arronei (arronei@131.107.0.105)
# [11:12] * Quits: jdaggett (jdaggett@202.221.217.73) (Quit: jdaggett)
# [12:04] * Quits: kennyluck (kennyluck@128.30.52.28) (Quit: kennyluck)
# [14:04] * Disconnected
# [14:05] * Attempting to rejoin channel #css
# [14:05] * Rejoined channel #css
# [14:05] * Topic is 'CSS Working Group discussion'
# [14:05] * Set by fantasai on Mon Aug 02 00:49:50
# [14:36] * Joins: karl (karlcow@128.30.54.58)
# [15:01] * Joins: jdaggett (jdaggett@183.77.242.62)
# [15:30] * Joins: kennyluck (kennyluck@128.30.52.28)
# [16:05] * Joins: szilles (chatzilla@67.188.27.37)
# [16:30] * Joins: Ms2ger (Ms2ger@91.181.33.168)
# [16:31] * Joins: nimbupani (nimbupani@24.22.131.46)
# [17:31] * Joins: glazou (glazou@82.247.96.19)
# [17:31] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [17:31] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
# [17:31] <RRSAgent> logging to http://www.w3.org/2010/09/29-CSS-irc
# [17:31] <glazou> Zakim, this will be Style
# [17:31] <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 32 minutes
# [17:31] <glazou> RRSAgent, make logs public
# [17:31] <RRSAgent> I have made the request, glazou
# [17:34] * Parts: nimbupani (nimbupani@24.22.131.46)
# [17:51] * Joins: oyvind (oyvinds@213.236.208.22)
# [17:57] <glazou> rhâââ european bridge saturated, as usual
# [17:57] <glazou> Zakim, code?
# [17:57] <Zakim> the conference code is 78953 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), glazou
# [18:00] * Joins: murakami (murakami@118.154.209.3)
# [18:00] <Zakim> Style_CSS FP()12:00PM has now started
# [18:00] <Zakim> +glazou
# [18:00] * Joins: bradk (bradk@67.188.133.45)
# [18:01] <Zakim> +[plinss]
# [18:01] * Joins: dethbakin (dethbakin@76.102.99.47)
# [18:01] * Joins: ChrisL (ChrisL@128.30.52.169)
# [18:01] <Zakim> +??P12
# [18:02] <fantasai> Zakim, ??P12 is me
# [18:02] <Zakim> +fantasai; got it
# [18:02] <Zakim> +bradk
# [18:02] * Joins: kojiishi (kojiishi@222.158.227.129)
# [18:03] <Zakim> +??P14
# [18:03] <jdaggett> zakim, p14 is jdaggett
# [18:03] <Zakim> sorry, jdaggett, I do not recognize a party named 'p14'
# [18:03] <jdaggett> zakim, +??P14 is jdaggett
# [18:03] <Zakim> sorry, jdaggett, I do not recognize a party named '+??P14'
# [18:03] <Ms2ger> zakim, ??P14 is jdaggett
# [18:03] <Zakim> +jdaggett; got it
# [18:04] <jdaggett> thx
# [18:04] <glazou> note to self: extra item http://www.w3.org/mid/4C9CC808.7010402@nokia.com
# [18:04] <Ms2ger> np
# [18:04] * Joins: smfr (smfr@72.25.91.178)
# [18:04] <Zakim> +??P18
# [18:04] <Zakim> +ChrisL
# [18:04] * Joins: TabAtkins_ (tabatkins@216.239.45.19)
# [18:05] <Zakim> +[Microsoft]
# [18:05] <Zakim> +smfr
# [18:05] <Zakim> +Bert
# [18:05] <arronei> zakim, microsoft has arronei
# [18:05] <Zakim> + +1.650.214.aaaa
# [18:05] <Zakim> +arronei; got it
# [18:05] <TabAtkins_> zakim, aaaa is me
# [18:05] <Zakim> +TabAtkins_; got it
# [18:06] <glazou> Zakim, who is here?
# [18:06] <Zakim> On the phone I see glazou, [plinss], fantasai, bradk, jdaggett, ??P18, ChrisL, [Microsoft], smfr, Bert, TabAtkins_
# [18:06] <Zakim> [Microsoft] has arronei
# [18:06] * Joins: alexmog (alexmog@131.107.0.117)
# [18:06] <Zakim> On IRC I see TabAtkins_, smfr, kojiishi, ChrisL, dethbakin, bradk, murakami, oyvind, RRSAgent, Zakim, glazou, Ms2ger, szilles, kennyluck, jdaggett, karl, krijnh, arronei, anne,
# [18:06] <Zakim> ... hyatt, tabatkins, shepazu, jgraham, fantasai, plinss_, Bert, plinss, lhnz, Hixie, gsnedders, trackbot
# [18:08] <glazou> Zakim, ??P18 is kojiishi
# [18:08] <Zakim> +kojiishi; got it
# [18:08] <TabAtkins_> ScribeNick: TabAtkins_
# [18:09] <Zakim> +SteveZ
# [18:09] <TabAtkins_> glazou: Request from Art Barstow for extra agenda item.
# [18:09] <glazou> http://www.w3.org/mid/4C9CC808.7010402@nokia.com
# [18:10] <TabAtkins_> glazou: Now, CSS2.1. Where are we with the test suite, IR, etc.?
# [18:10] <TabAtkins_> glazou: First, test suite.
# [18:10] <TabAtkins_> fantasai: There were a bunch of edits checked in by gsnedders about updating metadata.
# [18:10] <TabAtkins_> fantasai: And some other fixes.
# [18:10] <Zakim> +howcome
# [18:10] <TabAtkins_> fantasai: I'm not certain every issue has been addressed. If requested, I could publish a snapshot today.
# [18:10] <TabAtkins_> glazou: What about IR?
# [18:10] <TabAtkins_> smfr: I anticipate that Apple will be able to do test reports.
# [18:11] * Joins: howcome (howcome@80.203.20.94)
# [18:11] <TabAtkins_> smfr: I just need ot know which version to test - we probably won't be able to do this more than once.
# [18:11] <TabAtkins_> arronei: If we were to publish an update, we'll list only the differences from the previous, so you could just run today's testsuite and then run the handful of tests from the new suite.
# [18:11] <TabAtkins_> smfr: That would be fine.
# [18:12] <TabAtkins_> glazou: So for now take the 20100917 version, linked form the testsuite page.
# [18:12] <TabAtkins_> glazou: I pinged Opera and Moz to ask if we could have an impl report from them.
# [18:12] <TabAtkins_> howcome: We should be able to do it, I just need to get the right people internally.
# [18:12] <TabAtkins_> glazou: When do Opera and Apple think they could submit it?
# [18:13] <TabAtkins_> howcome: That's a much harder question to answer. ^_^
# [18:13] <TabAtkins_> glazou: I understand. Mid november, that would be fine. Mid Feb, not so fine.
# [18:13] <TabAtkins_> smfr: We anticipate by the end of Oct, possibly by mid Oct.
# [18:13] <TabAtkins_> howcome: I can't give a date at this point.
# [18:14] * ChrisL can run the tests for Mozilla if that will help; end October sounds realistic. Great to head Opera and Apple stepping up
# [18:14] <TabAtkins_> glazou: Understood; it's not super urgent right now, but we need more IRs more tests that aren't passing in at least 2 yet.
# [18:14] <TabAtkins_> smfr: I implemented a harness that lets you run through the test suite, with a few extra features.
# [18:15] <TabAtkins_> glazou: Great; if you could submit it to the group or www-style it could be useful.
# [18:15] <TabAtkins_> glazou: I would like to warn all members of the WG that some tests require a change of character encoding for the doc, and some browsers reload when they do that.
# [18:15] <TabAtkins_> smfr: Do we have a flag for tests that require a change in character encoding?
# [18:16] <TabAtkins_> TabAtkins_: I don't believe so.
# [18:16] <TabAtkins_> fantasai: Do you mean changing character encoding via UI, via HTTP, via @charset, via <meta>...?
# [18:16] <TabAtkins_> glazou: The ones I was mentioning were about changing it in the UI.
# [18:16] <ChrisL> The ones where usrer interaction is required
# [18:16] <TabAtkins_> fantasai: I think we should mark those as "need user interaction" or do a separate flag.
# [18:16] <TabAtkins_> smfr: I'd prefer a separate flag.
# [18:16] <TabAtkins_> fantasai: Okay.
# [18:17] * Joins: JohnJan (qw3birc@128.30.52.28)
# [18:17] <TabAtkins_> fantasai: Do we need one for general "needs special settings", or should we split it out?
# [18:17] * glazou is really about opera and apple IRs; thanks guys
# [18:17] <glazou> really glad
# [18:17] <TabAtkins_> smfr: I think it's okay to share a flag with user styles.
# [18:17] <TabAtkins_> fantasai: Okay. I can't do that tonight, but I'll look into it.
# [18:17] <Zakim> +[Microsoft.a]
# [18:17] <TabAtkins_> glazou: Enough about the test suite. Bert, you had a list of edits to do.
# [18:18] <TabAtkins_> Bert: I didn't do as much as I had hoped to do. I've done 6, and I think 20 left.
# [18:18] * ChrisL did we hear about IR from Microsoft?
# [18:18] <TabAtkins_> Bert: I assume I can do the remaining edits in 2 weeks.
# [18:18] <TabAtkins_> glazou: Anything blocking any of these?
# [18:18] <TabAtkins_> Bert: I don't think so.
# [18:18] <TabAtkins_> Bert: But I need to review some of Elika's edits.
# [18:19] <Bert> s/Elika's edits/Elika's reviews of my edits/
# [18:19] * Joins: sylvaing (sylvaing@131.107.0.101)
# [18:19] <TabAtkins_> TabAtkins_: I will have the rest of my 2.1 issues on the list by today.
# [18:19] <TabAtkins_> szilles: I sent a message to the list yesterday pointing to the issue I had open.
# [18:19] * sylvaing is unfashionably late
# [18:20] * TabAtkins_ tsk tsk, Sylvain!
# [18:20] <ChrisL> http://wiki.csswg.org/spec/css2.1#issue-198
# [18:20] * sylvaing GPUs don't squat for traffic
# [18:20] <Bert> http://lists.w3.org/Archives/Public/www-style/2010Sep/0674.html
# [18:20] <ChrisL> http://lists.w3.org/Archives/Public/www-style/2010Sep/0674.html
# [18:20] <TabAtkins_> glazou: Can you summarize, Steve?
# [18:21] <TabAtkins_> szilles: The problem is that, with runins, floats inside the runins - how do they relate to floats that precede and follow the runin?
# [18:21] * fantasai proposes marking run-in at risk
# [18:21] <TabAtkins_> szilles: I think we decided in Oslo that runins that run in are rendered/treated as a child of the block. So a float that originally came between the runin and the block is now treated as preceding the runin.
# [18:22] <TabAtkins_> glazou: MS, do you think run-in is sufficiently bad to be at risk?
# [18:23] <TabAtkins_> arronei: runins are pretty much fully implemented in IE and Opera. A few iffy areas around tables, but otherwise the 100+ tests we have are passed by both, and by Safari for many of them.
# [18:23] <TabAtkins_> glazou: So, Elika, is it worth putting it at risk?
# [18:23] <TabAtkins_> fantasai: Eh, if we have interop in everything but floats, that's probably good enough for most people.
# [18:24] <TabAtkins_> szilles: That's separate from the issue at hand, though, about runin and float interaction.
# [18:24] <TabAtkins_> glazou: If it ends up being at risk, we can just mark it undefined.
# [18:24] <TabAtkins_> Bert: I have two things to say.
# [18:25] <TabAtkins_> Bert: First is that the "first line" bit is complicated.
# [18:25] <TabAtkins_> Bert: It's not wrong, it's just unclear I think.
# [18:25] <TabAtkins_> szilles: I'm okay with juts saying "rendered as an inline (refer to section XX)".
# [18:26] <TabAtkins_> Bert: Second was a typo.
# [18:26] * ChrisL can no-one hear me?
# [18:26] * TabAtkins_ No, we can't here you, Chris.
# [18:26] * ChrisL redials
# [18:26] <Zakim> -ChrisL
# [18:26] * TabAtkins_ s/here/hear/
# [18:27] <Zakim> +ChrisL
# [18:28] * ChrisL helooooo????
# [18:28] <glazou> we can't hear you
# [18:28] <Zakim> -ChrisL
# [18:28] <TabAtkins_> szilles: There were comments from bz, but they were just saying that the general area about how floats are painted is undefined, but the actual part I defined is fine.
# [18:28] <glazou> type here pls
# [18:28] <ChrisL> Its is better to me to have normative text included and to put the subfeature at risk
# [18:28] <ChrisL> rather than the whole feature
# [18:28] <ChrisL> or having nio definition and thus no guidance for implementors
# [18:28] <glazou> yes
# [18:29] <bradk> agreed
# [18:29] <TabAtkins_> RESOLVED: Accept szilles' edits regarding floats and runins, but mark the float/runin interaction as at-risk.
# [18:30] * ChrisL "sorry, the number you have reached is not in service" sigh
# [18:30] <TabAtkins_> glazou: Next agenda item would be about CSS3 Color, but tantek isn't on the call and we can't hear Chris.
# [18:30] <TabAtkins_> glazou: We'll skip it and come back.
# [18:30] <ChrisL> noo
# [18:30] <TabAtkins_> glazou: Next is about the style attribute.
# [18:30] <Zakim> +ChrisL
# [18:30] <TabAtkins_> glazou: Bert, I see you sent a request for PR, anything else need to happen?
# [18:31] * TabAtkins_ Still no good, Chris.
# [18:31] <glazou> ChrisL: isn't it YOUR phone ?
# [18:31] <Zakim> -ChrisL
# [18:31] <TabAtkins_> Bert: No, we just need to wait for the telcon.
# [18:31] <TabAtkins_> glazou: next is about epub laiason. Bert?
# [18:31] <TabAtkins_> Bert: w3c has a laiason with the epub group. It's handled by MikeSmith on this side.
# [18:32] <TabAtkins_> Bert: They've asked us to provide more laiason with CSS.
# [18:32] <glazou> plinss_: could you conference ChrisL in ?
# [18:32] <TabAtkins_> Bert: They've shown their schedule for their expected spec, and they seem to be in quite a hurry to get it published.
# [18:32] * ChrisL calls from another phone
# [18:32] <glazou> ok ChrisL
# [18:32] <Zakim> + +39.524.9.aabb
# [18:32] <TabAtkins_> jdaggett: If you dig around in their doc, their set of requirements is fairly jaw-dropping - hyphenation, encoding schemes, etc.
# [18:33] <TabAtkins_> zakim, aabb is ChrisL
# [18:33] <Zakim> +ChrisL; got it
# [18:33] <TabAtkins_> jdaggett: So, what is the goal?
# [18:33] <TabAtkins_> Bert: Good question. I don't have one. I'm asking for how best to coordinate with them; we should also discuss what our goal for coordinating with them as well.
# [18:33] <TabAtkins_> Bert: We should probably tell them that their goal is too high - we can't finish that much of CSS3 in time, but we can do parts of it.
# [18:34] <TabAtkins_> howcome: hyphenation is finished, for example.
# [18:34] <TabAtkins_> Bert: We have good proposals, can they be brought to CR in time?
# [18:34] <TabAtkins_> howcome: I think so, if we fork it out separately.
# [18:34] <TabAtkins_> fantasai: I think I agree with howcome that we can get hyphenation to CR. I'm also trying to get the rest of CSS3 Text to CR, because many of the features they want are in that draft.
# [18:35] <TabAtkins_> Bert: jdaggett, you said there were more features?
# [18:35] <TabAtkins_> jdaggett: Vertical text - we're still arguing about the fundamental properties. It needs to be well-defined by the end of the year.
# [18:35] <TabAtkins_> jdaggett: To meet the epub schedule, at least.
# [18:35] <TabAtkins_> fantasai: We will have two impls by the end of the year.
# [18:35] <TabAtkins_> jdaggett: Impls of what?
# [18:36] <TabAtkins_> fantasai: what Antenna House and what Hyatt wrote for Webkit will be compatible.
# [18:36] <TabAtkins_> jdaggett: What have we agreed upon?
# [18:36] <TabAtkins_> fantasai: AH and Hyatt have implemented logical margins.
# [18:36] <TabAtkins_> howcome: That doens't mean that's what should be defined.
# [18:37] <TabAtkins_> jdaggett: Every time we discuss this we get to a point, but don't put things into a spec.
# [18:37] <TabAtkins_> szilles: What we agreed in Oslo was to see what your proposal was and then discuss it at TPAC.
# [18:37] <TabAtkins_> fantasai: Yes.
# [18:38] <TabAtkins_> Bert: I'd like to go back to coordination with IDPF. Koji, what's your role in there?
# [18:38] <TabAtkins_> kojiishi: I'm willing to take over what Shinyu has been doing.
# [18:38] <TabAtkins_> kojiishi: If you have anything else you expect the IPDF laiason to do beyond what Shinyu has been doing, I can do that.
# [18:38] <TabAtkins_> Bert: You plan to participate in both our meetings and IPDF meetings?
# [18:38] <TabAtkins_> kojiishi: Yes.
# [18:39] <TabAtkins_> kojiishi: [???] is a globalization effort within IPDF. I talk with him often, but I'm otherwise not very familiar with it.
# [18:40] * kennyluck I suppose [???] = Murata
# [18:40] <jdaggett> no ???? = EGLS
# [18:40] <TabAtkins_> s/[???]/EGLS/
# [18:41] <TabAtkins_> kojiishi: i can talk to my contact in IPDF for what they really expect.
# [18:42] <TabAtkins_> howcome: I think something that might help is to have a set of use-cases.
# [18:42] <TabAtkins_> howcome: I think what EPUB is looking for is perhaps simpler than the problem we're seeing on our side.
# [18:43] <TabAtkins_> kojiishi: Vertical text and globalization are on our radar. Hyphenation I'm not tracking right now.
# [18:43] <TabAtkins_> howcome: That's fine. I think the biggest issue we have is vertical text. If we could get proposed use-cases - typical things they need to solve - then we could more easily find a solution for that.
# [18:43] * Quits: lhnz (lhnz@188.223.83.48) (Ping timeout)
# [18:43] <kojiishi> http://code.google.com/p/epub-revision/wiki/EGLS_solutions
# [18:43] <TabAtkins_> szilles: There is a requirements doc that epub is putting out.
# [18:44] <TabAtkins_> kojiishi: They haven't finished the prioritization quite yet. They should have it be their meeting on Oct 5th.
# [18:44] <TabAtkins_> kojiishi: I'll be attending that meeting.
# [18:45] * Joins: lhnz (lhnz@188.223.83.48)
# [18:45] <TabAtkins_> kojiishi: Hopefully we'll find out what we're missing and what items are high priority.
# [18:45] <TabAtkins_> szilles: I believe Adobe will also have a rep on that meeting, though not me.
# [18:45] <TabAtkins_> Bert: Would it be possible to have reps come to our meeting in Lyon in November?
# [18:45] <TabAtkins_> glazou: That would be fine with me.
# [18:45] * kennyluck SZilles: Yes, Yamamoto-san from Adobe
# [18:45] <TabAtkins_> Bert: That we could probably ask via MikeSmith.
# [18:46] <TabAtkins_> Action Bert: Ping MikeSmith about getting IPDF people at TPAC.
# [18:46] * trackbot noticed an ACTION. Trying to create it.
# [18:46] * RRSAgent records action 1
# [18:46] <trackbot> Created ACTION-268 - Ping MikeSmith about getting IPDF people at TPAC. [on Bert Bos - due 2010-10-06].
# [18:46] <murakami> s/IPDF/IDPF/
# [18:46] <TabAtkins_> glazou: We need a laiason; the deadlines of CSS and EPUB don't quite match; we need a closer discussion with EPUB people to really decide something.
# [18:47] <TabAtkins_> ChrisL: Are the EPUB deadlines hard, or are they just a guess?
# [18:47] <TabAtkins_> szilles: I believe they're actually trying to operate toward those deadlines.
# [18:47] * sylvaing i.e. are they like implementation report deadlines, or are they deadlines ? :)
# [18:47] <TabAtkins_> szilles: EPUB primarily wants to base their work on existing standards.
# [18:47] <TabAtkins_> szilles: There was something that Sharp and related companies put together a while back that they're pushing to use.
# [18:48] <TabAtkins_> szilles: The real problem is having something in the near term that would better align with w3c's tech than some of th ealternatives.
# [18:48] <TabAtkins_> szilles: That's partly why teh deadlines are so short.
# [18:49] * TabAtkins_ Chris, I missed that part of what you said, unfortunately.
# [18:49] * TabAtkins_ ChrisL ^^^
# [18:49] <TabAtkins_> szilles: There are certainly a substantial number of people in the EPUB discussion that would prefer an approach that was closer to w3c standards, if they could.
# [18:50] <TabAtkins_> bradk: Can they align with working drafts, perhaps with an epub prefix? Or do they have to have PRs?
# [18:50] <ChrisL> if they dont get the featurs they need from w3c specs would they drop the feature, extebd the deadline, or pick a different source of standards?
# [18:50] * ChrisL tab ^^
# [18:50] <TabAtkins_> szilles: If they like what they think they're going to get, they may accept them before CR, because there's really nothing else out there right now except ISO standards.
# [18:50] <TabAtkins_> kojiishi: I think generally they need CR.
# [18:50] <kojiishi> http://code.google.com/p/epub-revision/wiki/CSS3Relations
# [18:50] * kennyluck they might invent their own -> http://code.google.com/p/epub-revision/wiki/CSS3Relations
# [18:51] <TabAtkins_> kojiishi: As far as I know they haven't decided yet, and they'll be discussing this in Taiwan on Oct 5th.
# [18:51] * fantasai would like to squeeze in a request to publish css3-text before the end of the call
# [18:52] <TabAtkins_> szilles: So, I believe that Elika and friends are tyring to produce a do we can look at and discuss by TPAC, to see if we have neough consensus to move ahead.
# [18:52] <TabAtkins_> jdaggett: There are two specs here - CSS3 Text and CSS3 Writing Modes.
# [18:52] <TabAtkins_> szilles: Elika, you were doing Text, not Writing Modes, right?
# [18:53] * glazou wants the 7 last minutes on css3-color even if this discussion is not finished
# [18:53] <TabAtkins_> fantasai: Right; I've made a lot of edits to Writing Modes, but it's not ready to publish right now. CSS3 Text is ready to publish as a WD.
# [18:53] <TabAtkins_> fantasai: The current CSS3 Text draft is quite outdated. The new draft has addressed nearly all the issues raised with it.
# [18:53] <TabAtkins_> fantasai: I'd like to get a new draft published before the Taiwan meeting next week.
# [18:55] <Zakim> +[Mozilla]
# [18:55] * Joins: tantek (tantek@63.245.220.240)
# [18:55] <jdaggett> jdaggett: i'm fine with publishing a new draft of CSS3 Text
# [18:55] <glazou> 30 seconds before next item plase
# [18:55] <glazou> please
# [18:55] <TabAtkins_> szilles: I haven't looked at the new Text. Has it changed?
# [18:55] <tantek> also for publishing new draft of CSS3 Text
# [18:55] <TabAtkins_> fantasai: Yes, a lot. [lists changes]
# [18:56] <glazou> TIME
# [18:56] * ChrisL pointer to editors draft?
# [18:56] <jdaggett> glazou: let's resolve to publish and move one
# [18:56] <kojiishi> http://dev.w3.org/csswg/css3-text/
# [18:56] <TabAtkins_> RESOLVED: Publish a new WD of CSS3 Text.
# [18:56] * fantasai thanks jdaggett !
# [18:56] <tantek> ChrisL - maybe this: http://dev.w3.org/csswg/css3-text/
# [18:56] <TabAtkins_> glazou: Now, CSS3 Color.
# [18:56] * jdaggett np
# [18:57] <ChrisL> http://dev.w3.org/csswg/css3-color/issues-lc-2008.html
# [18:57] <tantek> Thanks much Chris!
# [18:57] <TabAtkins_> ChrisL: I spent today making a Disposition of Comments. It's not in a great shape.
# [18:57] <TabAtkins_> ChrisL: We need what the WG did, what the commenter responded, etc.
# [18:57] <TabAtkins_> ChrisL: We have at least 3 where the commenter said they weren't happy, a bunch where they didn't respond, and 1 from the XSL WG where we didn't respond to them at all (we made edits, but didn't tell them).
# [18:58] <TabAtkins_> ChrisL: We mostly agreed with them, which makes it easy.
# [18:58] <TabAtkins_> ChrisL: I sent out a few others asking for confirmation.
# [18:59] * jdaggett oh, that's cute...
# [18:59] * sylvaing ...as long as CSS4 has normative Unicornosity...
# [18:59] <glazou> lol
# [18:59] <TabAtkins_> tantek: The DoC is looking good, thanks for writing it up.
# [19:00] <TabAtkins_> ChrisL: I didn't get the biblio updated, but I will.
# [19:00] * TabAtkins_ we need another color name - 'unicorn'=rgba(255,105,180,.5).
# [19:01] <TabAtkins_> tantek: Did you see the most recent followup regarding scRGB?
# [19:01] * sylvaing I was just thinking color:unicorn should map to some nifty gradient
# [19:01] <TabAtkins_> ChrisL: There was a recent discussion about adding a bunch of ICC spaces.
# [19:01] * glazou sylvaing with 90° north ?-)
# [19:01] <TabAtkins_> ChrisL: Should we treat it as an LC comment or what?
# [19:02] * sylvaing 9e1deg you mean ?
# [19:02] <TabAtkins_> tantek: I think it's out of scope right now. We should reject it for now, and have it as possible functionality for CSS4 Color.
# [19:02] <glazou> sylvaing: lol
# [19:02] * bradk lol
# [19:02] <TabAtkins_> tantek: Does the DoC look good otherwise?
# [19:02] <TabAtkins_> ChrisL: The XSLWG response we should probably wait a week or so for.
# [19:03] <TabAtkins_> tantek: So we're pretty happy with the DoC, and we'll give commenters a week or two to respond. What's next?
# [19:04] <TabAtkins_> ChrisL: Then we produce a director's ???, showing that we exit CR correctly.
# [19:04] <TabAtkins_> glazou: Any normative dependency on CSS2.1?
# [19:04] <TabAtkins_> ChrisL: yes.
# [19:04] <TabAtkins_> glazou: So it'll be at the same state as CSS3 Selectors?
# [19:04] <TabAtkins_> ChrisL: Yeah. It precludes PR, but not Rec.
# [19:04] <TabAtkins_> glazou: So yeah, we need to push CSS2.1 quick.
# [19:05] <TabAtkins_> ChrisL: Selectors already has "provisional Rec" contingent on CSS2.1 going to Rec.
# [19:05] <Zakim> -smfr
# [19:05] <Zakim> -SteveZ
# [19:05] <Zakim> -[Microsoft]
# [19:05] <Zakim> -[Microsoft.a]
# [19:05] <Zakim> -howcome
# [19:05] <Zakim> -jdaggett
# [19:05] <Zakim> -ChrisL
# [19:05] <Zakim> -[Mozilla]
# [19:05] <Zakim> -glazou
# [19:05] <Zakim> -Bert
# [19:05] <Zakim> -kojiishi
# [19:05] <Zakim> -fantasai
# [19:05] <glazou> View mode review request for email or next telcon
# [19:05] <Zakim> -TabAtkins_
# [19:05] <Ms2ger> ...Adjourned?
# [19:05] <glazou> yes
# [19:06] <TabAtkins_> Nope, simultaneous mass murder.
# [19:06] <glazou> lol
# [19:06] <fantasai> lol
# [19:06] <glazou> TabAtkins_: saw my private msg?
# [19:06] <TabAtkins_> glazou: yeah.
# [19:06] <tantek> TabAtkins_ to be clear it does NOT preclude PR
# [19:06] <tantek> it does preclude REC
# [19:06] <tantek> (per minutes above)
# [19:06] <TabAtkins_> Argh, I reversed them.
# [19:07] <TabAtkins_> fantasai: Could you fix that when you prepare minutes?
# [19:07] <tantek> glazou - did we record an action for Bert to setup a call with the Director?
# [19:07] <ChrisL> s/It precludes PR, but not Rec./It precludes Rec, but not PR
# [19:07] <tantek> or are we doing that later?
# [19:07] * Quits: bradk (bradk@67.188.133.45) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
# [19:07] <Bert> better wait until we actually have the DoC ready.
# [19:08] <Bert> (And maybe Chris and do it himself? That saves me work :-) )
# [19:08] * glazou has to go, bye people
# [19:08] <ChrisL> bert, yes I can do it once DoC is ready
# [19:08] * Quits: glazou (glazou@82.247.96.19) (Quit: glazou)
# [19:08] * Quits: kojiishi (kojiishi@222.158.227.129) (Quit: Leaving...)
# [19:08] * Quits: TabAtkins_ (tabatkins@216.239.45.19) (Quit: Lost terminal)
# [19:08] * Quits: JohnJan (qw3birc@128.30.52.28) (Quit: Page closed)
# [19:08] * Parts: murakami (murakami@118.154.209.3) (Leaving...)
# [19:08] <Zakim> -[plinss]
# [19:08] <tantek> Bert, ChrisL - excellent - thanks much!
# [19:09] <tantek> ChrisL - how much time did you want to give commenters to follow-up? is a week sufficient or would you be more comfortable with 2 weeks?
# [19:10] <ChrisL> I think a week is reasonable. Willtalk with xsl fo staff contact
# [19:10] * Parts: smfr (smfr@72.25.91.178)
# [19:11] <tantek> ok
# [19:13] <Zakim> disconnecting the lone participant, bradk, in Style_CSS FP()12:00PM
# [19:13] <Zakim> Style_CSS FP()12:00PM has ended
# [19:14] <Zakim> Attendees were glazou, [plinss], fantasai, bradk, jdaggett, ChrisL, smfr, Bert, +1.650.214.aaaa, arronei, TabAtkins_, kojiishi, SteveZ, howcome, [Microsoft], +39.524.9.aabb,
# [19:14] <Zakim> ... [Mozilla]
# [19:14] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Fire on main board error, client combusted)
# [19:16] * Quits: oyvind (oyvinds@213.236.208.22) (Quit: oyvind)
# [19:18] * Quits: dethbakin (dethbakin@76.102.99.47) (Quit: dethbakin)
# [19:19] * Quits: sylvaing (sylvaing@131.107.0.101) (Connection reset by peer)
# [19:29] <fantasai> RRSAgent: make minutes
# [19:29] <RRSAgent> I have made the request to generate http://www.w3.org/2010/09/29-CSS-minutes.html fantasai
# [19:29] <fantasai> RRSAgent: make logs public
# [19:29] <RRSAgent> I have made the request, fantasai
# [19:29] <fantasai> RRSAgent: make minutes
# [19:29] <RRSAgent> I have made the request to generate http://www.w3.org/2010/09/29-CSS-minutes.html fantasai
# [19:30] * Joins: sylvaing (sylvaing@131.107.0.80)
# [19:48] * Quits: szilles (chatzilla@67.188.27.37) (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854])
# [20:19] * Joins: dbaron (dbaron@63.245.220.240)
# [20:24] <hyatt> fantasai: ultimately writing-mode will be its own draft right
# [20:24] <hyatt> fantasai: and not part of that gigantic text draft?
# [20:42] * Quits: lhnz (lhnz@188.223.83.48) (Connection reset by peer)
# [20:42] * Joins: lhnz (lhnz@188.223.83.48)
# [20:47] * Quits: lhnz (lhnz@188.223.83.48) (Connection reset by peer)
# [20:47] * Joins: lhnz (lhnz@188.223.83.48)
# [20:49] * Zakim excuses himself; his presence no longer seems to be needed
# [20:49] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [21:57] * Quits: sylvaing (sylvaing@131.107.0.80) (Ping timeout)
# [22:06] * Joins: ChrisL (ChrisL@128.30.52.169)
# [22:18] * Quits: karl (karlcow@128.30.54.58) (Client exited)
# [22:52] * Quits: tantek (tantek@63.245.220.240) (Quit: tantek)
# [23:13] * Joins: karl (karlcow@128.30.54.58)
# [23:15] * Quits: lhnz (lhnz@188.223.83.48) (Ping timeout)
# [23:16] * Joins: lhnz (lhnz@188.223.83.48)
# [23:21] * Joins: sylvaing (sylvaing@131.107.0.101)
# [23:23] * Quits: Ms2ger (Ms2ger@91.181.33.168) (Quit: nn)
# [23:25] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Fire on main board error, client combusted)
# [23:26] * Joins: nimbupani (nimbupani@24.22.131.46)
# [23:36] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# Session Close: Thu Sep 30 00:00:00 2010

The end :)