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

Options:

  1. # Session Start: Wed May 19 00:00:00 2010
  2. # Session Ident: #css
  3. # [00:37] * Quits: Curt` (DorkeyDear@76.243.205.185) (Quit: Leaving)
  4. # [00:49] * Quits: miketaylr (miketaylr@38.117.156.163) (Client exited)
  5. # [01:03] <anne> maybe the idea was to use that inside style="" but that's
  6. # [01:03] <anne> still wrong
  7. # [02:14] * Joins: dsinger (dsinger@17.197.20.4)
  8. # [02:36] * Joins: jdaggett (jdaggett@118.243.224.63)
  9. # [02:57] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  10. # [03:50] * Quits: jdaggett (jdaggett@118.243.224.63) (Quit: jdaggett)
  11. # [04:06] * Joins: oli (oli@124.87.135.239)
  12. # [04:34] * Joins: miketaylr (miketaylr@24.42.95.234)
  13. # [04:53] * Joins: Curt` (DorkeyDear@76.243.205.185)
  14. # [05:40] * Quits: DanC (connolly@128.30.52.169) (Ping timeout)
  15. # [05:49] * Joins: dbaron (dbaron@98.234.51.190)
  16. # [05:50] * Joins: DanC (connolly@128.30.52.169)
  17. # [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
  18. # [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 { ]
  19. # [06:01] <DanC> er... rather: e { }
  20. # [06:02] <DanC> there's no S between selector and { in ruleset, and no S at the end of selector
  21. # [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
  22. # [06:02] <dbaron> but there have certainly been errors
  23. # [06:03] <dbaron> which grammar are you looking at, anyway?
  24. # [06:03] <dbaron> There are too many.
  25. # [06:03] <DanC> http://www.w3.org/TR/CSS2/grammar.html
  26. # [06:03] <dbaron> ugh
  27. # [06:03] <dbaron> probably the least accurate one :-P
  28. # [06:04] <DanC> has the WG published anything newer/better?
  29. # [06:04] <dbaron> no
  30. # [06:04] <dbaron> it's just that the interaction of the chapter 4 grammar and the appendix G grammar isn't particularly defined
  31. # [06:04] <dbaron> and my opinion is that the appendix G grammar doesn't really have a normative role
  32. # [06:04] <DanC> the chapter 4 grammar is almost entirely worthless
  33. # [06:04] <dbaron> except in so far as other features in the spec neglect to mention anything about parsing
  34. # [06:05] <DanC> except... exactly
  35. # [06:05] <dbaron> and the normative parts are mainly the chapter 4 grammar and the prose
  36. # [06:05] <dbaron> It looks to me like the selector production has builtin trailing whitespace
  37. # [06:05] <dbaron> so I think you're ok there
  38. # [06:05] <DanC> I've been known to be blind before... help?
  39. # [06:06] <dbaron> : simple_selector [ combinator selector | S+ [ combinator? selector ]? ]?
  40. # [06:06] <dbaron> so it's a recursive production
  41. # [06:06] <dbaron> and if you take the | option on the right
  42. # [06:06] <dbaron> and then don't take the ?
  43. # [06:06] <dbaron> you get S+ at the end
  44. # [06:06] <dbaron> (take the outer ? but not the inner ?, that is)
  45. # [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
  46. # [06:07] <dbaron> yeah, the whitespace is in selector and not simple_selector
  47. # [06:07] <dbaron> since simple_selector doesn't have any whitespace in the production since a space is a combinator
  48. # [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.
  49. # [06:09] * DanC wonders about tokenizer modes for "keep spaces" and "throw away spaces"
  50. # [06:09] <dbaron> In CSS1 it was the only combinator
  51. # [06:10] <dbaron> Mozilla uses GetToken(bool skip_whitespace), basically
  52. # [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
  53. # [06:11] <dbaron> we used to have that
  54. # [06:11] <dbaron> sort of
  55. # [06:11] <dbaron> but it implied that div*p was a valid selector
  56. # [06:11] <dbaron> for a p that is a descendant of a div but not its child
  57. # [06:11] <dbaron> whereas we actually want to require the space
  58. # [06:12] <dbaron> (though some browsers accepted it for a while after I wrote a testcase claiming it should be accepted)
  59. # [06:12] <DanC> why wouldn't div*p match child p's?
  60. # [06:13] * DanC looks up the * deely, which he's never seen in CSS before
  61. # [06:15] <DanC> I don't see div * p in the selector syntax summary table. :-/
  62. # [06:15] <DanC> there's an example in 5.5 Descendant selectors, but I don't see anything normative
  63. # [06:16] <dbaron> * is a universal selector
  64. # [06:16] <dbaron> it's not a combinator
  65. # [06:16] <dbaron> div>p is valid
  66. # [06:16] <dbaron> as is *>p
  67. # [06:16] <DanC> oh... I see... div * p is like div blort p but with * as a wildcard
  68. # [06:17] <DanC> so... why require spaces?
  69. # [06:18] <dbaron> because the combinator is a space
  70. # [06:18] <dbaron> otherwise div* vs div:hover is quite confusing
  71. # [06:18] <DanC> see point earlier; why not just sequence as combinator? hm.
  72. # [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
  73. # [06:21] * DanC is starting to think writing a perl parser would be easier ;-)
  74. # [06:21] <DanC> anyhoo... thanks for reading the selector production for me...
  75. # [06:31] * Quits: miketaylr (miketaylr@24.42.95.234) (Client exited)
  76. # [07:21] * Quits: Curt` (DorkeyDear@76.243.205.185) (Quit: Leaving)
  77. # [08:44] * Quits: oli (oli@124.87.135.239) (Ping timeout)
  78. # [08:58] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  79. # [09:08] * Quits: dbaron (dbaron@98.234.51.190) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  80. # [10:31] * Joins: Lachy (Lachlan@213.236.208.22)
  81. # [10:38] * Quits: karl (karlcow@128.30.54.58) (Ping timeout)
  82. # [11:14] * Joins: Bert_ (bbos@mcclure.w3.org)
  83. # [11:18] * Quits: Bert_ (bbos@mcclure.w3.org) (Quit: leaving)
  84. # [12:03] * Joins: karl (karlcow@128.30.54.58)
  85. # [14:12] * Joins: myakura (myakura@220.104.128.62)
  86. # [15:18] * Joins: miketaylr (miketaylr@38.117.156.163)
  87. # [15:33] * Joins: jdaggett (jdaggett@118.243.224.63)
  88. # [16:06] * Parts: anne (annevk@83.85.115.123)
  89. # [16:39] * Quits: myakura (myakura@220.104.128.62) (Quit: Leaving...)
  90. # [17:00] * Joins: Curt` (DorkeyDear@76.243.205.185)
  91. # [17:17] * Quits: jdaggett (jdaggett@118.243.224.63) (Quit: jdaggett)
  92. # [17:29] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  93. # [17:35] * Quits: arronei (arronei@131.107.0.71) (Ping timeout)
  94. # [17:39] * Joins: Lachy (Lachlan@85.196.122.246)
  95. # [17:40] * Joins: arronei (arronei@131.107.0.84)
  96. # [17:57] * Joins: oyvind (oyvinds@213.236.208.22)
  97. # [17:57] * Joins: glazou (glazou@82.247.96.19)
  98. # [17:58] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  99. # [17:58] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  100. # [17:58] <RRSAgent> logging to http://www.w3.org/2010/05/19-CSS-irc
  101. # [17:58] <glazou> Zakim, this will be Style
  102. # [17:58] <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 4 minutes
  103. # [17:58] <glazou> RRSAgent, make logs public
  104. # [17:58] <RRSAgent> I have made the request, glazou
  105. # [17:58] <glazou> Pfioooou, telephone and internet were borked 15 seconds ago...
  106. # [17:59] <Zakim> Style_CSS FP()12:00PM has now started
  107. # [17:59] <Zakim> +plinss
  108. # [18:00] <Zakim> + +1.650.253.aaaa
  109. # [18:00] <TabAtkins> zakim, aaaa is me
  110. # [18:00] <Zakim> +TabAtkins; got it
  111. # [18:02] <glazou> bridge refusing me
  112. # [18:02] <Zakim> +Bert
  113. # [18:02] <glazou> can"t dial in
  114. # [18:02] <Zakim> +glazou
  115. # [18:02] <glazou> ah 5th attempt
  116. # [18:02] <Zakim> +dsinger
  117. # [18:03] <glazou> Zakim, your friend bridge is lazy
  118. # [18:03] <Zakim> I don't understand 'your friend bridge is lazy', glazou
  119. # [18:03] * Joins: dbaron (dbaron@63.245.220.240)
  120. # [18:03] * Joins: dethbakin (dethbakin@17.246.19.169)
  121. # [18:03] * Joins: smfr (smfr@68.183.233.103)
  122. # [18:03] * Quits: dbaron (dbaron@63.245.220.240) (Connection reset by peer)
  123. # [18:03] * Joins: dbaron (dbaron@63.245.220.240)
  124. # [18:04] <Zakim> +smfr
  125. # [18:04] <Zakim> +[Apple]
  126. # [18:04] * Joins: dsinger_ (mobile@67.218.102.152)
  127. # [18:04] <Zakim> +[Microsoft]
  128. # [18:04] <dsinger_> zakim, mute dsinger
  129. # [18:04] <Zakim> dsinger should now be muted
  130. # [18:04] <dethbakin> Zakim, Apple has dethbakin
  131. # [18:04] <Zakim> +dethbakin; got it
  132. # [18:04] <Zakim> +sylvaing
  133. # [18:04] <dsinger_> zakim, who is on the phone?
  134. # [18:04] <Zakim> On the phone I see plinss, TabAtkins, Bert, glazou, dsinger (muted), smfr, [Apple], [Microsoft], sylvaing
  135. # [18:04] <Zakim> [Apple] has dethbakin
  136. # [18:04] <Zakim> +[Mozilla]
  137. # [18:04] <TabAtkins> Zakim, microsoft has arronei
  138. # [18:04] <Zakim> +arronei; got it
  139. # [18:04] * Joins: sylvaing (sylvaing@76.104.131.10)
  140. # [18:04] <dbaron> Zakim, [Mozilla] is David_Baron
  141. # [18:04] <Zakim> +David_Baron; got it
  142. # [18:04] <arronei> zakim, microsoft is me
  143. # [18:04] <Zakim> +arronei; got it
  144. # [18:05] * dsinger_ mornin' all!
  145. # [18:05] <Zakim> +??P8
  146. # [18:06] <glazou> good evening :)
  147. # [18:06] * sylvaing should really have joined as ::-ms-sylvaing
  148. # [18:06] * dsinger_ who is ??p8?
  149. # [18:06] <fantasai> probably me
  150. # [18:07] * TabAtkins Sylvain, just put yourself in a draft and get it to CR. Then you can drop your prefix.
  151. # [18:07] <fantasai> zakim, ??p8 is me
  152. # [18:07] <Zakim> +fantasai; got it
  153. # [18:07] * dsinger_ hi me!
  154. # [18:07] <smfr> heh
  155. # [18:07] <fantasai> ScribeNick: fantasai
  156. # [18:07] * glazou lol sylvaing
  157. # [18:08] <fantasai> Peter: Lots of open issues on CSS2.1
  158. # [18:08] <fantasai> Peter: dbaron? ETA?
  159. # [18:08] <fantasai> dbaron: Hopefully next week, but not sure
  160. # [18:08] * glazou elika said on twitter she now lives in a closet to deal with tests :)
  161. # [18:08] <fantasai> fantasai: I have not been working on issues, have been working on tests
  162. # [18:09] * fantasai not exactly true, but I'm considering switching to nocturnal so I can get more work done
  163. # [18:09] * fantasai doesn't concentrate well during hte day
  164. # [18:09] <fantasai> sylvain: Waiting for an answer
  165. # [18:09] <fantasai> Peter: Bert's issues mostly editorial...
  166. # [18:09] * glazou FYI, http://yro.slashdot.org/story/10/05/19/1425240/76-Web-Users-Affected-By-Browser-History-Stealing
  167. # [18:10] <fantasai> Bert: Don't know which issues are worth discussing.
  168. # [18:10] <fantasai> Arron: Been pulling together testcases. Should have no problem creating testcases.
  169. # [18:10] <fantasai> Arron: Started on image, but not done yet. Guessing next week.
  170. # [18:10] * Joins: bradk (bradk@67.188.133.45)
  171. # [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
  172. # [18:11] <fantasai> Peter: 151?
  173. # [18:11] <plinss> s/151/161/
  174. # [18:11] <fantasai> http://wiki.csswg.org/spec/css2.1
  175. # [18:12] <fantasai> Tab: Already sent proposal to list
  176. # [18:12] <fantasai> fantasai: Link from issues list?
  177. # [18:12] * bradk is having slow computer problems... trying to call in
  178. # [18:13] <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2010Apr/0389.html
  179. # [18:13] <Zakim> +bradk
  180. # [18:14] <fantasai> RESOLVED: Accept Tab's proposal for issue 161
  181. # [18:15] <plinss> http://wiki.csswg.org/spec/css2.1#issue-129
  182. # [18:15] * Quits: dsinger_ (mobile@67.218.102.152) (Quit: Rooms • iPhone IRC Client • http://www.roomsapp.mobi)
  183. # [18:15] <fantasai> Tab: I wish I understood enough to comment on that.
  184. # [18:15] * fantasai has no comments either
  185. # [18:15] <bradk> \me too
  186. # [18:16] * bradk too
  187. # [18:16] <fantasai> ..
  188. # [18:16] <fantasai> Bert: Tried to implement change with flex
  189. # [18:16] <fantasai> Bert: I only noticed a difference in speed for several thousand bytes
  190. # [18:17] <fantasai> Bert: The claim was that it's inefficient, that inefficiency is at the level of microseconds
  191. # [18:18] <fantasai> Peter: The change is just clarification, or change in error recovery?
  192. # [18:18] <fantasai> fantasai: It's a change in error recovery, because you no longer match brackets.
  193. # [18:19] <fantasai> Bert: url( ( )
  194. # [18:20] * fantasai didnt' catch which behavior was which proposal
  195. # [18:20] <fantasai> dbaron: I don't remember implementations passing the test I wrote for the test suite
  196. # [18:21] <Zakim> +[Apple.a]
  197. # [18:21] <dsinger> zakim, [apple] has dsinger
  198. # [18:21] <Zakim> +dsinger; got it
  199. # [18:21] <Zakim> -dsinger
  200. # [18:21] <fantasai> http://test.csswg.org/source/contributors/mozilla/incoming/reftests/bugs/invalid-url-handling.xht
  201. # [18:22] <smfr> Zakim, who's noisy?
  202. # [18:22] <Zakim> smfr, listening for 10 seconds I heard sound from the following: [Apple] (0%)
  203. # [18:22] <glazou> :)
  204. # [18:23] * dsinger shucks, that was my excessive silence, I am sorry. I will get a super-mute on my phone
  205. # [18:23] <oyvind> opera 10.53 passes that one
  206. # [18:23] <fantasai> Peter: The question is, should we be matching parentheses inside a URL token
  207. # [18:24] <fantasai> dbaron: If it is a url() token, then you don't match brackets
  208. # [18:24] <fantasai> dbaron: But if it's invalid, then it's not a url() token, and you have to match brackets
  209. # [18:24] <fantasai> dbaron: This change is about not matching brackets for invalid url() tokens
  210. # [18:25] <fantasai> dbaron: Look at test 9 for example
  211. # [18:25] <fantasai> dbaron: Actually, I think 9 is not testing what it's supposed to test.
  212. # [18:25] <fantasai> Peter: Brackets and braces are allowed in a URL. They should not match
  213. # [18:26] <fantasai> Peter: and it's perfectly valid
  214. # [18:26] <dbaron> I think test 9 would probably be more interesting if it had a (
  215. # [18:26] <fantasai> yes
  216. # [18:26] <fantasai> seems like several tests need revising, I think eight doesn't do much either
  217. # [18:27] <fantasai> Simon: Perhaps we should take this issue offline and have someone figure out what the behavior is
  218. # [18:27] <fantasai> Peter: What is the desired behavior of url(() ?
  219. # [18:28] <fantasai> Peter: Does that end the url, or is it consumed by the url?
  220. # [18:28] <fantasai> Peter: Once we figure that out, then we can figure it out
  221. # [18:29] <dbaron> We should really test that url([()) leaves the parser searching for a ]
  222. # [18:29] <fantasai> fantasai: Question is whether we end the url token there or keep parsing until we close the url() token
  223. # [18:30] <fantasai> Peter: Question is, do we keep parsing until we close the url( or do we also match against other things?
  224. # [18:30] <bradk> end the declaration as soon as that makes the url invalid?
  225. # [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 )?
  226. # [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 )
  227. # [18:32] <fantasai> Peter: My opinion is that we don't back up and reinterpret things that were part of a valid URL.
  228. # [18:32] <Bert> url((abc)) is currently FUNCTION + ( + abc + ) + ). Question is to change it to INVALID_URI + ( + abc + ) + )
  229. # [18:32] <Zakim> -bradk
  230. # [18:32] <fantasai> Peter summarizes the issue.
  231. # [18:33] * glazou must leave
  232. # [18:33] * glazou bye people
  233. # [18:33] <Zakim> -glazou
  234. # [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
  235. # [18:33] * Quits: glazou (glazou@82.247.96.19) (Quit: must go)
  236. # [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.
  237. # [18:34] <Zakim> +bradk
  238. # [18:34] <dbaron> I have three added tests to that test (I'll commit later) that will definitely test this issue...
  239. # [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)?
  240. # [18:34] <dsinger> I think I agree, the "[" is just a character that is valid.
  241. # [18:34] <fantasai> Peter: The issue is how far do we have to back up if something breaks?
  242. # [18:34] <fantasai> Peter: I would prefer that we don't back up at all.
  243. # [18:34] <dsinger> the next "(" is a character that is invalid in the URL
  244. # [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 )
  245. # [18:35] <dsinger> so then we go into "toss the junk until we close the url( form"
  246. # [18:35] <fantasai> fantasai: I'm in favor of not backing up, but no comment on what changes would be needed.
  247. # [18:35] <bradk> so don't keep looking for closing paren
  248. # [18:35] <fantasai> dbaron: Zack had a proposal
  249. # [18:35] <fantasai> Bert: I tested his grammar, and it works.
  250. # [18:35] <fantasai> Bert: The question is do we really need it. My preference is not to change anything.
  251. # [18:35] <fantasai> Peter: Do we have interop on this either way?
  252. # [18:36] <fantasai> arronei: Not really
  253. # [18:36] <fantasai> Peter: So something needs to change.
  254. # [18:37] * dbaron tries to remember the issue number for his commit message
  255. # [18:37] <sylvaing> ie9 currently matching Gecko except on #14
  256. # [18:37] <dbaron> Does anybody know what issue number this is?
  257. # [18:38] <fantasai> Peter: So how do we want this to behave? Does anyone have an opinion besides me?
  258. # [18:38] <fantasai> Bert: I want no change.
  259. # [18:38] <dbaron> I prefer not backtracking
  260. # [18:38] <fantasai> Peter: Do you want no change for the sake of no change, or ...?
  261. # [18:38] <Zakim> -bradk
  262. # [18:38] <bradk> \brad got dropped again. sigh.
  263. # [18:38] <fantasai> Bert: I want no change because this has not change in 15 years.
  264. # [18:38] <fantasai> Bert: And I don't know if we can afford to change it.
  265. # [18:38] * bradk got dropped again. sigh. geez.
  266. # [18:39] <fantasai> Bert: I don't know who implements it, who would need to change.
  267. # [18:39] <fantasai> Peter: Sounds like no change for the sake of no change.
  268. # [18:39] <fantasai> Peter: We don't have interop
  269. # [18:39] <fantasai> Bert: That's normal.
  270. # [18:39] <Zakim> +bradk
  271. # [18:39] * sylvaing 'no interop is normal'. well, that's a catchy statement !
  272. # [18:39] <Zakim> -bradk
  273. # [18:39] <fantasai> Peter: Would like to hear from Mozilla, MS, Apple
  274. # [18:40] <oyvind> dbaron, 129 (if I understand correctly)
  275. # [18:40] <fantasai> dbaron: I prefer not backtracking. I also just committed the additional 3 tests that definitely test this
  276. # [18:40] <fantasai> Arron: I think we need to investigate this more, and I think there's a bug in the testcase.
  277. # [18:40] <fantasai> Arron: My initial impression is that I'd prefer not to backtrack.
  278. # [18:40] <Zakim> +bradk
  279. # [18:41] <fantasai> Arron: Would like to test some more first
  280. # [18:41] <Zakim> -bradk
  281. # [18:41] <fantasai> Simon: I'd have to talk to hyatt to see his opinion on this
  282. # [18:41] <fantasai> Peter: Sounds like we have action items to get more data, and we'll come back to this later
  283. # [18:41] <fantasai> ACTION: Arron figure out opinion on issue 129
  284. # [18:41] * trackbot noticed an ACTION. Trying to create it.
  285. # [18:41] <trackbot> Created ACTION-229 - Figure out opinion on issue 129 [on Arron Eicholz - due 2010-05-26].
  286. # [18:41] * RRSAgent records action 1
  287. # [18:41] <fantasai> ACTION: Simon figure out opinion on issue 129
  288. # [18:41] * RRSAgent records action 2
  289. # [18:41] * trackbot noticed an ACTION. Trying to create it.
  290. # [18:41] <trackbot> Created ACTION-230 - Figure out opinion on issue 129 [on Simon Fraser - due 2010-05-26].
  291. # [18:42] <Zakim> +bradk
  292. # [18:42] <plinss> http://wiki.csswg.org/spec/css2.1#issue-137
  293. # [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.
  294. # [18:42] <dbaron> (129, that is)
  295. # [18:43] <fantasai> dbaron: I think there's a whole bunch of things that absolutely depend on them being the containing blocks for floats.
  296. # [18:44] <fantasai> Peter: Reading the summary, seems like everybody but WebKit uses the block, not the anonymous block.
  297. # [18:44] * fantasai thinks that makes sense, it would be confusing if behavior changed suddenly when I insert a block further down.
  298. # [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
  299. # [18:45] <fantasai> dbaron: So maybe we need to change the behavior of percentages, not containing block
  300. # [18:46] <fantasai> dbaron: I think the basic float positioning rules in 9.5.1 depend on the anon box being the containing block
  301. # [18:47] <dbaron> ... though that may depend on how you interpret rule 6
  302. # [18:47] <dbaron> but, basically, I think rule 4 depends on it.
  303. # [18:48] <dbaron> for the case of a float that's right below a block with a bottom margin
  304. # [18:48] <dbaron> and followed by text
  305. # [18:48] <fantasai> Bert: Trying to understand, is this about clarification or change?
  306. # [18:48] <fantasai> Bert: What's meant is the <div> is the containing block
  307. # [18:48] <fantasai> Bert: I think the text is clear enough, if bz thinks that's not the case we should work on that.
  308. # [18:48] <fantasai> Bert: Is that the question? Better text?
  309. # [18:49] <fantasai> dbaron: I remember discussions of float positioning rules in which we assumed the containing block was the anon box.
  310. # [18:49] <fantasai> dbaron: Don't remember what exactly was the issue.
  311. # [18:49] <fantasai> Bert: Maybe something with collapsing margins. Not about the height.
  312. # [18:49] <bradk> webkit looks like firefox when you remove the doctype
  313. # [18:50] <fantasai> fantasai: table captions have a similar issue in that they push through the anon box for certain calculations
  314. # [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>
  315. # [18:50] <fantasai> or maybe we changed that
  316. # [18:50] <dbaron> in which I think browsers uniformly place the float below the margin
  317. # [18:51] <dbaron> but if the containing block weren't the anonymous block
  318. # [18:51] <fantasai> Arron: Behavior is fairly consistent. I think it's just a bug in webkit
  319. # [18:52] <fantasai> dbaron looks at wording for containing blocks and percentage heights
  320. # [18:52] <fantasai> dbaron: I think WebKit is currently correct per the spec
  321. # [18:52] <dbaron> I think WebKit's rendering of bz's testcase is clearly correct per current spec
  322. # [18:52] <fantasai> dbaron: And we should fix the spec
  323. # [18:52] <bradk> without the doctype, that one is also the same in webkit
  324. # [18:52] <fantasai> Bert thinks the containing block is the <div> element.
  325. # [18:53] <fantasai> Tab and dbaron explain that there's an anonymous block in between.
  326. # [18:53] <fantasai> dbaron points to bullet point 2 in the containing box definition, where it says "box", not "element"
  327. # [18:54] <fantasai> dbaron: I posted a testcase to IRC showing that the anon box is the containing block for some other calculations.
  328. # [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
  329. # [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.
  330. # [18:56] * sylvaing -webkit-anonymous-box-adjust !
  331. # [18:56] * TabAtkins -webkit-prefix-support
  332. # [18:56] <Zakim> -bradk
  333. # [18:57] <fantasai> Peter: Should we make this change generically, or specifically for this case?
  334. # [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.
  335. # [18:57] <fantasai> fantasai: Basically say that anon boxes are not used in percentage calculations
  336. # [18:57] <Zakim> +bradk
  337. # [18:57] <fantasai> Peter: Do we have enough tests for this, or do we need more?
  338. # [18:58] <fantasai> Arron: I don't think we have a lot of tests that cover this specific case.
  339. # [18:58] <fantasai> Arron: We have tests for percentages in general, but very few involving anonymous boxes.
  340. # [18:59] * fantasai wonders about percentages when table anon boxes are involved
  341. # [18:59] <fantasai> Arron: Would that change be for every single percentage property, or in 10.1, or somewhere else?
  342. # [19:00] <fantasai> Arron: Where are we going to take that?
  343. # [19:01] <fantasai> Another issue is tables.
  344. # [19:02] <fantasai> suppose I have <table height=200px> <div height=50px> </table>
  345. # [19:02] <fantasai> with border-spacing: 50px
  346. # [19:02] <fantasai> er, make the div 50%
  347. # [19:02] <fantasai> ACTION: fantasai write proposed text
  348. # [19:02] * trackbot noticed an ACTION. Trying to create it.
  349. # [19:02] * RRSAgent records action 3
  350. # [19:02] <trackbot> Created ACTION-231 - Write proposed text [on Elika Etemad - due 2010-05-26].
  351. # [19:02] <fantasai> Peter: Can everyone look through unowned issues
  352. # [19:02] <Zakim> -smfr
  353. # [19:02] * dsinger byeeeee!
  354. # [19:02] <Zakim> -[Apple]
  355. # [19:02] <Zakim> -David_Baron
  356. # [19:02] <Zakim> -arronei
  357. # [19:02] <fantasai> Peter: And please update wiki with any updates
  358. # [19:02] <Zakim> -sylvaing
  359. # [19:02] * Quits: bradk (bradk@67.188.133.45) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
  360. # [19:02] <Zakim> -[Apple.a]
  361. # [19:02] <Zakim> -TabAtkins
  362. # [19:02] <Zakim> -Bert
  363. # [19:02] <Zakim> -fantasai
  364. # [19:03] <Zakim> -plinss
  365. # [19:03] <Zakim> -bradk
  366. # [19:03] * Quits: sylvaing (sylvaing@76.104.131.10) (Quit: sylvaing)
  367. # [19:03] <Zakim> Style_CSS FP()12:00PM has ended
  368. # [19:03] <Zakim> Attendees were plinss, +1.650.253.aaaa, TabAtkins, Bert, glazou, dsinger, smfr, dethbakin, sylvaing, arronei, David_Baron, fantasai, bradk, [Apple]
  369. # [19:03] * Quits: oyvind (oyvinds@213.236.208.22) (Quit: oyvind)
  370. # [19:13] * Parts: smfr (smfr@68.183.233.103)
  371. # [19:25] * Quits: DanC (connolly@128.30.52.169) (Ping timeout)
  372. # [19:42] * Joins: shepazu (schepers@128.30.52.169)
  373. # [19:44] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  374. # [19:47] * Quits: dsinger (dsinger@17.197.20.4) (Quit: dsinger)
  375. # [19:48] * Quits: plinss (plinss@68.107.121.183) (Ping timeout)
  376. # [19:48] * plinss_ is now known as plinss
  377. # [20:36] * Joins: DanC (connolly@128.30.52.169)
  378. # [22:07] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  379. # [22:17] * Zakim excuses himself; his presence no longer seems to be needed
  380. # [22:17] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  381. # [22:56] * Joins: Lachy (Lachlan@85.196.122.246)
  382. # [23:03] * Joins: jdaggett (jdaggett@118.243.224.63)
  383. # [23:03] * Quits: miketaylr (miketaylr@38.117.156.163) (Client exited)
  384. # [23:04] * Joins: jdaggett_ (jdaggett@118.243.224.63)
  385. # [23:04] * Quits: jdaggett (jdaggett@118.243.224.63) (Connection reset by peer)
  386. # [23:04] * jdaggett_ is now known as jdaggett
  387. # [23:12] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  388. # [23:13] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  389. # [23:21] * Joins: Lachy (Lachlan@85.196.122.246)
  390. # [23:25] * Joins: dbaron (dbaron@63.245.220.240)
  391. # [23:28] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: Leaving)
  392. # [23:28] * Joins: Lachy (Lachlan@85.196.122.246)
  393. # [23:34] * Joins: shepazu (schepers@128.30.52.169)
  394. # [23:39] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  395. # [23:45] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  396. # Session Close: Thu May 20 00:00:00 2010

The end :)