15:35:20 RRSAgent has joined #css 15:35:20 logging to http://www.w3.org/2012/09/12-css-irc 15:35:25 Zakim, this will be Style 15:35:25 ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 25 minutes 15:35:30 RRSAgent, make logs public 15:36:42 dbaron has joined #css 15:51:14 jdaggett has joined #css 15:51:21 lstorset has joined #css 15:52:18 jdaggett has joined #css 15:55:44 cabanier has joined #css 15:56:08 antonp has joined #css 15:56:34 rhauck has joined #css 15:57:13 Style_CSS FP()12:00PM has now started 15:57:19 + +1.415.615.aaaa 15:57:29 - +1.415.615.aaaa 15:57:30 Style_CSS FP()12:00PM has ended 15:57:30 Attendees were +1.415.615.aaaa 15:58:12 Style_CSS FP()12:00PM has now started 15:58:16 oyvind has joined #css 15:58:20 + +1.415.615.aaaa 15:58:32 +Lea 15:58:58 +??P33 15:58:59 +plinss 15:59:13 zakim, ??p33 is me 15:59:13 +jdaggett; got it 15:59:14 +stearns 15:59:42 +??P41 15:59:46 Zakim, ??P41 is me 15:59:47 + +1.206.324.aabb 15:59:49 +glazou; got it 15:59:56 Zakim, who is here ? 16:00:06 yup 16:00:13 On the phone I see +1.415.615.aaaa, Lea, jdaggett, plinss, stearns, glazou, +1.206.324.aabb 16:00:34 On IRC I see oyvind, rhauck, antonp, cabanier, jdaggett, lstorset, dbaron, RRSAgent, Zakim, glazou, koji, miketaylr, SteveZ, macpherson__, SimonSapin, drublic, victor, vhardy_, ed, 16:00:38 ... plinss, Bert, paul___irish, hober, decadance, fantasai, Hixie, TabAtkins_, gsnedders, jwir3, Liam, stearns, isherman, krijnhuman, logbot, leaverou, arronei, trackbot, alexmog, 16:00:40 ... vhardy, sylvaing, shans, CSSWG_LogBot, heycam|away 16:00:55 + +1.619.846.aacc 16:01:26 Regrets: szilles (AB meeting), brad, smfr (Apple event), florian, rbetts 16:01:34 + +93192aadd 16:01:40 Zakim, aadd is me 16:01:44 +lstorset 16:02:17 JohnJansen has joined #css 16:02:18 -lstorset 16:02:20 +antonp; got it 16:02:29 jarek has joined #css 16:02:29 rhauck has left #css 16:02:38 Zakim, aacc is me 16:02:41 Zakim, Lea is me 16:02:46 +lstorset 16:03:00 +hober; got it 16:03:04 +leaverou; got it 16:03:08 -leaverou 16:03:20 PhilCupp has joined #css 16:03:21 +[Microsoft] 16:03:33 +[Microsoft.a] 16:03:33 zakim, microsoft has me 16:03:33 Zakim, Microsoft has JohnJansen 16:03:46 +??P78 16:03:50 +arronei; got it 16:03:52 +JohnJansen; got it 16:03:59 +leaverou 16:04:15 Zakim, P78 is me 16:04:21 ScribeNick: fantasai 16:04:28 sorry, fantasai, I do not recognize a party named 'P78' 16:04:36 glazou: any additions to agenda? 16:04:39 Zakim, ??P78 is fantasai 16:04:53 rhauck has joined #css 16:05:15 +??P82 16:05:19 +[Microsoft.aa] 16:05:23 +fantasai; got it 16:05:35 glazou: First topic is Sunday of TPAC, but we don't have any news unless Bert joins 16:06:00 glazou: Any info on TTWF location in Paris? 16:06:05 +Bert 16:06:13 +dbaron 16:06:17 rhauck: We're working on it, 16:06:27 rhauck: if anyone has suggestions, let us know 16:06:35 rhauck: we'll email the list when we know 16:06:57 rhauck: hoping by end of week 16:07:33 Bert: We reserved the room for Sunday, will be in the Hotel de la Cité Concorde, in the conference center 16:07:59 -stearns 16:08:28 glazou: Marie-Claire is planning a W3C meetup on Monday evening at the city hall of Lyon 16:08:39 glazou: Will be general meetup aobut W3C and our specs and tools built on our specs 16:08:52 glazou: Will collect items, if you want to speak, ping Marie-Claire 16:09:02 http://lists.w3.org/Archives/Public/www-style/2012Sep/0222.html 16:09:35 http://lists.w3.org/Archives/Public/www-style/2012Aug/0916.html 16:09:55 glazou: maybe defer this until Florian can attend 16:10:01 Topic: Font Load Events 16:10:08 http://dev.w3.org/csswg/css3-fonts/#font-load-events 16:10:09 http://dev.w3.org/csswg/css3-fonts/#font-load-events 16:10:21 jdaggett: started out as proposal from Florian (?) 16:10:37 jdaggett: topic brought up a number of times, need for events that indicate when fonts have been loaded 16:10:57 jdaggett: reason for this is that there could be content on the page need to be measured, can't happen until fonts are loaded 16:11:04 +??P19 16:11:11 zakim, ??p19 is me 16:11:11 +koji; got it 16:11:29 jdaggett: we've had several rounds of posts about font events from a couple years ago 16:11:36 jdaggett: Tab recently proposed something 16:11:48 jdaggett: I didn't like it, so I posted another proposal, in the spec now 16:12:01 jdaggett: we need events for @font-face fonts b/c used lazily; not loaded until they're used 16:12:34 jdaggett: Wanted to get from this call whether ppl happy with this proposal, flush out any possible objections 16:12:55 jdaggett: Interface is still in flux; several ppl sent me private emails discussing certain parts of interface, things they find confusing, etc. 16:12:59 jdaggett: Basically 2 types of events 16:13:08 jdaggett: 1 gives you a way of identifying when all fonts are ready 16:13:16 jdaggett: page could include multiple fonts, e.g. a bold and an italic 16:13:28 jdaggett: It's hard for an author to track 16:13:34 jdaggett: Also events that fire per font 16:13:45 jdaggett: An app that wants to manage fonts very carefully would use those 16:13:54 jdaggett: The existing WebLoader interface put together by Google is supported 16:14:17 jdaggett: by several type [...] is more like per font detail 16:14:42 Bert: I have no problem with the technology, just wondering what it does to the schedule of the draft 16:14:53 Bert: Will it push back LC, or so easy will go ahead without loss of speed? 16:14:59 glazou: I read it and have no general comment; like it 16:15:00 [...] = online type services, I think 16:15:12 jdaggett: Think it can go ahead without loss of speed, b/c ppl are very interested and sending lots of feedback 16:15:23 jdaggett: caveat is that the OM for CSS font face rule, leftover from CSS2 16:15:30 jdaggett: it uses CSSStyleDeclaration, which is odd 16:15:43 jdaggett: I'm starting to hear rumblings of ppl that this isn't a good idea, switch to something else 16:15:48 jdaggett: others are ambivalent 16:15:56 jdaggett: Would influence this to a certain degree 16:16:19 glazou: Could you use a CSS Rule instead? 16:16:31 jdaggett: You need some place to define something like GetPropertyValue so you can get value of descriptors 16:16:37 jdaggett: don't think need a setter for that... 16:16:51 glazou: To avoid putting null CSSFontFaceRule in document, use a CSSRule 16:16:55 jdaggett: What does that get you? 16:17:11 glazou: In the future if we change CSSFontFaceRule [..] you will get it through CSSRule 16:17:25 glazou: The result would be CSSRule, but you say in prose it is a CSSFontFaceRule 16:17:36 several ppl confused 16:17:53 glazou: You said that CSSFontFaceRule is subject to changes, b/c ppl don't like how it is right now. 16:18:01 glazou: Suppose it becomes CSSFontFaceRule2 in the future 16:18:15 glazou: That will still query interface to CSSRule, and you can use that as a reply to font-face attribute 16:18:33 jdaggett: Don't think on CSSRule there's any way to access info currently contained in CSSStyleDeclaration 16:18:51 glazou: No, not saying that. Saying that giving reply as CSSRule lets you have another interface in the future 16:19:03 dbaron: Not a question of which interface, question of what we want on that interface 16:19:14 jdaggett: Existing implementations implement the old interface, so have to consider that carefully. 16:19:20 jdaggett: I think I need to do more research on this. 16:19:30 jdaggett: Direct answer to Bert, but other OM issue could influence the schedule. 16:19:57 jdaggett: If no one has other comments, then will continue to work through details on the list 16:20:10 jdaggett: Since this is relatively major piece, once syntax worked out on the list, would like to publish another WD 16:20:13 jdaggett: Sound reasonable? 16:20:13 yes 16:20:35 jdaggett: Ok, I'll work on this another week, then ask WG for publish 16:20:48 https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0293.html 16:20:54 topic: CSs2.1 16:21:06 anton: First is table box vs wrapper box and 'overflow' 16:21:17 anton: Observed that it's implemented on table box, but only some values are supported 16:21:27 anton: others are handled as visible 16:21:33 http://lists.w3.org/Archives/Public/www-style/2012Aug/0308.html 16:21:37 anton: I proposed some wording, hope everyone's happy with it. 16:22:05 works for me 16:22:20 +TabAtkins_ 16:22:34 Bert: Looks fine to me too 16:22:43 glazou: no objection, no other comments? 16:22:49 RESOLVED: Accepted 16:23:05 anton: Second issue is an idea to help the wording in various places 16:23:22 anton: going down a path we're going down a lot: defining terms we can reuse 16:23:23 jarek has joined #css 16:23:28 anton: Want to define the term "block container element" 16:23:36 anton: "block container box" was introduced in CSS2.1 16:23:43 slow down antonp please 16:23:50 anton: A "block container element" is an element that generates a "block container box" 16:24:03 anton: Don't have this wording in CSS2.1 yet, but would make fixing various issues much easier 16:24:18 anton: I proposed this on the list, talked with fantasai, but no one else involved in conversation. 16:24:21 http://lists.w3.org/Archives/Public/www-style/2012Sep/0041.html 16:24:24 anton: Looking what other ppl think 16:24:39 anton: It's a long email, starts with motiviation 16:24:45 anton: follows with prposal 16:25:35 Rossen: Can I give you feedback a little bit later? 16:26:05 glazou: Ok, let's take a week to review this proposal and discuss it next week. 16:26:22 http://lists.w3.org/Archives/Public/www-style/2012Sep/0112.html 16:26:23 Topic: Consuming height at breaks 16:26:36 ScribeNick: TabAtkins_ 16:27:03 fantasai: I've been going back and forth on this. 16:27:14 fantasai: Rossena nd I were talking last week about edits from the San Diego f2f. 16:27:20 fantasai: one of the issues taht came up was... 16:27:35 fantasai: If you have specified height on a box, that'll terminate *above* the bottom of the page, and continue on the next page. 16:27:42 +stearns 16:27:44 fantasai: You wont' consume height between the cut and the next page, and won't draw there either. 16:27:49 fantasai: That seems weird when you consider floats. 16:28:01 fantasai: Normally you ahve text wrapping around floats, and eventually wrapping under it. 16:28:09 fantasai: But here, there's space you can't wrap text around it. 16:28:17 fantasai: Because the element isn't visibly taking up space there. 16:28:28 fantasai: So we were discussing whether you can flow content under a broken float. 16:28:30 -[Microsoft] 16:28:31 fantasai: And the answer is no. 16:28:53 fantasai: And so - should you draw backgrounds, if you're taking up space (for the float)? If you're not drawing backgrounds, what are you doing with floats? 16:29:11 fantasai: So we're considering reversing, and just making everything draw to the bottom of the page and consume height. Thoughts? 16:29:31 antonp: I think it should draw to the bottom of the page. It's confusing as a reader to see something appear to terminate, but then it's there again at the next page. 16:30:22 antonp: I think I don't want it to consume height, though. Just calculate the extra space and add it on afterwards. 16:30:50 rossen: In essense, what Anton is asking for is to have a fairly tight coupling of content and containers, which is not present anywhere else in layout. 16:31:06 rossen: You have content, which draws independently of its container (to some degree). 16:31:23 rossen: The content is free to extend to whatever extent it needs. 16:31:31 rossen: The container may or may not take a dependency on that content. 16:31:59 rossen: If your height is auto, you stretch to the height; if it's specified, you just stick with that regardless of content. 16:32:13 rossen: Let's take as an example a block container with something with clearance on it. 16:32:28 rossen: If it's height auto, the clearance int he presence of a float will extend the height of the container. 16:32:37 rossen: Back to fragmentation, we're asking the same question. 16:32:49 rossen: I have something inside which needs to be longer than it was originally (extending to the next page). 16:33:03 rossen: The container may or may not take a dependency on that content, and stretch to the content's height. 16:33:11 rossen: But if it's fixed, it's just fixed. 16:33:30 rossen: So if, in this specific case, we don't consume from the specified height, now we're coupling content and containers. 16:33:41 rossen: And then my question is, why don't we do the same thing for 'clear' or similar mechanics? 16:33:52 rossen: That's why specified height is specified - if it's exhausted, it's exhausted. 16:34:22 antonp: That makes sense to me. You're right to bring up that there's two ways to look at it. 16:34:33 antonp: The question "why is height specified?" 16:34:47 antonp: It could be because of the relationship between the box and its surroundings, or between the box and its contents. 16:35:09 antonp: If you're specifying a height because you're going to specify properties on it that rely on that height, my answer won't be good - backgrounds won't look nice. 16:35:27 antonp: But equally, if you *don't* consume height, you might get the same visual problem as before. 16:35:42 antonp: I can imagine a situation where content is fragmented onto the next page. 16:35:56 antonp: There's a gap, but it's only partially filled now by the content. 16:36:10 antonp: You lose the visual indication that there can't be any more content. 16:36:37 TabAtkins_: In that case, it's kinda like overflow:visible, which does look horrible sometimes. 16:36:52 fantasai: Yes, you might have a background positioned relative to the top of the box, so it looks bad if it continues. 16:37:44 fantasai: On the other hand, you may have two boxes that have a specified height, because you want them to be the same specific size (maybe they're side-by-side). If they break at different points, they'll end at different points, when the layout of the rest of the box depends on them being the same height. 16:38:01 fantasai: There's no answer that'll give us the right behavior in all cases. 16:38:47 rossen: You can also usually address this by specifying min-height instead. In the non-fragmented case, they're the same height; if height extends to higher than expected during fragmentation, it's auto height and the container will stretch as necessary. 16:39:31 fantasai: One data point is that existing impls draw to the bottom fo the page and consume height. 16:39:55 fantasai: At least in Moz's codebase, it requires an extra level of bookkeeping if we want to draw to the bottom of the page but not consume height. You either do both or do neither. 16:40:31 fantasai: We're getting to the point of having more layout algorithms with boxes side-by-side, which should be the same height, and it makes sense for block flow to have the same behavior, so you're consistent. 16:40:46 s/should be the same height/should draw to the bottom of the page/ 16:41:15 antonp: I wouldnt' object to taht status quo. 16:41:26 antonp: I think it should draw to the bottom. If it's easier, let's have it consume height. 16:41:39 rossen: Again, I don't think anyone is suggesting the opposite. 16:41:39 ok bye hober 16:41:41 -hober 16:42:03 rossen: The visual should be consistent with the layout. 16:43:03 TabAtkins: [...] 16:43:23 TabAtkins_: Agreed. I liked the ability to sometimes do good, but you've convinced me that we cant' do good sufficiently often, so let's just do the simple thing that's usually good enough. 16:43:36 plinss: My only concern is having a box accidentally overflow when it wasn't intended to. 16:44:02 TabAtkins_: Right, that's the time when it turns bad. But as Rossen points out, there are ways around that (use min-height), and we can always expose an explicit swtich afterwards if we want. 16:44:29 rossen: Reiterating, looking at different impls, that's the beahvior you have today with pagination. So the spec will be fairly consistent with that. 16:44:43 rossen: So if we do introduce a smarter behavior, we may be looking at compat problems. 16:45:11 plinss: I'll point out that the "impls already do this" is usually a good argument, but most impls do such a bad job at pagination, it's not really a very strong argument here. 16:45:16 fantasai: I'd agree with that. 16:46:04 fantasai: But there are cases where consuming the specified height will cause overflow, and other cases where it will prevent overflow - by not consuming the remaining space on the page, the container may be longer than expected, and *it's* parent now overflows. 16:46:25 fantasai: Two boxes that are 100% tall in a fixed-height box, side by side. 16:46:37 fantasai: I break the page, one consumes height, the other doesn't, one of the boxes will overflow its parent. 16:46:57 fantasai: So neither behavior works in all cases. It depends on the layout, and depends on the content. 16:47:12 fantasai: Both answers are 50% good and 50% bad. So, the argument to be consistent seems to win otu. 16:48:13 Bert: I think it's fine, but could you summarize the conclusion again? 16:48:37 fantasai: The conclusion is that all boxes draw and consume height as normal in the presence of breaks, to the bottom of the page past the break. 16:48:47 Bert: Okay, I can agree with that. 16:49:02 -jdaggett 16:49:24 TabAtkins_: The point is that a break just does the equivalent of putting a big spacer element in there. 16:49:36 antonp: If you glue the boxes back together, it's the total height. 16:49:42 (The key is "consumes height", the border may indeed not even reach the bottom of the page.) 16:49:58 glazou: Objections? 16:50:17 RESOLVED: Conclusion by fantasai about breaking, above, accepted. 16:51:09 -??P82 16:51:26 Topic: Counter Styles 16:51:27 http://lists.w3.org/Archives/Public/www-style/2012Aug/0916.html 16:51:33 sylvaing: lol 16:51:40 fantasai: I think florian's issue is that he'd like the counter styles that weren't in 2.1 to be marked as at-risk. 16:52:33 TabAtkins_: I'm fine with marking all the non-2.1 styles (the 2.0 styles, and the replacement CJK styles) as at-risk. 16:52:37 -fantasai 16:52:43 RESOLVED: Mark the non-2.1 Counter Styles as at-risk. 16:53:18 +??P33 16:53:19 glazou: I have one additional thing. 16:53:26 Zakim, ??P33 is fantasai 16:53:26 +fantasai; got it 16:53:30 glazou: Koji, you're right that I missed CSS Ruby in the list of documents int he prioritization email. 16:53:38 glazou: So please consider it included. I missed it by accident. 16:53:44 arronei: I ahve another comment on that list. 16:54:02 arronei: Did you send that list to some influentials, like Molly or Designers? 16:54:09 glazou: The Invited Experts in the WG got it. 16:54:21 glazou: I didn't ping anyone outside the WG. 16:54:52 TabAtkins_: I think between our IEs we ahve enough "designer voice" to be useful - Molly, Lea, etc. 16:55:02 you heard well 16:56:41 sylvaing: I don't see anything in there that says "you ahve to be an implementor to answer this", but if Anton thought he shouldn't answer it... 16:56:49 glazou: Be sure that the entire WG's answer will be valued. 16:57:34 glazou: Lea, you have two faces in this group - on the one hand, you're W3C staff, on the other hand, you're an influential member of the design community. So we'd probably be interested in your more personal opinions. 16:57:42 leaverou: Like what devs would like the most? Sure. 16:58:00 glazou: So, everyone, ping your AC reps so we can get the surveys back in two weeks time. 16:58:16 -[Microsoft.aa] 16:58:16 -dbaron 16:58:17 -[Microsoft.a] 16:58:19 -TabAtkins_ 16:58:20 -leaverou 16:58:21 -glazou 16:58:28 -stearns 16:58:30 - +1.206.324.aabb 16:58:32 -lstorset 16:58:33 -antonp 16:58:36 - +1.415.615.aaaa 16:58:40 -koji 16:58:41 -Bert 16:58:48 -plinss 16:59:11 -fantasai 16:59:12 Style_CSS FP()12:00PM has ended 16:59:12 Attendees were +1.415.615.aaaa, plinss, jdaggett, stearns, +1.206.324.aabb, glazou, +1.619.846.aacc, +93192aadd, lstorset, antonp, hober, leaverou, arronei, JohnJansen, 16:59:12 ... [Microsoft], fantasai, Bert, dbaron, koji, TabAtkins_ 17:02:04 rhauck has joined #css 17:04:34 rhauck1 has joined #css 17:11:18 glazou: what's the best way to reply? Copy the table in the email client and fill it in? Is there something better? 17:11:20 SteveZ has joined #css 17:11:28 e.g. a wiki 17:11:41 leaverou: no, copy/paste + email please 17:11:49 I was going to just make a list with headings for the priority categories. 17:12:01 TabAtkins_: ah, that sounds better! 17:12:07 guys, NO 17:12:12 :( 17:12:18 some membres may request confidentiality 17:12:24 let Peter and I handle this 17:12:29 Yeah, I was saying for *my* response. 17:12:31 members even 17:12:32 ok 17:12:33 That is, Google's. 17:12:36 ok then 17:13:07 yes, i was talking about my response too 17:13:38 ah, nevermind, I found a good way to do it with Apple’s Mail. I'll send the table 17:13:51 for anyone interested: Right click the email, choose "Redirect" 17:13:59 then you get the table without any quotation 17:15:26 In most clients, you can just select "forward" and then remove the additional headers it puts in. No additional quotation added. 17:16:36 TabAtkins_: when you forward, the original message is usually in a quote 17:16:44 Not in Gmail, at least. 17:16:51 I guess Gmail is an exception then 17:17:00 Thunderbird and Apple’s Mail put it in a quote 17:18:38 dbaron: you there? 17:18:54 leaverou, yes 17:19:04 dbaron: I had never seen color correction before 17:19:13 may I ask 17:19:31 Why is there only default and sRGB? What about specifying a custom color profile? 17:21:58 leaverou, because the spec is trying to solve the problem that it describes in the abstract & introduction 17:22:28 leaverou, which is finding a path through which we can migrate to actually being in a defined color space at all 17:22:48 dbaron: so there are thoughts about extending it in the future to allow custom color profiles, right? 17:23:12 leaverou, I'm not sure; images can, of course, have custom color profiles 17:23:19 leaverou, but I'm not sure it's really that valuable for CSS colors 17:23:29 drublic has joined #css 17:23:45 dbaron: It certainly would be valuable if cmyk() colors were allowed outside of paged media 17:23:52 leaverou, cmyk() is a mess 17:24:01 leaverou, there's no standard for what it means 17:24:20 there are multiple color profiles that define how it converts to sRGB, non? 17:24:53 leaverou, I've really got to run now, though 17:25:17 leaverou, can talk more another time 17:25:29 dbaron: sure, lets pick this up later 17:25:38 I'm very interested in the topic 17:40:52 glazou: the FXTF specs are missing, is that intentional? 17:43:45 leaverou: I'm guessing css3-background is LI because it's implemented already? 17:43:54 fantasai: exactly 17:43:57 :P 17:44:31 once something is implemented in the big four, the community's interest shifts 17:44:42 they don't really care much about the edge cases 17:44:45 in my experience 17:47:14 for example, background-clip is still not implemented correctly by WebKit, but nobody seems to care 17:50:21 drublic has joined #css 17:56:53 dbaron has joined #css 18:02:26 TabAtkins_: you there? 18:02:34 arno1 has joined #css 18:07:24 leaverou: pong 18:07:37 arno1 has joined #css 18:07:41 TabAtkins_: I think I remember a discussion about this, but I can't find it 18:07:46 in CSS hierarchies 18:07:57 can you do things like .foo > & > .bar ? 18:08:39 The current state of the spec, no. Just this morning I sent an email to Shane arguing that we should bite the bullet and allow it. 18:08:58 TabAtkins_: ha, nice coincidence. Was that email to a list? 18:09:10 TabAtkins_: I've recently started using LESS to experiment a bit with these concepts 18:09:13 Nah, private. 18:09:15 and even though LESS doesn't allow it 18:09:20 I think it would be immensely useful 18:09:26 LESS doesn't allow it? Sass does. 18:09:29 e..g. When using .foo as a "conditional" type of thing 18:10:10 e.g. I want the h1 to be styled this way, but when inside section#foo I want it to be styled a bit differently, but I still want to have everything in one place 18:10:20 Yeah, definitely. Clear and obvious use-cases. 18:10:32 I'm surprised that LESS doesnt' support it, but that's why Sass is better. 18:11:39 TabAtkins_: also, does it allow @media rules to be nested inside it? 18:11:58 e.g. I want this heading to be styled this way, but another way in print 18:11:59 Not yet. That's another, separate thing I'd like to make happen. 18:12:09 awesome! 18:12:13 Unrelated to Hierarchies - that should be part of Conditional. 18:14:27 TabAtkins_: I'm not sure about that. I'm not talking about nesting @rules inside @rules, I'm talking about nesting @rules in CSS rules 18:14:35 Yes. 18:14:53 The problems that make Hierarchies somewhat difficult are non-existent for nesting at-rules. 18:15:03 and still be able to use & inside the @rule 18:18:55 TabAtkins_: also, is & still necessary in the beginning? I remember there was a parsing issue? 18:19:17 That's the issue I was talking about up above. 18:19:36 is it that you have to lookahead to more tokens to realize it's a nested rule? 18:19:51 Theoretically, it requires infinite lookahead to disambiguate, yeah. 18:20:07 due to pseudo classes, I guess? 18:20:10 In practice, it requires 1-token lookahead for anything in HTML, and three-token for virtually anything in arbitrary XML. 18:20:27 Yeah, "a:hover" looks like a property named "a" with a value starting with the keyword "hover". 18:20:54 oh, why is it different for XML? I'd guess due to namespaces, but I don't see the collision 18:21:18 HTML has a limited set of tagnames. XML has infinite. 18:21:32 There are no collisions between html tagnames and CSS properties so far. (SVG has 5.) 18:21:38 authors can still use invalid arbitary tag names in HTML 18:21:45 and CSS is still supposed to style them 18:21:51 though I'm not sure that's specced 18:22:10 Sure, but that's okay. 18:22:38 also, CSS has to remain forwards compatible, we can't restrict the tag selector to only known tag names, right? 18:22:51 Just check the first three tokens. If they look like "ident colon ident", interpret as a selector. Otherwise, interpret as a property. 18:23:06 This effectively means we're requiring a space on at least one side fo the colon in properties. 18:23:54 TabAtkins_: could they still look like ident colon ident and look as a declaration? 18:24:22 for example, border-style:solid 18:24:37 No, because of forward-compat. We don't want legacy browsers to break when we add new tagnames or pseudoclasses. 18:24:38 yes 18:24:59 that's exactly what I'm saying 18:25:33 my IRC client isn't helping much, it has this weird bug where I have to type /reload style to get new messages sometimes 18:26:07 my IRC client (Colloquy) isn't helping much, it has this weird bug where I have to type / reload style to get new messages sometimes 18:26:21 jet has joined #CSS 18:26:38 including my messages, e.g. it seemed I didn't send this until I did that, which is why I sent it twice :( 18:27:07 Jeez. 18:27:24 it only does it on W3C rooms for some reason, both private and public 18:31:03