15:56:06 <RRSAgent> RRSAgent has joined #CSS
15:56:07 <RRSAgent> logging to http://www.w3.org/2010/05/19-CSS-irc
15:56:10 <glazou> Zakim, this will be Style
15:56:10 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 4 minutes
15:56:15 <glazou> RRSAgent, make logs public
15:56:39 <glazou> Pfioooou, telephone and internet were borked 15 seconds ago...
15:57:36 <Zakim> Style_CSS FP()12:00PM has now started
15:57:43 <Zakim> +plinss
15:58:07 <Zakim> + +1.650.253.aaaa
15:58:14 <TabAtkins> zakim, aaaa is me
15:58:14 <Zakim> +TabAtkins; got it
16:00:12 <glazou> bridge refusing me
16:00:30 <Zakim> +Bert
16:00:37 <glazou> can"t dial in
16:00:48 <Zakim> +glazou
16:00:50 <glazou> ah 5th attempt
16:00:54 <Zakim> +dsinger
16:01:11 <glazou> Zakim, your friend bridge is lazy
16:01:11 <Zakim> I don't understand 'your friend bridge is lazy', glazou
16:01:49 <dbaron> dbaron has joined #css
16:01:54 <dethbakin> dethbakin has joined #css
16:01:54 <smfr> smfr has joined #css
16:01:57 <dbaron> dbaron has joined #css
16:02:04 <Zakim> +smfr
16:02:08 <Zakim> +[Apple]
16:02:09 <dsinger_> dsinger_ has joined #css
16:02:20 <Zakim> +[Microsoft]
16:02:22 <dsinger_> zakim, mute dsinger
16:02:22 <Zakim> dsinger should now be muted
16:02:24 <dethbakin> Zakim, Apple has dethbakin 
16:02:24 <Zakim> +dethbakin; got it
16:02:31 <Zakim> +sylvaing
16:02:39 <dsinger_> zakim, who is on the phone?
16:02:39 <Zakim> On the phone I see plinss, TabAtkins, Bert, glazou, dsinger (muted), smfr, [Apple], [Microsoft], sylvaing
16:02:41 <Zakim> [Apple] has dethbakin
16:02:41 <Zakim> +[Mozilla]
16:02:45 <TabAtkins> Zakim, microsoft has arronei
16:02:45 <Zakim> +arronei; got it
16:02:45 <sylvaing> sylvaing has joined #css
16:02:46 <dbaron> Zakim, [Mozilla] is David_Baron
16:02:47 <Zakim> +David_Baron; got it
16:02:50 <arronei> zakim, microsoft is me
16:02:50 <Zakim> +arronei; got it
16:03:41 <Zakim> +??P8
16:04:08 <glazou> good evening :)
16:04:57 <fantasai> probably me
16:05:10 <fantasai> zakim, ??p8 is me
16:05:10 <Zakim> +fantasai; got it
16:05:14 <smfr> heh
16:05:39 <fantasai> ScribeNick: fantasai
16:06:01 <fantasai> Peter: Lots of open issues on CSS2.1
16:06:22 <fantasai> Peter: dbaron? ETA?
16:06:28 <fantasai> dbaron: Hopefully next week, but not sure
16:06:52 <fantasai> fantasai: I have not been working on issues, have been working on tests
16:07:39 <fantasai> sylvain: Waiting for an answer
16:07:52 <fantasai> Peter: Bert's issues mostly editorial...
16:08:10 <fantasai> Bert: Don't know which issues are worth discussing.
16:08:35 <fantasai> Arron: Been pulling together testcases. Should have no problem creating testcases.
16:08:43 <fantasai> Arron: Started on image, but not done yet. Guessing next week.
16:08:53 <bradk> bradk has joined #css
16:09:25 <fantasai> Tab: Just have one open, need to do some edits to satisfy Boris to complete proposal. Rest was handled by fantasai's rewrite
16:09:33 <fantasai> Peter: 151?
16:09:47 <plinss> s/151/161/
16:09:57 <fantasai> http://wiki.csswg.org/spec/css2.1
16:10:18 <fantasai> Tab: Already sent proposal to list
16:10:26 <fantasai> fantasai: Link from issues list?
16:11:04 <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2010Apr/0389.html
16:11:49 <Zakim> +bradk
16:12:41 <fantasai> RESOLVED: Accept Tab's proposal for issue 161
16:13:09 <plinss> http://wiki.csswg.org/spec/css2.1#issue-129
16:13:39 <fantasai> Tab: I wish I understood enough to comment on that.
16:13:59 <bradk> \me too
16:14:41 <fantasai> ..
16:14:47 <fantasai> Bert: Tried to implement change with flex
16:14:58 <fantasai> Bert: I only noticed a difference in speed for several thousand bytes
16:15:46 <fantasai> Bert: The claim was that it's inefficient, that inefficiency is at the level of microseconds
16:16:44 <fantasai> Peter: The change is just clarification, or change in error recovery?
16:16:55 <fantasai> fantasai: It's a change in error recovery, because you no longer match brackets.
16:17:54 <fantasai> Bert: url( ( )
16:18:25 <fantasai> dbaron: I don't remember implementations passing the test I wrote for the test suite
16:19:25 <Zakim> +[Apple.a]
16:19:34 <dsinger> zakim, [apple] has dsinger
16:19:34 <Zakim> +dsinger; got it
16:19:48 <Zakim> -dsinger
16:19:58 <fantasai> http://test.csswg.org/source/contributors/mozilla/incoming/reftests/bugs/invalid-url-handling.xht
16:20:25 <smfr> Zakim, who's noisy?
16:20:35 <Zakim> smfr, listening for 10 seconds I heard sound from the following: [Apple] (0%)
16:20:46 <glazou> :)
16:21:40 <oyvind> opera 10.53 passes that one
16:21:44 <fantasai> Peter: The question is, should we be matching parentheses inside a URL token
16:22:05 <fantasai> dbaron: If it is a url() token, then you don't match brackets
16:22:15 <fantasai> dbaron: But if it's invalid, then it's not a url() token, and you have to match brackets
16:22:26 <fantasai> dbaron: This change is about not matching brackets for invalid url() tokens
16:23:11 <fantasai> dbaron: Look at test 9 for example
16:23:38 <fantasai> dbaron: Actually, I think 9 is not testing what it's supposed to test.
16:23:55 <fantasai> Peter: Brackets and braces are allowed in a URL. They should not match
16:24:04 <fantasai> Peter: and it's perfectly valid
16:24:27 <dbaron> I think test 9 would probably be more interesting if it had a (
16:24:35 <fantasai> yes
16:24:52 <fantasai> seems like several tests need revising, I think eight doesn't do much either
16:25:23 <fantasai> Simon: Perhaps we should take this issue offline and have someone figure out what the behavior is
16:25:52 <fantasai> Peter: What is the desired behavior of url(() ?
16:26:02 <fantasai> Peter: Does that end the url, or is it consumed by the url?
16:26:28 <fantasai> Peter: Once we figure that out, then we can figure it out
16:27:06 <dbaron> We should really test that url([()) leaves the parser searching for a ]
16:27:12 <fantasai> fantasai: Question is whether we end the url token there or keep parsing until we close the url() token
16:28:10 <fantasai> Peter: Question is, do we keep parsing until we close the url( or do we also match against other things?
16:28:44 <bradk> end the declaration as soon as that makes the url invalid?
16:29:21 <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 )?
16:30:22 <fantasai> Peter: My opinion is that we don't back up and reinterpret things that were part of a valid URL.
16:30:32 <Bert> url((abc)) is currently FUNCTION + ( + abc + ) + ). Question is to change it to INVALID_URI + ( + abc + ) + )
16:30:52 <Zakim> -bradk
16:30:54 <fantasai> Peter summarizes the issue.
16:31:28 <Zakim> -glazou
16:31:35 <fantasai> Peter: Within a URL, a [ is just a valid character. We wouldn't normally try to match it. url([) is complete and valid
16:31:55 <fantasai> Peter: The question is, suppose you start parsing and you find url([ and then you find something that's invalid inside a URL.
16:32:05 <Zakim> +bradk
16:32:13 <dbaron> I have three added tests to that test (I'll commit later) that will definitely test this issue...
16:32:14 <fantasai> 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)?
16:32:34 <dsinger> I think I agree, the "[" is just a character that is valid.
16:32:34 <fantasai> Peter: The issue is how far do we have to back up if something breaks?
16:32:45 <fantasai> Peter: I would prefer that we don't back up at all.
16:32:45 <dsinger> the next "(" is a character that is invalid in the URL
16:32:59 <bradk> I think if you see a ( in a url where it doesn't belong, then it was probably supposed to be a )
16:33:01 <dsinger> so then we go into "toss the junk until we close the url( form"
16:33:11 <fantasai> fantasai: I'm in favor of not backing up, but no comment on what changes would be needed.
16:33:14 <bradk> so don't keep looking for closing paren
16:33:32 <fantasai> dbaron: Zack had a proposal
16:33:38 <fantasai> Bert: I tested his grammar, and it works.
16:33:48 <fantasai> Bert: The question is do we really need it. My preference is not to change anything.
16:33:57 <fantasai> Peter: Do we have interop on this either way?
16:34:02 <fantasai> arronei: Not really
16:34:11 <fantasai> Peter: So something needs to change.
16:35:36 <sylvaing> ie9 currently matching Gecko except on #14
16:35:56 <dbaron> Does anybody know what issue number this is?
16:36:05 <fantasai> Peter: So how do we want this to behave? Does anyone have an opinion besides me?
16:36:12 <fantasai> Bert: I want no change.
16:36:19 <dbaron> I prefer not backtracking
16:36:24 <fantasai> Peter: Do you want no change for the sake of no change, or ...?
16:36:25 <Zakim> -bradk
16:36:31 <bradk> \brad got dropped again. sigh.
16:36:36 <fantasai> Bert: I want no change because this has not change in 15 years.
16:36:46 <fantasai> Bert: And I don't know if we can afford to change it.
16:37:00 <fantasai> Bert: I don't know who implements it, who would need to change.
16:37:10 <fantasai> Peter: Sounds like no change for the sake of no change.
16:37:12 <fantasai> Peter: We don't have interop
16:37:16 <fantasai> Bert: That's normal.
16:37:32 <Zakim> +bradk
16:37:51 <Zakim> -bradk
16:37:53 <fantasai> Peter: Would like to hear from Mozilla, MS, Apple
16:38:17 <oyvind> dbaron, 129 (if I understand correctly)
16:38:17 <fantasai> dbaron: I prefer not backtracking. I also just committed the additional 3 tests that definitely test this
16:38:48 <fantasai> Arron: I think we need to investigate this more, and I think there's a bug in the testcase.
16:38:56 <fantasai> Arron: My initial impression is that I'd prefer not to backtrack.
16:38:58 <Zakim> +bradk
16:39:03 <fantasai> Arron: Would like to test some more first
16:39:17 <Zakim> -bradk
16:39:17 <fantasai> Simon: I'd have to talk to hyatt to see his opinion on this
16:39:27 <fantasai> Peter: Sounds like we have action items to get more data, and we'll come back to this later
16:39:42 <fantasai> ACTION: Arron figure out opinion on issue 129
16:39:42 <trackbot> Created ACTION-229 - Figure out opinion on issue 129 [on Arron Eicholz - due 2010-05-26].
16:39:48 <fantasai> ACTION: Simon figure out opinion on issue 129
16:39:48 <trackbot> Created ACTION-230 - Figure out opinion on issue 129 [on Simon Fraser - due 2010-05-26].
16:40:07 <Zakim> +bradk
16:40:13 <plinss> http://wiki.csswg.org/spec/css2.1#issue-137
16:40:48 <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.
16:40:53 <dbaron> (129, that is)
16:41:30 <fantasai> dbaron: I think there's a whole bunch of things that absolutely depend on them being the containing blocks for floats.
16:42:14 <fantasai> Peter: Reading the summary, seems like everybody but WebKit uses the block, not the anonymous block.
16:43:33 <fantasai> dbaron: I think there are a bunch of other things where browsers are consistent in treating the anon box as the containing block
16:43:52 <fantasai> dbaron: So maybe we need to change the behavior of percentages, not containing block
16:44:25 <fantasai> dbaron: I think the basic float positioning rules in 9.5.1 depend on the anon box being the containing block
16:45:37 <dbaron> ... though that may depend on how you interpret rule 6
16:45:46 <dbaron> but, basically, I think rule 4 depends on it.
16:46:03 <dbaron> for the case of a float that's right below a block with a bottom margin
16:46:09 <dbaron> and followed by text
16:46:09 <fantasai> Bert: Trying to understand, is this about clarification or change?
16:46:20 <fantasai> Bert: What's meant is the <div> is the containing block
16:46:33 <fantasai> Bert: I think the text is clear enough, if bz thinks that's not the case we should work on that.
16:46:39 <fantasai> Bert: Is that the question? Better text?
16:47:07 <fantasai> dbaron: I remember discussions of float positioning rules in which we assumed the containing block was the anon box.
16:47:18 <fantasai> dbaron: Don't remember what exactly was the issue.
16:47:37 <fantasai> Bert: Maybe something with collapsing margins. Not about the height.
16:47:58 <bradk> webkit looks like firefox when you remove the doctype
16:48:27 <fantasai> fantasai: table captions have a similar issue in that they push through the anon box for certain calculations
16:48:34 <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>
16:48:54 <fantasai> or maybe we changed that
16:48:59 <dbaron> in which I think browsers uniformly place the float below the margin
16:49:07 <dbaron> but if the containing block weren't the anonymous block
16:49:37 <fantasai> Arron: Behavior is fairly consistent. I think it's just a bug in webkit
16:50:06 <fantasai> dbaron looks at wording for containing blocks and percentage heights
16:50:15 <fantasai> dbaron: I think WebKit is currently correct per the spec
16:50:17 <dbaron> I think WebKit's rendering of bz's testcase is clearly correct per current spec
16:50:18 <fantasai> dbaron: And we should fix the spec
16:50:21 <bradk> without the doctype, that one is also the same in webkit
16:50:53 <fantasai> Bert thinks the containing block is the <div> element.
16:51:04 <fantasai> Tab and dbaron explain that there's an anonymous block in between.
16:51:30 <fantasai> dbaron points to bullet point 2 in the containing box definition, where it says "box", not "element"
16:52:35 <fantasai> dbaron: I posted a testcase to IRC showing that the anon box is the containing block for some other calculations.
16:53:24 <fantasai> 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
16:54:21 <fantasai> fantasai: That's consistent with tables. They have an anon box as their containing block, but percentages are calculated wrt that box's parent.
16:54:54 <Zakim> -bradk
16:55:11 <fantasai> Peter: Should we make this change generically, or specifically for this case?
16:55:26 <fantasai> fantasai: I think generically. There are a lot of properties to cover, and I don't want to miss out on any.
16:55:40 <fantasai> fantasai: Basically say that anon boxes are not used in percentage calculations
16:55:45 <Zakim> +bradk
16:55:58 <fantasai> Peter: Do we have enough tests for this, or do we need more?
16:56:11 <fantasai> Arron: I don't think we have a lot of tests that cover this specific case.
16:56:25 <fantasai> Arron: We have tests for percentages in general, but very few involving anonymous boxes.
16:57:54 <fantasai> Arron: Would that change be for every single percentage property, or in 10.1, or somewhere else?
16:58:06 <fantasai> Arron: Where are we going to take that?
16:59:23 <fantasai> Another issue is tables.
17:00:02 <fantasai> suppose I have <table height=200px> <div height=50px> </table>
17:00:05 <fantasai> with border-spacing: 50px
17:00:14 <fantasai> er, make the div 50%
17:00:28 <fantasai> ACTION: fantasai write proposed text
17:00:28 <trackbot> Created ACTION-231 - Write proposed text [on Elika Etemad - due 2010-05-26].
17:00:45 <fantasai> Peter: Can everyone look through unowned issues 
17:00:50 <Zakim> -smfr
17:00:52 <Zakim> -[Apple]
17:00:53 <Zakim> -David_Baron
17:00:53 <Zakim> -arronei
17:00:53 <fantasai> Peter: And please update wiki with any updates
17:00:54 <Zakim> -sylvaing
17:00:56 <Zakim> -[Apple.a]
17:00:58 <Zakim> -TabAtkins
17:00:58 <Zakim> -Bert
17:00:59 <Zakim> -fantasai
17:01:02 <Zakim> -plinss
17:01:03 <Zakim> -bradk
17:01:05 <Zakim> Style_CSS FP()12:00PM has ended
17:01:06 <Zakim> Attendees were plinss, +1.650.253.aaaa, TabAtkins, Bert, glazou, dsinger, smfr, dethbakin, sylvaing, arronei, David_Baron, fantasai, bradk, [Apple]
17:11:09 <smfr> smfr has left #css
17:40:40 <shepazu> shepazu has joined #css
18:34:32 <DanC> DanC has joined #CSS
20:15:15 <Zakim> Zakim has left #CSS
20:54:52 <Lachy> Lachy has joined #css
21:01:20 <jdaggett> jdaggett has joined #css
21:02:26 <jdaggett_> jdaggett_ has joined #css
21:19:39 <Lachy> Lachy has joined #css
21:23:54 <dbaron> dbaron has joined #css
21:26:30 <Lachy> Lachy has joined #css
21:32:56 <shepazu> shepazu has joined #css
22:09:45 <shepazu> shepazu has joined #css
22:41:34 <anne> anne has joined #CSS
23:25:41 <shepazu> shepazu has joined #css
23:26:28 <Lachy> Lachy has joined #css