[CSSWG] Minutes and Resolutions 2010-05-19

Summary:

   - Reviewed status of CSS2.1 issues
   - Discussed CSS2.1 Issue 129 (Parsing of invalid url() tokens)
       http://wiki.csswg.org/spec/css2.1#issue-129
   - Discussed CSS2.1 Issue 137 (Anonymous boxes as containing blocks)
       http://wiki.csswg.org/spec/css2.1#issue-137

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

Present:
   Tab Atkins
   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Beth Dakin
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Peter Linss
   David Singer

<RRSAgent> logging to http://www.w3.org/2010/05/19-CSS-irc
Scribe: fantasai

CSS2.1 Issues
-------------

   http://wiki.csswg.org/spec/css2.1
   Peter: Lots of open issues on CSS2.1

   Peter: dbaron? ETA?
   dbaron: Hopefully next week, but not sure

   fantasai: I have not been working on issues, have been working on tests
   * glazou elika said on twitter she now lives in a closet to deal with tests :)
   * fantasai not exactly true, but I'm considering switching to nocturnal
       so I can get more work done
   * fantasai doesn't concentrate well during the day

   sylvain: Waiting for an answer

   Peter: Bert's issues mostly editorial...
   Bert: Don't know which issues are worth discussing.
   Arron: Been pulling together testcases. Should have no problem creating
          testcases by Fri.
   Arron: Started on image, but not done yet. Guessing next week.

   Tab: Just have one open, need to do some edits to satisfy Boris to complete
        proposal. Rest was handled by fantasai's rewrite
   Peter: 161?
   Tab: Already sent proposal to list
   fantasai: Link from issues list?
   <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2010Apr/0389.html
   RESOLVED: Accept Tab's proposal for issue 161

   <plinss> http://wiki.csswg.org/spec/css2.1#issue-129
   Tab: I wish I understood enough to comment on that.
   * fantasai has no comments either
   * bradk too
   ..
   Bert: Tried to implement change with flex
   Bert: I only noticed a difference in speed for several thousand bytes
   Bert: The claim was that it's inefficient, that inefficiency is at the
         level of microseconds
   Peter: The change is just clarification, or change in error recovery?
   fantasai: It's a change in error recovery, because you no longer match
             brackets.
   Bert: url( ( )
   * fantasai didnt' catch which behavior was which proposal
   dbaron: I don't remember implementations passing the test I wrote for
           the test suite
   http://test.csswg.org/source/contributors/mozilla/incoming/reftests/bugs/invalid-url-handling.xht
   Peter: The question is, should we be matching parentheses inside a URL token
   dbaron: If it is a url() token, then you don't match brackets
   dbaron: But if it's invalid, then it's not a url() token, and you have
           to match brackets
   dbaron: This change is about not matching brackets for invalid url() tokens
   dbaron: Look at test 9 for example
   dbaron: Actually, I think 9 is not testing what it's supposed to test.
   Peter: Brackets and braces are allowed in a URL. They should not match
   Peter: and it's perfectly valid
   <dbaron> I think test 9 would probably be more interesting if it had a (
   <fantasai> yes
   <fantasai> seems like several tests need revising, I think eight doesn't
              do much either
   Simon: Perhaps we should take this issue offline and have someone figure
          out what the behavior is
   Peter: What is the desired behavior of url(() ?
   Peter: Does that end the url, or is it consumed by the url?
   Peter: Once we figure that out, then we can figure it out
   fantasai: Question is whether we end the url token there or keep parsing
             until we close the url() token
   <dbaron> We should really test that url([()) leaves the parser searching
            for a ]
   Peter: Question is, do we keep parsing until we close the url( or do we
          also match against other things?
   <bradk> end the declaration as soon as that makes the url invalid?
   <dsinger> we hit a syntax error in the URL itself.  surely we should
             toss until we hit the end of the url() form, i.e. its closing )?
   Peter: My opinion is that we don't back up and reinterpret things that
          were part of a valid URL.
   <dsinger> my uninformed opinion is that David's "(" is starting a syntax
             error, and we close the url( on the next ), and then there is
             another error, the next )
   <Bert> url((abc)) is currently FUNCTION + ( + abc + ) + ). Question is
          to change it to INVALID_URI + ( + abc + ) + )
   Peter summarizes the issue.
-glazou
   <dbaron> I have three added tests to that test (I'll commit later) that
            will definitely test this issue...
   Peter: Within a URL, a [ is just a valid character. We wouldn't normally
          try to match it. url([) is complete and valid
   Peter: The question is, suppose you start parsing and you find url([
          and then you find something that's invalid inside a URL.
   Peter: Do you go back and reparse the url([ as if it was not a URL to
          begin with (i.e. now go back and match brackets)?
   <dsinger> I think I agree, the "[" is just a character that is valid.
   Peter: The issue is how far do we have to back up if something breaks?
   Peter: I would prefer that we don't back up at all.
   <dsinger> the next "(" is a character that is invalid in the URL
   <bradk> I think if you see a ( in a url where it doesn't belong, then
           it was probably supposed to be a )
   <dsinger> so then we go into "toss the junk until we close the url( form"
   fantasai: I'm in favor of not backing up, but no comment on what changes
             would be needed.
   <bradk> so don't keep looking for closing paren
   dbaron: Zack had a proposal
   Bert: I tested his grammar, and it works.
   Bert: The question is do we really need it. My preference is not to
         change anything.
   Peter: Do we have interop on this either way?
   arronei: Not really
   Peter: So something needs to change.
   * dbaron tries to remember the issue number for his commit message
   <sylvaing> ie9 currently matching Gecko except on #14
   <dbaron> Does anybody know what issue number this is?
   Peter: So how do we want this to behave? Does anyone have an opinion
          besides me?
   Bert: I want no change.
   <dbaron> I prefer not backtracking
   Peter: Do you want no change for the sake of no change, or ...?
   Bert: I want no change because this has not change in 15 years.
   Bert: And I don't know if we can afford to change it.
   Bert: I don't know who implements it, who would need to change.
   Peter: Sounds like no change for the sake of no change.
   Peter: We don't have interop
   Bert: That's normal.
   Peter: Would like to hear from Mozilla, MS, Apple
   <oyvind> dbaron, 129 (if I understand correctly)
   dbaron: I prefer not backtracking. I also just committed the additional
           3 tests that definitely test this
   Arron: I think we need to investigate this more, and I think there's a
          bug in the testcase.
   Arron: My initial impression is that I'd prefer not to backtrack.
   Arron: Would like to test some more first
   Simon: I'd have to talk to hyatt to see his opinion on this
   Peter: Sounds like we have action items to get more data, and we'll
          come back to this later
   ACTION: Arron figure out opinion on issue 129
   ACTION: Simon figure out opinion on issue 129
   <dbaron> OK, tests 15-17 in
     http://test.csswg.org/source/contributors/mozilla/incoming/reftests/bugs/invalid-url-handling.xht
            are specifically designed to test this issue.

   <plinss> http://wiki.csswg.org/spec/css2.1#issue-137
   dbaron: I think there's a whole bunch of things that absolutely depend
           on them being the containing blocks for floats.
   Peter: Reading the summary, seems like everybody but WebKit uses the
          block, not the anonymous block.
   * fantasai thinks that makes sense, it would be confusing if behavior
       changed suddenly when I insert a block further down.
   dbaron: I think there are a bunch of other things where browsers are
           consistent in treating the anon box as the containing block
   dbaron: So maybe we need to change the behavior of percentages, not
           containing block
   dbaron: I think the basic float positioning rules in 9.5.1 depend on
           the anon box being the containing block
   <dbaron> ... though that may depend on how you interpret rule 6
   <dbaron> but, basically, I think rule 4 depends on it.
   <dbaron> for the case of a float that's right below a block with a
            bottom margin
   <dbaron> and followed by text
   Bert: Trying to understand, is this about clarification or change?
   Bert: What's meant is the <div> is the containing block
   Bert: I think the text is clear enough, if bz thinks that's not the
         case we should work on that.
   Bert: Is that the question? Better text?
   dbaron: I remember discussions of float positioning rules in which we
           assumed the containing block was the anon box.
   dbaron: Don't remember what exactly was the issue.
   Bert: Maybe something with collapsing margins. Not about the height.
   <bradk> webkit looks like firefox when you remove the doctype
   fantasai: table captions have a similar issue in that they push
             through the anon box for certain calculations
   <fantasai> or maybe we changed that
   <dbaron> I think the simple testcase that depends on it is
            <div>
              <div style="Margin-bottom: 10px; height: 100px; background:yellow"></div>
              <div style="float:left;height:50px;width:50px;background:yellow">float</div>
            </div>
   <dbaron> in which I think browsers uniformly place the float below
            the margin
   <dbaron> but if the containing block weren't the anonymous block
   Arron: Behavior is fairly consistent. I think it's just a bug in webkit
   dbaron looks at wording for containing blocks and percentage heights
   dbaron: I think WebKit's rendering of bz's testcase is clearly correct
           per current spec
   dbaron: And we should fix the spec
   <bradk> without the doctype, that one is also the same in webkit
   Bert thinks the containing block is the <div> element.
   Tab and dbaron explain that there's an anonymous block in between.
   dbaron points to bullet point 2 in the containing box definition,
     where it says "box", not "element"
   dbaron: I posted a testcase to IRC showing that the anon box is the
           containing block for some other calculations.
   Peter: So the anonymous box should be the containing block of the
          float, but it should not be used to compute the percentage
          height of the float. That box should be the nearest
          block-level element box
   fantasai: That's consistent with tables. They have an anon box as
             their containing block, but percentages are calculated
             wrt that box's parent.
   Peter: Should we make this change generically, or specifically for
          this case?
   fantasai: I think generically. There are a lot of properties to cover,
             and I don't want to miss out on any.
   fantasai: Basically say that anon boxes are not used in percentage
             calculations
   Peter: Do we have enough tests for this, or do we need more?
   Arron: I don't think we have a lot of tests that cover this specific
          case.
   Arron: We have tests for percentages in general, but very few
          involving anonymous boxes.
   Arron: Would that change be for every single percentage property,
          or in 10.1, or somewhere else?
   Arron: Where are we going to take that?
   * fantasai wonders about percentages when table anon boxes are involved
   <fantasai> Another issue is tables.
   <fantasai> suppose I have <table height=200px> <div height=50%> </table>
   <fantasai> with border-spacing: 50px
   ACTION: fantasai write proposed text
   Peter: Can everyone look through unowned issues
   Peter: And please update wiki with any updates

Received on Thursday, 20 May 2010 00:20:36 UTC