15:24:15 RRSAgent has joined #CSS 15:24:15 logging to http://www.w3.org/2010/05/12-CSS-irc 15:25:04 Zakim, this will be Style 15:25:04 ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 35 minutes 15:33:03 dbaron has joined #css 15:35:56 Lachy has joined #css 15:52:04 RRSAgent, make logs public 15:54:05 TabAtkins_ has joined #css 15:55:28 dethbakin has joined #css 15:55:46 oyvind has joined #css 15:56:04 Zakim, code ? 15:56:04 the conference code is 78953 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), glazou 15:56:06 Style_CSS FP()12:00PM has now started 15:56:22 + +1.858.216.aaaa 15:56:30 zakim, aaaa is me 15:56:30 +plinss; got it 15:58:27 + +95089aabb 15:59:56 + +1.617.650.aacc 16:00:14 zakim, aacc is me 16:00:14 +dethbakin; got it 16:00:50 bradk has joined #css 16:01:51 + +1.415.920.aadd 16:01:59 + +1.650.275.aaee 16:02:01 - +1.415.920.aadd 16:02:07 ChrisL has joined #css 16:02:15 Zakim, aaee is me 16:02:15 +bradk; got it 16:02:19 +Bert 16:02:33 +Michael_Cooper 16:02:59 +[Microsoft] 16:03:13 zakim, microsoft is me 16:03:15 +ChrisL 16:03:17 +arronei; got it 16:03:54 smfr has joined #css 16:04:11 -ChrisL 16:04:12 +David_Baron 16:04:16 Zakim, whois noisy? 16:04:16 I don't understand your question, glazou. 16:04:50 +ChrisL 16:04:50 ScribeNick: fantasai 16:04:54 TabAtkins_: np 16:05:44 glazou: please send minutes from last week 16:05:58 glazou: No extra agenda items today 16:06:10 http://lists.w3.org/Archives/Member/w3c-css-wg/2010AprJun/0083.html 16:06:13 CSS2.1 16:06:16 + +1.408.636.aaff 16:06:30 Zakim, aaff is smfr 16:06:30 +smfr; got it 16:06:30 glazou: Arron sent me an email on the status of the spec. We have 57 open issues on CSS2.1 16:06:35 glazou: list is in the agenda 16:06:46 glazou lists assigned actions 16:06:53 glazou: 23 open and unassigned 16:07:00 glazou: We have to solve all of these asap. 16:07:08 glazou: Ideally we'd like to have all the proposals by the end of this month 16:07:24 glazou: and assign the actions to update the spec and the test suite 16:07:49 Bert: It's not as bad as it seems. All but 2 of mine are editorial. 16:08:49 glazou: Let's browse the issues 16:08:51 http://wiki.csswg.org/spec/css2.1#issue-26 16:09:03 http://wiki.csswg.org/spec/css2.1#issue-101 16:09:11 dbaron: We came to a resolution for 26, but I need to write wording. 101 I need to look into 16:09:18 glazou: Can you do that before the end of the month? 16:09:19 dbaron: I think so 16:09:28 http://wiki.csswg.org/spec/css2.1#issue-53 16:10:30 +SteveZ 16:10:31 fantasai: I'm supposed to work on the test suite, so I probably won't get to CSS2.1 issues until beginning of June 16:10:44 glazou: How do these issues impact the test suite? 16:10:51 fantasai: Some will require test changes, other require more tests. 16:11:41 arronei: I've been trying to track issues and write tests, but haven't caught everything 16:11:46 http://wiki.csswg.org/spec/css2.1#issue-60 16:12:01 fantasai ... June 16:12:18 arronei: Sylvain's issue, I think he just needs to send out a summary email on that. 16:12:42 glazou: Bert? 16:13:29 Bert: Haven't read through the anonymous table one, I had promised to do that before editing. 16:14:00 Bert: The one on table captions and block-level items, #120, that will take me time 16:14:06 Bert: but should be possible before the end of the month 16:14:51 glazou: Arron? 16:15:01 arronei: I should have the testcase ones today or tomorrow. 16:15:18 arronei: I assigned one to myself about creating images for line-height etc. I can have that done this week 16:15:33 glazou: Tab sent an email about his actions 16:15:39 glazou: He did issue 161 16:15:46 glazou: And will have a proposal for 110 by Friday. 16:16:09 glazou: We have 11 issues assigned to the WG, and 12 that are unassigned 16:16:23 arronei: Do we have feedback on the SVGWG one yet? 16:17:08 ChrisL: In summary, I'm halfway through porting your testcases to SVG. Should be done by end of this week. We have an F2F end of may, so should be able to discuss and close the issue June 2nd 16:17:36 glazou: First unassigned issue is 86 16:17:44 http://wiki.csswg.org/spec/css2.1#issue-86 16:19:18 dbaron: The horizonal position is straightforward, vertical maybe harder. 16:19:26 dbaron: Could also leave it undefined 16:19:34 fantasai: Prefer to leave it undefined, define in CSS3 Lists 16:19:38 arron agrees. 16:19:41 actually, the complexity of horizontal and vertical isn't that different 16:20:03 RESOLVED: Leave exact position of the bullet undefined. 16:22:07 "The position of the list-item marker in the presence of floats and when text-align is not its initial value is undefined in CSS2.1." 16:22:44 "when adjacentg to floats" maybe? 16:22:53 better 16:23:23 http://wiki.csswg.org/spec/css2.1#issue-117 16:23:52 I think this is basically http://lists.w3.org/Archives/Public/www-style/1999Mar/0121.html :-) 16:24:05 at least 4a 16:25:27 dbaron: I think 4b and 4c are relatively straightforward. 16:25:40 dbaron: I think this was a point we missed when we added the strut 16:26:05 dbaron: I think the solution is to remove bullet .4 and add a parenthetical to .3 mentioning the strut 16:27:15 dbaron: "(Including the strut described below.)" 16:27:26 dbaron: Although we don't actually say strut, we say "what TeX calls a strut" 16:28:25 I suggest "(taking into consideration the strut mentioned below)" 16:28:35 dbaron: 4a is the same as my message from 1999. 16:28:44 dbaron: I think we resolved to leave it undefined in 2.1 and define it in 3 16:29:32 -SteveZ 16:29:53 glazou: fine by me 16:30:07 fantasai: Do we need to make it explicitly undefined? 16:30:16 dbaron: It's not currently stated as undefined 16:30:36 +SteveZ 16:31:10 RESOLVED: Mark 4a undefined in CSS2.1, accept dbaron's proposal (drop 4 and add parenthetical to 3) for 4b and 4c. 16:31:18 http://lists.w3.org/Archives/Public/www-style/2009Mar/0004.html 16:31:50 dbaron: I think 10a is editorial, but probably a good idea 16:33:24 I think 10b is editorial; I have no opinion either way. 16:33:41 Bert: There's more explanation in CSS3, but I wouldn't want to copy it all. 16:34:26 several happy to leave explanation to CSS3 16:34:37 fantasai: I don't see us having a motivation to work on CSS3 Line in the near future 16:35:07 glazou: What are our options? 16:35:28 Bert: The issue there is to mention that baselines are found in the font. Maybe we can make a note about baselines being found in the font metrics somewhere 16:35:47 Chris: Yes, I think that's enough of a hint to say that they're in the font without having to import the whole css3 line module. 16:36:00 arron: And maybe say at the end of that that this will be defined further in a future specification. 16:36:44 http://wiki.csswg.org/spec/css2.1#issue-119 16:37:01 -SteveZ 16:37:03 arron: I think this can be done at the same time 120 is being updated with a new proposal 16:37:38 +SteveZ 16:37:50 dbaron: I think they're actually done rather different. The definition Anton cites for table cells is not really the definition that we want here anyway 16:38:32 dbaron: The baseline of a block is the baseline the block would have if it had text in it 16:38:48 dbaron: The problem is that what the baseline actually is depends on what characters are in the block. We just sort of ignore that issue and pick one 16:39:13 dbaron: This another reason why the anonymous root inline box idea works better than the strut idea. 16:39:30 dbaron: That said, I think the proposal in the issues list, to remove "block's", is the right idea here. 16:40:07 dbaron: I can also see changing block's baseline to line's baseline. But I'd be ok either way, and maybe Bert can come up with something better 16:40:21 Bert: Either would work for me. Don't know which is better. Can't think of a third option. 16:41:07 http://wiki.csswg.org/spec/css2.1#issue-129 16:41:59 Bert: It's a bit more complex than that. To get all the backup out of the parser, we'd have to change some of the tokens. I'm not in favor of that. 16:42:09 Bert: There aren't many cases that change. 16:43:11 glazou: Zack's email was mostly concerned about performance of the scanner. 16:43:40 glazou: It is not necessary to implement CSS parsing using the tokens in the grammar, they are just there to define things. 16:43:52 Bert: Yes, but you'd still have to buffer things no matter how you implement. 16:44:17 dbaron: The point Zack made is something we generally want to be true: anything that is itself a token in the tokenizer, you want the same thing minus one character to also be a token. 16:44:38 dbaron: Whether or not that thing is the same token is less important. 16:44:58 dbaron: You don't want to start parsing a long token, realize it doesn't end, and have to go back all the way to the beginning. 16:45:07 dbaron: The current place we have this problem is the url() token. 16:45:42 dbaron: Gecko gets around this by handling it in the parser. 16:46:05 glazou: The prose says it is a URI. If it's not a valid URI, it should be an invalid token. 16:46:35 dbaron: ... we're scanning all these characters. We build a character buffer of the characters that will be the URL. 16:47:30 dbaron: If we get a valid URL token, then we save it. If we don't, we go backwards to the start. 16:47:52 dbaron: If you need to backtrack you have to go and reparse and match parentheses and things 16:48:03 peter: Parentheses aren't allowed unquoted. 16:48:32 dbaron: But essentially, if you're using a tokenizer, you have to backtrack through the whole thing and retokenize so you handle brackets and parens correctly 16:49:42 glazou: Is ? necessary? 16:49:50 dbaron: I don't know. 16:50:16 peter: We already say that url parsing is its own special world anyway 16:50:33 dbaron: But in the error cases, you don't match that token. So if you follow the spec as written, you need to go back and retokenize 16:50:54 dbaron: An example of an invalid url token is url(a'b) 16:51:18 dbaron: One of the things Zack was proposing was to add a new token for invalid URIs so that you don't have to backtrack. 16:51:35 dbaron: A token that represents the invalid cases so you don't have to go back and count brackets and braces. 16:51:45 peter: I think I prefer that. 16:51:54 peter: It may be a bit weird to define that token 16:53:18 dethbakin has joined #css 16:53:49 glazou: Ok, let's defer this until next week so we have time to discuss, dbaron with Zack, etc. 16:54:35 alllo ?-) 16:54:44 - +95089aabb 16:54:45 glazou, we still hear each other 16:54:48 ChrisL is talking, so maybe you need to reconnect 16:54:50 glazou, but we can't hear you 16:54:56 http://wiki.csswg.org/spec/css2.1#issue-137 16:55:08 + +95089aagg 16:55:08 -SteveZ 16:55:16 Zakim, aagg isme 16:55:16 I don't understand 'aagg isme', glazou 16:55:31 Zakim, 95089aagg is me 16:55:31 sorry, glazou, I do not recognize a party named '95089aagg' 16:55:39 Zakim, aagg is glazou 16:55:39 +glazou; got it 16:56:12 Chris: I have some proposals for other issues 16:56:17 ISSUE 143 has already been dealt with, a very clear spec change looks good to me, suggest closing it 16:56:30 http://dev.w3.org/cvsweb/csswg/selectors3/Overview.html.diff?r1=1.66&r2=1.67&f=h 16:57:27 ChrisL: fantasai's wording changes look good, let's put those in 16:57:41 RESOLVED: Copy Selectors 3 wording into 2.1 for issue 143 16:57:48 http://wiki.csswg.org/spec/css2.1#issue-148 16:58:22 Add 'unicode-bidi: embed' should be there 16:58:48 dbaron: It was removed in the first WD of 2.1, but I can't find a record of why. 16:59:06 http://wiki.csswg.org/spec/css2.1#issue-156 16:59:07 ChrisL: It might have been removed because someone didn't understand why it was there. We all agree it should be there, so let's put iback in 16:59:13 RESOLVED: Accept proposal for 148 16:59:22 So I think the reason it might have been taken out was concern about embedding levels bumping above 63. 17:00:01 Hm, yes, but we should have wording to prevent embedding levels from increasing on blocks 17:00:25 Issue 156 was resolved at F2F, resolution was not copied into issues list. 17:01:17 glazou: Please review the vendor prefixes thread so we can discuss it. 17:01:28 -ChrisL 17:01:29 arron: Please everyone take a look through the unowned issues 17:01:30 -smfr 17:01:30 -David_Baron 17:01:31 -plinss 17:01:32 -arronei 17:01:34 -dethbakin 17:01:36 -Michael_Cooper 17:01:38 -Bert 17:01:40 -glazou 17:01:40 -bradk 17:01:41 Style_CSS FP()12:00PM has ended 17:01:43 Attendees were +1.858.216.aaaa, plinss, +95089aabb, +1.617.650.aacc, dethbakin, +1.415.920.aadd, +1.650.275.aaee, bradk, Bert, Michael_Cooper, ChrisL, arronei, David_Baron, 17:01:46 ... +1.408.636.aaff, smfr, SteveZ, +95089aagg, glazou 17:22:39 shepazu has joined #css 17:32:09 arronei has joined #CSS 17:39:38 shepazu has joined #css 18:25:25 dbaron has joined #css 18:56:27 Zakim has left #CSS 19:57:52 jdaggett has joined #css 20:01:28 ChrisL2 has joined #css