/irc-logs / w3c / #css / 2011-11-09 / end

Options:

# Session Start: Wed Nov 09 00:00:00 2011
# Session Ident: #css
# [00:00] <fantasai> works for me
# [00:00] <brianman> Tab?
# [00:00] <TabAtkins> Not really happy about it, but my caring is *far* outdwarfed by my desire to resolve.
# [00:00] <brianman> heh, 100% agree
# [00:01] <brianman> So are we 3/4 resolved on everything but cover/contain, and leaving that to WG to decide?
# [00:01] <brianman> [editorial issues aside]
# [00:01] <brianman> s/WG/larger WG/g
# [00:01] <TabAtkins> Yeah.
# [00:02] <fantasai> ok, brian want to run a summary so I can edit this in?
# [00:02] <brianman> I can try
# [00:02] <stearns> brianman: you want *more* people in the CSS WG!?!?
# [00:02] <fantasai> (live editing, of course)
# [00:02] <brianman> hah @ stearns
# [00:02] <brianman> Is a grammar enough to get you going Elika?
# [00:02] <brianman> s/going/unblocked/g
# [00:02] <fantasai> toss in whatever's relevant
# [00:02] <fantasai> I'll edit, update, and you'll check
# [00:02] <brianman> I'll fire off an email in 30min to an hour
# [00:02] <brianman> and you can run from there?
# [00:03] <fantasai> just write it here
# [00:03] * Parts: stearns (anonymous@192.150.22.5)
# [00:03] <fantasai> and then we can draft an email
# [00:03] <fantasai> I just want to make sure I don't miss anything
# [00:03] * Joins: stearns (anonymous@192.150.22.5)
# [00:03] * fantasai looks at this grammar
# [00:03] <fantasai> uhhhhhhh
# [00:03] <fantasai> >________<;;;;;;;;
# [00:04] <fantasai> I don't know how to incorporate that into the grammar without making it completely opaque
# [00:05] <fantasai> Let me try a different approache
# [00:05] <fantasai> s/e//
# [00:05] <TabAtkins> fantasai: google doc for realtime editing collab?
# [00:05] <fantasai> don't feel like importing it
# [00:05] <fantasai> give me a minute
# [00:06] <fantasai> we'll just cvs checkin a bunch
# [00:06] <TabAtkins> I just meant grab the grammar, specifically.
# [00:06] <fantasai> ah
# [00:06] <TabAtkins> kk
# [00:06] * Joins: danbeam (bitlbee@75.83.194.56)
# [00:08] <danbeam> anybody know why combinators are not allowed within :not() pseudo-class in CSS 3 selectors? (only simple selector atm)
# [00:08] <TabAtkins> danbeam: 'cause it's confusing (also harder to implement)
# [00:08] <fantasai> danbeam: complexity
# [00:08] <fantasai> danbeam: also, ambiguity
# [00:08] <danbeam> fantasai: amiguity in what?
# [00:08] <fantasai> hm
# [00:09] * fantasai tries to remember what the issue was
# [00:09] <fantasai> no, that was a different issue about parentheses :)
# [00:09] <fantasai> nm then
# [00:09] <danbeam> I understand the complexity and confusing arguments
# [00:09] <fantasai> definitely complexity, though
# [00:09] <fantasai> danbeam: L4 will allow compound selectors
# [00:09] <danbeam> L4 = CSS 4?
# [00:09] <fantasai> danbeam: Although still no combinators, unless some implementor comes and says "I did it and I want it in the spec now"
# [00:09] <fantasai> danbeam: Selectors Level 4
# [00:09] <danbeam> ah
# [00:10] <fantasai> http://www.w3.org/TR/selectors4/
# [00:10] <fantasai> brianman: Are we allowing 'ellipse to 50%'?
# [00:11] <brianman> no
# [00:11] <brianman> "ellipse to 50% 50%" yes
# [00:11] <brianman> "circle to 50px" yes
# [00:11] <brianman> "ellipse to 50px 75px" yes
# [00:11] <TabAtkins> Agreed.
# [00:11] <danbeam> fantasai: so if it was implemented in WebKit and was pretty much already accounted for in the grammar of L3, that might be a candidate for inclusion?
# [00:12] <fantasai> alright, we'll put this all together and post to the WG for comment, see what they think
# [00:12] <fantasai> danbeam: yes
# [00:12] <fantasai> danbeam: Note that :not() and :matches() would be equivalent in this respect wrt complexity
# [00:13] <fantasai> danbeam: :not() just negates :matches()
# [00:13] <fantasai> danbeam: The definition would remain :matches() is an element that matches the selector in its argument
# [00:13] <fantasai> danbeam: and :not() is an element that does not match the selector in its argument
# [00:13] <danbeam> fantasai: cool
# [00:13] <fantasai> danbeam: the grammar on L3 is irrelevant
# [00:13] <fantasai> danbeam: It's mainly the implementation complexity that's the issue here
# [00:14] <danbeam> damn, :)
# [00:14] <danbeam> it's already allowed in the BNF
# [00:14] * fantasai suspects that's a bug in the BNF :)
# [00:14] <danbeam> could be
# [00:14] <fantasai> consider
# [00:15] * Joins: gilles (gilles@144.189.101.1)
# [00:15] <danbeam> FUNCTION -> IDENT '(' expr -> term [ operator term ]* -> ','
# [00:15] <fantasai> section h1:matches(div *)
# [00:15] <fantasai> it means an h1 that has a section ancestor and also has a div ancestor
# [00:15] <fantasai> could be <div><section><h1/></section></div>
# [00:15] <fantasai> or <section><div><h1/></div></section>
# [00:15] <fantasai> you have this branching issue
# [00:15] <danbeam> circular, yeah
# [00:15] <fantasai> in selectors currently, you only walk up the ancestor chain once
# [00:16] <fantasai> this will get even more complicated once we have the ability to choose the subject of the selector
# [00:16] <fantasai> that's a more important use case, and when you combine it with :matches() and :not() it gets pretty complex
# [00:17] <danbeam> "the ability to choose the subject of the selector" -> can you give an example for the dense like myself, :)?
# [00:18] <fantasai> iwantthis(:link) img { text-decoration: none; }
# [00:18] <fantasai> :link img selects the img descendant of a link
# [00:18] <fantasai> if you want the :link ancestor of an img, you need something different
# [00:18] <fantasai> still debating what exactly :) but something different
# [00:18] * Quits: anne (annevk@72.14.229.87) (Quit: anne)
# [00:19] <danbeam> OK, cool, was wondering when this ability was going to come around
# [00:19] <danbeam> often wondered why you can't traverse both ways in the ancestor tree, like you said
# [00:19] <fantasai> performance
# [00:20] <danbeam> (if I'm understanding correctly that's what's being added)
# [00:20] <fantasai> yeah, we're adding it to the spec.. remains to be seen if anyone implements it
# [00:20] <danbeam> yeah, well, in an ideal world performance doesn't exist and we add features based on wants and desires, haha
# [00:20] <danbeam> cool, cool
# [00:20] <fantasai> selector matching in layout engines operates differently from the way it does when you write it out in JS
# [00:20] <fantasai> because we're solving a different problem
# [00:21] <danbeam> when you write it out in JS = .qS or .qSA?
# [00:21] <fantasai> in JS you have a tree, and you're trying to find an element in it, usually
# [00:21] <fantasai> in layout engine, you have an element, and you want to see which of this list of selectors matches this element
# [00:22] <TabAtkins> fantasai: On that note, I think we'll probably need a "Selectors for Batch Processors" draft, since there are a couple of things that are too expensive for normal selectors but fine in qSA.
# [00:22] <fantasai> TabAtkins: we should just profile Selectors
# [00:22] <fantasai> no need for a separate draft
# [00:22] <TabAtkins> Yeah, same thing.
# [00:23] * Joins: Mike5_ (Mike5@mcclure.w3.org)
# [00:27] <danbeam> fantasai: thanks for the explanation
# [00:27] <fantasai> np
# [00:27] <fantasai> danbeam: We've wanted the ability to walk up and down the ancestor line since the early days of CSS3
# [00:27] <fantasai> danbeam: It was in some early drafts of Selectors L3
# [00:27] <danbeam> yes, I can imagine
# [00:28] <danbeam> ah, cool, didn't know that
# [00:28] * Quits: Mike5 (Mike5@mcclure.w3.org) (Ping timeout)
# [00:28] * Mike5_ is now known as Mike5
# [00:28] <fantasai> danbeam: It's really just the implementation difficulty that's preventing it from being part of Selectors
# [00:28] <danbeam> fantasai: Gotcha.
# [00:28] <fantasai> TabAtkins, brianman: Reload and let me know what needs fixing
# [00:29] <fantasai> TabAtkins, brianman: I didn't add it to the grammar per se, but I split it out into separate constructs in a way that I hope is clear enough
# [00:30] <danbeam> fantasai: I will say that it must be log(N) cheap to walk up the ancestor tree compared to other selectors (N being the average number of children per node), so hopefully it won't be without a [performant] implentation for that much longer, :).
# [00:31] <danbeam> but maybe I misunderstand
# [00:31] <fantasai> danbeam: walking up the ancestor tree is easy, that's what we do right now
# [00:31] <fantasai> danbeam: it's walking down the ancestor tree that's hard
# [00:31] <fantasai> danbeam: and handling the matching/non-matching state over the course of dynamic changes is even harder
# [00:31] * nimbupani is now known as divya
# [00:31] <fantasai> danbeam: consider if I said 'iwantthis(ul) .foo'
# [00:32] <fantasai> danbeam: selector matching takes an element and asks, does it match this selector?
# [00:32] <fantasai> danbeam: if ul has 200 children, that'll take 200 checks
# [00:32] <fantasai> danbeam: on the other hand 'ul .foo' is easy to match
# [00:33] <fantasai> danbeam: I check first if I am .foo, and then walk up my ancestor chain (usually not more than 10 elements) to find if there's a ul
# [00:33] <danbeam> I thought selectors were matched from right -> left ?
# [00:33] <fantasai> nope
# [00:33] <fantasai> that's why I said it's different in layout engines :)
# [00:33] <danbeam> ah, some silly presenter told me that once
# [00:33] <fantasai> it might be how JS frameworks implement it
# [00:33] <divya> it was actually dbaron who mentioned it in a talk
# [00:33] <divya> or so i understood
# [00:33] <danbeam> and Nicole Sullivan
# [00:33] <danbeam> (aka @stubbornella)
# [00:34] <TabAtkins> Um, fantasai, you may have read wrong.
# [00:34] <TabAtkins> Selectors *are* matched from right to left.
# [00:34] <danbeam> fantasai: they weren't talking about Sizzle
# [00:34] <fantasai> TabAtkins: yeah, you're right
# [00:34] <TabAtkins> But in the case of the subject selector, things get complicated.
# [00:34] <danbeam> fantasai: or anything like that
# [00:34] <fantasai> sory, got that backwards
# [00:34] <fantasai> right-> left
# [00:34] <divya> :)
# [00:34] <fantasai> you start with .foo, and then find ul
# [00:34] <fantasai> but currently, the rightmost is the subject
# [00:35] <TabAtkins> fantasai: That grammar + prose works for me.
# [00:35] <danbeam> yeah, so, findthis(ul) would be, 1) get all the ULs, then match some FUNCTION
# [00:35] <danbeam> ?
# [00:35] <fantasai> no, you don't get all the ULs
# [00:35] <fantasai> for selector matching you (roughly speaking) walk the entire tree element by element
# [00:35] <fantasai> and match each node against a list of selectors
# [00:36] <fantasai> so you have an element, and then you try to figure out if it matches the selector
# [00:36] <fantasai> in JS you generally have a selector, and then walk the tree trying to find what it matches
# [00:37] <fantasai> TabAtkins: problem -- since we default to ellipse, a single <length> will not be valid...
# [00:38] <TabAtkins> fantasai: Yes?
# [00:38] <fantasai> radial-gradient(to 5em, red, blue) should work
# [00:38] <brianman> mail sent. looky looky
# [00:38] <brianman> :)
# [00:38] <TabAtkins> fantasai: Just committed a formatting fixup.
# [00:38] * fantasai hopes it doesn't begin "We decided the following"...
# [00:40] <TabAtkins> fantasai: We can switch the default shape based on the to argument, I suppose.
# [00:42] <TabAtkins> "If the <shape> is omitted it defaults to 'ellipse', unless the <extent> is provided as a single <length>, in which case it default to 'circle'."?
# [00:43] <fantasai> hang on
# [00:44] * fantasai tweaks wording
# [00:44] * Quits: miketaylr (miketaylr@24.42.93.245) (Quit: miketaylr)
# [00:48] <fantasai> How about
# [00:48] <fantasai> explicitly as:
# [00:48] <fantasai> <length> Gives the radius of the circle explicitly. Negative values are not allowed.
# [00:48] <fantasai> If the ending shape is declared as an ‘ellipse’ or is left unspecified, <extent> may instead be given explicitly as:
# [00:48] <fantasai> [<length> | <percentage>]{2} Gives the size of the ellipse explicitly. The first value...
# [00:48] <fantasai> uh
# [00:48] <fantasai> that didn't paste correctly
# [00:48] <fantasai> If the ending shape is declared as a ‘circle’ or is left unspecified, the <extent> may be given explicitly as:
# [00:48] <fantasai> <length> Gives the radius of the circle explicitly. Negative values are not allowed.
# [00:48] <fantasai> If the ending shape is declared as an ‘ellipse’ or is left unspecified, <extent> may instead be given explicitly as:
# [00:48] <fantasai> [<length> | <percentage>]{2} Gives the size of the ellipse explicitly. The first value
# [00:49] <fantasai> Alternatively s/unspecified/implicit/
# [00:49] <TabAtkins> s/unspecified/omitted/
# [00:49] <fantasai> ahhhh
# [00:49] <fantasai> much better :)
# [00:49] <fantasai> ok, changed
# [00:49] <fantasai> check in?
# [00:49] <TabAtkins> do it
# [00:49] * Joins: dcosta (dcosta@187.31.77.7)
# [00:52] <fantasai> checked in
# [00:54] <TabAtkins> Just checked in a change to remove the now-incorrect line about the shape default to 'ellipse'.
# [00:55] <fantasai> no, we still need that
# [00:55] <fantasai> for the keywords
# [00:55] <fantasai> there needs to be an explicit default
# [00:56] <TabAtkins> Oh, you're right.
# [00:56] <TabAtkins> Reverting!
# [00:57] <TabAtkins> done
# [00:57] <fantasai> k
# [00:58] <fantasai> anything else
# [00:58] <fantasai> ?
# [00:59] <TabAtkins> Reviewing...
# [01:00] * Quits: paul_irish (paul_irish@216.239.45.4) (Client exited)
# [01:00] <TabAtkins> Ah, accidentally left the old intro line for 2-length extents. Removing now.
# [01:00] * Joins: miketaylr (miketaylr@24.42.93.245)
# [01:01] <fantasai> ....
# [01:02] * Quits: miketaylr (miketaylr@24.42.93.245) (Quit: miketaylr)
# [01:03] <brianman> Catching upon IRC, wasn't watching...
# [01:03] <fantasai> Tab, I'm checking in now
# [01:04] <brianman> K, skimmed
# [01:04] <brianman> Anything I need to know (changes?)?
# [01:04] <fantasai> brianman: reload and review?
# [01:04] <TabAtkins> Just a clarification that it's valid to say "r-g(to 50px, red, blue)"
# [01:05] <brianman> reload's not doing much
# [01:05] <brianman> I'll try looking at the CVS versioned one
# [01:05] <fantasai> shift+reload?
# [01:05] <brianman> ctrl, not shift...didn't help\
# [01:05] <TabAtkins> I'm gonna strip out the explicit grammar from repeating gradients and just say that it's identical to l-g and r-g except for the function name.
# [01:07] <brianman> ok, so 192 doesn't match mine either
# [01:07] <brianman> @confused
# [01:07] <brianman> I thought our compromise said we will have the grammar detail the ellipse/circle explicit concerns.
# [01:08] <brianman> rather than the prose
# [01:08] <brianman> Did that compromise get tossed?
# [01:08] <fantasai> As I mentioned above, I tried to do that, and realized it made the grammar really unreadable.
# [01:08] <brianman> I disagree.
# [01:08] <TabAtkins> Allowing for omitting 'circle' in the one-length case would be *really* verbose.
# [01:08] <TabAtkins> Like, 4-clause verbose.
# [01:09] <fantasai> brianman: So what I did was to break up <extent>'s definition by type
# [01:09] <brianman> Ok, so we need to revisit this then.
# [01:09] <brianman> I don't understand that assertion, Tab.
# [01:09] <fantasai> brianman: which makes it more explicit
# [01:09] <fantasai> brianman: even though it's not quite in the grammar
# [01:09] <fantasai> brianman: it's not done entirely by prose sentences, but by breaking up <extent> via if clauses
# [01:09] <brianman> What was wrong with my emailed grammar?
# [01:10] <brianman> All I see in email is "I changed it" with no clarification or explanation.
# [01:10] <fantasai> the explanation was that the full grammar makes me dizzy
# [01:10] <TabAtkins> [ [ <shape> , ] |
# [01:10] <TabAtkins> [ <shape>? [ at <position> || to <implicit-extent> ] , ] |
# [01:10] <TabAtkins> [ ellipse? [ at <position> || to [<length> | <percentage>]{2} ] , ] |
# [01:10] <TabAtkins> [ circle? [ at <position> || to <length> ] , ]
# [01:10] <TabAtkins> ]?
# [01:11] <brianman> My version didn't have <shape> but regardless...
# [01:11] * Quits: plinss_ (plinss@192.6.114.30) (Quit: plinss_)
# [01:11] <brianman> So what are the concerns with that grammar?
# [01:11] <TabAtkins> It's 4 clauses! With only tiny differences between each!
# [01:12] <brianman> not tiny
# [01:12] <fantasai> we can include the full grammar *also* but I'd rather not start with it at the top, more like an appendix...
# [01:12] <brianman> They are EXACTLY what we're trying to call out as important.
# [01:12] * Joins: tantek (tantek@159.63.23.38)
# [01:12] <TabAtkins> brianman: Nod to fantasai - we can include the full grammar, but the current grammar is *nearly* readable, and the prose is explicit and easy to understand.
# [01:13] * fantasai wishes we could get rid of the 2-clause and just have one... stupid comma
# [01:13] <TabAtkins> fantasai: We need an ARGSEP token!
# [01:13] <fantasai> um, how would that help exactly?
# [01:13] * fantasai doesn't seen how defining ARGSEP = "," would make the grammar more readable
# [01:13] <TabAtkins> It represents a comma iff both of its arguments are present. Otherwise, it's omitted.
# [01:13] <fantasai> ...
# [01:14] <brianman> Pull the comma outside one set of ]
# [01:14] <brianman> ,]?
# [01:14] <brianman> and then simplify
# [01:14] <TabAtkins> Well, that wouldn't actually help here.
# [01:14] <fantasai> right
# [01:14] <tantek> FYI: http://www.w3.org/wiki/TPAC2011/feedback
# [01:15] <TabAtkins> You need to express the fact that the comma is only present if at least one of the clauses is present.
# [01:15] <brianman> 192 doesn't allow this: radial-gradient(to 5px, red, blue)
# [01:16] <TabAtkins> It should...
# [01:16] <brianman> because "If the <shape> is omitted it defaults to ‘ellipse’. "
# [01:16] <brianman> My grammar allowed it
# [01:16] * fantasai looks at what 192 is
# [01:16] <TabAtkins> fantasai: It's the latest.
# [01:17] <fantasai> brianman: read further
# [01:17] <brianman> repeat recommendation: "both dimensions" should be "each dimension"
# [01:17] <TabAtkins> brianman: The prose specially calls out the case where the keyword is omitted in allowing the 1- and 2-length forms.
# [01:17] <TabAtkins> brianman: Ah yeah, meant to fix that.
# [01:17] <brianman> (in closest-side)
# [01:18] <brianman> "If the <shape> is omitted it defaults to ‘ellipse’." implies that "r-g(to 5px, red, blue" is an ellipse
# [01:23] <brianman> Also a question... Does circle/ellipse have any value for non-keyword extent cases at all? Or is it just in the way?
# [01:23] <TabAtkins> In the way, at least for now.
# [01:23] <TabAtkins> Recall that the old syntax let you specify *either* shape+extent or explicit lengths.
# [01:23] <brianman> how about...
# [01:23] <fantasai> we might add 'box' later
# [01:23] * Quits: gilles (gilles@144.189.101.1) (Quit: gilles)
# [01:23] <fantasai> (which is different from a box gradient)
# [01:23] <fantasai> maybe it'd be rectangle then :)
# [01:24] <brianman> radial-gradient( [at <position> || [to <extent> <shape>?],], <color-stop> [, <color-stop>]+ )
# [01:24] <brianman> ^ 1 clause
# [01:24] <brianman> actually bury the <shape> inside the <extent>
# [01:24] <brianman> radial-gradient( [at <position> || [to <extent>],], <color-stop> [, <color-stop>]+ )
# [01:25] <TabAtkins> Though that's closer to my older syntax, I think it's less readable.
# [01:25] <brianman> <extent> = ... <shape>?
# [01:25] * Quits: drublic (drublic@77.2.136.225) (Client exited)
# [01:25] <brianman> for the implicit
# [01:25] <brianman> and no <shape> for the explicit
# [01:25] * fantasai would prefer not to change that now
# [01:25] <fantasai> not even convinced it's better
# [01:25] <brianman> Dramatically simplifies the grammar, and avoids the circle/ellipse noise with lengths
# [01:25] <fantasai> we don't have to force authors to be concise
# [01:26] <brianman> the issue is that (relative to WD) we've attached circle/ellipse to explicit which is more harm than good
# [01:26] <brianman> this would solve that
# [01:26] <TabAtkins> It's not really any harm.
# [01:26] <brianman> "closest-side circle" and "closest-side ellipse" would appear that way and make more sense anyway
# [01:26] <brianman> it reinforces that the shape keywords are pointless and distracting for the explicit cass
# [01:27] <brianman> cases*
# [01:27] <brianman> Well if you stick with what you have, you still have the defaults problem I mentioned above.
# [01:28] <brianman> "to 5px" is invalid because it's only the circle syntax allows it, but the omission means it's ellipse not circle
# [01:28] <brianman> thus circle is required ("circle to 5px") for the 1 length case
# [01:28] <fantasai> brianman, 'to <length>' is explicitly allowed when the keyword is omitted
# [01:28] <fantasai> s/keyword/shape keyword/
# [01:29] <brianman> The "default" and the "<length>" prose are in conflict.
# [01:29] <brianman> Find a way to resolve that.
# [01:29] <brianman> More evidence that a grammar is better than prose.
# [01:30] <brianman> And I renew my concern that if we're going to allow 1 length it needs to be in the grammar. That's what we agreed upon.
# [01:30] <TabAtkins> Again, it makes the grammar *impossible* to read for anyone but us grammar wonks.
# [01:31] <brianman> Split the 4 lines into subtokens if you like then.
# [01:31] <TabAtkins> It's already stupidly complex because of the silly comma.
# [01:31] <brianman> And I disagree.
# [01:31] <brianman> I solved the comma problem above and you rejected it.
# [01:31] <TabAtkins> No, you didn't solve it.
# [01:31] <brianman> read it again
# [01:31] <TabAtkins> Your solution was incorrect.
# [01:32] <brianman> radial-gradient( [at <position> || [to <extent> <shape>?],]? <color-stop> [, <color-stop>]+ )
# [01:32] <TabAtkins> Oh, I thought you were still referring to your suggestion to pull the comma out one level and simplify.
# [01:33] <brianman> ^ that was A
# [01:33] <brianman> B is...
# [01:33] <brianman> radial-gradient( [at <position> || [to <extent>],]? <color-stop> [, <color-stop>]+ )
# [01:33] <brianman> With <extent> expressing when <shape> is allowed.
# [01:33] <TabAtkins> No, I think the grammar we decided on before, with <shape> pulled out at the beginning, is the best.
# [01:34] <brianman> Well then you have to accept the comma. That's required.
# [01:34] <brianman> And you have to fix the prose-on-prose conflict.
# [01:35] <TabAtkins> I know we ahve to accept the comma. The grammar that produces is just silly, is all.
# [01:35] <TabAtkins> (It was silly in the old syntax, too.)
# [01:36] <brianman> 1. If the ending shape is declared as ‘circle’ or is omitted, <extent> may be given explicitly as:
# [01:36] <brianman> <length>
# [01:36] <brianman> 2. If the <shape> is omitted it defaults to ‘ellipse’.
# [01:36] <brianman> Combined this means you are defining a 1 parameter ellipse -- which we said we didn't want to allow.
# [01:36] <brianman> How are you NOT concerned by this?
# [01:37] <TabAtkins> Because you're not really allowing a 1-param ellipse. ^_^
# [01:37] <brianman> Yes, you are.
# [01:37] <brianman> Shape is omitted, and thus it's an ellipse.
# [01:37] <TabAtkins> 'ellipse to 5px' is still illegal.
# [01:37] <brianman> Only half of ...
# [01:37] <brianman> 'ellipse? to 5px' is illegal
# [01:38] <TabAtkins> Yes?
# [01:38] <brianman> Let me try again.
# [01:38] <brianman> 1. We resolved to disallow 1param ellipse.
# [01:38] <TabAtkins> How about this. Kill the "if shape is omitted" line.
# [01:38] <brianman> the "or is omitted"?
# [01:38] <brianman> or the defaults tesxt
# [01:38] <brianman> text*
# [01:38] <TabAtkins> Add "or is omitted" to the keyword definitions.
# [01:38] <fantasai> reload
# [01:39] <fantasai> just, reload
# [01:39] <TabAtkins> hehe
# [01:39] <brianman> A. "If the <shape> is omitted the ending shape defaults to an ellipse."
# [01:40] <brianman> B. "If <shape> is specified as ‘circle’ or is omitted, <extent> may be given explicitly as:
# [01:40] <brianman> <length>"
# [01:40] <brianman> still conflicts
# [01:40] <fantasai> No it doesn't
# [01:40] <fantasai> <shape> doesn't default to 'ellipse'
# [01:40] <fantasai> "ending shape" defaults to an ellipse
# [01:40] <brianman> How does that help
# [01:40] <fantasai> <shape> still remains omitted
# [01:40] <fantasai> and thus the clause applies
# [01:41] <TabAtkins> Reload.
# [01:41] <TabAtkins> I applied my above suggestions.
# [01:42] <fantasai> TabAtkins, I think that makes it more confusing personally
# [01:42] <fantasai> There's no "this is what happens when you leave it out" up front
# [01:43] <TabAtkins> Well, that's because it depends on what extent you give it.
# [01:43] * Joins: arno1 (arno@192.150.10.200)
# [01:43] <brianman> I think that might solve the prose conflict but leaves an open question - "radial-gradient(red, blue)", extent is implicitly farthest-corner but shape is unknown.
# [01:43] <brianman> ending-shape*
# [01:43] <TabAtkins> No, the farthest-corner prose defines what to do with that.
# [01:44] <fantasai> TabAtkins, given that circles are a subset of ellipses, I think the prose is fine with the default ending shape stated up front
# [01:44] <fantasai> oh, bother
# [01:45] <brianman> so f-c -> c-c -> c-s -> "each dimension"
# [01:45] <fantasai> TabAtkins, no, really, I would rather have the default non-circularness stated up front as before.
# [01:45] * Quits: arno (arno@192.150.10.200) (Ping timeout)
# [01:46] <brianman> Then qualify the sentence:
# [01:46] <fantasai> which sentence?
# [01:46] <brianman> "If <shape> is unspecified and extent is a single length, then defaults to circle; otherwise ellipse."
# [01:47] <brianman> simpler...
# [01:47] <brianman> "When <extent> is a single <length>, <shape> defaults to 'circle'; otherwise, it defaults to 'ellipse'."
# [01:48] <brianman> [unspecified was redundant to the whole point of having a default]
# [01:49] <TabAtkins> That would be fine with me too.
# [01:49] <fantasai> so what if I write
# [01:49] * Quits: tantek (tantek@159.63.23.38) (Quit: tantek)
# [01:49] <fantasai> radial-gradient(to 10px 10px, blue, white)
# [01:49] <fantasai> ?
# [01:50] <fantasai> vs.
# [01:50] <TabAtkins> That hits the "otherwise" clause.
# [01:50] <brianman> defaults to ellipse, has 2 lengths - looks fine
# [01:50] <fantasai> radial-gradient(to 10px, blue, white)
# [01:50] <TabAtkins> That hits the first clause.
# [01:50] <fantasai> they are exactly the same
# [01:50] <brianman> defaults to circle, has 1 length - looks fine
# [01:50] <brianman> no they are not
# [01:50] <fantasai> there's no reason one needs to result in anything different from the other
# [01:50] <fantasai> how are they different?
# [01:50] <TabAtkins> Here's the more important question: does it matter?
# [01:50] <brianman> 1 has an ellipse shape, the other does not
# [01:50] <TabAtkins> Why are we caring about this?
# [01:50] <brianman> they render equivalently, yes
# [01:51] <fantasai> TabAtkins: That's my point. It doesn't matter whether it's an ellipse or a circle if the radii are defined to be the same.
# [01:51] <brianman> @Tab: I care because I think the grammar is the right answer. The prose is at best "ok". Broken prose is not ok.
# [01:51] <brianman> If you want to use prose instead of a grammar, use correct prose.
# [01:51] <TabAtkins> fantasai: My point is that I don't care, but Brian does, and his preferred wording isn't any less clear.
# [01:52] <brianman> a
# [01:52] <brianman> Another option is to say "The default <shape> depends on the <extent> syntax chosen." And then clarify in each type of <extent> prose which default applies.
# [01:52] * Joins: arno (arno@206.80.17.29)
# [01:53] <brianman> My concern a few edits ago was that 1 of the 3 extent syntaxes was incompatible with the default prose.
# [01:53] <TabAtkins> Givent hat there's only one clause where it's different, I dont' think that's better than just expli1citly s/aying "If X, circle; "1
# [01:53] <TabAtkins> (Sorry for spelling - kitten on keyboard.)
# [01:53] <brianman> (heh, meow)
# [01:54] * Quits: arno (arno@206.80.17.29) (Quit: Leaving.)
# [01:54] * Quits: arno1 (arno@192.150.10.200) (Ping timeout)
# [01:54] <brianman> Waiting for Elika to say Refresh.
# [01:55] <fantasai> I want to know what the difference is between 'circle' and 'ellipse' when the radii are equal.
# [01:55] <fantasai> Because if there's a difference, we need to document it.
# [01:55] <brianman> They are rendering equivalent.
# [01:55] <TabAtkins> Other than the grammar differences, no difference.
# [01:56] <brianman> For OM/serialization purposes, they are as different as "cover" and "farthest-corner" are.
# [01:56] <fantasai> OM/serialization of an omitted value is omitted
# [01:56] <fantasai> So they're the same there as well
# [01:56] <fantasai> How are they different?
# [01:56] <pjrm> might be different for animation
# [01:56] <brianman> indeed, pjrm
# [01:56] <TabAtkins> One has 1 length, the other has 2 lengths
# [01:57] <brianman> they are different states
# [01:57] <fantasai> Can you animate a circle to an ellipse?
# [01:57] <brianman> the fact that they render the same is one dimension of equivalent
# [01:57] <TabAtkins> fantasai: Yes.
# [01:57] <fantasai> I want to know what's the dimension of unequivalence.
# [01:57] <fantasai> TabAtkins: in that case, they are the same wrt animation
# [01:57] <brianman> ellipse has 2 pieces of data, circle has 1
# [01:57] <fantasai> TabAtkins: In what way are they different?
# [01:57] <brianman> example:
# [01:57] <brianman> ellipse 5.000000000000000000000001px 5.00000000000000000000000px
# [01:58] <brianman> circle 5.00000000000000000px
# [01:58] <TabAtkins> fantasai: You know the answer already. We told you. They're rendering-identical, but different in grammar.
# [01:58] <brianman> Are they the same render? "Maybe. Us dependent."
# [01:58] <brianman> UA*
# [01:58] <brianman> ..and internal representation
# [01:59] <TabAtkins> Yeah, but that detail's hidden. She's specifically asking about ellipses with identical width/height.
# [01:59] <fantasai> I still don't understand why we should care whether the ending shape is considered a "circle" or an "ellipse".
# [01:59] <fantasai> Afaict it's just an editorial difference.
# [01:59] <fantasai> Unless you show me otherwise
# [02:00] <fantasai> You're insisting that the distinction is important
# [02:00] <brianman> Because the prose is not self-consistent.
# [02:00] <TabAtkins> fantasai: We have an edit that resolves the problem. Why are you still caring.
# [02:00] <brianman> If you can't make self-consistent prose, then don't use prose. Or don't move the spec forward.
# [02:01] <fantasai> The prose /was/ self-consistent at my checkin.
# [02:01] <brianman> If 192 was yours, then you are incorrect.
# [02:01] <TabAtkins> fantasai: Repeating my question. Why are you still caring. Is the prose incorrect or unclear now?
# [02:01] * Joins: gilles (gilles@144.189.101.1)
# [02:01] <fantasai> 1.202
# [02:03] <brianman> Looking @ 202..I didn't realize you added back the full grammar (it was offscreen)
# [02:03] <brianman> Sidenote while I'm looking: I don't know if "keyword" is what you call "closest-corner". Feel free to rename that in extent-keyword.
# [02:03] <brianman> Reading...
# [02:05] <brianman> table of contents in 202 looks busted, maybe something with viewing via cvsweb
# [02:05] <brianman> Ok, so the issue with 202...
# [02:06] <brianman> "radial-gradient(to 5px, red blue)" is a shape undefined, ending-shape ellipse, with 1 length
# [02:06] <brianman> An ending-shape of ellipse with 1 length specified isn't a grammar problem (like we resolved to avoid) but is a conceptual problem.
# [02:06] <brianman> IMO
# [02:07] <brianman> Elaborating, and ending-shape of ellipse with 1 length reasonably resolves to a circle....so why wouldn't you call the ending shape a circle?
# [02:10] <brianman> </endwalloftext>
# [02:10] <fantasai> reload
# [02:13] <brianman> [Editorial] "and to an ellipse otherwise" -- The sentence runs on a bit. I'd prefer semicolon.
# [02:13] * Quits: stearns (anonymous@192.150.22.5) (Ping timeout)
# [02:13] <brianman> 204 looks fine otherwise
# [02:13] <brianman> Do we have 3/4 consensus on 204 then? Tab?
# [02:14] <brianman> [With a remaining WG open issue of cover/contain.
# [02:14] <fantasai> I can put a comma, but a semicolon would be grammatically incorrect
# [02:14] <brianman> ]
# [02:14] <brianman> depends what you change the post-semicolon text to :P
# [02:14] <brianman> but yes, a comma might help
# [02:14] <fantasai> not changing it
# [02:15] * brianman pings Tab.
# [02:15] <fantasai> TabAtkins
# [02:15] <brianman> Does that trigger a ding or something on his client?
# [02:15] <fantasai> more likely to, yes
# [02:15] <brianman> heh
# [02:15] <fantasai> usually people have notifications on for their nick
# [02:16] * fantasai has it too, but doesn't have sound :(
# [02:18] * Joins: miketaylr (miketaylr@24.42.93.245)
# [02:20] * Quits: miketaylr (miketaylr@24.42.93.245) (Quit: miketaylr)
# [02:22] <brianman> so assuming Tab comes back
# [02:22] <brianman> and doesn't have issues
# [02:22] <brianman> we just need Brad input
# [02:22] <brianman> yes?
# [02:24] * Quits: gilles (gilles@144.189.101.1) (Quit: gilles)
# [02:39] <brianman> Elika you still there?
# [02:39] <fantasai> sorry, wandered out
# [02:40] <brianman> heh
# [02:40] <fantasai> yeah, sounds good
# [02:40] <brianman> The 3rd and 4th clause
# [02:40] <brianman> Tab noticed but we didn't fix it in the edit...
# [02:40] <fantasai> ?
# [02:40] <brianman> 3rd and 4th are missing position
# [02:40] <brianman> and "to" keyword
# [02:40] <brianman> You got it covered or want me to fix it?
# [02:43] <fantasai> think I got it, just a sec
# [02:43] <fantasai> I also took out a spare set of brackets
# [02:43] * fantasai should pull them out of the short version too
# [02:43] <fantasai> reload
# [02:44] <brianman> reading sec
# [02:45] <brianman> yah looks good
# [02:45] <fantasai> ship it? :)
# [02:48] <brianman> :)
# [02:50] <brianman> oh, the brackets per line
# [02:50] <brianman> because of the strength of space
# [02:51] <brianman> I like the spacing in the expanded. It helps.
# [02:52] <brianman> Do you want to reply to the thread "please look at 206 and comment" or should I? ;)
# [02:53] <fantasai> which thread?
# [02:53] * fantasai has so many threads...
# [02:54] <brianman> Heh phone call thread
# [02:54] <brianman> i'll reply in a bit
# [02:54] <brianman> briefing my Arron
# [02:54] <brianman> Mr.*
# [02:54] * Quits: dbaron (dbaron@63.245.220.240) (Ping timeout)
# [03:01] * Joins: gilles (gilles@144.189.101.1)
# [03:31] * Quits: gilles (gilles@144.189.101.1) (Quit: gilles)
# [03:36] * Joins: dbaron (dbaron@173.228.28.129)
# [03:41] * Joins: gilles (gilles@144.189.101.1)
# [03:59] * Quits: gilles (gilles@144.189.101.1) (Quit: gilles)
# [04:59] * Joins: stearns (anonymous@50.132.63.33)
# [05:57] * Quits: dbaron (dbaron@173.228.28.129) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [06:23] * Joins: Mike5_ (Mike5@mcclure.w3.org)
# [06:28] * Quits: Mike5 (Mike5@mcclure.w3.org) (Ping timeout)
# [06:28] * Mike5_ is now known as Mike5
# [06:51] * Quits: TabAtkins (tabatkins@216.239.45.4) (Ping timeout)
# [06:54] * Joins: TabAtkins (tabatkins@216.239.45.4)
# [09:08] * Joins: Ms2ger (Ms2ger@91.181.45.148)
# [09:58] * Joins: drublic (drublic@77.2.129.32)
# [10:34] * Quits: Ms2ger (Ms2ger@91.181.45.148) (Quit: bbl)
# [10:51] * Joins: arronei_ (arronei@131.107.0.114)
# [10:51] * Quits: arronei (arronei@131.107.0.85) (Ping timeout)
# [11:11] * Quits: brianman_ (brianman@67.170.96.162) (Ping timeout)
# [11:37] * danbeam is now known as danbeam__
# [12:23] * Joins: Mike5_ (Mike5@mcclure.w3.org)
# [12:28] * Quits: Mike5 (Mike5@mcclure.w3.org) (Ping timeout)
# [12:28] * Mike5_ is now known as Mike5
# [12:53] * Joins: karl (karlcow@128.30.54.58)
# [14:09] * Quits: lhnz (lhnz@188.223.83.48) (Connection reset by peer)
# [14:10] * Joins: lhnz (lhnz@188.223.83.48)
# [14:14] * Quits: lhnz (lhnz@188.223.83.48) (Connection reset by peer)
# [14:15] * Joins: lhnz (lhnz@188.223.83.48)
# [14:16] * Quits: lhnz (lhnz@188.223.83.48) (Connection reset by peer)
# [15:20] * Joins: miketaylr (miketaylr@206.217.92.186)
# [16:06] * Quits: florianr (florianr@213.236.208.22) (Quit: Leaving.)
# [16:07] * Joins: anne (annevk@98.210.155.154)
# [16:07] * Joins: florianr (florianr@213.236.208.22)
# [16:10] * Quits: anne (annevk@98.210.155.154) (Connection reset by peer)
# [16:12] * Joins: gilles (gilles@204.14.156.63)
# [16:28] * Quits: gilles (gilles@204.14.156.63) (Quit: gilles)
# [17:09] * Quits: stearns (anonymous@50.132.63.33) (Ping timeout)
# [17:31] * Joins: paul_irish (paul_irish@76.14.88.222)
# [17:35] * Quits: paul_irish (paul_irish@76.14.88.222) (Client exited)
# [17:42] * Joins: vhardy (vhardy@192.150.10.201)
# [17:43] * Quits: vhardy (vhardy@192.150.10.201) (Client exited)
# [17:54] * Quits: florianr (florianr@213.236.208.22) (Quit: Leaving.)
# [18:04] * Joins: plinss_ (plinss@68.107.116.103)
# [18:04] * Quits: plinss (plinss@68.107.116.103) (Ping timeout)
# [18:04] * plinss_ is now known as plinss
# [18:04] * Quits: drublic (drublic@77.2.129.32) (Ping timeout)
# [18:13] * Joins: stearns (anonymous@50.132.63.33)
# [18:20] * Joins: drublic (drublic@93.132.246.238)
# [18:22] * Quits: stearns (anonymous@50.132.63.33) (Quit: stearns)
# [18:23] * Joins: Mike5_ (Mike5@mcclure.w3.org)
# [18:28] * Quits: Mike5 (Mike5@mcclure.w3.org) (Ping timeout)
# [18:28] * Mike5_ is now known as Mike5
# [18:38] * Joins: anne (annevk@98.210.155.154)
# [18:40] * Quits: anne (annevk@98.210.155.154) (Connection reset by peer)
# [18:53] * Joins: brianman_ (brianman@67.170.96.162)
# [18:55] * Joins: paul_irish (paul_irish@76.14.88.222)
# [18:56] * Quits: brianman (brianman@131.107.0.86) (Ping timeout)
# [18:58] * Joins: brianman (brianman@131.107.0.117)
# [19:01] * Joins: stearns (anonymous@192.150.22.5)
# [19:07] * Joins: gilles (gilles@144.189.101.1)
# [19:11] <fantasai> dbaron: location?
# [19:39] * Quits: gilles (gilles@144.189.101.1) (Quit: gilles)
# [19:49] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
# [19:58] * Quits: plinss (plinss@68.107.116.103) (Ping timeout)
# [20:18] * Joins: tantek (tantek@63.245.220.240)
# [20:45] * Quits: tantek (tantek@63.245.220.240) (Quit: tantek)
# [20:47] * Quits: paul_irish (paul_irish@76.14.88.222) (Client exited)
# [20:54] * Joins: paul_irish (paul_irish@107.38.86.57)
# [21:07] * Joins: gilles (gilles@144.189.101.1)
# [21:10] * Quits: paul_irish (paul_irish@107.38.86.57) (Ping timeout)
# [21:16] * Quits: gilles (gilles@144.189.101.1) (Quit: gilles)
# [21:26] * Joins: Ms2ger (Ms2ger@91.181.45.148)
# [21:36] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Make the road by walking. (B-side: Tired of Fighting))
# [21:45] * Joins: plinss (plinss@68.107.117.88)
# [22:06] * Joins: anne (annevk@208.54.15.183)
# [22:32] * Joins: paul_irish (paul_irish@72.14.229.81)
# [22:42] * Quits: Ms2ger (Ms2ger@91.181.45.148) (Quit: nn)
# [22:44] * Joins: tantek (tantek@70.36.139.219)
# [22:56] * Joins: gilles (gilles@144.189.101.1)
# [22:57] * Quits: anne (annevk@208.54.15.183) (Quit: anne)
# [23:02] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
# [23:04] * Quits: gilles (gilles@144.189.101.1) (Quit: gilles)
# [23:05] * Joins: gilles (gilles@144.189.101.1)
# Session Close: Thu Nov 10 00:00:00 2011

The end :)