- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 02 Jun 2010 19:27:31 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Reviewed status of CSS2.1 test suite
- RESOLVED: Publish new GCPM working draft.
- RESOLVED: Accept dbaron's proposal for CSS2.1 issue 26 with "(see above)"
and s/specified/computed/ changes from Peter Moulder; open a new
issue for the remaining points from Peter's email.
http://wiki.csswg.org/spec/css2.1#issue-126
- RESOLVED: For CSS2.1 Issue 129, change the grammar to avoid backup. Exact
changes TBD by Bert.
http://wiki.csswg.org/spec/css2.1#issue-129
- RESOLVED: Accept in principle to change the grammar for 2.1 Issue 140 and
note that we won't use the additional capabilities (exact
wording TBD by Bert).
http://wiki.csswg.org/spec/css2.1#issue-140
- RESOLVED: font-family names are ident+ or quoted strings (CSS2.1 Issue 114)
http://wiki.csswg.org/spec/css2.1#issue-114
====== Full minutes below ======
Present:
César Acebal
Tab Atkins
David Baron
Bert Bos
Arron Eicholz
Elika Etemad
Simon Fraser
Brad Kemper
Hĺkon Wium Lie
Chris Lilley
Peter Linss
STeve Zilles
<RRSAgent> logging to http://www.w3.org/2010/06/02-CSS-irc
Scribe: Tab Atkins
Administrative
--------------
plinss: Anything to add to the agenda?
plinss: Request from Hakon to publish GCPM.
<Zakim> -[IPcaller]
TabAtkins: I have no objection to publishing.
plinss: I think we all agreed to publish once he fixed one issue, which
I believe he did his best to address.
RESOLVED: Publish new GCPM working draft.
<howcome> Correct]
<ChrisL> howcome, thanks for clarifying that cmyk is device cmyk. I still
think its underspecified but at least it is a little clearer now
CSS2.1 Test Suite Status
------------------------
plinss: Css 2.1 issues. Anything interesting in the test suite?
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.
fantasai: I'm about halfway through converting Hixie's tests, but
it takes awhile since they often need manual tweaking
fantasai: Reftests are now buildable. I've added bzbarsky's, not yet Mozilla's
arronei: There'll be substantial updates from me from feedback on test cases.
arronei: No more issues from the repo.
CSS2.1 Issues
-------------
plinss: David, any updates?
dbaron: Wrote proposal for 66 last night, haven't yet resolved 101 -
it's somewhat more involved.
<dbaron> http://lists.w3.org/Archives/Public/www-style/2010Jun/0048.html
<dbaron> http://lists.w3.org/Archives/Public/www-style/2010Jun/0049.html
dbaron: There was one response on www-style about issue 26.
dbaron: I think Peter's first 2 proposed changes we should just take,
and the remaining ones should maybe be a separate issue.
<dbaron> the first 2 are the (see above) and the s/specified/computed/
plinss: Are we okay with accepting the proposal?
arronei: I agree with putting the later points into a separate issue.
<szilles> +1 for the proposal
RESOLVED: Accept dbaron's proposal for issue 26 with (see above) and
s/specified/computed/ changes from Peter Moulder, open a new
issue for the remaining points from Peter Moulder
Bert: For my issues, I'm working on 120. It's difficult. I'm checking
if it's possible to resolve.
Bert: I've put text for 117 on the list.
Bert: I think everything else is just editorial and I'll slowly work
through them.
plinss: arron?
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.
arronei: But I think 165 is actually a css3 issue.
arronei: Because it talks about "start" and "end" the entire email.
<dbaron> I think 165 is a CSS 2.1 issue.
<dbaron> It's the question of whether the way float placement rules
respond to 'direction' is correct.
<dbaron> But it might be pointing to the wrong emails.
plinss: Tab?
TabAtkins: Issue 161 is Bert's now to make the edit, the rest I've
worked on, but haven't brought anything to the list yet.
plinss: 129 is for all of us to discuss and bring to a close.
<plinss> http://lists.w3.org/Archives/Public/www-style/2009Jun/0164.html
plinss: What to do about brace matching inside an invalid url.
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.
Bert: Currently it's the latter.
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.
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-140
http://wiki.csswg.org/spec/css2.1#issue-129
* fantasai notes we have two issues that seem somewhat related here
* fantasai doesn't claim to know much about the grammar, though
plinss: fantasai, you're mentioning that issue 140 seems to be related.
plinss: It's similar, but it might even be putting us in an opposite
direction from the issue 129.
* TabAtkins got too lost to minute that last exchange. ;_;
plinss: We seem to be stalled on this. Does anyone have any ideas?
Bert: I think it's possible to expand the definition of any* like
dbaron says.
Bert: Nothing uses that, it's just making something more defined
where it is undefined.
Bert: I think it's ugly to define a grammar and then say we won't
use it, but oh well.
Bert: But are braces all that needs to be added, or other tokens
as well?
dbaron: Possible semicolons.
Bert: What about @?
dbaron: Isn't a lone @ DELIM?
Bert: yes, sorry, I meant @keyword.
dbaron: Putting braces in any* is a little problematic for the
selector rule, though?
Bert: Yes.
<dbaron> and ; is a little problematic for the at-rule part
Bert: But if it's only braces it only needs to be changed in 3 places.
<smfr> sorry, i have to drop off the call
<Zakim> -smfr
plinss: We seem to have consensus on issue 140 and nothing but silence
on issue 129.
plinss: Can we even get agreement on what we want the behavior to
*be* on 129?
Bert: I remain reluctant to change that.
Bert: I'm not planning to use parens in urls, but I don't know if
someone else does.
Bert: The issue with invalid comments is less serious. Afaik there
is no way to use the current definition for anything.
Bert: It doesn't make sense to only change comments, though, since
the goal is to remove all backup.
<Bert> url((http://foo/), (12))
TabAtkins: Do we actually think that anyone has invented a new url
syntax that uses parens.
fantasai: I'm pretty sure there's random urls with parens stuck in them.
Bert: As far as I know, though, current impls reject that as they should.
fantasai: If parens are mismatched, then how we resolve this issue will
change how the stylesheet is handled.
fantasai: Under the current urls you have to go back and match the parens.
ChrisL: There's no requirement in the uri spec to match the parens,
though, right?
ChrisL: It's a valid url to have mismatched parens.
plinss: Our definition of url token doesn't even allow parens in the url.
Bert: Right, that's what allows the extension I put into irc.
<fantasai> url([)
fantasai: Also brackets cause the issue.
plinss: brackets and braces are allowed in our definition of a url
token, parens are not.
<fantasai> background: url([) purple;
<fantasai> is it purple?
TabAtkins: yes.
plinss: that is a perfectly valid url.
plinss: Now what happens if you put something after that bracket and
it's no longer a valid url?
<fantasai> background: url([()) purple;
<dbaron> The current spec says that:
<dbaron> background: url([) purple;
<dbaron> is purple
<dbaron> but
<dbaron> background: url([() purple;
<dbaron> is not
<fantasai> what about url([()) purple?
<dbaron> fantasai, not purple
plinss: Correct. Now is that our desired behavior or not?
<fantasai> background: url([()); color: purple;
<dbaron> fantasai, still not purple
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.
fantasai: That's not the issue. The issue is that the parser has to
go back and reparse everything in the url token.
fantasai: Where it then treats things as CSS garbage, with matched
quotes and brackets and such.
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.
fantasai: So what we want is something that can read until we know it
fails, and then just get thrown out without reinterpreting.
<fantasai> backing up arbitrary amount is the problem, not what to
do with valid stuff that doesn't get thrown out
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?
fantasai: That's the proposal.
szilles: And this is an error recovery mechanism.
plinss: Bert is resistant to change the core grammar.
Bert: As far as I can see it's not an error recovery mechanism, it's
just one token or another?
plinss: But the issue is that you can't tell which token you have
until it's either done or you reparse.
Bert: You have the same problem with other tokens, such as numbers
and dimensions.
ChrisL: urls can be bigger, though.
Bert: I measured, and couldn't measure the difference until the url
hits megabyte lengths.
ChrisL: Bert, so you're suggesting close the issue with no change?
Bert: Yes.
Bert: It's a pity no one noticed this 10 years ago, but I don't
like changing things at this late stage.
plinss: There is the other proposal, to change the grammar.
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 fantasai put in IRC. I don't
think that our existing specified behavior really makes
sense, and is something we want.
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.
szilles: And then if it happens to be invalid for some other reasons,
that doesn't seem that it should affect the tokenizer.
Bert: That case that fantasai typed into IRC would change.
szilles: I don't see that in a sufficiently obscure case we can't
make a change
* fantasai likes szilles term "sufficiently obscure"
Bert: So it's clearly a change.
szilles: But it's also clearly a legal url.
plinss: but it's not legal CSS, becasue you have to escape the parens.
fantasai: I typed several things into IRC, and only some of them would
change.
fantasai: As long as it's a valid url token, there's no change in
behavior.
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.
plinss: That seems to already be in place. The only thing we're
changing is the error recovery behavior.
szilles: I say consume as much as fits the uri syntax and not go back.
TabAtkins: Which of the cases that fantasai posted would change under
the proposal? The url([(), or the url([())?
TabAtkins: Right now both kill the entire declaration. Would either
of those change?
fantasai: It would still kill the declaration, but it wouldn't eat
the rest of the style sheet trying to close the bracket.
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.
fantasai: In either case it's invalid, the question is just if we lose
the entire rest of the stylesheet or just the declaration.
szilles: I'd prefer just lose the declaration.
fantasai: Can we take a straw poll on this?
plinss: In favor of only losing declaration (change grammar).
TabAtkins: I prefer to change the grammar.
fantasai: Change the grammar.
Bert: Keep the grammar.
CesarAcebal: Keep the grammar.
arronei: Prefer to keep, but I think we have to change. So my vote
is to change.
bradk: Change, but I don't feel strongly.
dbaron: Change the grammar.
szilles: Change the grammar.
ChrisL: Change the grammar.
howcome: Keep the grammar, but I don't feel strongly.
8 for change (1 not strong), 3 to keep (1 not strong).
plinss: I wonder if we could get the same effect by changing the prose
rather than the grammar.
ChrisL: You could, but that would just mean you don't implement the
grammar anyway, you do something else.
fantasai: I think most of our error handling is in the prose anyway,
not the grammar.
plinss: We have a few existing INVALID tokens, so adding another one
or two would be good for clarity.
RESOLVED: Change the grammar to avoid backup.
<ChrisL> I offer to take Issue 145 which has no owner. I think the
commentor is correct, will discuss with I18n folks
<fantasai> 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
ChrisL: On issue 114, SVG liked option 1, which is that font names
are idents or quoted strings.
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.
ChrisL: We understood that it did, and because of your reluctance
to change the grammar we didn't think it would fly.
ChrisL: We thought it was slightly irritating to have to quote fonts
starting with a number, but it was ok.
ChrisL: What was the accepted proposal for csswg?
fantasai: IDENT+.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2010Apr/0275.html
look for CSS2.1 Issues
Bert: I have a different memory of the straw poll.
<fantasai> glazou: 7 for 1, 4 for 2, 3 for 3, and almost everyone
<fantasai> can live with everything
ChrisL: Since 1 was most popular for CSS and SVG, we can just pick
that, close it, and move on?
fantasai: Yup.
arronei: I'll have to change the test cases, right?
fantasai: I think we assumed ident+.
plinss: I think you may have gotten 1 and 2 mixed up.
[discussion]
plinss: Okay, so we're going with 1.
Bert: A pity.
fantasai: I would prefer nmchars+ as well, but at this point this is
probably better for authors anyway, since current impls
are mostly ident+.
szilles: I believe the goal was to give authors something easy to
understand, rather than to omit quotes.
RESOLVED: font-family names are ident+ or quoted strings
plinss: Did we come to a resolution for issue 129 or 140?
<dbaron> I think plinss just asked about 140.
<dbaron> We did resolve 129.
fantasai: Seems that bert and dbaron agreed to change the grammar to
handle 140 per dbaron's proposal.
plinss: I suggest whoever writes the proposal for one does both
RESOLVED: Accept in principle to change the grammar for 140 and note
that we won't use the additional capabilities (exact
wording TBD).
fantasai: I suggest either dbaron or Bert, since they seem to
understand this part of the spec
* dbaron thinks Bert would be better :-)
Bert: I'm going on a holiday soon, so if I work on it'll be in july.
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.
Bert: That'd work.
Received on Thursday, 3 June 2010 14:49:32 UTC