- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 19 May 2010 17:20:00 -0700
- To: "www-style@w3.org" <www-style@w3.org>
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