/irc-logs / w3c / #css / 2010-05-19 / end

Options:

# Session Start: Wed May 19 00:00:00 2010
# Session Ident: #css
# [00:37] * Quits: Curt` (DorkeyDear@76.243.205.185) (Quit: Leaving)
# [00:49] * Quits: miketaylr (miketaylr@38.117.156.163) (Client exited)
# [01:03] <anne> maybe the idea was to use that inside style="" but that's
# [01:03] <anne> still wrong
# [02:14] * Joins: dsinger (dsinger@17.197.20.4)
# [02:36] * Joins: jdaggett (jdaggett@118.243.224.63)
# [02:57] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [03:50] * Quits: jdaggett (jdaggett@118.243.224.63) (Quit: jdaggett)
# [04:06] * Joins: oli (oli@124.87.135.239)
# [04:34] * Joins: miketaylr (miketaylr@24.42.95.234)
# [04:53] * Joins: Curt` (DorkeyDear@76.243.205.185)
# [05:40] * Quits: DanC (connolly@128.30.52.169) (Ping timeout)
# [05:49] * Joins: dbaron (dbaron@98.234.51.190)
# [05:50] * Joins: DanC (connolly@128.30.52.169)
# [06:00] <dbaron> http://www.smashingmagazine.com/2010/05/18/the-beauty-of-typography-writing-systems-and-calligraphy-of-the-world/ is a pretty impressive article
# [06:01] <DanC> this whitespace-in-the-grammar stuff is driving me bananas. I think the full grammar in the appendix doesn't generate this trivial stylesheet: e { ]
# [06:01] <DanC> er... rather: e { }
# [06:02] <DanC> there's no S between selector and { in ruleset, and no S at the end of selector
# [06:02] <dbaron> I think the grammar generally works so that most productions have trailing whitespace, so that you don't need additional whitespace after a production
# [06:02] <dbaron> but there have certainly been errors
# [06:03] <dbaron> which grammar are you looking at, anyway?
# [06:03] <dbaron> There are too many.
# [06:03] <DanC> http://www.w3.org/TR/CSS2/grammar.html
# [06:03] <dbaron> ugh
# [06:03] <dbaron> probably the least accurate one :-P
# [06:04] <DanC> has the WG published anything newer/better?
# [06:04] <dbaron> no
# [06:04] <dbaron> it's just that the interaction of the chapter 4 grammar and the appendix G grammar isn't particularly defined
# [06:04] <dbaron> and my opinion is that the appendix G grammar doesn't really have a normative role
# [06:04] <DanC> the chapter 4 grammar is almost entirely worthless
# [06:04] <dbaron> except in so far as other features in the spec neglect to mention anything about parsing
# [06:05] <DanC> except... exactly
# [06:05] <dbaron> and the normative parts are mainly the chapter 4 grammar and the prose
# [06:05] <dbaron> It looks to me like the selector production has builtin trailing whitespace
# [06:05] <dbaron> so I think you're ok there
# [06:05] <DanC> I've been known to be blind before... help?
# [06:06] <dbaron> : simple_selector [ combinator selector | S+ [ combinator? selector ]? ]?
# [06:06] <dbaron> so it's a recursive production
# [06:06] <dbaron> and if you take the | option on the right
# [06:06] <dbaron> and then don't take the ?
# [06:06] <dbaron> you get S+ at the end
# [06:06] <dbaron> (take the outer ? but not the inner ?, that is)
# [06:07] <DanC> ah. ok. I was cheating and only coding simple_selector to start with; I didn't think I was missing any trailing whitespace
# [06:07] <dbaron> yeah, the whitespace is in selector and not simple_selector
# [06:07] <dbaron> since simple_selector doesn't have any whitespace in the production since a space is a combinator
# [06:09] <DanC> I hope zillions of web designers bask in the glory of having space as a combinator. cuz it massively complicates the grammar.
# [06:09] * DanC wonders about tokenizer modes for "keep spaces" and "throw away spaces"
# [06:09] <dbaron> In CSS1 it was the only combinator
# [06:10] <dbaron> Mozilla uses GetToken(bool skip_whitespace), basically
# [06:11] <DanC> er... for stuff like: div p { color: blue } the grammar could just use two ident tokens, with no S token in between
# [06:11] <dbaron> we used to have that
# [06:11] <dbaron> sort of
# [06:11] <dbaron> but it implied that div*p was a valid selector
# [06:11] <dbaron> for a p that is a descendant of a div but not its child
# [06:11] <dbaron> whereas we actually want to require the space
# [06:12] <dbaron> (though some browsers accepted it for a while after I wrote a testcase claiming it should be accepted)
# [06:12] <DanC> why wouldn't div*p match child p's?
# [06:13] * DanC looks up the * deely, which he's never seen in CSS before
# [06:15] <DanC> I don't see div * p in the selector syntax summary table. :-/
# [06:15] <DanC> there's an example in 5.5 Descendant selectors, but I don't see anything normative
# [06:16] <dbaron> * is a universal selector
# [06:16] <dbaron> it's not a combinator
# [06:16] <dbaron> div>p is valid
# [06:16] <dbaron> as is *>p
# [06:16] <DanC> oh... I see... div * p is like div blort p but with * as a wildcard
# [06:17] <DanC> so... why require spaces?
# [06:18] <dbaron> because the combinator is a space
# [06:18] <dbaron> otherwise div* vs div:hover is quite confusing
# [06:18] <DanC> see point earlier; why not just sequence as combinator? hm.
# [06:20] <DanC> "There's a semantic difference between "a:hover" and "a :hover"... " -- Zack W http://lists.w3.org/Archives/Public/www-style/2009Oct/0258.html
# [06:21] * DanC is starting to think writing a perl parser would be easier ;-)
# [06:21] <DanC> anyhoo... thanks for reading the selector production for me...
# [06:31] * Quits: miketaylr (miketaylr@24.42.95.234) (Client exited)
# [07:21] * Quits: Curt` (DorkeyDear@76.243.205.185) (Quit: Leaving)
# [08:44] * Quits: oli (oli@124.87.135.239) (Ping timeout)
# [08:58] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
# [09:08] * Quits: dbaron (dbaron@98.234.51.190) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [10:31] * Joins: Lachy (Lachlan@213.236.208.22)
# [10:38] * Quits: karl (karlcow@128.30.54.58) (Ping timeout)
# [11:14] * Joins: Bert_ (bbos@mcclure.w3.org)
# [11:18] * Quits: Bert_ (bbos@mcclure.w3.org) (Quit: leaving)
# [12:03] * Joins: karl (karlcow@128.30.54.58)
# [14:12] * Joins: myakura (myakura@220.104.128.62)
# [15:18] * Joins: miketaylr (miketaylr@38.117.156.163)
# [15:33] * Joins: jdaggett (jdaggett@118.243.224.63)
# [16:06] * Parts: anne (annevk@83.85.115.123)
# [16:39] * Quits: myakura (myakura@220.104.128.62) (Quit: Leaving...)
# [17:00] * Joins: Curt` (DorkeyDear@76.243.205.185)
# [17:17] * Quits: jdaggett (jdaggett@118.243.224.63) (Quit: jdaggett)
# [17:29] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
# [17:35] * Quits: arronei (arronei@131.107.0.71) (Ping timeout)
# [17:39] * Joins: Lachy (Lachlan@85.196.122.246)
# [17:40] * Joins: arronei (arronei@131.107.0.84)
# [17:57] * Joins: oyvind (oyvinds@213.236.208.22)
# [17:57] * Joins: glazou (glazou@82.247.96.19)
# [17:58] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [17:58] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
# [17:58] <RRSAgent> logging to http://www.w3.org/2010/05/19-CSS-irc
# [17:58] <glazou> Zakim, this will be Style
# [17:58] <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 4 minutes
# [17:58] <glazou> RRSAgent, make logs public
# [17:58] <RRSAgent> I have made the request, glazou
# [17:58] <glazou> Pfioooou, telephone and internet were borked 15 seconds ago...
# [17:59] <Zakim> Style_CSS FP()12:00PM has now started
# [17:59] <Zakim> +plinss
# [18:00] <Zakim> + +1.650.253.aaaa
# [18:00] <TabAtkins> zakim, aaaa is me
# [18:00] <Zakim> +TabAtkins; got it
# [18:02] <glazou> bridge refusing me
# [18:02] <Zakim> +Bert
# [18:02] <glazou> can"t dial in
# [18:02] <Zakim> +glazou
# [18:02] <glazou> ah 5th attempt
# [18:02] <Zakim> +dsinger
# [18:03] <glazou> Zakim, your friend bridge is lazy
# [18:03] <Zakim> I don't understand 'your friend bridge is lazy', glazou
# [18:03] * Joins: dbaron (dbaron@63.245.220.240)
# [18:03] * Joins: dethbakin (dethbakin@17.246.19.169)
# [18:03] * Joins: smfr (smfr@68.183.233.103)
# [18:03] * Quits: dbaron (dbaron@63.245.220.240) (Connection reset by peer)
# [18:03] * Joins: dbaron (dbaron@63.245.220.240)
# [18:04] <Zakim> +smfr
# [18:04] <Zakim> +[Apple]
# [18:04] * Joins: dsinger_ (mobile@67.218.102.152)
# [18:04] <Zakim> +[Microsoft]
# [18:04] <dsinger_> zakim, mute dsinger
# [18:04] <Zakim> dsinger should now be muted
# [18:04] <dethbakin> Zakim, Apple has dethbakin
# [18:04] <Zakim> +dethbakin; got it
# [18:04] <Zakim> +sylvaing
# [18:04] <dsinger_> zakim, who is on the phone?
# [18:04] <Zakim> On the phone I see plinss, TabAtkins, Bert, glazou, dsinger (muted), smfr, [Apple], [Microsoft], sylvaing
# [18:04] <Zakim> [Apple] has dethbakin
# [18:04] <Zakim> +[Mozilla]
# [18:04] <TabAtkins> Zakim, microsoft has arronei
# [18:04] <Zakim> +arronei; got it
# [18:04] * Joins: sylvaing (sylvaing@76.104.131.10)
# [18:04] <dbaron> Zakim, [Mozilla] is David_Baron
# [18:04] <Zakim> +David_Baron; got it
# [18:04] <arronei> zakim, microsoft is me
# [18:04] <Zakim> +arronei; got it
# [18:05] * dsinger_ mornin' all!
# [18:05] <Zakim> +??P8
# [18:06] <glazou> good evening :)
# [18:06] * sylvaing should really have joined as ::-ms-sylvaing
# [18:06] * dsinger_ who is ??p8?
# [18:06] <fantasai> probably me
# [18:07] * TabAtkins Sylvain, just put yourself in a draft and get it to CR. Then you can drop your prefix.
# [18:07] <fantasai> zakim, ??p8 is me
# [18:07] <Zakim> +fantasai; got it
# [18:07] * dsinger_ hi me!
# [18:07] <smfr> heh
# [18:07] <fantasai> ScribeNick: fantasai
# [18:07] * glazou lol sylvaing
# [18:08] <fantasai> Peter: Lots of open issues on CSS2.1
# [18:08] <fantasai> Peter: dbaron? ETA?
# [18:08] <fantasai> dbaron: Hopefully next week, but not sure
# [18:08] * glazou elika said on twitter she now lives in a closet to deal with tests :)
# [18:08] <fantasai> fantasai: I have not been working on issues, have been working on tests
# [18:09] * fantasai not exactly true, but I'm considering switching to nocturnal so I can get more work done
# [18:09] * fantasai doesn't concentrate well during hte day
# [18:09] <fantasai> sylvain: Waiting for an answer
# [18:09] <fantasai> Peter: Bert's issues mostly editorial...
# [18:09] * glazou FYI, http://yro.slashdot.org/story/10/05/19/1425240/76-Web-Users-Affected-By-Browser-History-Stealing
# [18:10] <fantasai> Bert: Don't know which issues are worth discussing.
# [18:10] <fantasai> Arron: Been pulling together testcases. Should have no problem creating testcases.
# [18:10] <fantasai> Arron: Started on image, but not done yet. Guessing next week.
# [18:10] * Joins: bradk (bradk@67.188.133.45)
# [18:11] <fantasai> Tab: Just have one open, need to do some edits to satisfy Boris to complete proposal. Rest was handled by fantasai's rewrite
# [18:11] <fantasai> Peter: 151?
# [18:11] <plinss> s/151/161/
# [18:11] <fantasai> http://wiki.csswg.org/spec/css2.1
# [18:12] <fantasai> Tab: Already sent proposal to list
# [18:12] <fantasai> fantasai: Link from issues list?
# [18:12] * bradk is having slow computer problems... trying to call in
# [18:13] <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2010Apr/0389.html
# [18:13] <Zakim> +bradk
# [18:14] <fantasai> RESOLVED: Accept Tab's proposal for issue 161
# [18:15] <plinss> http://wiki.csswg.org/spec/css2.1#issue-129
# [18:15] * Quits: dsinger_ (mobile@67.218.102.152) (Quit: Rooms • iPhone IRC Client • http://www.roomsapp.mobi)
# [18:15] <fantasai> Tab: I wish I understood enough to comment on that.
# [18:15] * fantasai has no comments either
# [18:15] <bradk> \me too
# [18:16] * bradk too
# [18:16] <fantasai> ..
# [18:16] <fantasai> Bert: Tried to implement change with flex
# [18:16] <fantasai> Bert: I only noticed a difference in speed for several thousand bytes
# [18:17] <fantasai> Bert: The claim was that it's inefficient, that inefficiency is at the level of microseconds
# [18:18] <fantasai> Peter: The change is just clarification, or change in error recovery?
# [18:18] <fantasai> fantasai: It's a change in error recovery, because you no longer match brackets.
# [18:19] <fantasai> Bert: url( ( )
# [18:20] * fantasai didnt' catch which behavior was which proposal
# [18:20] <fantasai> dbaron: I don't remember implementations passing the test I wrote for the test suite
# [18:21] <Zakim> +[Apple.a]
# [18:21] <dsinger> zakim, [apple] has dsinger
# [18:21] <Zakim> +dsinger; got it
# [18:21] <Zakim> -dsinger
# [18:21] <fantasai> http://test.csswg.org/source/contributors/mozilla/incoming/reftests/bugs/invalid-url-handling.xht
# [18:22] <smfr> Zakim, who's noisy?
# [18:22] <Zakim> smfr, listening for 10 seconds I heard sound from the following: [Apple] (0%)
# [18:22] <glazou> :)
# [18:23] * dsinger shucks, that was my excessive silence, I am sorry. I will get a super-mute on my phone
# [18:23] <oyvind> opera 10.53 passes that one
# [18:23] <fantasai> Peter: The question is, should we be matching parentheses inside a URL token
# [18:24] <fantasai> dbaron: If it is a url() token, then you don't match brackets
# [18:24] <fantasai> dbaron: But if it's invalid, then it's not a url() token, and you have to match brackets
# [18:24] <fantasai> dbaron: This change is about not matching brackets for invalid url() tokens
# [18:25] <fantasai> dbaron: Look at test 9 for example
# [18:25] <fantasai> dbaron: Actually, I think 9 is not testing what it's supposed to test.
# [18:25] <fantasai> Peter: Brackets and braces are allowed in a URL. They should not match
# [18:26] <fantasai> Peter: and it's perfectly valid
# [18:26] <dbaron> I think test 9 would probably be more interesting if it had a (
# [18:26] <fantasai> yes
# [18:26] <fantasai> seems like several tests need revising, I think eight doesn't do much either
# [18:27] <fantasai> Simon: Perhaps we should take this issue offline and have someone figure out what the behavior is
# [18:27] <fantasai> Peter: What is the desired behavior of url(() ?
# [18:28] <fantasai> Peter: Does that end the url, or is it consumed by the url?
# [18:28] <fantasai> Peter: Once we figure that out, then we can figure it out
# [18:29] <dbaron> We should really test that url([()) leaves the parser searching for a ]
# [18:29] <fantasai> fantasai: Question is whether we end the url token there or keep parsing until we close the url() token
# [18:30] <fantasai> Peter: Question is, do we keep parsing until we close the url( or do we also match against other things?
# [18:30] <bradk> end the declaration as soon as that makes the url invalid?
# [18:31] <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 )?
# [18:32] * 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 )
# [18:32] <fantasai> Peter: My opinion is that we don't back up and reinterpret things that were part of a valid URL.
# [18:32] <Bert> url((abc)) is currently FUNCTION + ( + abc + ) + ). Question is to change it to INVALID_URI + ( + abc + ) + )
# [18:32] <Zakim> -bradk
# [18:32] <fantasai> Peter summarizes the issue.
# [18:33] * glazou must leave
# [18:33] * glazou bye people
# [18:33] <Zakim> -glazou
# [18:33] <fantasai> Peter: Within a URL, a [ is just a valid character. We wouldn't normally try to match it. url([) is complete and valid
# [18:33] * Quits: glazou (glazou@82.247.96.19) (Quit: must go)
# [18:33] <fantasai> Peter: The question is, suppose you start parsing and you find url([ and then you find something that's invalid inside a URL.
# [18:34] <Zakim> +bradk
# [18:34] <dbaron> I have three added tests to that test (I'll commit later) that will definitely test this issue...
# [18:34] <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)?
# [18:34] <dsinger> I think I agree, the "[" is just a character that is valid.
# [18:34] <fantasai> Peter: The issue is how far do we have to back up if something breaks?
# [18:34] <fantasai> Peter: I would prefer that we don't back up at all.
# [18:34] <dsinger> the next "(" is a character that is invalid in the URL
# [18:34] <bradk> I think if you see a ( in a url where it doesn't belong, then it was probably supposed to be a )
# [18:35] <dsinger> so then we go into "toss the junk until we close the url( form"
# [18:35] <fantasai> fantasai: I'm in favor of not backing up, but no comment on what changes would be needed.
# [18:35] <bradk> so don't keep looking for closing paren
# [18:35] <fantasai> dbaron: Zack had a proposal
# [18:35] <fantasai> Bert: I tested his grammar, and it works.
# [18:35] <fantasai> Bert: The question is do we really need it. My preference is not to change anything.
# [18:35] <fantasai> Peter: Do we have interop on this either way?
# [18:36] <fantasai> arronei: Not really
# [18:36] <fantasai> Peter: So something needs to change.
# [18:37] * dbaron tries to remember the issue number for his commit message
# [18:37] <sylvaing> ie9 currently matching Gecko except on #14
# [18:37] <dbaron> Does anybody know what issue number this is?
# [18:38] <fantasai> Peter: So how do we want this to behave? Does anyone have an opinion besides me?
# [18:38] <fantasai> Bert: I want no change.
# [18:38] <dbaron> I prefer not backtracking
# [18:38] <fantasai> Peter: Do you want no change for the sake of no change, or ...?
# [18:38] <Zakim> -bradk
# [18:38] <bradk> \brad got dropped again. sigh.
# [18:38] <fantasai> Bert: I want no change because this has not change in 15 years.
# [18:38] <fantasai> Bert: And I don't know if we can afford to change it.
# [18:38] * bradk got dropped again. sigh. geez.
# [18:39] <fantasai> Bert: I don't know who implements it, who would need to change.
# [18:39] <fantasai> Peter: Sounds like no change for the sake of no change.
# [18:39] <fantasai> Peter: We don't have interop
# [18:39] <fantasai> Bert: That's normal.
# [18:39] <Zakim> +bradk
# [18:39] * sylvaing 'no interop is normal'. well, that's a catchy statement !
# [18:39] <Zakim> -bradk
# [18:39] <fantasai> Peter: Would like to hear from Mozilla, MS, Apple
# [18:40] <oyvind> dbaron, 129 (if I understand correctly)
# [18:40] <fantasai> dbaron: I prefer not backtracking. I also just committed the additional 3 tests that definitely test this
# [18:40] <fantasai> Arron: I think we need to investigate this more, and I think there's a bug in the testcase.
# [18:40] <fantasai> Arron: My initial impression is that I'd prefer not to backtrack.
# [18:40] <Zakim> +bradk
# [18:41] <fantasai> Arron: Would like to test some more first
# [18:41] <Zakim> -bradk
# [18:41] <fantasai> Simon: I'd have to talk to hyatt to see his opinion on this
# [18:41] <fantasai> Peter: Sounds like we have action items to get more data, and we'll come back to this later
# [18:41] <fantasai> ACTION: Arron figure out opinion on issue 129
# [18:41] * trackbot noticed an ACTION. Trying to create it.
# [18:41] <trackbot> Created ACTION-229 - Figure out opinion on issue 129 [on Arron Eicholz - due 2010-05-26].
# [18:41] * RRSAgent records action 1
# [18:41] <fantasai> ACTION: Simon figure out opinion on issue 129
# [18:41] * RRSAgent records action 2
# [18:41] * trackbot noticed an ACTION. Trying to create it.
# [18:41] <trackbot> Created ACTION-230 - Figure out opinion on issue 129 [on Simon Fraser - due 2010-05-26].
# [18:42] <Zakim> +bradk
# [18:42] <plinss> http://wiki.csswg.org/spec/css2.1#issue-137
# [18:42] <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.
# [18:42] <dbaron> (129, that is)
# [18:43] <fantasai> dbaron: I think there's a whole bunch of things that absolutely depend on them being the containing blocks for floats.
# [18:44] <fantasai> Peter: Reading the summary, seems like everybody but WebKit uses the block, not the anonymous block.
# [18:44] * fantasai thinks that makes sense, it would be confusing if behavior changed suddenly when I insert a block further down.
# [18:45] <fantasai> dbaron: I think there are a bunch of other things where browsers are consistent in treating the anon box as the containing block
# [18:45] <fantasai> dbaron: So maybe we need to change the behavior of percentages, not containing block
# [18:46] <fantasai> dbaron: I think the basic float positioning rules in 9.5.1 depend on the anon box being the containing block
# [18:47] <dbaron> ... though that may depend on how you interpret rule 6
# [18:47] <dbaron> but, basically, I think rule 4 depends on it.
# [18:48] <dbaron> for the case of a float that's right below a block with a bottom margin
# [18:48] <dbaron> and followed by text
# [18:48] <fantasai> Bert: Trying to understand, is this about clarification or change?
# [18:48] <fantasai> Bert: What's meant is the <div> is the containing block
# [18:48] <fantasai> Bert: I think the text is clear enough, if bz thinks that's not the case we should work on that.
# [18:48] <fantasai> Bert: Is that the question? Better text?
# [18:49] <fantasai> dbaron: I remember discussions of float positioning rules in which we assumed the containing block was the anon box.
# [18:49] <fantasai> dbaron: Don't remember what exactly was the issue.
# [18:49] <fantasai> Bert: Maybe something with collapsing margins. Not about the height.
# [18:49] <bradk> webkit looks like firefox when you remove the doctype
# [18:50] <fantasai> fantasai: table captions have a similar issue in that they push through the anon box for certain calculations
# [18:50] <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>
# [18:50] <fantasai> or maybe we changed that
# [18:50] <dbaron> in which I think browsers uniformly place the float below the margin
# [18:51] <dbaron> but if the containing block weren't the anonymous block
# [18:51] <fantasai> Arron: Behavior is fairly consistent. I think it's just a bug in webkit
# [18:52] <fantasai> dbaron looks at wording for containing blocks and percentage heights
# [18:52] <fantasai> dbaron: I think WebKit is currently correct per the spec
# [18:52] <dbaron> I think WebKit's rendering of bz's testcase is clearly correct per current spec
# [18:52] <fantasai> dbaron: And we should fix the spec
# [18:52] <bradk> without the doctype, that one is also the same in webkit
# [18:52] <fantasai> Bert thinks the containing block is the <div> element.
# [18:53] <fantasai> Tab and dbaron explain that there's an anonymous block in between.
# [18:53] <fantasai> dbaron points to bullet point 2 in the containing box definition, where it says "box", not "element"
# [18:54] <fantasai> dbaron: I posted a testcase to IRC showing that the anon box is the containing block for some other calculations.
# [18:55] <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
# [18:56] <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.
# [18:56] * sylvaing -webkit-anonymous-box-adjust !
# [18:56] * TabAtkins -webkit-prefix-support
# [18:56] <Zakim> -bradk
# [18:57] <fantasai> Peter: Should we make this change generically, or specifically for this case?
# [18:57] <fantasai> fantasai: I think generically. There are a lot of properties to cover, and I don't want to miss out on any.
# [18:57] <fantasai> fantasai: Basically say that anon boxes are not used in percentage calculations
# [18:57] <Zakim> +bradk
# [18:57] <fantasai> Peter: Do we have enough tests for this, or do we need more?
# [18:58] <fantasai> Arron: I don't think we have a lot of tests that cover this specific case.
# [18:58] <fantasai> Arron: We have tests for percentages in general, but very few involving anonymous boxes.
# [18:59] * fantasai wonders about percentages when table anon boxes are involved
# [18:59] <fantasai> Arron: Would that change be for every single percentage property, or in 10.1, or somewhere else?
# [19:00] <fantasai> Arron: Where are we going to take that?
# [19:01] <fantasai> Another issue is tables.
# [19:02] <fantasai> suppose I have <table height=200px> <div height=50px> </table>
# [19:02] <fantasai> with border-spacing: 50px
# [19:02] <fantasai> er, make the div 50%
# [19:02] <fantasai> ACTION: fantasai write proposed text
# [19:02] * trackbot noticed an ACTION. Trying to create it.
# [19:02] * RRSAgent records action 3
# [19:02] <trackbot> Created ACTION-231 - Write proposed text [on Elika Etemad - due 2010-05-26].
# [19:02] <fantasai> Peter: Can everyone look through unowned issues
# [19:02] <Zakim> -smfr
# [19:02] * dsinger byeeeee!
# [19:02] <Zakim> -[Apple]
# [19:02] <Zakim> -David_Baron
# [19:02] <Zakim> -arronei
# [19:02] <fantasai> Peter: And please update wiki with any updates
# [19:02] <Zakim> -sylvaing
# [19:02] * Quits: bradk (bradk@67.188.133.45) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
# [19:02] <Zakim> -[Apple.a]
# [19:02] <Zakim> -TabAtkins
# [19:02] <Zakim> -Bert
# [19:02] <Zakim> -fantasai
# [19:03] <Zakim> -plinss
# [19:03] <Zakim> -bradk
# [19:03] * Quits: sylvaing (sylvaing@76.104.131.10) (Quit: sylvaing)
# [19:03] <Zakim> Style_CSS FP()12:00PM has ended
# [19:03] <Zakim> Attendees were plinss, +1.650.253.aaaa, TabAtkins, Bert, glazou, dsinger, smfr, dethbakin, sylvaing, arronei, David_Baron, fantasai, bradk, [Apple]
# [19:03] * Quits: oyvind (oyvinds@213.236.208.22) (Quit: oyvind)
# [19:13] * Parts: smfr (smfr@68.183.233.103)
# [19:25] * Quits: DanC (connolly@128.30.52.169) (Ping timeout)
# [19:42] * Joins: shepazu (schepers@128.30.52.169)
# [19:44] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# [19:47] * Quits: dsinger (dsinger@17.197.20.4) (Quit: dsinger)
# [19:48] * Quits: plinss (plinss@68.107.121.183) (Ping timeout)
# [19:48] * plinss_ is now known as plinss
# [20:36] * Joins: DanC (connolly@128.30.52.169)
# [22:07] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
# [22:17] * Zakim excuses himself; his presence no longer seems to be needed
# [22:17] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [22:56] * Joins: Lachy (Lachlan@85.196.122.246)
# [23:03] * Joins: jdaggett (jdaggett@118.243.224.63)
# [23:03] * Quits: miketaylr (miketaylr@38.117.156.163) (Client exited)
# [23:04] * Joins: jdaggett_ (jdaggett@118.243.224.63)
# [23:04] * Quits: jdaggett (jdaggett@118.243.224.63) (Connection reset by peer)
# [23:04] * jdaggett_ is now known as jdaggett
# [23:12] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [23:13] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
# [23:21] * Joins: Lachy (Lachlan@85.196.122.246)
# [23:25] * Joins: dbaron (dbaron@63.245.220.240)
# [23:28] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: Leaving)
# [23:28] * Joins: Lachy (Lachlan@85.196.122.246)
# [23:34] * Joins: shepazu (schepers@128.30.52.169)
# [23:39] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# [23:45] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
# Session Close: Thu May 20 00:00:00 2010

The end :)