[CSSWG] Minutes and Resolutions 2010-06-02


   - 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.

   - RESOLVED: For CSS2.1 Issue 129, change the grammar to avoid backup. Exact
               changes TBD by Bert.

   - 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).

   - RESOLVED: font-family names are ident+ or quoted strings (CSS2.1 Issue 114)

====== Full minutes below ======

   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


   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
   * 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
   fantasai: As long as it's a valid url token, there's no change in
   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.
   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