/irc-logs / w3c / #css / 2011-12-07 / end

Options:

# Session Start: Wed Dec 07 00:00:00 2011
# Session Ident: #css
# [00:20] * Quits: ksweeney (ksweeney@63.119.10.10) (Quit: Leaving.)
# [00:43] * Quits: dbaron (dbaron@159.63.23.38) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [00:43] * Joins: dbaron (dbaron@159.63.23.38)
# [00:54] <fantasai> tantek: http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0095.html
# [01:04] <fantasai> TabAtkins: yo, unless you want to write the blog post yourself, I need a quick summary of what's changed in flexbox since the last draft
# [01:08] * Quits: plinss (plinss@192.6.114.30) (Quit: plinss)
# [01:19] * Joins: miketaylr (miketaylr@24.42.93.245)
# [01:36] <tantek> fantasai - oh hey that's kinda neat: http://www.la-grange.net/2011/12/05/w3c-spec-status-prototype
# [01:42] * Joins: jdaggett (jdaggett@202.221.217.73)
# [01:43] <stearns> I particularly like the status indicator
# [01:47] <pjrm> Re optimizing specs for web devs: The following might not make a difference to decisions about where the top matter should be placed within the spec, but: Definitely we should optimize for the needs of web devs. In practice web devs need CSS to be implemented much more than they need to read the specs: most web devs can't even read English, while most of those who can don't read the specs to find how to do things. What web devs are crying out for first of all i
# [01:48] <fantasai> pjrm: that got cut off, mind reposting in smaller pieces?
# [01:51] <pjrm> Re optimizing specs for web devs:
# [01:51] <pjrm> The following might not make a difference to decisions about where the top matter should be placed within the spec, but:
# [01:51] <pjrm> Definitely we should optimize for the needs of web devs.
# [01:51] <pjrm> In practice web devs need CSS to be implemented much more than they need to read the specs: most web devs can't even read English, while most of those who can don't read the specs to find how to do things.
# [01:52] <pjrm> What web devs are crying out for first of all is that CSS works on common browsers, and works interoperably.
# [01:52] <pjrm> I believe this means we should recognize optimize for getting CSS implemented in a way that meets the needs of web devs (and other authors, and of course the readers of their content).
# [01:52] <pjrm> (Of course I may well be biased by being an implementor.)
# [01:53] <pjrm> s/recognize optimize/optimize/
# [01:55] * Quits: cyril (chatzilla@203.12.172.254) (Quit: ChatZilla 0.9.87 [Firefox 8.0/20111104165243])
# [01:56] <fantasai> pjrm: I think I'm missing something here. You say we should optimize for web devs, but then argue for optimizing for implementers.
# [01:56] <pjrm> i said optimize for the needs of web devs, but recognizing that the needs of web devs doesn't necessarily include reading the spec themselves.
# [01:57] <fantasai> ah
# [01:57] <fantasai> ok, that makes sense then :)
# [01:57] * fantasai thinks we should write the specs in a way that's comfortable and makes sense to both, even if it's not absolutely the most efficient to either
# [02:01] <pjrm> This was something I was thinking of in the context of the dilemma of how to write the the containing block text (10.1), and the question of whether to write things in terms of elements or boxes.
# [02:01] <pjrm> Writing in terms of elements makes it easier to get a general feel of how things work, but only if you don't actually need to know how it works in general (various tree manipulation things such as list items, anonymous table objects, and (at the time) run-in), in which case writing in terms of boxes makes things better.
# [02:01] <pjrm> I was thinking that the solution might be first to use some introductory text in terms of elements, but to give the normative text in terms of boxes.
# [02:02] <fantasai> yeah, I try to organize my spec text in a way that the web-designer can find what they're looking for at the top, and it gets more technical and edge-casy as you go down the section
# [02:02] <fantasai> :)
# [02:02] * fantasai thinks Tantek tries to do that too
# [02:22] * Quits: stearns (anonymous@192.150.22.5) (Ping timeout)
# [02:24] <brianman> fantasai - while you're discussing formatting and readability of specs...
# [02:25] <brianman> Something to consider is being "clever" in the online version of the specification such that you can click "web dev view" and "implementer view" buttons, with different presentations.
# [02:25] <brianman> Another view might be "grammar and syntax only please."
# [02:25] <brianman> grammar and examples* I meant.
# [02:25] <fantasai> Hm
# [02:25] <fantasai> The latter I think we can do
# [02:26] <fantasai> the former...
# [02:26] <fantasai> I don't think it's actually a clear distinction
# [02:26] <fantasai> The examples etc. help implementers understand what they're trying to implement
# [02:26] <brianman> Perhaps not; just something to consider if you find conflicting goals w/r/t audience.
# [02:27] <fantasai> And the implementation notes, while they might not be interesting to an author in general, hiding them is imo harmful to the few who might be looking for more detail on something
# [02:27] <brianman> Implementer view might include "don't forget that 0 without units is the devil for parsing", while a webdev mostly doesn't care.
# [02:27] <fantasai> heh
# [02:27] <fantasai> well
# [02:27] <fantasai> that is something you'll have to remember yourself :)
# [02:28] <brianman> heh
# [02:28] <brianman> And webdev view might include "if your numbers are near-zero, expect non-interoperable behavior".
# [02:29] <fantasai> I think the important thing is, as Tantek said, progressive disclosure. Put the overview at the top. Put simple descriptions of what the goal of the property /value is up front. Then dig into the details later.
# [02:29] <fantasai> that way you only need to read as far as until you've got your answer
# [02:29] <fantasai> and most people will find their answers up front
# [02:30] <pjrm> one gotcha there is that sometimes it's hard to distinguish informative "roughly speaking this is true" from a normative statement. Sometimes you see the rough statement and think you have the answer to your question and stop reading.
# [02:30] <fantasai> That helps web devs to find things quickly and not get lost in details
# [02:30] <fantasai> and it helps implementers understand the thing overall so they can plug the details into some kind of conceptual framework
# [02:30] <fantasai> rather than having a pile of details to sort out without guidance
# [02:31] <brianman> It would be a fun exercise to add buttons to sections of the ED that say "click this to make this text larger".
# [02:31] <fantasai> pjrm: good point, we should be careful about those
# [02:31] <brianman> And see which text ends up larger over time. Feedback mechanism from audience.
# [02:31] <fantasai> pjrm: I try to, in CSS3 specs
# [02:31] <fantasai> pjrm: Admittedly, as always, CSS2.1 prose is a mess
# [02:32] <fantasai> pjrm: I don't expect that to improve; we're not doing any editorial rewrites there, just error-correction
# [02:32] * brianman is tempted to apply the Turing Test to krijnhuman.
# [02:32] <pjrm> above someone linked to the whatdev page on spec writing, which suggested the approach that every normative statement contain must/should/may, and that every other sentence is to be considered as non-normative. (I don't know if they follow this rule strictly.)
# [02:32] <fantasai> Yeah, we don't do that in CSS.
# [02:33] <tantek> yes I linked to that
# [02:33] <tantek> it's something to consider
# [02:33] <brianman> "Every normative sentence must contain must, should, or may."
# [02:33] <fantasai> I found, actually, Tab tried to do that in part of css3-images, and got the behavior wrong
# [02:33] <tantek> and see if we can take some of the points mentioned there to improve
# [02:33] <tantek> not necessarily in entirety
# [02:33] <fantasai> WHATWG tends to write more interms of algorithms
# [02:33] <fantasai> CSSWG tends to write more in terms of constraints
# [02:35] <fantasai> For informative sentences, I will use terms like "generally" or "typically" or something else to signal that it's not a normative constraint
# [02:35] <fantasai> or, of course, indicate something is an example or a note
# [02:37] <tantek> fantasai - apparently my using the term "obstructionist" previously was open to misinterpretation. To be clear - in no way do I expect anyone in the CSSWG to be obstructionist.
# [02:37] <fantasai> I don't either
# [02:37] <pjrm> part of the reason that whatwg [sorry, i knew i had that wrong when i wrote whatdev, i just couldn't think what the right thing was] can write in terms of algorithms is that whatwg specs have a license that allows derivative works.
# [02:37] <pjrm> css specs are published under a "no derivatives" license.
# [02:37] <fantasai> pjrm: I think that's totally irrelevant
# [02:37] <fantasai> pjrm: It's a different spec-writing approach, and there are advantages and disadvantages to both
# [02:38] <tantek> pjrm - true - hence some new stuff is being worked on separately, but yes is orthogonal to the format/style of specs issue.
# [02:38] * Joins: arronei (arronei@131.107.0.84)
# [02:38] <tantek> what fantasai said
# [02:38] <fantasai> tantek: But I do expect the WG to request adequate time to review whatever it is you want to push to LC
# [02:38] <tantek> fantasai - I don't necessarily
# [02:38] <pjrm> i did say "part of the reason"
# [02:38] <fantasai> tantek: I don't consider that being obstructionist, it's fair to request adequate review time.
# [02:38] * Quits: arronei_ (arronei@131.107.0.113) (Ping timeout)
# [02:38] <tantek> I don't know what "the WG" means
# [02:38] <tantek> without speaking about specific individuals and their concerns
# [02:39] <tantek> sure, technically process allows for a lot more stalling than necessary, but I don't expect anyone to do that.
# [02:40] <fantasai> it's not about stalling, it's about you haven't published those edits and asked for review, so people who aren't following your cvs logs (which is most people) haven't reviewed them
# [02:40] <tantek> and yes it's possible there are folks that do care about the new features that haven't necessarily kept up with www-style and/or the editor's drafts.
# [02:40] <tantek> but my understanding/expectation is that most have (been keeping up)
# [02:40] <tantek> you can shoot me down later for being an optimist :p
# [02:40] <tantek> (and no I don't think cvs logs are sufficient notification either)
# [02:41] <fantasai> nah, I don't need to shoot you. If your optimism fails, you'll just get "we want x weeks to review the draft" and no resolution to publish :)
# [02:42] <fantasai> and, fwiw, I have not reviewed your draft
# [02:42] <brianman> There's another aspect to the time component.
# [02:42] <fantasai> I've only been skimming your messages to www-style
# [02:42] * fantasai can barely keep up with anything these days
# [02:42] <tantek> fantasai - you've had perhaps the most direct input of anyone into the text of text-overflow :P
# [02:42] <tantek> in-person even
# [02:42] <fantasai> true, but I haven't looked at anything else in the draft
# [02:42] <fantasai> and I haven't looked at it since :)
# [02:42] <brianman> Even if everybody is completely current, the CSSWG (and perhaps the W3C) seems to feel "it needs some realtime/walltime" to breathe/bake w/r/t draft publishing.
# [02:43] <tantek> I think ime-mode is the only other new feature
# [02:43] <brianman> For better or worse.
# [02:43] * tantek is going to drop pointer-events from css3-ui and punt it to 4 since hit-testing is *totally new*
# [02:43] <tantek> brianman - I've never understood the breathe/bake w/r/t draft publishing
# [02:43] <tantek> live updating drafts makes much more sense per editor's drafts and whatwg
# [02:43] <brianman> I'm just observing, not agreeing/disagreeing.
# [02:43] <tantek> yeah totally
# [02:44] <brianman> I do have some strong opinions about "living specs" but that's a longer discussion than 2011 allows.
# [02:44] <tantek> hah true
# [02:44] <tantek> I like living specs and stabilizing/versioned forks off of those.
# [02:45] <tantek> hence I like working in both modes
# [02:45] <brianman> IMO, that's not a living spec.
# [02:45] <brianman> (which is a good modification)
# [02:45] <tantek> which "that"?
# [02:46] <brianman> My concern was about the "current draft spec" always being an hourly publish.
# [02:46] <brianman> The snapshot model I think you're referring to is a different beast, and doesn't bother me.
# [02:46] * tantek would love to see a living "CSS" spec that realtime automatically incorporates "stable" specs (similar to the Beijing processes, but actually pulls everything inline into one mega spec on a daily basis or something)
# [02:46] <brianman> Yah, that doesn't work.
# [02:46] <fantasai> yeah, my computer will freeze :(
# [02:46] <brianman> Unless your implementations *compile* directly from the spec...which is skynet.
# [02:46] <tantek> for some people, it works, for others it doesn't. that much is clear.
# [02:47] <brianman> For nobody it works.
# [02:47] <brianman> Implementation isn't that fast.
# [02:47] <fantasai> tantek: What we *are* doing is slowly incorporating more indexing into the Snapshot
# [02:47] <brianman> Interoperable implementations is nowhere near that fast.
# [02:47] <fantasai> tantek: The 2010 has an index by property
# [02:47] <fantasai> tantek: I'm hoping to work in a glossary at some point as well
# [02:47] <tantek> fantasai - yes - that's an excellent improvement
# [02:48] <tantek> brianman - you might have better luck discussing pros/cons of living spec as a strategy in Freenode#whatwg.
# [02:48] <brianman> I'll pass for now, but good to know. ;)
# [02:48] <brianman> fantasai - While you're here... where (in any spec) does it say "top" keyword should be resolve to a number or percentage as part of "computed"?
# [02:48] <brianman> Arron nudged me that direction but I couldn't find the backing spec.
# [02:50] <fantasai> http://www.w3.org/TR/css3-background/#the-background-position
# [02:50] <fantasai> See the Computed value line and also the definitions of the keywords.
# [02:50] <fantasai> I suppose "Equivalent to" should be "Computes to"
# [02:51] <brianman> Yes, computes to would help dramatically
# [02:51] <fantasai> one sec...
# [02:51] <brianman> equivalent to reads as a rendering observation to me
# [02:51] <fantasai> :)
# [02:51] <brianman> related question
# [02:51] <brianman> "If three or four values are specified, two pairs of a keyword plus a length or percentage. "
# [02:51] <fantasai> http://www.w3.org/TR/CSS21/colors.html#propdef-background-position
# [02:52] <brianman> What is the computed value of "center bottom 3px"?
# [02:52] <fantasai> CSS2.1 requires a <length> or <percentage> as the computed value
# [02:52] <fantasai> so, it's clear it needs to compute
# [02:53] <brianman> I don't read that.
# [02:53] <brianman> "Computed value:
# [02:53] <brianman> for <length> the absolute value, otherwise a percentage "
# [02:53] <fantasai> right
# [02:53] <brianman> Actually, maybe it's a language barrier.
# [02:53] <fantasai> so you can't preserve the keyword as a keyword
# [02:53] <fantasai> therefore the "equivalent to" needs to be interpreted as "computes to"
# [02:53] <brianman> k, I can let that one go as good enough
# [02:54] <brianman> See second question above. Your thoughts?
# [02:54] <fantasai> good enough for 2.1, anyway :)
# [02:54] <brianman> yah
# [02:54] <fantasai> brianman: check that - http://dev.w3.org/csswg/css3-background/#the-background-position
# [02:54] <fantasai> ok, second question
# [02:55] <fantasai> that gets computed to "left 50% bottom 3px"
# [02:55] <fantasai> falls under the "If three or four values" clause
# [02:55] <brianman> that seems confusing and bizarre to me
# [02:55] <brianman> that's how i read it from the text in the spec, but i think it's a bad choice
# [02:55] <fantasai> and 'center' is specified as computing to either 'left 50%' or 'top 50%' depending
# [02:55] <fantasai> ok
# [02:56] <fantasai> why is it a bad choice, and what would be better?
# [02:56] <brianman> Ok so two questions you're asking...
# [02:56] <brianman> why is it left / top not right / bottom?
# [02:56] <brianman> (right 50%) and (bottom 50%)
# [02:57] <brianman> is it "center is equivalent to 50%, is equivalent to left 50%"?
# [02:57] <fantasai> yes
# [02:57] <brianman> (and similar for vertical)
# [02:57] <fantasai> because the two-value syntax uses offsets from the top left
# [02:57] <brianman> That's like 4 steps from obvious. Not sure how to fix it. Maybe an example in the spec would at least capture the subtleties here.
# [02:57] <fantasai> I figured it would be more consistent to continue that when computing center
# [02:58] <brianman> and the second aspect.... why is it a bad choice
# [02:58] <brianman> Authors write "center 20px" and get back "left 50% top 20px" and immediately think wtf.
# [02:58] <fantasai> no, no they don't
# [02:58] <brianman> It's longer and non-obvious how you got there.
# [02:58] <fantasai> if they write 'center 20px' they get back '50% 20px'
# [03:03] <brianman> perhaps...
# [03:03] <brianman> sec
# [03:05] <brianman> specified: center top 20px => left 50% top 20px
# [03:05] <brianman> specified: center 20px -> 50% 20px
# [03:05] <fantasai> right
# [03:05] <brianman> The specified are supposed to be equivalent but they have different computed values.
# [03:05] <brianman> That's bizarre.
# [03:06] <fantasai> as soon as you use the extended syntax (3 or more values) you get the 4-value syntax
# [03:06] <brianman> Yah, I think that's wrong.
# [03:06] <brianman> Wrong is probably the wrong word. Undesirable.
# [03:06] <fantasai> What would you change?
# [03:06] <fantasai> 'center 20px' *has to* compute to '50% 20px'
# [03:06] <fantasai> that's specified by 2.1
# [03:06] <brianman> From CSSOM (and other), my mindset was/is that things that are logical equivalent should be stored in the OM equivalently.
# [03:06] <brianman> Given the example above, that is violated.
# [03:07] <fantasai> 'center bottom 50px' can't compute to '50px bottom 50px' because that's invalid
# [03:07] <brianman> We have to store an extra bit (at least) to remember the input format so that we can compute differently when queried.
# [03:07] <brianman> you mean 50% and i agree
# [03:07] <fantasai> yeah
# [03:07] <fantasai> so
# [03:07] <brianman> I think the input format should have little/no bearing on the output format.
# [03:07] <fantasai> I agree with your principle
# [03:07] <fantasai> but I couldn't figure out a way to make it work
# [03:08] <brianman> If it can be reduced to an equivalent simpler expression it should be.
# [03:08] <brianman> I would prefer something more like....
# [03:09] <brianman> Computed value: <Length> values becomes absolute lengths. When possible, two-value output. Otherwise, three-value output. Otherwise, four-value output. When possible, keywords are replaced with percentages.
# [03:09] * Joins: stearns (anonymous@50.132.63.33)
# [03:10] <brianman> Correction: "Otherwise when possible, three-value output."
# [03:10] <brianman> In short -- minimal canonical form, avoid keywords when possible. Lengths resolve to absolute value.
# [03:12] <fantasai> so..
# [03:13] <fantasai> 'center bottom 5px' would compute to exactly that?
# [03:13] <fantasai> wait no
# [03:13] <fantasai> and 'center top 5px' would compute to '50% 5px'?
# [03:13] <fantasai> that seems counter-intuitive, too
# [03:14] <brianman> correct it would
# [03:14] <fantasai> ...
# [03:14] <fantasai> I'm not sure that's better :)
# [03:14] <brianman> center top 5px == center 5px => 50% 5px
# [03:14] <brianman> the original is non-minimal
# [03:14] <fantasai> true, but it's more consistent to the input
# [03:15] <brianman> right but again my point
# [03:15] <brianman> the UA should be allowed to store the *meaning* not the *format* of the input
# [03:15] <brianman> and always output a minimal canonical form
# [03:15] <fantasai> well
# [03:15] <brianman> IMO
# [03:15] <fantasai> toss the issue onto www-style
# [03:15] <brianman> I did
# [03:15] <brianman> no reply
# [03:15] <fantasai> ah
# [03:15] <brianman> my big mail with 12 examples
# [03:15] <brianman> or whatever
# [03:15] <brianman> chew on it, we can talk about it later
# [03:15] <brianman> 1 more quick thing....
# [03:15] * fantasai wonders who implemented this for Mozilla
# [03:16] <fantasai> I don't have much of an opinion on the best way to resolve this conflict between consistency and minimalism
# [03:16] <brianman> If I can "become more minimal" by flipping a percentage to the other side of the [0%, 100%] band, should I?
# [03:16] <fantasai> no
# [03:16] <brianman> I agree.
# [03:16] <brianman> We should capture that in the spec(s).
# [03:16] <fantasai> good point
# [03:16] <brianman> Because Tab didn't argue that it was disallowed when I asked.
# [03:16] <fantasai> we should ask Anne wrt the other point
# [03:16] <brianman> (He had no opinion yhet.)
# [03:16] <brianman> yet*
# [03:17] <brianman> Both Tab and Brad said ask you. :P
# [03:17] <fantasai> Dude, I am so not a CSSOM person.
# [03:17] <brianman> re: background-position, computed
# [03:17] <fantasai> My concern wrt computed styles is what inherits
# [03:17] <pjrm> (It's tempting to say that the answer should be "50% (100% - 5px)", but I suspect that that opens a can of worms.)
# [03:17] <fantasai> in this case, it doesn't make a difference
# [03:17] <fantasai> so it becomes a CSSOM issue
# [03:17] <brianman> I think you mean calc there, pjrm?
# [03:17] <pjrm> yes
# [03:17] <brianman> And I didn't mean that example
# [03:18] <brianman> I meant "50% (100% - 20%)" -> "50% 80%"
# [03:18] <brianman> valid and equivalent, but confusing
# [03:18] <brianman> center bottom 20% =(compute)=> 50% 80%
# [03:19] <brianman> to reiterate: I think we shouldn't do that. Just expressing the example.
# [03:19] <brianman> fantasai - A little more context: this plays directly into radial-gradient implementation work going forward, which gives it new visibility than just css3-backgrounds
# [03:20] <brianman> Which is why I ran into it again recently.
# [03:20] <fantasai> ah
# [03:20] <brianman> And don't even get me started on calc. :P
# [03:21] <fantasai> well, again, I think Anne has given the most thought to what computed values should return
# [03:21] <fantasai> dbaron also
# [03:21] <fantasai> I'd defer to those two on this issue
# [03:21] <brianman> I thought Anne stepped aside.
# [03:21] <fantasai> Doesn't make him any less an expert :)
# [03:21] <brianman> So I guess dbaron.
# [03:21] <brianman> We have plenty of "not fixing it" experts. :P
# [03:21] <brianman> addressing* it
# [03:21] <brianman> We need editors and such
# [03:21] <fantasai> I'll fix it, I just want to know what to fix it /to/
# [03:21] <brianman> Understood.
# [03:22] <brianman> Fix it to what I said. :P
# [03:22] <brianman> Solved.
# [03:22] <fantasai> Heh, nope
# [03:22] <brianman> :(
# [03:22] <fantasai> This is a CR spec, needs a WG resolution
# [03:22] <brianman> Yah, yah.
# [03:22] <fantasai> and for Opera/Mozilla/Webkit to agree that they'll implement whatever's specced ;)
# [03:22] <brianman> Holidays are coming up. Soon I won't have bandwidth for much of this until January. Fair warning.
# [03:24] <dbaron> what about calc() ?
# [03:24] <brianman> Hah, someone woke him up.
# [03:25] <brianman> I don't have calc spec issues to articulate (yet). Mostly spec implementation and interop issues to explore.
# [03:25] <fantasai> brianman: https://www.w3.org/Style/CSS/Tracker/issues/197 ask sylvain to make sure it gets on the agenda by whenver you need it on the agenda
# [03:25] * Quits: tantek (tantek@159.63.23.38) (Quit: tantek)
# [03:25] * tantek_ is now known as tantek
# [03:25] <brianman> issue 197 - thx. that covers it well enough.
# [03:26] * fantasai will probably otherwise defer all css3-background issue to next year on account of having too much stuff to do to even remember whatit all is
# [03:26] <brianman> One specific example, since dbaron's awake...
# [03:27] <dbaron> I don't think the "Computed value" lines in the spec are syntactic. They're semantic
# [03:27] <dbaron> so I don't understand https://www.w3.org/Style/CSS/Tracker/issues/197
# [03:27] <brianman> Restate, dbaron?
# [03:28] <dbaron> "Computed value:" lines in the spec have no bearing on syntax
# [03:28] <brianman> They have bearing on inherit behavior.
# [03:28] <dbaron> but that's semantic rather than syntactic
# [03:28] <brianman> And on OM querying behavior for computedvalue.
# [03:28] <dbaron> no, no effect on OM
# [03:28] <dbaron> that's used values
# [03:28] <brianman> ok, that totally confuses me
# [03:28] <brianman> ComputedValue returns used values?
# [03:29] <dbaron> yep
# [03:29] <brianman> and %s stay percentages in used value form?
# [03:29] <dbaron> no spec defines that
# [03:29] <brianman> lovely
# [03:29] <fantasai> um
# [03:29] <dbaron> though in most cases no
# [03:29] * Quits: tantek (tantek@159.63.23.38) (Quit: tantek)
# [03:29] <dbaron> but for background-position they have to
# [03:29] <dbaron> since it's an exception
# [03:29] <dbaron> but no spec defines that
# [03:29] <brianman> So when I query computed value, I might get percentages, I might not, it's anybody's guess?
# [03:29] <dbaron> right
# [03:30] <brianman> fail
# [03:30] <dbaron> there's pretty good interop in most cases, though
# [03:30] <brianman> A spec that undefines more than it defines is bad.
# [03:30] <brianman> Not that I'm seeing.
# [03:30] <brianman> Arron saw otherwise as well.
# [03:30] <brianman> But that can be fixed.
# [03:30] <brianman> So let me ask my question another way...
# [03:31] <brianman> Why does the computed value line for background-position say anything about the number of values output or the format of them?
# [03:31] <brianman> Instead of just saying what needs to be resolved.
# [03:31] <dbaron> I'd call that a mistake in the spec
# [03:31] <dbaron> though sometimes it's easy to define semantics with syntax
# [03:32] <brianman> Clarify: agree with my "just say" proposal?
# [03:32] <fantasai> brianman: I've clarified the spec to deal with the other issue you raised about it, too
# [03:33] <brianman> fantasai - which spec and where (so I can look)?
# [03:33] <fantasai> same one
# [03:33] <fantasai> background-position
# [03:33] * fantasai forgets what she was supposed to clarify against now
# [03:33] <brianman> ed/cr?
# [03:33] <fantasai> ed
# [03:33] <brianman> sorry, the clarify question was for dbaron
# [03:33] * fantasai is getting very confused now...
# [03:33] <brianman> Let me try to be more explicit...
# [03:34] <fantasai> I think my working memory is corrupted
# [03:34] * fantasai needs a reboot
# [03:34] <brianman> 1- dbaron: Do you agree with my assertion that we should remove the number of values and the formatting language from the computed-value line of background-position, instead just speaking to which values resolve to absolute lengths?
# [03:34] <brianman> 2- fantasai: which draft of backgrounds did you update?
# [03:34] <fantasai> ED
# [03:34] <fantasai> I can't update /TR
# [03:35] <brianman> looking...
# [03:35] <fantasai> don't forget to reload
# [03:35] <brianman> overview.src not overview i take i
# [03:35] <brianman> it
# [03:35] <dbaron> brianman, yes
# [03:35] <brianman> ok, cool
# [03:35] <fantasai> darn, I forgot to regenerate :)
# [03:36] <fantasai> ok, try now :)
# [03:36] <brianman> 3- dbaron: would you agree that the formatting off computedvalue() query should be governed by css-om serialization rules?
# [03:36] <brianman> (i.e. we should handle it there)
# [03:36] <dbaron> yes, agree we should handle it there
# [03:36] <brianman> Ok, cool. I'm on board with that.
# [03:37] <dbaron> anyway, responded on list
# [03:37] <brianman> fantasai - yah, your fixes look good, but I think dbaron and I agree to simplify that language significantly as per 1-
# [03:39] <brianman> dbaron - good enough for now
# [03:40] <brianman> Hopefully we can someday solve the interoperability issues here with -a- editorial effort in cssom module and -b- test suite.
# [03:41] <brianman> @fantasai - "influenced by which language you speak". that's a good argument but I thought the ship already sailed w/r/t English is the language we're already using
# [03:42] <brianman> ... which is arguably another benefit (raised in some of the blog comments) of the old grammar (commas don't hit linguistic variance concerns)
# [03:51] * Quits: rworth (rworth@72.83.231.22) (Quit: Linkinus - http://linkinus.com)
# [03:56] * Joins: karl (karlcow@128.30.54.58)
# [04:03] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
# [04:13] * Quits: dbaron (dbaron@159.63.23.38) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [04:40] * Joins: plinss (plinss@98.176.133.137)
# [04:43] * Joins: karl (karlcow@128.30.54.58)
# [04:50] * Joins: tantek (tantek@199.83.220.131)
# [05:49] * Quits: miketaylr (miketaylr@24.42.93.245) (Quit: miketaylr)
# [06:02] * Quits: tantek (tantek@199.83.220.131) (Quit: tantek)
# [07:56] * Joins: dbaron (dbaron@173.228.28.129)
# [08:13] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
# [08:43] * Quits: dbaron (dbaron@173.228.28.129) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [09:24] * Quits: jdaggett (jdaggett@202.221.217.73) (Quit: jdaggett)
# [10:04] * Joins: florianr (florianr@213.236.208.22)
# [10:24] * Joins: tantek (tantek@70.36.139.219)
# [11:01] * Joins: drublic (drublic@95.115.55.40)
# [14:01] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
# [14:56] * Joins: rworth (rworth@72.83.231.22)
# [15:08] * Joins: arno (arno@222.128.202.2)
# [15:09] * Quits: arno (arno@222.128.202.2) (Quit: Leaving.)
# [15:15] * Joins: miketaylr (miketaylr@206.217.92.186)
# [15:24] * Joins: Ms2ger (Ms2ger@91.181.55.40)
# [15:29] * Joins: karl (karlcow@128.30.54.58)
# [15:59] * Quits: Ms2ger (Ms2ger@91.181.55.40) (Connection reset by peer)
# [15:59] * Joins: Ms2ger (Ms2ger@91.181.55.40)
# [16:11] * Joins: ksweeney (ksweeney@63.119.10.10)
# [16:58] * Joins: danielfilho (danielfilh@187.31.77.7)
# [17:04] * Joins: kojiishi (kojiishi@222.158.227.129)
# [17:27] * Joins: glazou (glazou@82.247.96.19)
# [17:27] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [17:27] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
# [17:27] <RRSAgent> logging to http://www.w3.org/2011/12/07-css-irc
# [17:27] <glazou> Zakim, this will be Style
# [17:27] <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 39 minutes
# [17:27] <glazou> RRSAgent, make logs public
# [17:27] <RRSAgent> I have made the request, glazou
# [17:29] <glazou> Regrets: cesaracebal, Chris, dstorey, danielweck
# [17:31] * Joins: jdaggett (jdaggett@180.235.9.33)
# [17:47] <glazou> hi John
# [17:52] * Joins: ericm (qw3birc@128.30.52.28)
# [17:52] <glazou> Regrets: cesaracebal, Chris, dstorey, danielweck, kimberlyblessing
# [17:53] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
# [17:57] <jdaggett> glazou: heya
# [17:58] <glazou> sorry to keep you late in front of the computer...
# [17:58] * jdaggett is now known as sleepy_jdaggett
# [17:58] <glazou> my point, exactly :-D
# [17:58] <sleepy_jdaggett> yes, my eyeballs are dying...
# [17:59] <glenn> zakim, this is css
# [17:59] <Zakim> glenn, I see Style_CSS FP()12:00PM in the schedule but not yet started. Perhaps you mean "this will be css".
# [18:01] * Joins: bradk (bradk@99.7.175.117)
# [18:01] <glazou> glenn: already done
# [18:01] <Zakim> Style_CSS FP()12:00PM has now started
# [18:01] <Zakim> +??P16
# [18:01] * Joins: glenn (gadams@174.29.109.101)
# [18:01] <sleepy_jdaggett> zakim, ??p16 is me
# [18:01] <Zakim> +sleepy_jdaggett; got it
# [18:02] <Zakim> +SteveZ
# [18:02] <Zakim> +glenn
# [18:03] * Joins: antonp (50a94e63@64.62.228.82)
# [18:03] <glazou> sip bridge not working for me, pls hold on
# [18:03] <Zakim> +antonp
# [18:04] <Zakim> +??P34
# [18:04] <bradk> google voice not working in webkit...
# [18:04] <Zakim> +??P36
# [18:04] <glazou> Zakim, ??P36 is me
# [18:04] <Zakim> +glazou; got it
# [18:04] <Zakim> + +1.510.364.aaaa
# [18:04] <Zakim> - +1.510.364.aaaa
# [18:04] <glazou> Zakim, who is here?
# [18:04] <Zakim> On the phone I see sleepy_jdaggett, SteveZ, glenn, antonp, ??P34, glazou
# [18:04] <Zakim> On IRC I see antonp, glenn, bradk, ericm, sleepy_jdaggett, RRSAgent, Zakim, glazou, kojiishi, danielfilho, ksweeney, Ms2ger, miketaylr, rworth, drublic, tantek, florianr, plinss,
# [18:04] <Zakim> ... stearns, arronei, brianman, Bert, lhnz, hober, trackbot, brianman_, ed, TabAtkins, pjrm, dglazkov, shepazu, gsnedders, paul_irish, krijnhuman, fantasai, CSSWG_LogBot
# [18:05] <glazou> Zakim, ??p36 is rossen
# [18:05] <Zakim> I already had ??P36 as glazou, glazou
# [18:05] <glazou> Zakim, ??P34 is rossen
# [18:05] <Zakim> +rossen; got it
# [18:05] <Zakim> + +1.510.364.aabb
# [18:05] * Joins: smfr (smfr@173.228.90.57)
# [18:05] <glazou> Zakim, aabb is ericm
# [18:05] <Zakim> +ericm; got it
# [18:06] * bradk must have run flash. Computer barely moving...
# [18:06] <glazou> bradk: eheh
# [18:06] <Zakim> + +1.619.846.aacc
# [18:06] <hober> Zakim, aacc is me
# [18:06] <Zakim> +hober; got it
# [18:06] <Zakim> +stearns
# [18:06] <Zakim> +??P49
# [18:06] <glazou> Zakim, mute ??P49
# [18:06] <Zakim> ??P49 should now be muted
# [18:07] <Zakim> +smfr
# [18:07] <Zakim> +[Microsoft]
# [18:07] * Joins: vhardy (vhardy@192.150.10.200)
# [18:07] * Joins: JohnJan (johnjan@131.107.0.125)
# [18:07] <Zakim> -??P49
# [18:07] <Zakim> +plinss
# [18:07] <JohnJan> zakim, microsoft has johnjan
# [18:07] <Zakim> +johnjan; got it
# [18:07] * Joins: sylvaing (sylvaing@98.232.9.174)
# [18:07] * Joins: myakura (myakura@211.135.241.47)
# [18:08] * Joins: SteveZ (chatzilla@24.6.120.172)
# [18:08] * Joins: oyvind (oyvinds@213.236.208.22)
# [18:08] <Zakim> +sylvaing
# [18:08] <glazou> Zakim, you lag
# [18:08] <Zakim> +Oliver_Goldman
# [18:08] <Zakim> I don't understand 'you lag', glazou
# [18:08] <Zakim> +??P68
# [18:08] <Zakim> +??P70
# [18:08] * Quits: glazou (glazou@82.247.96.19) (Client exited)
# [18:09] * Joins: glazou (glazou@82.247.96.19)
# [18:09] <glazou> Zakim, who is here?
# [18:09] <Zakim> +tantek
# [18:09] * Zakim hears ??P68's hand up
# [18:09] <tantek> Thanks Zakim
# [18:09] * Zakim sees ??P68 on the speaker queue
# [18:09] <Zakim> On the phone I see sleepy_jdaggett, SteveZ, glenn, antonp, rossen, glazou, ericm, hober, stearns, smfr, [Microsoft], plinss, sylvaing, Oliver_Goldman, ??P68, ??P70, tantek
# [18:09] <Zakim> [Microsoft] has johnjan
# [18:09] <glazou> Zakim, who is noisy?
# [18:09] <Zakim> +bradk
# [18:09] * Bert zakim, ??P68 is me
# [18:09] <Zakim> On IRC I see glazou, oyvind, SteveZ, myakura, sylvaing, JohnJan, vhardy, smfr, antonp, glenn, bradk, ericm, sleepy_jdaggett, RRSAgent, Zakim, kojiishi, danielfilho, ksweeney,
# [18:10] <Zakim> ... Ms2ger, miketaylr, rworth, drublic, tantek, florianr, plinss, stearns, arronei, brianman, Bert, lhnz, hober, trackbot, brianman_, ed, TabAtkins, pjrm, dglazkov, shepazu,
# [18:10] <Zakim> ... gsnedders, paul_irish, krijnhuman, fantasai, CSSWG_LogBot
# [18:10] * Zakim +Bert; got it
# [18:10] * Zakim hears Bert's hand down
# [18:10] * Zakim sees ??P68 on the speaker queue
# [18:10] <Zakim> glazou, listening for 10 seconds I heard sound from the following: ??P68 (29%), ??P70 (47%)
# [18:10] * Joins: dbaron (dbaron@159.63.23.38)
# [18:10] <Bert> q- ??P68
# [18:10] <Zakim> +[Mozilla]
# [18:10] * dbaron Zakim, [Mozilla] is dbaron
# [18:11] * Zakim sees no one on the speaker queue
# [18:11] * Zakim +dbaron; got it
# [18:11] <Zakim> +??P89
# [18:11] <florianr> Zakim, I am ??P89
# [18:11] <Zakim> +??P90
# [18:11] <kojiishi> zakim, ??p90 is me
# [18:12] * tantek has to go at 9:40-0800
# [18:12] * Joins: Cathy (qw3birc@128.30.52.28)
# [18:12] <Zakim> +florianr; got it
# [18:12] <Zakim> +kojiishi; got it
# [18:12] * Joins: dsinger (dsinger@17.197.32.11)
# [18:13] <dbaron> ScribeNick: dbaron
# [18:13] <dbaron> Meeting: CSS WG Teleconference
# [18:13] <dbaron> Chair: Daniel Glazman
# [18:13] <dbaron> Scribe: David Baron
# [18:13] <dbaron> Topic: Agenda?
# [18:13] <dbaron> glazou: any extra items? Tab wanted to add item on switching back to fantasai's current-work listing
# [18:13] <dbaron> glazou: I suggest doing that after the high-priority items.
# [18:13] <dbaron> Topic: Bucharest meeting in May
# [18:13] <dbaron> glazou: Sent email to list to confirm the dates of the meeting.
# [18:14] <dbaron> glazou: Vincent, can we confirm the dates?
# [18:14] <dbaron> Vincent: May 9-10-11 (Wed-Thu-Fri)
# [18:14] <dbaron> Vincent: FX meeting with SVG would be Wednesday morning
# [18:14] <dbaron> glazou: When to expect hotel recommendations?
# [18:14] <dbaron> ACTION Vincent provide recommended hotels for Bucharest meeting ASAP
# [18:14] * trackbot noticed an ACTION. Trying to create it.
# [18:14] <trackbot> Created ACTION-407 - Provide recommended hotels for Bucharest meeting ASAP [on Vincent Hardy - due 2011-12-14].
# [18:15] <dbaron> jdaggett: is there a wiki page with address of venue, etc.?
# [18:15] * Parts: ksweeney (ksweeney@63.119.10.10)
# [18:15] <dbaron> ACTION vincent to make wiki page for Bucharest with location of meeting, etc.
# [18:15] * trackbot noticed an ACTION. Trying to create it.
# [18:15] <trackbot> Created ACTION-408 - Make wiki page for Bucharest with location of meeting, etc. [on Vincent Hardy - due 2011-12-14].
# [18:15] <dbaron> Topic: Multicol spanning margins
# [18:15] <glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2011OctDec/0138.html
# [18:15] <glazou> http://www.w3.org/mid/4ED416B1.7070902@inkedblade.net
# [18:15] <dbaron> glazou: previously waiting for fantasai to post blog
# [18:16] <dbaron> fantasai: That's been done
# [18:16] <fantasai> http://www.css3.info/multi-column-margin-collapse/
# [18:16] <dbaron> glazou: We decided to make a decision this week.
# [18:16] <dbaron> rossen: Can we do this as the second item, in 5 minutes?
# [18:16] <tantek> I updated http://wiki.csswg.org/planning/2012 per the confirmed Bucharest dates above.
# [18:16] <dbaron> Topic: Update on Unicode TR50
# [18:16] <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2011OctDec/0249.html
# [18:17] <dbaron> jdaggett: This is text-orientation; action was for Sylvain and Ted to get feedback from Microsoft and Apple.
# [18:17] * Joins: howcome (howcome@88.89.78.85)
# [18:17] <dbaron> sylvain: ... would come back to me with details on latest version of note. Chatted with Elika last time. Sergei will have another look at it and I'll share what he says on the list.
# [18:18] <dbaron> sylvain: We've provided feedback in the past; Sergei's been busy with other things.
# [18:18] <dbaron> jdaggett: At ??? ... Peter Constable ... he'd tell you who was there.
# [18:18] <dbaron> jdaggett: They were talking about other proposals.
# [18:18] <dbaron> fantasai: What they were proposing was different from what Sergei was taking.
# [18:18] <dbaron> s/taking/saying/
# [18:18] <Zakim> +howcome
# [18:19] <dbaron> Ted: I've got the conversation going internally, waiting to get more useful feedback for list/wiki.
# [18:19] <dbaron> Ted: Like Sylvain I don't have the knowledge myself.
# [18:19] <dbaron> Ted: My knee-jerk reaction is that if WebKit and IE agree we should go with that, but I'll have some feedback on the list as soon as I can.
# [18:20] <dbaron> jdaggett: Especially helpful would be if there are things that seem bad to you about the actual proposal.
# [18:20] <dbaron> Sylvain: What kind of timeline? Something needed before the new year?
# [18:20] <dbaron> jdaggett: Concerned about that, since second round of comments has been extended to mid-January, but if we're not careful we'll miss that.
# [18:21] <dbaron> glazou: need an action?
# [18:21] <dbaron> jdaggett: have 2 existing
# [18:21] <dbaron> Topic: Multicol spanning margins
# [18:21] <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2011OctDec/0138.html
# [18:21] <dbaron> howcome: Certainly an issue we'd like to settle, hopefully today.
# [18:21] <dbaron> howcome: I don't see this as a major issue; it's a corner case, but will have implications for authors.
# [18:22] <dbaron> howcome: We'd published a blog on the topic. I'm not quite up-to-date with the feedback on that post, but it's been made.
# [18:22] <fantasai> http://www.css3.info/multi-column-margin-collapse/
# [18:22] <dbaron> fantasai: I can summarize the feedback.
# [18:22] <dbaron> fantasai: The blog post tried to get people to imagine the scenario we're envisioning, and shows the 2 options we're considering.
# [18:23] <dbaron> fantasai: Most of the comments say collapsed margins for consistency with the rest of CSS.
# [18:23] <dbaron> fantasai: A few suggest no collapsing.
# [18:23] <dbaron> fantasai: A few wanted not collapsing for consistency (which doesn't make sense).
# [18:23] <dbaron> florian: A few said they wanted no collapsing in CSS.
# [18:23] * Ms2ger glazou, howcome, any reason https://lists.w3.org/Archives/Member/w3c-css-wg/2011OctDec/0138.html isn't public?
# [18:23] <dbaron> fantasai: And some suggestions for a margin collapsing control property.
# [18:23] <dbaron> fantasai: But most suggestions seemed to want collapsing just like regular paragraphs.
# [18:23] <glazou> Ms2ger: not I know of
# [18:24] <glazou> should be public
# [18:24] <dbaron> howcome: I think if the example had column-span set to 2 out of 3 columns, it might have been slightly different. That's a futuristic case.
# [18:24] <dbaron> florian: Even if we agree that collapsing is better, it doesn't tell us whether we should prefer solution A or C.
# [18:24] * Joins: Rossen (Rossen@131.107.0.81)
# [18:24] <tantek> good catch Ms2ger
# [18:25] <glazou> ACTION howcome to repost his message to www-style https://lists.w3.org/Archives/Member/w3c-css-wg/2011OctDec/0138.html
# [18:25] * trackbot noticed an ACTION. Trying to create it.
# [18:25] <trackbot> Created ACTION-409 - Repost his message to www-style https://lists.w3.org/Archives/Member/w3c-css-wg/2011OctDec/0138.html [on Håkon Wium Lie - due 2011-12-14].
# [18:25] <dbaron> fantasai: I was talking with Kimberly while we were working on this blog post. The mental model she had (with picture) was that you have a multicolumn element, then you have a row of columns before the spanner, then the spanners, and then a row of multicolumn elements after the spanners. The model was that the row of columns was a row of columns but it behaved as a block-level element that was a sibling of all of the spanners.
# [18:25] <tantek> thanks glazou
# [18:25] * Ms2ger Thanks
# [18:25] <dbaron> fantasai: And inside the block-level element you had regular block flow with the rows of columns being a special block-level block.
# [18:25] <dbaron> anton: (too fast)
# [18:26] <fantasai> s/block/box/
# [18:26] <dbaron> anton: At the moment that mental model makes sense because columns can't have vertical margin because they can't be targeted with a selector, but in future they might be able to be targeted.
# [18:26] * Joins: Hixie (ianh@129.241.93.37)
# [18:26] <dbaron> anton: So if the columns themselves had bottom margin, would we expect that to collapse with whatever comes next?
# [18:27] <dbaron> anton: I'd expect the margins on the columns themselves not to collapse.
# [18:27] <Zakim> +[Microsoft.a]
# [18:27] <Zakim> -rossen
# [18:27] <dbaron> anton: I think what's important is the inter-spanner relationship rather than the beginning/end of the spanners.
# [18:27] * fantasai thinks allowing margins on columns would be like allowing margins on table cells, i.e. wouldn't make sense even if we allowed styling those boxes
# [18:27] <dbaron> florian: Even for inter-spanner behavior A and C propose different things: margin collapsing was the same but floating was not.
# [18:27] <glazou> slower antonp please
# [18:27] <dbaron> anton: Makes sense to allow floats to behave as in normal block flow.
# [18:28] <dbaron> rossen: Would you expect floats to expect flow of column?
# [18:28] <dbaron> ?: no, not in flow of column
# [18:28] <dbaron> anton: spanners in A or C are wrapped in a BFC. Question is whether each wrapped independently or all in one.
# [18:28] <dbaron> rossen: In B you don't have a BFC; they are BFC.
# [18:29] <dbaron> florian: B is ruled out by the poll
# [18:29] <dbaron> ...
# [18:30] <dbaron> anton: If there's just one spanner it's still wrapped in a BFC (in A), but if there are 2 or 3 they would all be wrapped in a BFC.
# [18:30] <florianr> In A, spanners are not individually BFCs, but their are together wrapped in an anonymous one
# [18:30] <florianr> in C, each spanner is a BFC
# [18:30] <dbaron> Håkon: my preference is C
# [18:31] <dbaron> rossen: In the blog post the example is oversimplified; just text and spanners. Would like to see example that's more complicated, e.g., tables in the column and the spanners coming from deep inside the tables.
# [18:31] <fantasai> D, each column row is a BFC and everything else just behaves like regular block flow
# [18:31] <dbaron> florian: That's probably something we don't want to support at all.
# [18:31] <dbaron> rossen: Then I'd want spanners to come only from the ??? level of the column.
# [18:32] <dbaron> florian: After talking w/ implementors, would be comfortable with that.
# [18:32] <dbaron> sylvain: Things become really weird.
# [18:32] <dbaron> florian: The property just doesn't do anything when you apply it on something "too deep"
# [18:32] <dbaron> anton: Restrict it to the BFC. A spanner can't escape from a BFC.
# [18:33] <dbaron> florian: We can argue back and forth; we certainly want to forbid things that are way too deep like inside a table.
# [18:33] <dbaron> rossen: The first time I looked at it, the deeper structures were the problem I ran into it. That makes collapsing pretty hairy.
# [18:33] <dbaron> rossen: Everyone seems to be ignoring the general case.
# [18:33] <dbaron> rossen: Either we say this is level 1 only or ??? ???
# [18:34] <dbaron> florian: I don't think anyone wants to span things that come from deep down, and I think we should resolve on that.
# [18:34] <dbaron> Håkon: ...
# [18:34] <dbaron> Sylvain: We just need to define what Rossen means.
# [18:35] <dbaron> fantasai: I suggest we resolve that the spanner has to be in the same BFC as the main level of the column content.
# [18:35] <dbaron> Håkon: someone suggested making each column a BFC
# [18:35] <dbaron> anton: but I've gone off that idea
# [18:35] <dbaron> glazou: I'm almost hearing consensus.
# [18:35] <dbaron> Rossen: BFC or non-BFC-ness of spanners themselves... not resolved
# [18:35] <dbaron> florian: we should resolve on that first
# [18:36] <dbaron> Sylvain: I've heard a couple of definitions of level 1 already.
# [18:36] <dbaron> Sylvain & florian talk at the same time
# [18:36] <dbaron> Sylvain: We agree that spanning should be scoped at some level.
# [18:36] <dbaron> Rossen: to the BFC of the column
# [18:37] <dbaron> Håkon: definition of spanning is that the element spans across all columns of the nearest multicol ancestor of the same BFC
# [18:37] <howcome> The element spans across all columns of the nearest multicol
# [18:37] <howcome> ancestor of the same block formatting context.
# [18:37] <dbaron> anton: we might need to tinker with that wording
# [18:37] <dbaron> q+
# [18:37] * Zakim sees dbaron on the speaker queue
# [18:37] <dbaron> anton: question is whether spanner can escape inline-block
# [18:37] <howcome> Proposed definition of spanner: The element spans across all columns of the nearest multicol ancestor of the same block formatting context.
# [18:37] <fantasai> dbaron: How could a multi-column not establish a BFC?
# [18:38] <dbaron> q-
# [18:38] * Zakim sees no one on the speaker queue
# [18:39] <dbaron> RESOLUTION: column-spanning elements can only span when the closest ancestor BFC is established by the multicol (whether by the columns or the multicol)
# [18:40] <dbaron> ?: need an action for somebody to propose wording for this
# [18:40] <dbaron> Rossen: I can write it
# [18:40] <dbaron> glazou: Back to the choice between A and C.
# [18:40] <dbaron> fantasai: and D
# [18:40] <dbaron> fantasai: D is where the multicolumn element establishes a block formatting context and column spanning elements are treated as regular blocks and each column row is a block level BFC within the multicol BFC
# [18:40] <dbaron> fantasai: It's like the table element having an outer table that has the captions and the table box
# [18:41] <dbaron> florian: This D model wouldn't play nice with the ability to select individual columns and do things with them (in the future).
# [18:41] <dbaron> rossen: Especially if multicolumns are going towards ??? columns that Håkon was proposing.
# [18:41] * sylvaing did we ACTION someone to propose that wording ?
# [18:41] <dbaron> ACTION rossen propose wording for column-spanning elements can only span when the closest ancestor BFC is established by the multicol (whether by the columns or the multicol)
# [18:41] * trackbot noticed an ACTION. Trying to create it.
# [18:41] <trackbot> Created ACTION-410 - Propose wording for column-spanning elements can only span when the closest ancestor BFC is established by the multicol (whether by the columns or the multicol) [on Rossen Atanassov - due 2011-12-14].
# [18:41] * sylvaing thx
# [18:42] <dbaron> Håkon: Can't we just pick one of A and C ?
# [18:42] <dbaron> fantasai: That's just what came out of the discussion I had with Kimberly. Though we didn't discuss floats.
# [18:42] <dbaron> Rossen: On option A, if we were going to go with the non-BFC behavior where floats can affect subsequent spanning elements, what would be drawing order and who would be drawing floats?
# [18:43] <dbaron> Rossen: You meant(?) anonymous BFC; in our implementation we have nothing of this sort.
# [18:43] <dbaron> Rossen: Option C seems fairly consistent: spanners will collapse margins between themselves and keep everything else to themselves.
# [18:43] * Quits: vhardy (vhardy@192.150.10.200) (Ping timeout)
# [18:44] <dbaron> Florian: There is another difference between A and C: if the spanner itself has children do the margins of the children collapse with things in the next spanner. In C they don't; in A they do.
# [18:44] <dbaron> Rossen/Florian: Also if there is an empty spanner between 2 non-empty spanners
# [18:44] <dbaron> Anton: It depends what you want these spanners to be. If you want them to look like normal block formatting then they ought to collapse. If they're each individually special then it's fine that they don't.
# [18:44] <dbaron> Rossen: I think they're each individually special.
# [18:44] * Joins: TabAtkins_ (qw3birc@128.30.52.28)
# [18:45] <TabAtkins_> Urgh, apologies everyone.
# [18:45] <dbaron> Rossen: At the end of the day we're taking the spanners out of the flow and collapsing the margins between the spanners themselves.
# [18:45] <dbaron> Rossen: Whether or not we have to treate empty spanners the way we treat emptyp blocks today. But if we're taking them out of the block flow and collapsing margins in between them, then I don't see a reason to make them non-BFC.
# [18:45] <dbaron> Rossen: There's no other precedent for taking anything out of the flow that isn't a BFC.
# [18:46] <dbaron> Anton: I'm not entirely convinced we're taking stuff out of the flow here.
# [18:46] <Zakim> +tabatkins_
# [18:46] <dbaron> Anton: If you've got a spanner you're ending the columns and then starting them again.
# [18:46] <dbaron> Anton: They disrupt the multicol, but they're not out of the flow.
# [18:46] <dbaron> dbaron: I t hink they're out of the flow.
# [18:46] <dbaron> Rossen: They're out of the flow in our implementation apparently.
# [18:46] <dbaron> fantasai: I see this more like a block-in-inline case.
# [18:46] <dbaron> fantasai: Jumping out to an outer flow.
# [18:47] <Bert> (I think D works, but there appears to be very little difference with A in the visual effect.)
# [18:47] * sylvaing display:block-inline!
# [18:47] <dbaron> Håkon: I think we have consensus for C. I don't hear anyone arguing for A.
# [18:47] <dbaron> various: does anyone object to C?
# [18:47] <fantasai> (Bert, except when there are margins on the children of the spanner)
# [18:47] <dbaron> SteveZ: Only mildly.
# [18:47] * sleepy_jdaggett thinks we need to move on...
# [18:48] <glazou> yes
# [18:48] * glazou too
# [18:48] <Bert> (Ah right. So then I think I actually like D better. :-) )
# [18:48] <dbaron> SteveZ: I think one of the things Elika just said: treatment of blocks in an inline. If you look at is a headings it doesn't make much sense. But if you look at it as temporarily switching back to single-column, it seems like the user would want those pieces to behave as inside one single column.
# [18:48] <dbaron> Florian: If you want that, you can have a containing element be the spanner rather than make several consecutive elements spanners.
# [18:48] <dbaron> Håkon: As long as you can insert a div around ...
# [18:48] <fantasai> (Oh, wait, no I think you're right!)
# [18:49] <dbaron> Steve: I'm not strong on this, just wondering wat users will expect.
# [18:49] <fantasai> (A and D are equivalent)
# [18:49] * Joins: vhardy (vhardy@192.150.10.200)
# [18:49] * sleepy_jdaggett warning warning ratholing...
# [18:49] <fantasai> (C and D are different)
# [18:49] <dbaron> Håkon: Float behavior will be different, that's true.
# [18:49] * sylvaing thinks sleepy_jdaggett means 'omg now i know what those vertical talks sound like to the rest of you'
# [18:49] <dbaron> glazou: Given constraints, I think authors won't meet expectations anyway.
# [18:49] <glazou> LOL
# [18:49] <dbaron> fantasai: Bert points A and D are equivalent, so I'm leaning towards A.
# [18:50] * sleepy_jdaggett heh
# [18:50] <dbaron> fantasai: If we take the premise that a column row stretches across the entire column and clears all the floats before it, then A expresses that behavior.
# [18:50] <dbaron> fantasai: Interrupting the column flow and going to a flow that stretches across the entire block... can resume multicol afterwards.
# [18:50] <dbaron> q+
# [18:50] * Zakim sees dbaron on the speaker queue
# [18:50] <dbaron> fantasai: Within the anonymous BFC everything is a regular block.
# [18:50] * sylvaing actually loves all the involved CJK text stuff and is frustrated he can't keep up more than 12.2s.
# [18:51] <dbaron> fantasai: Nothing different from ... except border of multicol box goes around everything.
# [18:51] * sleepy_jdaggett you just need to see more pretty pictures...
# [18:51] * sylvaing YES
# [18:51] * tantek is walking away from IRC for a bit (rest of the hour).
# [18:52] <dbaron> dbaron: (minute later) pref C
# [18:52] <dbaron> Håkon: implemented ... . ...
# [18:53] * glazou allocates only 3 more minutes to this item
# [18:53] <dbaron> Florian: Could have strange cases: span:all followed by span:3 would lead to weird results if you have 3 columns
# [18:53] <dbaron> fantasai: I'm happy with C.
# [18:53] <dbaron> Steve: I can live with C.
# [18:53] <dbaron> glazou: anyone objecting?
# [18:53] <dbaron> ?: Alex, but he's not here?
# [18:54] <dbaron> RESOLVED: each column spanning element establishes a separate BFC (option C)
# [18:54] <florianr> s/?/florianr/
# [18:54] * sylvaing aquavit for everyone!
# [18:54] <dbaron> Topic: Editorship of cssom and cssom-view
# [18:54] <dbaron> glazou: Anne left the group.
# [18:54] <dbaron> glazou: We need editors for these documents.
# [18:54] <dbaron> glazou: Proposal from Glenn to be coeditor.
# [18:55] <dbaron> Tab: At last TPAC Shane Stevens offered to edit as wel.
# [18:55] <dbaron> jdaggett: Florian offered?
# [18:55] <dbaron> Florian: In Media Queries
# [18:55] <dbaron> Sylvain: I can help with MQ too.
# [18:55] <glenn> is here
# [18:55] <dbaron> jdaggett: OM is kind of a key spec; also to some extent OM-view. Is that the right spec for people new to the group? Would be more comfortable with somebody with more familiarity.
# [18:56] <dbaron> Tab: With Shane, I expect I'd be acting as a mentor for that spec.
# [18:56] <dbaron> jdaggett: I'd feel better if he was working on different specs.
# [18:56] <dbaron> Glenn: I've implemented cssom and cssom-view and CSS formatting semantics in 2 or 3 products.
# [18:57] <dbaron> glazou: Tab, what's Shane's opinion?
# [18:57] <dbaron> Tab: He's fine with Glenn being a coeditor.
# [18:57] <dbaron> Glenn: I'd suggest both Shane and I be assigned as coeditors as a starting point, and if others want to help we can change that over time.
# [18:57] <dbaron> Florian: I think Shane said he was interested in documenting existing compatible bits.
# [18:58] <dbaron> Tab: Yeah, he dosen't want to start working on new stuff until we get the existing stuff documented & stable
# [18:58] <dbaron> Sylvain: Fundamental specs, but were neglected for a long time.
# [18:58] <dbaron> Glenn: One reason I voluneteered because I'm working with an external org called DOMA (?) normatively referencing both of these, and identified these as needing significant work to get to CR.
# [18:59] <fantasai> sylvain^: I'm more concerned about what we're working on rather than who's working on them.
# [18:59] <dbaron> Sylvain: One issue recently was that DLMA was depending on editor's drafts. Are we going to have shenanigans of that sort if draft changing what previous draft said?
# [18:59] <dbaron> Glenn: You'd formally objected to a change in css3-fonts because it was incompatible with a prior editor's draft.
# [19:00] <dbaron> Glenn: Formally, DLNA policy does not allow normative ref to anything other than final spec (REC in W3C). They're interested in participating to move all the dependencies forward.
# [19:00] <dbaron> Glenn: The css3-fonts issue I brought up while representing Samsung has been closed as far as I'm concerned. I'm now representing Cox Communications in this WG.
# [19:00] <dbaron> Glenn: I wish to help to move to REC as fast as possible not only these specs but other specs I can help with.
# [19:00] <dbaron> q|+
# [19:00] <dbaron> q+
# [19:00] * Zakim sees dbaron on the speaker queue
# [19:01] <dbaron> glazou: What this WG would like to see is a schedule for these documents. They've been orphaned for a long time; they're crucial for CSS.
# [19:01] <dbaron> glazou: Do you think this is doable? Doing the steps to move these documents along the rec track.
# [19:01] <dbaron> Glazou: At least by the end of the year, I'd like to provide a proposed schedule for the work.
# [19:02] <dbaron> Florian: Seems like Shane is interested in documenting the stable bits, and Glenn interested in moving to R.c
# [19:02] <dbaron> Sylvain: What is the work? Reduce to what's implemented? Values API?
# [19:02] * Quits: drublic (drublic@95.115.55.40) (Client exited)
# [19:02] <dbaron> Tab: I think 2.1-style :reduce to what's implement.d
# [19:02] <dbaron> Tab: New stuff needs to be in CSSOM level 2.
# [19:02] <dbaron> glazou: I agree with tat
# [19:02] <dbaron> that
# [19:03] <dbaron> q-
# [19:03] * Zakim sees no one on the speaker queue
# [19:03] <dbaron> dbaron: was going to express concerne about (minute later 2)
# [19:03] <dbaron> glazou: I think I'm hearing consensus.
# [19:03] <fantasai> dbaron^: I'd be concerned about moving the new stuff to REC "as fast as possible", but if we're splitting that out I have no concern.
# [19:04] <dbaron> RESOLVED: Glenn and Shane coedit cssom and cssom-view, Florian and Sylvain become coeditors of css3-mediaqueries, and we will revisit schedules in 2 weeks
# [19:04] <glenn> thanks, looking forward to accomplishing this work in a timely manner
# [19:04] <glazou> http://lists.w3.org/Archives/Public/www-style/2011Nov/0395.html
# [19:04] <dbaron> Topic: Moving stuff from css3-text to level 4
# [19:04] <dbaron> ?: take more than 2 minutes
# [19:05] <dbaron> Tab: unless we agree to just do what Elika's saying
# [19:05] <dbaron> Topic: current work page
# [19:05] <dbaron> Tab: It's been more than a month; new page should be up.
# [19:05] <dbaron> Tab: what do we need to do to make this happen?
# [19:05] <dbaron> Tab: Bert, if there's still work you need to do, let me help you with it
# [19:05] <glenn> s/DOMA (?)/DLNA/
# [19:05] <Zakim> -ericm
# [19:06] * Quits: ericm (qw3birc@128.30.52.28) (Quit: Page closed)
# [19:06] <dbaron> Bert: I started discussing with Elika on common list of drafts. Long to do list. The content is what I'm worried about.
# [19:06] <dbaron> Tab: The content that Elika proposed is much more useful than what's there right now.
# [19:06] <dbaron> Tab: we can tweak it after it's up
# [19:06] <dbaron> glazou: I agree with that.
# [19:06] <dbaron> Bert: I'm not so sure that content is usefu.
# [19:06] <dbaron> glazou: We had a resolution on that
# [19:06] * fantasai notes we don't actually, we only have an action item
# [19:06] <dbaron> Bert: You had a resolution that you think it's more useful.
# [19:06] <dbaron> glazou: the group
# [19:07] <dbaron> Bert: I'd like to find some way to integrate that. The original text that Elika proposed is not complete, and there are some distinctions that I think shouldn't be made.
# [19:07] <dbaron> Tab: Let us do that afterwards.
# [19:07] <dbaron> glazou: It's better.
# [19:07] <dbaron> Bert: I don't see that -- there are so many categories: what do they mean?
# [19:07] <Zakim> -sleepy_jdaggett
# [19:07] <dbaron> Tab: They mean the English names of the categories, and arranged in order of stabilization.
# [19:07] * sleepy_jdaggett off to bed, night night everyone
# [19:07] <dbaron> glazou: we have a resolution
# [19:07] <dbaron> fantasai: not technically
# [19:08] * Quits: sleepy_jdaggett (jdaggett@180.235.9.33) (Quit: sleepy_jdaggett)
# [19:08] <dbaron> Bert: I have a lot of freedom in making these pages, but I still have responsibility there: I'm making them on behalf of the W3C not on behalf of the working group.
# [19:08] <dbaron> Bert: We don't have a list that ... happy with ... agreed on.
# [19:09] <dbaron> fantasai: You sent me a list that was a slightly modified version of mine. We seem to be pretty close with the exception of naming one of the sections. Why can't we move to that?
# [19:09] <dbaron> Bert: I haven't looked at your list wiwt hthat in mind
# [19:09] <dbaron> fantasai: section on abandoned specs, location of cfss3-ui in list
# [19:09] <dbaron> Bert: I think that list is fgine.
# [19:09] <dbaron> glazou: This is part of the outreach of the wg
# [19:09] <Zakim> -tantek
# [19:10] <dbaron> glazou: We have to close that issue
# [19:10] <dbaron> glazou: Bert, I want you to do that change as soon as possible.
# [19:10] <dbaron> Bert: It will be done within the next week and a half.
# [19:10] <dbaron> glazou: That's the best you can do?
# [19:10] <dbaron> Bert: I have things to do tomorrow and the day after.
# [19:10] <dbaron> Tab: Can one of us publish the page, then?
# [19:10] <dbaron> Bert: I guess Elika can.
# [19:10] <dbaron> glazou: Let's do that.
# [19:11] * Joins: karl (karlcow@128.30.54.58)
# [19:11] <dbaron> fantasai: I don't know the structural dependencies
# [19:11] <dbaron> Bert: keep ids completed and high-prio
# [19:11] <dbaron> ACTION fantasai update the current-work page
# [19:11] * trackbot noticed an ACTION. Trying to create it.
# [19:11] <trackbot> Created ACTION-411 - Update the current-work page [on Elika Etemad - due 2011-12-14].
# [19:11] <Zakim> -Oliver_Goldman
# [19:11] <Zakim> -dbaron
# [19:11] <Zakim> -antonp
# [19:11] <Zakim> -tabatkins_
# [19:11] <Zakim> -smfr
# [19:11] <Zakim> -stearns
# [19:11] <Zakim> -glazou
# [19:11] <Zakim> -[Microsoft]
# [19:11] * Quits: JohnJan (johnjan@131.107.0.125) (Quit: JohnJan)
# [19:11] <Zakim> -florianr
# [19:11] <dbaron> s/cfss3/css3/
# [19:11] <Zakim> -sylvaing
# [19:11] <Zakim> -SteveZ
# [19:11] <Zakim> -hober
# [19:11] * Parts: antonp (50a94e63@64.62.228.82)
# [19:11] <Zakim> -plinss
# [19:11] <Zakim> -kojiishi
# [19:11] <Zakim> -[Microsoft.a]
# [19:12] <Zakim> -glenn
# [19:12] <Zakim> -bradk
# [19:12] * Quits: kojiishi (kojiishi@222.158.227.129) (Quit: Leaving...)
# [19:12] <Zakim> -Bert
# [19:12] * Quits: TabAtkins_ (qw3birc@128.30.52.28) (Quit: Page closed)
# [19:12] <Zakim> -??P70
# [19:12] <dbaron> s/(minute later) pref C/Considering the possibility that we might later move to having column spans that don't cross all columns, I think it's much better to think of each column spanning element as isolated -- I'm scared of doing otherwise. Thus I prefer option C./
# [19:12] <dbaron> s/is fgine/is fine/
# [19:12] <Zakim> -howcome
# [19:12] <Zakim> Style_CSS FP()12:00PM has ended
# [19:12] <dbaron> s/wiwt hthat/with that/
# [19:13] <Zakim> Attendees were sleepy_jdaggett, SteveZ, glenn, antonp, glazou, +1.510.364.aaaa, rossen, +1.510.364.aabb, ericm, +1.619.846.aacc, hober, stearns, smfr, plinss, johnjan, sylvaing,
# [19:13] <Zakim> ... Oliver_Goldman, tantek, bradk, Bert, dbaron, florianr, kojiishi, howcome, [Microsoft], tabatkins_
# [19:13] <dbaron> s/R.c/Rec/
# [19:13] <dbaron> s/implement.d/implemented/
# [19:14] <dbaron> s/style :reduce/style: reduce/
# [19:14] <dbaron> s/concerne about/concerns about/
# [19:14] * Quits: glazou (glazou@82.247.96.19) (Quit: glazou)
# [19:14] <dbaron> s/DLMA/DLNA/
# [19:15] <Rossen> Zkim: [Microsoft] is Rossen
# [19:16] <dbaron> boy, jdaggett stayed up until 3am for this...
# [19:16] * Quits: SteveZ (chatzilla@24.6.120.172) (Quit: ChatZilla 0.9.87 [Firefox 8.0/20111104165243])
# [19:16] <Rossen> dedication!
# [19:17] <Rossen> Zkim [Microsoft] is Rossen
# [19:19] * Quits: smfr (smfr@173.228.90.57) (Quit: smfr)
# [19:19] <Rossen> Zkim, [Microsoft] has Rossen
# [19:19] * Quits: dsinger (dsinger@17.197.32.11) (Quit: dsinger)
# [19:19] * Parts: oyvind (oyvinds@213.236.208.22)
# [19:20] <fantasai> TabAtkins: Changes/feedback on flexbox for blog?
# [19:21] <fantasai> Rossen: would help to spell it correctly, I think. You're missing an 'a' :)
# [19:21] * fantasai will fix though
# [19:21] <Rossen> Zakim, [Microsoft] has Rossen
# [19:21] <Zakim> sorry, Rossen, I do not recognize a party named '[Microsoft]'
# [19:21] * Quits: florianr (florianr@213.236.208.22) (Quit: Leaving.)
# [19:22] * Rossen is having a fat fingers day :-)
# [19:23] <dbaron> Rossen, I don't think it works after the call is over
# [19:23] <Rossen> right, I'll have to add my cell number in the w3c list so I don't have to deal with this again... oh well
# [19:28] * Quits: Rossen (Rossen@131.107.0.81) (Quit: Rossen)
# [19:31] * Quits: tantek (tantek@70.36.139.219) (Quit: tantek)
# [19:50] * Quits: bradk (bradk@99.7.175.117) (Quit: Computer has gone to sleep)
# [19:53] * Quits: vhardy (vhardy@192.150.10.200) (Ping timeout)
# [20:03] * Quits: brianman (brianman@131.107.0.113) (Ping timeout)
# [20:04] * Joins: brianman (brianman@131.107.0.76)
# [20:09] * Quits: stearns (anonymous@50.132.63.33) (Quit: stearns)
# [20:29] * Joins: stearns (anonymous@192.150.22.5)
# [20:50] * Quits: sylvaing (sylvaing@98.232.9.174) (Ping timeout)
# [20:53] * Joins: sylvaing (sylvaing@98.232.9.174)
# [21:10] * Quits: myakura (myakura@211.135.241.47) (Client exited)
# [21:25] * Zakim excuses himself; his presence no longer seems to be needed
# [21:25] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [21:47] * Quits: howcome (howcome@88.89.78.85) (Ping timeout)
# [21:51] * Joins: tantek (tantek@70.36.139.219)
# [22:08] * Quits: sylvaing (sylvaing@98.232.9.174) (Ping timeout)
# [22:21] * Joins: sylvaing (sylvaing@98.232.9.174)
# [22:25] * Quits: Ms2ger (Ms2ger@91.181.55.40) (Quit: nn)
# [22:29] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
# [22:29] <TabAtkins> fantasai: Hm?
# [22:35] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
# [22:48] * Joins: karl (karlcow@128.30.54.58)
# [23:47] * Quits: tantek (tantek@70.36.139.219) (Quit: tantek)
# [23:55] * Joins: arronei_ (arronei@131.107.0.76)
# [23:56] * Quits: arronei (arronei@131.107.0.84) (Ping timeout)
# Session Close: Thu Dec 08 00:00:00 2011

The end :)