15:31:24 RRSAgent has joined #CSS 15:31:24 logging to http://www.w3.org/2010/06/02-CSS-irc 15:31:38 zakim, this will be style 15:31:38 ok, plinss; I see Style_CSS FP()12:00PM scheduled to start in 29 minutes 15:31:46 rrsagent, make logs public 15:47:35 oyvind has joined #css 15:55:23 fantasai: Yeah, I'll be on in a few. ^_^ 15:57:15 Style_CSS FP()12:00PM has now started 15:57:22 + +1.858.655.aaaa 15:57:30 zakim, aaaa is me 15:57:30 +plinss; got it 15:57:46 + +1.650.253.aabb 15:57:57 Zakim, aabb is me 15:57:57 +TabAtkins; got it 15:59:36 bradk has joined #css 15:59:41 +ChrisL 15:59:59 +fantasai 16:00:31 + +1.650.275.aacc 16:00:47 +Bert 16:00:59 Zakim, aacc is me 16:00:59 +bradk; got it 16:01:19 + +49.238.aadd 16:01:52 zakim, aadd is CesarAcebal 16:01:52 +CesarAcebal; got it 16:02:00 zakim, who is breathing? 16:02:00 I don't understand your question, ChrisL. 16:02:02 smfr has joined #css 16:02:03 I think I am going to hang up and try again to see if I can get a better connection... 16:02:26 +[Microsoft] 16:02:27 zakim, microsoft is me 16:02:27 -bradk 16:02:27 +arronei; got it 16:02:33 + +1.408.636.aaee 16:02:43 Zakim, aaee is me 16:02:44 +smfr; got it 16:03:21 -ChrisL 16:03:33 +bradk 16:04:56 dbaron has joined #css 16:05:36 +[IPcaller] 16:05:43 +David_Baron 16:06:04 ScribeNick: fantasai 16:06:06 +SteveZ 16:06:12 Shit. 16:06:17 ScribeNick: TabAtkins 16:06:34 plinss: Anything to add to the agenda? 16:06:43 plinss: Request from Hakon to publish GCPM. 16:06:47 -[IPcaller] 16:06:51 howcome has joined #css 16:07:02 TabAtkins: I have no objection to publishing. 16:07:22 szilles has joined #css 16:07:28 plinss: I think we all agreed to publish once he fixed one issue, which I believe he did his best to address. 16:07:37 RESOLVED: Publish new GCPM working draft. 16:07:45 Correct 16:07:51 +ChrisL 16:08:15 plinss: Css 2.1 issues. Anything interesting in the test suite? 16:08:29 howcome, thanks for clarifying that cmyk is device cmyk. I still think its underspecified but at least it is a little clearer now 16:08:32 fantasai: i18n submitted their tests and I've added them. Not sure if I got all the encodings right, so I'll need Richard to check them. 16:08:49 fantasai: Taking a while to convert Hixie's tests right now. 16:09:12 I'm about halfway through, but it takes awhile since they often need manual tweaking 16:09:26 Reftests are buildable. I've added bzbarsky's, not yet Mozilla's 16:09:26 arronei: There'll be substantial updates from me from feedback on test cases. 16:09:37 arronei: No more issues from the repo. 16:10:00 plinss: David, any updates? 16:10:17 dbaron: Wrote proposal for 66 last night, haven't yet resolved 101 - it's somewhat more involved. 16:10:19 http://lists.w3.org/Archives/Public/www-style/2010Jun/0048.html 16:10:21 http://lists.w3.org/Archives/Public/www-style/2010Jun/0049.html 16:10:25 +??P29 16:10:27 dbaron: There was one response on www-style about issue 66. 16:10:36 s/issue 66/issue 26/ 16:10:36 -??P29 16:11:08 dbaron: I think Peter's first 2 proposed changes we should just take, and the remaining ones should maybe be a separate issue. 16:11:22 the first 2 are the (see above) and the s/specified/computed/ 16:13:50 plinss: Are we okay with accepting the proposal? 16:15:13 arronei: I agree with putting the later points into a separate issue. 16:15:19 +[IPcaller] 16:15:28 +1 for the proposal 16:15:44 RESOLVED: Accept dbaron's proposal for issue 26, open a new issue for the remaining points from Peter Moulder 16:17:27 Bert: For my issues, I'm working on 120. It's difficult. I'm checking if it's possible to resolve. 16:17:34 Bert: I've put text for 117 on the list. 16:17:43 Bert: I think everything else is just editorial and I'll slowly work through them. 16:17:55 plinss: arron? 16:18:38 arronei: I finished 134. 107 I'm working on, but the test case is wrong. 154, I have the diagram drawn up, I'm having one of our guys look at it first. It should be pretty close. 165 I haven't gotten to yet. 16:18:48 arronei: But I think 165 is actually a css3 issue. 16:19:08 arronei: Because it talks about "start" and "end" the entire email. 16:19:29 I think 165 is a CSS 2.1 issue. 16:19:42 plinss: Tab? 16:19:51 It's the question of whether the way float placement rules respond to 'direction' is correct. 16:19:58 But it might be pointing to the wrong emails. 16:19:58 TabAtkins: Issue 161 is Bert's now to make the edit, the rest I've worked on, but havent' brought anything to the list yet. 16:20:27 plinss: 129 is for all of us to discuss and bring to a close. 16:20:34 http://lists.w3.org/Archives/Public/www-style/2009Jun/0164.html 16:21:20 plinss: What to do about brace matching inside an invalid url. 16:21:42 Bert: The question is if you find parens or brackets, is it invalid or something other than a url - something we haven't defined yet. 16:21:47 Bert: Currently it's the latter. 16:22:39 http://wiki.csswg.org/spec/css2.1#issue-140 http://wiki.csswg.org/spec/css2.1#issue-129 16:23:00 plinss: Problem with urls is that characters like brackets are valid within urls, but if something happens later that makes it invalid do we have to back up to handle it properly or not. 16:23:41 plinss: fantasai, you're mentioning that issue 140 seems to be related. 16:24:43 plinss: It's similar, but it might even be putting us in an opposite direction from the issue 129. 16:27:03 plinss: We seem to be stalled on this. Does anyone have any ideas? 16:27:14 Bert: I think it's possible to expand the definition of any* like dbaron says. 16:27:33 Bert: Nothing uses that, it's just making something more defined where it is undefined. 16:27:47 Bert: I think it's ugly to define a grammar and then say we won't use it, but oh well. 16:28:01 Bert: But are braces all that needs to be added, or other tokens as well? 16:28:18 dbaron: Possible semicolons. 16:28:28 Bert: What about @? 16:28:41 dbaron: Isn't a lone @ DELIM? 16:28:50 Bert: yes, sorry, I meant @keyword. 16:29:27 dbaron: Putting braces in any* is a little problematic for the selector rule, though? 16:29:38 Bert: Yes. 16:29:39 and ; is a little problematic for the at-rule part 16:29:47 sorry, i have to drop off the call 16:29:50 Bert: But if it's only braces it only needs to be changed in 3 places. 16:29:52 -smfr 16:30:28 plinss: We seem to have consensus on issue 140 and nothing but silence on issue 129. 16:30:38 plinss: Can we even get agreement on what we want the behavior to *be* on 129? 16:30:49 Bert: I remain reluctant to change that. 16:31:01 Bert: I'm not planning to use parens in urls, but I don't know if someone else does. 16:31:33 Bert: The issue with invalid comments is less serious. Afaik there is no way to use the current definition for anything. 16:32:10 Bert: It doesn't make sense to only change comments, though, since the goal is to remove all backup. 16:32:23 url((http://foo/), (12)) 16:32:38 TabAtkins: Do we actually think that anyone has invented a new url syntax that uses parens. 16:33:02 fantasai: I'm pretty sure there's random urls with parens stuck in them. 16:33:17 Bert: As far as I know, though, current impls reject that as they should. 16:33:27 howcome has joined #css 16:33:34 fantasai: If parens are mismatched, then how we resolve this issue will change how the stylesheet is handled. 16:33:39 smfr has left #css 16:33:45 fantasai: Under the current urls you have to go back and match the parens. 16:33:56 ChrisL: There's no requirement in the uri spec to match the parens, though, right? 16:34:04 ChrisL: It's a valid url to have mismatched parens. 16:34:52 plinss: Our definition of url token doesn't even allow parens in the url. 16:35:08 Bert: Right, that's what allows the extension I put into irc. 16:35:10 url([) 16:35:16 fantasai: Also brackets cause the issue. 16:35:35 plinss: brackets and braces are allowed in our definition of a url token, parens are not. 16:35:39 background: url([) purple; 16:35:41 is it purple? 16:35:56 I say: yes. 16:36:06 plinss: that is a perfectly valid url. 16:36:19 plinss: Now what happens if you put something after that bracket and it's no longer a valid url? 16:36:24 background: url([()) purple; 16:36:26 The current spec says that: 16:36:37 background: url([) purple; 16:36:39 is purple 16:36:40 but 16:36:44 background: url([() purple; 16:36:45 is not 16:37:02 what about url([()) purple? 16:37:08 fantasai, not purple 16:37:10 plinss: Correct. Now is that our desired behavior or not? 16:37:31 background: url([()); color: purple; 16:37:44 fantasai, still not purple 16:37:54 Bert: We know whether it's purple or not, the question is we want to allow that grammar for other people, even if we didn't use it. 16:38:15 fantasai: That's not the issue. The issue is that the parser has to go back and reparse everything in the url token. 16:38:47 fantasai: Where it then treats things as random garbage, with matched quotes and brackets and such. 16:39:08 fantasai: So we know how to deal with invalid stuff. But an impl said they don't want to have to back up like that. 16:39:26 fantasai: So what we want is something that can read until we know it fails, and then just get thrown out without reinterpreting. 16:39:31 backing up anarbitrary amount is the problem 16:39:45 szilles: So another way of saying this is, as long as it's a legal uri we'll put it into the token and not reparse it? 16:39:48 fantasai: Right. 16:39:59 szilles: And this is an error recovery mechanism. 16:40:11 plinss: Bert is resistant to change the core grammar. 16:40:29 Bert: As far as I can see it's not an error recovery mechanism, it's just one token or another? 16:41:07 plinss: But the issue is that you can't tell which token you have until it's either done or you reparse. 16:41:29 Bert: You have the same problem with other tokens, such as numbers and dimensions. 16:41:37 ChrisL: urls can be bigger, though. 16:41:51 Bert: I measured, and couldn't measure the difference until the url hits megabyte lengths. 16:41:59 ChrisL: Bert, so you're suggesting close the issue with no change? 16:42:02 Bert: Yes. 16:42:46 Bert: It's a pity no one noticed this 10 years ago, but I don't like changing things at this late stage. 16:43:07 plinss: There is the other proposal, to change the grammar. 16:43:44 plinss: There's impls that don't want to backup. I understand Bert's point, but another point is that there's a difference in error recovery, such as what Elika put in IRC. I don't think that our existing specified behavior really makes sense, and is something we want. 16:44:26 szilles: I lead toward changing the grammar because it seems to let urls accept anything except that, because we use parens, in a url you have to escape the parens. 16:44:45 szilles: And then if it happens to be invalid for some other reasons, that doesn't seem that it should affect the tokenizer. 16:45:07 Bert: That case that elika typed into IRC would change. 16:45:15 :P 16:45:34 Bert: So it's clearly a change. 16:45:42 szilles: But it's also clearly a legal url. 16:45:44 szilles: I don't see that in a sufficiently obscure case we can't make a change 16:45:58 plinss: but it's not legal CSS, becasue you have to escape the parens. 16:46:13 fantasai: I typed several things into IRC, and only one of them would change. 16:46:26 fantasai: As long as it's a valid url token, there's no change in behavior. 16:46:54 szilles: That's what I tried to argue. For simplicity of use, putting any valid uri in there with a simple rule saying that parens need to be escaped is what I would hope for. 16:47:14 plinss: That seems to already be in place. The only thing we're changing is the error recovery behavior. 16:47:23 szilles: I say consume as much as fits the uri syntax and not go back. 16:47:53 TabAtkins: Which of the cases that elika posted would change under the proposal? The url([(), or the url([())? 16:48:31 TabAtkins: Right now both kill the entire declaration. Would either of those change? 16:48:50 fantasai: It would still kill the declaration, but it wouldn't eat more trying to close the bracket. 16:49:23 szilles: Gut feeling, it seems people are more likely to forget to escape a paren, then they're looking to match a bracket or a brace. 16:49:42 fantasai: In either case it's invalid, the question is just if we lose the entire rest of the stylesheet or just the declaration. 16:49:47 szilles: I'd prefer just lose the declaration. 16:49:54 fantasai: Can we take a straw poll on this? 16:50:00 zakim, who is on the phone? 16:50:00 On the phone I see plinss, TabAtkins, fantasai, Bert, CesarAcebal, arronei, bradk, David_Baron, SteveZ, ChrisL, [IPcaller] 16:50:24 plinss: IN favor of only losing declaration (change grammar). 16:50:35 TabAtkins: I prefer to change the grammar. 16:50:40 fantasai: Change the grammar. 16:50:44 Bert: Keep the grammar. 16:51:03 CesarAcebal: Keep the grammar. 16:51:23 arronei: Prefer to keep, but I think we have to change. So my vote is to change. 16:51:33 bradk: Change, but I don't feel strongly. 16:51:41 dbaron: Change the grammar. 16:51:46 szilles: Change the grammar. 16:51:52 ChrisL: Change the grammar. 16:52:10 howcome: Keep the grammar, but I don't feel strongly. 16:52:43 8 for change (1 not strong), 3 to keep (1 not strong). 16:53:03 plinss: I wonder if we could get the same effect by changing the prose rather than the grammar. 16:53:18 ChrisL: You could, but that would just mean you don't implement the grammar anyway, you do something else. 16:53:34 fantasai: I think most of our error handling is in the prose anyway, not the grammar. 16:54:44 plinss: We have a few existing INVALID tokens, so adding another one or two would be good for clarity. 16:55:18 RESOLVED: Change the grammar to avoid backup. 16:55:37 I offer to take Issue 145 which has no owner. I think the commentor is correct, will discuss with I18n folks 16:55:46 -bradk 16:56:14 ChrisL: On issue 114, SVG liked option 1, which is that font names are idents or quoted strings. 16:56:21 i18n has gone back and forth on 145, I don't expect us to get an answer until next week's bidi f2f is over 16:56:39 Bert: There's a mistake in the message you sent. It says proposal 2 requires a change in the grammar, but that's not the case. 16:57:04 ChrisL: We understood that it did, and because of your reluctance to change the grammar we didn't think it would fly. 16:57:30 ChrisL: We thought it was slightly irritating to have to quote fonts starting with a number, but it was ok. 16:57:43 ChrisL: What was the accepted proposal for csswg? 16:57:55 +bradk 16:58:14 -bradk 16:58:22 fantasai: IDENTs. 16:58:26 http://lists.w3.org/Archives/Public/www-style/2010Apr/0275.html look for CSS2.1 Issues 16:58:34 Bert: I have a different memory of the straw poll. 16:59:07 glazou: 7 for 1, 4 for 2, 3 for 3, and almost everyone can live with 16:59:07 everything 16:59:27 ChrisL: Since 1 was most popular for CSS and SVG, we can just pick that, close it, and move on? 16:59:30 fantasai: Yup. 16:59:51 arronei: I'll have to change the test cases, right? 17:00:26 plinss: I think you may have gotten 1 and 2 mixed up. 17:00:36 [discussion] 17:00:57 plinss: Okay, so we're going with 1. 17:01:00 Bert: A pity. 17:01:31 resolution: go with option 1 on issue 114 17:01:33 fantasai: This is probably better for authors anyway, since current impls are ident+. 17:02:03 -howcome 17:02:16 szilles: I believe the goal was to give authors something easy to understand, rather than to omit quotes. 17:02:28 RESOLVED: font-family names are ident+ 17:02:32 RESOLVED: Accept option 1 (font names are IDENTs or quoted strings) for issue 114. 17:02:41 plinss: Did we come to a resolution for issue 129 or 140? 17:03:09 I think plinss just asked about 140. 17:03:13 We did resolve 129. 17:03:14 fantasai: Seems that bert and dbaron agreed to change the grammar to handle 129 per dbaron's proposal. 17:03:24 s/129/140/ 17:03:50 plinss: I suggest whoever does one does both 17:04:46 plinss: Accept in principle to change the grammar for 140 and note that we wont' use the additional capabilities (exact wording tbd). 17:04:53 s/plinss/RESOLVED/ 17:04:58 RESOLVED: Accept in principle to change the grammar for 140 and note that we wont' use the additional capabilities (exact wording tbd). 17:05:23 Bert: I'm going on a holiday soon, so if I work on it'll be in july. 17:05:39 fantasai: How about you work on the grammar rather than the block thing, since I can do the block thing in June, but can't do grammar changes. 17:05:44 Bert: That'd work. 17:05:50 -ChrisL 17:06:11 -David_Baron 17:06:42 -arronei 17:06:47 -plinss 17:06:48 -Bert 17:06:55 -fantasai 17:06:59 -CesarAcebal 17:07:00 -TabAtkins 17:07:19 -SteveZ 17:07:20 Style_CSS FP()12:00PM has ended 17:07:22 Attendees were +1.858.655.aaaa, plinss, +1.650.253.aabb, TabAtkins, ChrisL, fantasai, +1.650.275.aacc, Bert, bradk, +49.238.aadd, CesarAcebal, arronei, +1.408.636.aaee, smfr, 17:07:24 ... David_Baron, SteveZ, howcome 17:36:51 So where did the css3-color test suite get moved? 17:36:57 It used to be in dev.w3.org CVS 17:37:02 along with implementation reports 17:41:30 arronei has joined #CSS 17:50:23 Hmmm. It seems the development copy of the css3-color test suite moved from dev.w3.org to some other repository, but I'm not sure where. 18:00:39 What makes you think that? 18:03:15 TabAtkins_ has joined #css 18:06:24 http://dev.w3.org/CSS/css3-color-test-suite/src/ is empty 18:06:55 Oh I misread what you wrote. Was there ever something there? 18:07:16 http://dev.w3.org/cvsweb/CSS/css3-color-test-suite/src/Attic/ says it moved to test.csswg.org 18:07:47 but http://test.csswg.org/source/approved/css3-color/ is also empty 18:07:51 so I'm not sure where it moved 18:08:20 http://test.csswg.org/source/cvs-import/css3-color-test-suite/ ? 18:09:04 http://test.csswg.org/svn/cvs-import/css3-color-test-suite/ for svn access... 18:11:41 ah, ok 18:14:21 I think that's where fantasai simply moved the cvs files to, the proper tests should be living somewhere else in the repository 19:37:09 hm, looks like I forgot to move them over into approved/ 19:37:29 that's where they /should/ be 19:38:13 Ok, I'm heading to the airport. Feel free to text me if you've got further questions, should be on the ground until 5:30pm EDT 20:07:08 Zakim has left #CSS 21:44:46 shepazu has joined #css 22:26:08 dbaron has joined #css