/irc-logs / w3c / #css / 2011-03-07 / end

Options:

  1. # Session Start: Mon Mar 07 00:00:00 2011
  2. # Session Ident: #css
  3. # [00:05] * Quits: homata_ (homata_@58.158.182.50) (Client exited)
  4. # [00:06] * Joins: homata_ (homata_@58.158.182.50)
  5. # [00:06] * Quits: homata_ (homata_@58.158.182.50) (Client exited)
  6. # [00:07] * Joins: homata_ (homata_@58.158.182.50)
  7. # [01:10] * Joins: homata (homata@58.158.182.50)
  8. # [03:55] * Quits: dbaron (dbaron@173.228.28.143) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  9. # [07:04] * Quits: homata (homata@58.158.182.50) (Ping timeout)
  10. # [07:04] * Joins: homata (homata@58.158.182.50)
  11. # [07:45] * Joins: homata__ (homata@58.158.182.50)
  12. # [07:47] * Quits: homata (homata@58.158.182.50) (Ping timeout)
  13. # [08:09] * Quits: homata__ (homata@58.158.182.50) (Quit: Leaving...)
  14. # [08:15] * Joins: davve (davve@83.218.67.122)
  15. # [08:32] * Joins: anne (annevk@83.85.115.123)
  16. # [11:41] * Quits: kennyluck (kennyluck@128.30.52.169) (Quit: kennyluck)
  17. # [11:53] * Quits: arronei (arronei@131.107.0.85) (Ping timeout)
  18. # [11:58] * Joins: arronei (arronei@131.107.0.118)
  19. # [13:02] * Quits: homata_ (homata_@58.158.182.50) (Client exited)
  20. # [13:46] * Joins: kennyluck (kennyluck@128.30.52.169)
  21. # [13:53] * Joins: myakura (myakura@123.224.162.182)
  22. # [15:06] * Quits: kennyluck (kennyluck@128.30.52.169) (Client exited)
  23. # [15:12] * Joins: miketaylr (miketaylr@206.217.92.186)
  24. # [15:35] * Quits: myakura (myakura@123.224.162.182) (Client exited)
  25. # [16:32] * Joins: kennyluck (kennyluck@128.30.52.169)
  26. # [16:32] * Quits: kennyluck (kennyluck@128.30.52.169) (Client exited)
  27. # [16:32] * Joins: kennyluck (kennyluck@128.30.52.169)
  28. # [17:22] * Joins: nattokirai (nattokirai@64.134.229.11)
  29. # [17:22] * nattokirai is now known as jdaggett
  30. # [17:23] * Quits: jdaggett (nattokirai@64.134.229.11) (Quit: jdaggett)
  31. # [17:23] * Joins: jdaggett (jdaggett@64.134.229.11)
  32. # [17:33] * jdaggett wonders if the room is open yet or not...
  33. # [17:34] * Quits: jdaggett (jdaggett@64.134.229.11) (Quit: jdaggett)
  34. # [17:55] * Joins: jdaggett (jdaggett@63.245.220.224)
  35. # [18:08] * Joins: Arron (arronei@63.245.220.224)
  36. # [18:08] * Joins: smfr (smfr@63.245.220.224)
  37. # [18:09] * Joins: glazou (glazou@63.245.220.224)
  38. # [18:10] <glazou> test
  39. # [18:10] * Joins: plinss_ (plinss@63.245.220.224)
  40. # [18:12] * Joins: bradk (bradk@63.245.220.224)
  41. # [18:12] * Joins: szilles (chatzilla@63.245.220.224)
  42. # [18:13] * Joins: shan (qw3birc@128.30.52.28)
  43. # [18:16] * Joins: dbaron (dbaron@63.245.220.240)
  44. # [18:16] * Joins: sylvaing (sylvaing@63.245.220.224)
  45. # [18:18] <dbaron> Present: John Jansen, Tab Atkins, Peter Linss, Håkon Lie, John Daggett, Sylvain Galineau, Arron Eicholz, Elika Etemad, David Baron, Brad Kemper, Daniel Glazman, Bert Bos, Steve Zilles, ? (NTT AC Rep), Simon Fraser, Masayuki Ihara, Soonbo Han, Kazutaka Yamamoto, Koji Ishii, ? (NTT), Hiroyuki Ishii
  46. # [18:18] * Joins: TabAtkins_ (tabatkins@63.245.220.224)
  47. # [18:19] * Quits: lhnz (lhnz@188.223.83.48) (Quit: Leaving)
  48. # [18:19] <TabAtkins_> ScribeNick: TabAtkins_
  49. # [18:20] <TabAtkins_> Topic: Meeting Agenda
  50. # [18:20] <glazou> http://wiki.csswg.org/planning/mountain-view-2011
  51. # [18:20] * Joins: howcome (howcome@63.245.220.224)
  52. # [18:21] * Joins: kojiishi (kojiishi@222.158.227.129)
  53. # [18:21] * Joins: johnjan (qw3birc@128.30.52.28)
  54. # [18:22] <TabAtkins_> glazou: CSS 2.1 will take up the morning, I expect. What about the afternoon?
  55. # [18:22] <TabAtkins_> jdaggett: I'd like the Fonts discussion to happen tomorrow, for christopher slye.
  56. # [18:23] <TabAtkins_> dbaron: If Christopher could do wednesday we'd have an easier time, I believe.
  57. # [18:23] <TabAtkins_> jdaggett: Wednesday AM would be fine.
  58. # [18:26] * Joins: Kazutaka (yamamoto_k@63.245.220.224)
  59. # [18:26] <dbaron> Present: Arno Gourdol, John Jansen, Tab Atkins, Peter Linss, Håkon Lie, John Daggett, Sylvain Galineau, Arron Eicholz, Elika Etemad, David Baron, Brad Kemper, Daniel Glazman, Bert Bos, Steve Zilles, ? (NTT AC Rep), Simon Fraser, Masayuki Ihara, Soonbo Han, Kazutaka Yamamoto, Koji Ishii, ? (NTT), Hiroyuki Ishii
  60. # [18:26] * Quits: Kazutaka (yamamoto_k@63.245.220.224) (Connection reset by peer)
  61. # [18:26] <TabAtkins_> glazou: Writing Modes, when?
  62. # [18:26] <TabAtkins_> fantasai: Writing Modes should be fine today, also Text.
  63. # [18:27] <TabAtkins_> howcome: If we could do hyphenation early, would be great.
  64. # [18:27] * Joins: Kazutaka (yamamoto_k@63.245.220.224)
  65. # [18:27] <TabAtkins_> jdaggett: And we can do Text this afternoon, if necessary.
  66. # [18:30] <TabAtkins_> glazou: So, start with 2.1.
  67. # [18:31] * Quits: Kazutaka (yamamoto_k@63.245.220.224) (Connection reset by peer)
  68. # [18:31] <TabAtkins_> dbaron: I'll take a dinner count just before lunch.
  69. # [18:31] <TabAtkins_> Topic: 2.1 issues
  70. # [18:32] <TabAtkins_> johnjan: The new issues start at 224
  71. # [18:32] <szilles> I would strongly prefer to do text on Wednesday
  72. # [18:33] * Parts: howcome (howcome@63.245.220.224)
  73. # [18:33] <Bert> http://lists.w3.org/Archives/Member/w3c-css-wg/2011JanMar/0271.html
  74. # [18:33] * Joins: Kazutaka (yamamoto_k@63.245.220.224)
  75. # [18:34] <TabAtkins_> Bert: ??? [something about issue 153]
  76. # [18:35] <TabAtkins_> szilles: How does the height of the ascenders/descenders work?
  77. # [18:35] <TabAtkins_> Bert: Each glyph gets [something about leading]
  78. # [18:35] * Quits: johnjan (qw3birc@128.30.52.28) (Quit: Page closed)
  79. # [18:35] * Joins: howcome (howcome@63.245.220.224)
  80. # [18:36] <TabAtkins_> Bert: The height of the inline box is only based on its own glyphs, not its sub-elements. They each have their own inline box.
  81. # [18:36] <TabAtkins_> dbaron: The intent of what I proposed was taht the height o the ocntent area was based only on th eglyphs and not the descendants. If you are saying that explicitly, that's fine.
  82. # [18:36] <TabAtkins_> Bert: I couldn't say "content area", because 10.6 says it's undefined.
  83. # [18:36] <TabAtkins_> glazou: Accepted.
  84. # [18:37] <TabAtkins_> Bert: Next issue, 181.
  85. # [18:37] * Joins: stearns (c0961605@78.129.202.38)
  86. # [18:37] <TabAtkins_> Bert: This was an issue about heights in the line box. I needed to explain that it didn't refer to the content height nor the line box.
  87. # [18:37] <sylvaing> actually, tiny nitpick: one change specifies the inline box to be glyphs + half-leading; the other 'all glyphs and their leading'. I'd prefer saying half-leading both times ?
  88. # [18:37] * Joins: cameronmalek (cameronmal@71.10.107.219)
  89. # [18:37] <TabAtkins_> Bert: There was a reaction afterwards from Anton Prowse, but I think that's solved now by the previous issue.
  90. # [18:38] * Parts: cameronmalek (cameronmal@71.10.107.219)
  91. # [18:38] <Bert> http://www.w3.org/mid/201103041709.55059.bert@w3.org
  92. # [18:39] * Joins: mi (mi@63.245.220.224)
  93. # [18:39] <TabAtkins_> glazou: Accepted 181.
  94. # [18:40] <TabAtkins_> Bert: next issue is 204.
  95. # [18:40] <TabAtkins_> Bert: In 9.4.2 there is text about lineboxes formed from elements without content.
  96. # [18:41] <TabAtkins_> Bert: It says they're ignored for the purpose of finding adjacent margins. This wasn't mentioned in 8.3.1, so the action was to make that clear.
  97. # [18:41] <TabAtkins_> glazou: Accepted 204.
  98. # [18:42] <TabAtkins_> Bert: next is 213. We weren't clear if :first applied to the first page generated by a forced line break, or to the page after it. This makes that undefined.
  99. # [18:42] <TabAtkins_> glazou: Accepted 213.
  100. # [18:42] <TabAtkins_> Bert: 215 is about an inline with position:relative which is broken over two lines - what is its containing block?
  101. # [18:43] <TabAtkins_> Bert: We decided to make it undefined.
  102. # [18:43] <TabAtkins_> Bert: This makes the text in 10.1 much shorter.
  103. # [18:44] <TabAtkins_> fantasai: Does this apply to elements that have been split by bidi in a single line?
  104. # [18:44] <TabAtkins_> Bert: I'm not sure; the issue only talks about breaking over multiple lines.
  105. # [18:45] * Joins: lhnz (lhnz@188.223.83.48)
  106. # [18:45] <TabAtkins_> szilles: So if it's on the same line, it does define a box, if they're on different lines it's undefined?
  107. # [18:45] <TabAtkins_> fantasai: Yes.
  108. # [18:45] * Joins: johnjan (qw3birc@128.30.52.28)
  109. # [18:46] * Joins: shonda (shonda@63.245.220.224)
  110. # [18:46] <TabAtkins_> ACTION Bert to re-edit 215 to take into account bidi-reordered boxes on the same line.
  111. # [18:46] * trackbot noticed an ACTION. Trying to create it.
  112. # [18:46] <trackbot> Created ACTION-302 - Re-edit 215 to take into account bidi-reordered boxes on the same line. [on Bert Bos - due 2011-03-14].
  113. # [18:47] <fantasai> So the definition should say that the top left padding box corner of the leftmost box and the bottom right corner of the rightmost box define a rectangle which is the contianing block.
  114. # [18:47] <dbaron> Present: Arno Gourdol, John Jansen, Tab Atkins, Peter Linss, Håkon Lie, John Daggett, Sylvain Galineau, Arron Eicholz, Elika Etemad, David Baron, Brad Kemper, Daniel Glazman, Bert Bos, Steve Zilles, ? (NTT AC Rep), Simon Fraser, Edward O'Connor, Masayuki Ihara, Soonbo Han, Kazutaka Yamamoto, Koji Ishii, ? (NTT), Hiroyuki Ishii
  115. # [18:47] <fantasai> If the inline is split across multiple lines, it's undefined
  116. # [18:48] <TabAtkins_> Bert: For 218, I just need a review. I was removing all references to percentage intrinsic dimensions.
  117. # [18:49] <TabAtkins_> glazou: Accepted 218.
  118. # [18:49] * mi is now known as mihara
  119. # [18:49] <dbaron> Present: Arno Gourdol, John Jansen, Tab Atkins, Peter Linss, Håkon Lie, John Daggett, Alex Mogilevsky, Sylvain Galineau, Arron Eicholz, Elika Etemad, David Baron, Brad Kemper, Daniel Glazman, Bert Bos, Steve Zilles, ? (NTT AC Rep), Simon Fraser, Edward O'Connor, Masayuki Ihara, Soonbo Han, Kazutaka Yamamoto, Koji Ishii, ? (NTT), Hiroyuki Ishii
  120. # [18:49] <TabAtkins_> Bert: For 228, we missed that width and height calcs were subject to min/max calculations in one place.
  121. # [18:50] <TabAtkins_> Bert: So I added a note saying that the width may have to be calculated multiple times to satisfy min/max width/height.
  122. # [18:50] <TabAtkins_> glazou: Accepted 228.
  123. # [18:50] <TabAtkins_> Bert: And for 121, an explanation of why line-height works the way it does.
  124. # [18:51] <TabAtkins_> Bert: If you have the same font throughout, you get a constant line-height. I changed the "generally" line to a more explicit note.
  125. # [18:51] <Kazutaka> Toru Kobayashi (NTT AC Rep) , Shinkuro Honda (NTT)
  126. # [18:51] * fantasai suggests using (and there are no atomic inlines) to shorten
  127. # [18:51] <dbaron> Present: Arno Gourdol, John Jansen, Tab Atkins, Peter Linss, Håkon Lie, John Daggett, Alex Mogilevsky, Sylvain Galineau, Arron Eicholz, Elika Etemad, David Baron, Brad Kemper, Daniel Glazman, Bert Bos, Steve Zilles, Toru Kobayashi (NTT AC Rep), Simon Fraser, Edward O'Connor, Masayuki Ihara, Soonbo Han, Kazutaka Yamamoto, Koji Ishii, Shinkuro Honda (NTT), Hiroyuki Ishii
  128. # [18:52] <fantasai> ACTION fantasai: Check the rest of Bert's edits
  129. # [18:52] * trackbot noticed an ACTION. Trying to create it.
  130. # [18:52] <trackbot> Created ACTION-303 - Check the rest of Bert's edits [on Elika Etemad - due 2011-03-14].
  131. # [18:53] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-224
  132. # [18:53] <TabAtkins_> fantasai: Issue 224 should be straightforward.
  133. # [18:55] * Joins: Martijnc (Martijnc@91.176.79.35)
  134. # [18:56] <TabAtkins_> TabAtkins_: fantasai, your edit misses the "ratio but no width or height" case.
  135. # [18:57] * Quits: lhnz (lhnz@188.223.83.48) (Quit: Leaving)
  136. # [18:57] <TabAtkins_> TabAtkins_: My edits are now consistent with the image-sizing rules elsewhere, and match Opera and IE9, and would match Webkit if used 1em instead of some weird value.
  137. # [18:57] <TabAtkins_> RESOlVED: Accept Tab's proposal for issue 224.
  138. # [18:57] <TabAtkins_> glazou: Next is 225.
  139. # [18:58] <TabAtkins_> fantasai: 225 needs someone to analyze it and propose some text.
  140. # [18:58] * Joins: alexmog (qw3birc@128.30.52.28)
  141. # [19:01] <TabAtkins_> glazou: Now on issue 229.
  142. # [19:03] <dbaron> ACTION dbaron Write a proposal for http://wiki.csswg.org/spec/css2.1#issue-229
  143. # [19:03] * trackbot noticed an ACTION. Trying to create it.
  144. # [19:03] <trackbot> Created ACTION-304 - Write a proposal for http://wiki.csswg.org/spec/css2.1#issue-229 [on David Baron - due 2011-03-14].
  145. # [19:03] * Joins: lhnz (lhnz@188.223.83.48)
  146. # [19:04] <TabAtkins_> fantasai: Second issue 229, for some reason, about numbering in list items.
  147. # [19:04] <fantasai> no, that's 230
  148. # [19:04] <fantasai> RESOLVED: Proposal accepted for 230
  149. # [19:04] <TabAtkins_> RESOLVED: Make precise numbering of list items undefined in 2.1 (it's defined in 3)
  150. # [19:06] <TabAtkins_> RESOLVED: Accept proposal for issue 231.
  151. # [19:07] <TabAtkins_> fantasai: Sometimes ::markers have to be siblings, so they'll have the desired behavior in overflow:scroll
  152. # [19:07] <TabAtkins_> glazou: Now, issue 232.
  153. # [19:08] <TabAtkins_> dbaron: This is editorial, but it may result in non-editorial changes to text-decoration which relies on the undefined term "in-flow".
  154. # [19:10] <fantasai> see issue 236
  155. # [19:12] <TabAtkins_> fantasai: I think the best idea for the unresolved issues is to break into groups of 3, all take a single issue and work on it, while I go off and file the remaning issues.
  156. # [19:12] <TabAtkins_> glazou: Won't work.
  157. # [19:13] <TabAtkins_> fantasai: For 236, which relates to 232, the definition of "in-flow" I was using was "not out-of-flow".
  158. # [19:14] <TabAtkins_> fantasai: We have interop between IE9 and Opera for spreading the underline down.
  159. # [19:14] <johnjan> I think we should approach this like this: what does it take to get done today, not Wednesday. And do our best to achieve that goal.
  160. # [19:14] <TabAtkins_> fantasai: dbaron brought up a problem with <u> <table/> </u>
  161. # [19:16] <TabAtkins_> dbaron: The HTML5 parsing algorithm surrounding parsing of <table> in an inline has the consequence of forcing you to not spread underlines. In particular, if you pass underlines through to <table>, everything in Ebay becomes underlined.
  162. # [19:17] <dbaron> Present: Arno Gourdol, John Jansen, Tab Atkins, Peter Linss, Håkon Lie, John Daggett, Alex Mogilevsky, Sylvain Galineau, Arron Eicholz, Elika Etemad, David Baron, Brad Kemper, Tantek Çelik, Daniel Glazman, Bert Bos, Steve Zilles, Toru Kobayashi (NTT AC Rep), Simon Fraser, Edward O'Connor, Masayuki Ihara, Soonbo Han, Kazutaka Yamamoto, Koji Ishii, Shinkuro Honda (NTT), Hiroyuki Ishii
  163. # [19:18] <TabAtkins_> dbaron: Do we want the same behavior as blocks, or as inline-tables and inline-blocks?
  164. # [19:18] <TabAtkins_> fantasai: What about flexbox?
  165. # [19:18] <TabAtkins_> arronei: If you had one in a <del>, you'd want the strike-through to go through it.
  166. # [19:19] <TabAtkins_> arronei: How about for 236, we say the text-decoration propogation for <table>s is undefined.
  167. # [19:20] <TabAtkins_> arronei: We can disable underlines in CSS3, so we can just fix the UA stylesheet at that point. For now, CSS 2.1 can punt.
  168. # [19:21] <fantasai> ua.css: u table { text-decoration: no-underline; }
  169. # [19:22] <TabAtkins_> RESOLVED: 236 makes the behavior of underlines through tables undefined.
  170. # [19:23] <TabAtkins_> fantasai: So, back to 232, I say we should just make "in-flow" be "not out-of-flow".
  171. # [19:24] <fantasai> RESOLVED: 232 Make in-flow mean not out-of-flow, check that spec remains correct.
  172. # [19:24] <fantasai> action to Bert is to edit and review for correctness
  173. # [19:24] * trackbot noticed an ACTION. Trying to create it.
  174. # [19:24] <trackbot> Sorry, couldn't find user - to
  175. # [19:26] <TabAtkins_> Action Bert to edit 232 and review for correctness.
  176. # [19:26] * trackbot noticed an ACTION. Trying to create it.
  177. # [19:26] <trackbot> Created ACTION-305 - Edit 232 and review for correctness. [on Bert Bos - due 2011-03-14].
  178. # [19:27] <TabAtkins_> dbaron: Next issue, 233. I thought we decided on this years ago, so I'm not sure why we want to change it now.
  179. # [19:27] <dbaron> s/decided on this/all fixed this bug/
  180. # [19:29] <TabAtkins_> fantasai: I just thought the behavior was really weird - if you have a 4em table-cell and the screen is 40em, and you say text-indent:10%;, you get an indent of 4em, not .4em.
  181. # [19:29] <TabAtkins_> fantasai: If it's interop, though, whatever.
  182. # [19:29] <TabAtkins_> RESOLVED: No change for issue 233.
  183. # [19:30] <TabAtkins_> glazou: Issue 234 - margin-collapsing and min-height.
  184. # [19:31] <TabAtkins_> fantasai: There are 2 impls that do one thing, and 2 impls that do something else.
  185. # [19:31] <TabAtkins_> <br dur=10m>
  186. # [19:49] <TabAtkins_> glazou: Back to issue 234.
  187. # [19:49] <TabAtkins_> arronei: For 234's testcase, we have interop between IE, Opera, and Webkit. FF is the only one that does something different.
  188. # [19:49] <TabAtkins_> glazou: So we have 3 passes?
  189. # [19:50] <TabAtkins_> arronei: Not sure what the pass condition is, but we have interop.
  190. # [19:50] <TabAtkins_> dbaron: A problem is that, if we change the spec, do we get an infinite loop? With margin-collapsing and clearance that's possible.
  191. # [19:52] <TabAtkins_> glazou: So if we change the spec and test, we may have 3 passes.
  192. # [19:52] <TabAtkins_> arronei: Maybe. And maybe we'll hit an infinite loop.
  193. # [19:52] <fantasai> while (marginCollapsing in spec) { RewriteSpec(); }
  194. # [19:53] <TabAtkins_> dbaron: What's the spec change that would make the spec match what the other 3 browsers do?
  195. # [19:53] * Joins: Ms2ger (Ms2ger@91.181.106.89)
  196. # [19:55] <TabAtkins_> dbaron: 8.3.1 says an elements' own margins are adjoining if ...
  197. # [19:55] <TabAtkins_> dbaron: The important clause is "if the min-height property is 0".
  198. # [19:57] * Quits: Ms2ger (Ms2ger@91.181.106.89) (Ping timeout)
  199. # [20:00] <TabAtkins_> [looking at a testcase]
  200. # [20:00] <dbaron> The bottom margin of an in-flow block box with a 'height' of 'auto' is adjoining to its last in-flow block-level child's bottom margin if the element has no bottom padding or border.
  201. # [20:00] <dbaron> has no conditions on min-height
  202. # [20:02] * Joins: hyatt (hyatt@98.200.13.42)
  203. # [20:03] <dbaron> ACTION dbaron reply to Alan's message w.r.t http://wiki.csswg.org/spec/css2.1#issue-234 http://lists.w3.org/Archives/Public/www-style/2010Sep/0649.html that (a) this testcase is exercising "The bottom margin of an in-flow block box with..." and therefore all browsers other than Gecko are correct and (b) add a test to the CSS 2.1 test suite for post-PR.
  204. # [20:03] * trackbot noticed an ACTION. Trying to create it.
  205. # [20:03] <trackbot> Created ACTION-306 - Reply to Alan's message w.r.t http://wiki.csswg.org/spec/css2.1#issue-234 http://lists.w3.org/Archives/Public/www-style/2010Sep/0649.html that (a) this testcase is exercising "The bottom margin of an in-flow block box with..." and therefore all browsers other than Gecko are correct and (b) add a test to the CSS 2.1 test suite for post-PR. [on David Baron - due 2011-03-14].
  206. # [20:03] <TabAtkins_> glazou: Issue 235 now.
  207. # [20:04] <dbaron> http://lists.w3.org/Archives/Public/www-style/2010Sep/0728.html
  208. # [20:06] <TabAtkins_> glazou: Editorial.
  209. # [20:06] <TabAtkins_> glazou: issue 239.
  210. # [20:06] <TabAtkins_> fantasai: I say no.
  211. # [20:07] <TabAtkins_> dbaron: I think that HTML has a lot of history of authors putting <html dir> rather than <body dir>.
  212. # [20:07] <TabAtkins_> dbaron: Hyatt says that IE does the <body> propagation, and so he did it for Webkit.
  213. # [20:10] * Quits: Kazutaka (yamamoto_k@63.245.220.224) (Client exited)
  214. # [20:10] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%3E%0A%3Cbody%20dir%3D%22rtl%22%20style%3D%22width%3A%20200px%3B%20border%3A%20thin%20solid%20green%22%3Etext%3C%2Fbody%3E
  215. # [20:11] <TabAtkins_> arronei: IE propagates.
  216. # [20:12] <Arron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%20style%3D%22width%3A%20500px%3B%20border%3A%20solid%20green%3B%22%3E%0A%3Cbody%20style%3D%22width%3A%20250px%3B%20border%3A%20solid%20blue%3Bheight%3A%2050px%3Bdirection%3A%20rtl%3B%22%3E%0A%3C%2Fbody%3E%0A%3C%2Fhtml%3E
  217. # [20:12] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%20style%3D%22border%3A%20thin%20solid%20blue%22%3E%0A%3Cbody%20style%3D%22direction%3A%20rtl%3B%20width%3A%20400px%3B%20border%3A%20thin%20solid%20green%22%3Etext%0A%3Cdiv%20style%3D%22direction%3A%20ltr%3B%20border%3A%20thin%20solid%20fuchsia%3B%20width%3A%20200px%22%3Etext%3C%2Fdiv%3E%0A%3C%2Fbody%3E
  218. # [20:14] * Joins: Ms2ger (Ms2ger@91.181.106.89)
  219. # [20:14] <TabAtkins_> dbaron: I'd rather not have propagation.
  220. # [20:14] <Bert> rrsagent, pointer?
  221. # [20:14] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  222. # [20:14] <RRSAgent> logging to http://www.w3.org/2011/03/07-css-irc
  223. # [20:15] <TabAtkins_> RESOLVED: Do not propagate direction from <body> to <html>.
  224. # [20:15] <hyatt> that will be a compatibility issue
  225. # [20:15] <hyatt> i guess we'll do it in quirks mode. sigh.
  226. # [20:15] <TabAtkins_> johnjan: We're willing to take the behavior as a bug.
  227. # [20:16] <TabAtkins_> dbaron: For issue 240, I thought we already said that min/max-width was undefined.
  228. # [20:16] <TabAtkins_> RESOLVED: For issue 240, min/max-width on internal table elements is undefined.
  229. # [20:20] <TabAtkins_> alexmog: A problem - if you set overflow and direction on <body>, you get bad behavior.
  230. # [20:21] <TabAtkins_> alexmog: Can we say the same thing as overflow?
  231. # [20:21] <TabAtkins_> dbaron: That's weird because if you have <html dir=ltr><body dir=rtl>, the rtl will propagate to <html> invisibly.
  232. # [20:21] <dbaron> (alternative is just saying to use the value from body... though that's really not particularly different.)
  233. # [20:24] <hyatt> TabAtkins_: in webkit body direction only propagates to html direction if html doesnt' set it
  234. # [20:24] <hyatt> TabAtkins_: (similar to background propagation)
  235. # [20:25] <dbaron> hyatt, what does "doesn't set it" mean?
  236. # [20:25] <dbaron> hyatt, background propagation does it based on whether background-image is none
  237. # [20:25] <dbaron> hyatt, does it mean whether direction is ltr?
  238. # [20:25] * Quits: mihara (mi@63.245.220.224) (Ping timeout)
  239. # [20:25] <hyatt> dbaron: we actually detect if any CSS rule sets direction to any value
  240. # [20:25] <hyatt> on the HTML
  241. # [20:26] <dbaron> We've never had anything like that in the spec
  242. # [20:26] <hyatt> actually maybe we don't do that
  243. # [20:26] <dbaron> we shouldn't cross the value computation line
  244. # [20:26] <hyatt> let me double check
  245. # [20:26] <dbaron> compute values -> do something with the computed values
  246. # [20:26] * Joins: mihara (mihara@63.245.220.224)
  247. # [20:26] <hyatt> yeah that is what we do
  248. # [20:26] <hyatt> we set a flag if direction is ever set on the html
  249. # [20:27] <dbaron> is that what IE also does?
  250. # [20:27] <hyatt> i cant' remember if i arrived at that because it's what IE did
  251. # [20:27] <hyatt> i discussed it in the bug at the time let me try to find
  252. # [20:27] <TabAtkins_> dbaron: If we propagate, we have to decide how to propagate,and what Hyatt's describing for Webkit's behavior is pretty weird.
  253. # [20:28] <hyatt> not that weird. to an author, the concept of setting the direction explicitly via a rule is a simple one
  254. # [20:28] <hyatt> it's just weird since we have never done it before
  255. # [20:29] <johnjan> entire room is easily distracted by ropes flailing outside the window...
  256. # [20:29] <hyatt> the simpler option might be to just ignore the html whne body sets it
  257. # [20:30] <hyatt> i.e., just always propagate body
  258. # [20:30] <dbaron> which I think is fine since direction's inherited anyway
  259. # [20:30] <hyatt> i think that is what ie does
  260. # [20:30] <dbaron> I'd prefer that
  261. # [20:31] <hyatt> https://bugs.webkit.org/show_bug.cgi?id=48157
  262. # [20:31] <fantasai> why are FF and Opera getting away with not doing this, if it's a web compat issue?
  263. # [20:32] <hyatt> looks like my main reasoning for not ignoring the html was just:
  264. # [20:32] <hyatt> "This is in direct violation of CSS2.1 is the problem. It states that the direction on the root element should be propagated to the initial containing block. I don't think it makes sense to actually overwrite the direction specified on the <html> if it is there just because the <body> specified something different.
  265. # [20:32] <hyatt> "
  266. # [20:32] <hyatt> so if the spec told me it was ok i'd have matched WinIE :)
  267. # [20:32] <hyatt> i was just concerned about ignoring the value on the html
  268. # [20:32] <hyatt> since that sounded like violating the spec language
  269. # [20:33] <hyatt> so o
  270. # [20:33] <hyatt> i'm fine with making body just overwrite html
  271. # [20:33] <hyatt> would just need the spec to say so
  272. # [20:35] <fantasai> well, CSS2.1 assigns a 'direction' value to HTML whether one's set explicitly or not
  273. # [20:35] <fantasai> so you're violating the spec either way
  274. # [20:35] <fantasai> by doing this at all
  275. # [20:35] <alexmog> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20HTML%3E%0A%3Chtml%20style%3D%22direction%3Altr%3Boverflow%3Ascroll%22%3E%0A%3Cbody%20style%3D%22border%3A10px%20solid%20silver%3B%20width%3A100px%3B%20%20direction%3Artl%3B%22%3Exxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  276. # [20:35] <fantasai> I don't see anything in the bug explaining *why* you're doing this, though; there's nothing in the bug that says what the problem is with just following the spec instead of trying to copy IE
  277. # [20:36] <hyatt> it's broken out from another bug
  278. # [20:36] <hyatt> let me keep digging
  279. # [20:37] <hyatt> vaguely remember some dhtml menu on israeli sites not positioning properly
  280. # [20:37] <hyatt> used right: but didn't get computed correctly because the icb wasn't properly rtl or something
  281. # [20:38] <fantasai> dbaron: We use the direction of body to determine the scrolling direction of the viewport
  282. # [20:38] <fantasai> dbaron: But we don't actually propagate the 'direction' property
  283. # [20:38] <TabAtkins_> dbaron: So when Gecko determines the scrollbars for root, we use the direction for <body>, but we don't do any other propagation. So it's really the scrollbars for the ICB.
  284. # [20:38] <dbaron> s/scrollbars for the root/scrollbars for the ICB/
  285. # [20:39] <TabAtkins_> dbaron: We don't want a "propagated if not specified" in CSS.
  286. # [20:40] <TabAtkins_> glazou: Let's move on. We're not making immediate progress.
  287. # [20:40] <dbaron> issue 241: http://lists.w3.org/Archives/Public/www-style/2010Nov/0035.html
  288. # [20:41] <dbaron> I'd by happy to just make the change Øyvind suggests
  289. # [20:41] <dbaron> (change the spec)
  290. # [20:42] * Joins: Kazutaka (yamamoto_k@63.245.220.224)
  291. # [20:42] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22left%3A%20100px%22%3E%3Cdiv%20style%3D%22position%3A%20relative%3B%20left%3A%20inherit%3B%20background%3A%20lime%22%3EIs%20this%20indented%3F%3C%2Fdiv%3E
  292. # [20:43] <dbaron> is a simple testcase
  293. # [20:43] <TabAtkins_> RESOLVED: Accept the spec change for 241.
  294. # [20:43] <TabAtkins_> glazou: Now issue 242.
  295. # [20:45] <TabAtkins_> dbaron: I think we just need to action for a proposal.
  296. # [20:47] <TabAtkins_> dbaron: I don't think anything has to be undefined here. We do need to make the change for consecutive block boxes.
  297. # [20:48] <fantasai> might be able to handle white space interaction in the phantom line boxes clause
  298. # [20:50] <dbaron> http://wiki.csswg.org/spec/css2.1#issue-142
  299. # [20:50] <TabAtkins_> johnjan: There are some issues, starting with 142, that need an action for Bert edit.
  300. # [20:54] <TabAtkins_> dbaron: As far as I can tell fro mreading the spec, the containing block for a child of a table cell, is the block that contains the table, which seems like a bug.
  301. # [20:55] <TabAtkins_> dbaron: Boris's comments is asking for whether the table should be the containing block. It seems to me that the table-cell should be the containing block, even if it's anonymous.
  302. # [20:55] <TabAtkins_> fantasai: I think the table cell should be a containing block for the inner table cell box.
  303. # [20:56] <TabAtkins_> dbaron: Is "inner table cell box" even in the spec yet?
  304. # [20:56] <TabAtkins_> fantasai: I don't think so.
  305. # [20:56] <dbaron> s/for the inner table cell box/for the boxes inside the cell/
  306. # [20:57] <TabAtkins_> dbaron: What Boris is talking about is what the containing block is for an inner table element, like table-row.
  307. # [20:59] <TabAtkins_> Bert: I think the table-cell is fine; I believe the question was only about anonymous table-cells.
  308. # [21:00] * Quits: bradk (bradk@63.245.220.224) (Quit: Computer has gone to sleep)
  309. # [21:00] * Quits: glazou (glazou@63.245.220.224) (Quit: glazou)
  310. # [21:00] <TabAtkins_> <br type=lunch duration=1h>
  311. # [21:02] * Parts: stearns (c0961605@78.129.202.38)
  312. # [21:02] * Quits: plinss_ (plinss@63.245.220.224) (Quit: plinss_)
  313. # [21:03] * Quits: shonda (shonda@63.245.220.224) (Ping timeout)
  314. # [21:04] * Quits: TabAtkins_ (tabatkins@63.245.220.224) (Ping timeout)
  315. # [21:09] * Quits: mihara (mihara@63.245.220.224) (Client exited)
  316. # [21:23] * Joins: TabAtkins_ (tabatkins@63.245.220.224)
  317. # [21:27] * Quits: sylvaing (sylvaing@63.245.220.224) (Ping timeout)
  318. # [21:29] * Joins: sylvaing (sylvaing@63.245.220.224)
  319. # [21:34] * Joins: bradk (bradk@63.245.220.224)
  320. # [21:36] * Joins: glazou (glazou@63.245.220.224)
  321. # [21:41] * Joins: W3C-CSS (arno@192.150.10.200)
  322. # [21:42] * Quits: W3C-CSS (arno@192.150.10.200) (Quit: Leaving.)
  323. # [21:42] * Joins: davve` (davve@83.218.67.122)
  324. # [21:42] * Joins: arno (arno@192.150.10.200)
  325. # [21:42] * Parts: davve` (davve@83.218.67.122) (Killed buffer)
  326. # [21:45] * Joins: plinss_ (plinss@63.245.220.224)
  327. # [21:45] * Quits: Martijnc (Martijnc@91.176.79.35) (Quit: Martijnc)
  328. # [21:47] * Parts: arno (arno@192.150.10.200)
  329. # [21:47] * Joins: arno (arno@192.150.10.200)
  330. # [21:51] * Joins: stearns (c0961605@78.129.202.38)
  331. # [22:00] <fantasai> sylvaing: Can you answer http://lists.w3.org/Archives/Public/www-style/2010Nov/0435.html ? :-)
  332. # [22:01] * Joins: shonda (shonda@63.245.220.224)
  333. # [22:06] <Bert> Scribe: Bert
  334. # [22:06] <Bert> Scribenick: Bert
  335. # [22:06] <dbaron> To remind myself...we have 22 people for dinner at http://www.vasoazzurro.com/ tonight at 7pm.
  336. # [22:06] <Bert> Topic: CSS 2.1 issues (continued)
  337. # [22:07] <Bert> Topic: Issue 142 http://wiki.csswg.org/spec/css2.1#issue-142
  338. # [22:09] <Bert> -> http://lists.w3.org/Archives/Public/www-style/2011Mar/0022.html Bert's proposal
  339. # [22:11] <Bert> DB: So it seems we have a proposal. Somebody needs to respond to Boris.
  340. # [22:11] <dbaron> sounds like we concluded that followup 2 was ok since anonymous boxes can be containing blocks since we define containing blocks in terms of boxes
  341. # [22:12] <Bert> Bert: Is that not what my proposed text does?
  342. # [22:13] <Bert> DB: Needs to be explained better.
  343. # [22:15] <Bert> PL: So we are still stuck on this issue?
  344. # [22:15] <Bert> DB: [reading the texts]
  345. # [22:16] <Bert> ... In 2c, rule is skipping anonymous boxes.
  346. # [22:16] <Bert> ... That may skip the table cell.
  347. # [22:17] <Bert> -> http://lists.w3.org/Archives/Public/www-style/2011Mar/0023.html Boris' last reply
  348. # [22:18] <Bert> JJ: It seems Boris essentially agrees, with maybe clarification.
  349. # [22:19] * Joins: mihara (mihara@63.245.220.224)
  350. # [22:19] <Bert> DB: I think anonymous boxes should not be skipped.
  351. # [22:19] <Bert> BB: They should be, except for anonymous table cells.
  352. # [22:19] <Bert> EE: They aren't all skipped.
  353. # [22:20] <dbaron> And I think this makes the definition of containing block deviate from the definition of the box tree.
  354. # [22:20] <Bert> PL: Are there functional changes? Or only editorial?
  355. # [22:20] * Joins: mi (mi@63.245.220.224)
  356. # [22:20] <Bert> EE: We should have only one possible interpretation of the spec.
  357. # [22:21] <Bert> PL: If there is no test in the suite that shows the difference, then let's defer this.
  358. # [22:21] <Bert> RESOLVED: no change, pusj to errata
  359. # [22:21] * Quits: mihara (mihara@63.245.220.224) (Client exited)
  360. # [22:21] <Bert> Topic: issue 192
  361. # [22:22] <Bert> TA: What happens to content that precedes the float in the source.
  362. # [22:22] * mi is now known as mihara
  363. # [22:23] <Bert> ... Implementations never move such content down.
  364. # [22:23] <Bert> ... Instead, they move the float down.
  365. # [22:23] <Bert> DB: That is what the spec says should happen.
  366. # [22:23] <Bert> ... Float constraint include that top of float must not be above prior content.
  367. # [22:24] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-192
  368. # [22:24] <Bert> ... So float *has* to be pushed down.
  369. # [22:24] <Bert> ... That is not stated explicitly, only as implicit result of the constraints.
  370. # [22:24] <Bert> TA: OK, so that everything is fine.
  371. # [22:24] <Bert> DB: Might be wordt a note in the spec.
  372. # [22:25] <Bert> -> http://lists.w3.org/Archives/Public/www-style/2011Mar/0064.html Bert's msg on 192
  373. # [22:25] <Bert> PL: WHo is writing that note?
  374. # [22:26] <Bert> TA: I could
  375. # [22:26] <Bert> DB: I could, too.
  376. # [22:26] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-199
  377. # [22:27] <Bert> ACTION dbaron: write such a note for issue 192.
  378. # [22:27] * trackbot noticed an ACTION. Trying to create it.
  379. # [22:27] * RRSAgent records action 1
  380. # [22:27] <trackbot> Created ACTION-307 - Write such a note for issue 192. [on David Baron - due 2011-03-14].
  381. # [22:27] <Bert> Topic: issue 199
  382. # [22:27] <Bert> -> http://wiki.csswg.org/spec/css2.1#issue-199 Issue 199
  383. # [22:28] <Bert> -> http://lists.w3.org/Archives/Public/www-style/2010Oct/0707.html Tab's proposal
  384. # [22:28] <Bert> TA: I think I didn not test vertical and horizontal margins seperately
  385. # [22:29] <Bert> DB: That may make a difference.
  386. # [22:30] <Bert> DB: "The auto position" is a bit vague. Needs to be defined.
  387. # [22:30] <Bert> PL: Any tests for this?
  388. # [22:31] <Bert> JJ: Leave text as TAb proposed, with edit for "static" and then add tests after PR.
  389. # [22:31] <Bert> RESOLVED: as JJ just said.
  390. # [22:31] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-204
  391. # [22:32] <Bert> Topic: Issue 204
  392. # [22:32] <Bert> EE: Bert sent an e-mail, which is not yet in this list.
  393. # [22:33] <Bert> ... Probably wherever it says "Bert edit" we don't have to discuss now.
  394. # [22:33] <Bert> Topic: Issue 207
  395. # [22:33] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-207
  396. # [22:33] <Bert> -> http://wiki.csswg.org/spec/css2.1#issue-207 Issue 207
  397. # [22:36] <Bert> DB: What do implementtions do?
  398. # [22:37] <Bert> AE: Impls are interoperable.
  399. # [22:38] <Bert> DB: ... Is the same as margin collapse clear test case.
  400. # [22:38] <dbaron> s/DB:/AE:/
  401. # [22:38] <Bert> JJ: Spec remains underdefined.
  402. # [22:39] <Bert> ... Is there an edit to do, or an errata later?
  403. # [22:40] <Bert> PL: Any proposals?
  404. # [22:40] <fantasai> ACTION fantasai find margin-collapse-clear-005 issue and make sure it's in the issues list for editing
  405. # [22:40] * trackbot noticed an ACTION. Trying to create it.
  406. # [22:40] <trackbot> Created ACTION-308 - Find margin-collapse-clear-005 issue and make sure it's in the issues list for editing [on Elika Etemad - due 2011-03-14].
  407. # [22:43] <Bert> [People trying to understand...]
  408. # [22:45] <Bert> DB: Defer to errata?
  409. # [22:46] <Bert> AE: Seems possible, yes.
  410. # [22:46] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-208
  411. # [22:46] <Bert> RESOLVED: no action on 207
  412. # [22:46] <Bert> Topic: issue 208
  413. # [22:48] <dbaron> 11.1.1: "In the case of a scrollbar being placed on an edge of the element's box, it should be inserted between the inner border edge and the outer padding edge. Any space taken up by the scrollbars should be taken out of (subtracted from the dimensions of) the containing block formed by the element with the scrollbars. "
  414. # [22:49] <Bert> DB: So it doesn't say that the width is changed.
  415. # [22:50] <Bert> ... Reason may the case when 'width' is not 'auto'.
  416. # [22:50] <Bert> AE: You don't want to make the box bigger when you add scrollbars.
  417. # [22:51] <Bert> ... So the content box width has to shrink.
  418. # [22:51] <Bert> DB: But the value of 'width' odesn't change, and is thus different from the content box.
  419. # [22:52] <dbaron> s/odesn't/doesn't/
  420. # [22:52] <Bert> DB: Is this different for 'height'?
  421. # [22:53] <Bert> ... Assume the block has 'height: auto'
  422. # [22:53] <Bert> ... Does the vertical scrollbar make the box taller?
  423. # [22:54] * Quits: Kazutaka (yamamoto_k@63.245.220.224) (Quit: CHOCOA)
  424. # [22:56] <Bert> PL: No tests for this I think? Should we skip the issue?
  425. # [22:57] <Bert> AE: No need to change the spec, it seems.
  426. # [22:57] <Bert> PL: Scrolling has always been a UA-dependent thing.
  427. # [22:57] <Bert> EE: Still in scope for CSS, thought maybe not for CSS 2.1.
  428. # [22:58] <Bert> AE: Define some tests later and write it into CSS then.
  429. # [22:58] <Bert> RESOLVED: no action on 207
  430. # [22:58] <smfr> http://wiki.csswg.org/spec/css2.1#issue-219
  431. # [22:58] <Bert> Topic: issue 219
  432. # [22:59] <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Feb/0669.html
  433. # [23:00] <Bert> [EE proposed text]
  434. # [23:00] <Bert> RESOLVED: EE's text accepted.
  435. # [23:01] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-244
  436. # [23:01] <Bert> Topic: issue 244
  437. # [23:02] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
  438. # [23:02] <Bert> Topic: Issue 245
  439. # [23:02] <Bert> JJ: No change needed.
  440. # [23:03] <Bert> EE: Could do in in level 3.
  441. # [23:03] <Bert> RESOLVED: no changes for issues 245
  442. # [23:03] <Bert> Topic: issue 244
  443. # [23:06] <Bert> DB: depends on defining rendering tree.
  444. # [23:07] <johnjan> we are not going to be able to define rendering tree in CSS21
  445. # [23:08] <Bert> EE: should we still add that it depends on rendering tree, even if the rendering tree is undefined?
  446. # [23:08] <dbaron> http://www.w3.org/TR/CSS21/about.html#organization is quite out of date
  447. # [23:08] <Bert> RESOLVED: no chnage for 244
  448. # [23:08] <Bert> s/chnage/change/
  449. # [23:08] <dbaron> (but we agree that it *is* the rendering tree)
  450. # [23:08] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-211
  451. # [23:09] <Bert> Topic: Issue 211
  452. # [23:09] <Bert> DB: Before margin collapsing text was reorganzized, there was a contradiction.
  453. # [23:10] <Bert> ... We had rules "A collapses with B" and "C does not collapse with D" and we assumed rules were transitive.
  454. # [23:10] <Bert> ... We should only define what *does* collapse.
  455. # [23:11] <Bert> EE: New text indeed moved in that direction.
  456. # [23:11] <Bert> DB: We had a case with element with bottom and top collapsing together and the bottom collapsing with parent bottom, or not.
  457. # [23:12] <Bert> ... It was possible that top and bottom were forbidden from collapsing, but both collapsed with the same other margins, so should collapse because of transitivity.
  458. # [23:13] <Bert> AE: You have a proposal?
  459. # [23:13] <Bert> DB: My proposal might be against an old version of the spec.
  460. # [23:14] <dbaron> bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height
  461. # [23:14] <dbaron> bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height and '0' computed 'min-height'
  462. # [23:14] <Bert> ... Change in bullet 3.3 in 2nd list of 8.3.1.
  463. # [23:15] <Bert> ... Because the 4th bullet mentions zero 'min-height' and the 3rd doesn't.
  464. # [23:16] <Bert> AE: Issue 225 is not related..
  465. # [23:17] <fantasai> 234
  466. # [23:17] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-234
  467. # [23:17] <fantasai> is related
  468. # [23:18] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%23one%20%7B%20min-height%3A%202px%20%7D%0A%23one%2C%20%23two%20%7B%20margin-bottom%3A%201em%20%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%20id%3D%22one%22%3E%3Cdiv%20id%3D%22two%22%3EHello%3C%2Fdiv%3E%3C%2Fdiv%3E%0AWorld%0A
  469. # [23:18] <Bert> DB: This morning we discussed 234. Ignore Gecko for that, because it has a bug.
  470. # [23:19] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A.one%2C%20.three%20%7B%20min-height%3A%202px%20%7D%0A.one%2C%20.two%20%7B%20margin-bottom%3A%201em%20%7D%0A.three%20%7B%20margin%3A%201em%200%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%20class%3D%22one%22%3E%3Cdiv%20class%3D%22two%22%3EHello%3C%2Fdiv%3E%3C%2Fdiv%3E%0AWorld%0A%0AHello%0A%3Cdiv%20class%3D%22three%22%3E%3C%2Fdiv%3E%0AWorld
  471. # [23:20] <Bert> JJ: Seem FF does it the same as everybody else, though.
  472. # [23:22] <Bert> DB: So whether 'min-height' stops collapsing depends on whether it's own bottom and top margins collapse.
  473. # [23:22] <Bert> ... That test case is wrong.
  474. # [23:23] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%23one%20{%20min-height%3A%202px%20}%0A%23one%2C%20%23two%20{%20margin-bottom%3A%201em%20}%0A%3C%2Fstyle%3E%0A%3Cdiv%20id%3D%22one%22%3E%3Cdiv%20id%3D%22two%22%3EHello%3C%2Fdiv%3E%3C%2Fdiv%3E%0AWorld%0A
  475. # [23:23] <Bert> ... Say you have an elt with a 'min-height'. It's margins don't collpse. Now add an empty child. Now it's margins do collapse.
  476. # [23:23] <Bert> s/it's/its/
  477. # [23:24] <Bert> s/it's/its/
  478. # [23:24] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A.one%2C%20.three%20%7B%20min-height%3A%202px%20%7D%0A.one%2C%20.two%20%7B%20margin-bottom%3A%201em%20%7D%0A.three%20%7B%20margin%3A%201em%200%7D%0A%3C%2Fstyle%3E%0AHello%0A%3Cdiv%20class%3D%22one%22%3E%3Cdiv%20class%3D%22two%22%3E%3C%2Fdiv%3E%3C%2Fdiv%3E%0AWorld%0A%0AHello%0A%3Cdiv%20class%3D%22three%22%3E%3C%2Fdiv%3E%0AWorld
  479. # [23:25] <Bert> s/collpse/collapse/
  480. # [23:26] <dbaron> current spec says that last testcase should have a 1em gap and then a 2em gap
  481. # [23:27] <Bert> EE: Should 3rd bullet check whether min-height has an effect, or whether it is set?
  482. # [23:27] <Bert> DB: The latter, otherwise infinite loop is possible.
  483. # [23:28] <Bert> ... Gecko still does the former, but has an explicit loop detector.
  484. # [23:28] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A.one%2C%20.three%20%7B%20min-height%3A%202px%20%7D%0A.one%2C%20.two%20%7B%20margin-bottom%3A%201em%20%7D%0A.three%20%7B%20margin%3A%201em%200%7D%0A%3C%2Fstyle%3E%0AShould%20have%20a%201em%20gap%3A%3Cbr%3E%0AHello%0A%3Cdiv%20class%3D%22one%22%3E%3Cdiv%20class%3D%22two%22%3E%3C%2Fdiv%3E%3C%2Fdiv%3E%0AWorld%0A%3Chr%3E%0AShould%20have%20a%201em%20gap%3A%0A%3Cdiv%20class%3D
  485. # [23:28] <dbaron> %22one%22%3E%3Cdiv%20class%3D%22two%22%3EHello%3C%2Fdiv%3E%3C%2Fdiv%3E%0AWorld%0A%3Chr%3E%0AShould%20have%20a%202em%20gap%3A%0AHello%0A%3Cdiv%20class%3D%22three%22%3E%3C%2Fdiv%3E%0AWorld
  486. # [23:29] * Joins: dsinger (dsinger@17.72.145.154)
  487. # [23:29] <fantasai> That brings me to a brilliant suggestion. How about a "min-height: contains-floats" keyword, so we can get rid of all this clearfix junk?
  488. # [23:31] <Bert> RESOLVED: no change for issue 211
  489. # [23:31] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-247
  490. # [23:31] <Bert> Topic: issue 247
  491. # [23:35] <dbaron> 9.2.1.1: "When such an inline box is affected by relative positioning, the relative positioning also affects the block-level box contained in the inline box. "
  492. # [23:37] <Bert> DB: The test cas ein the e-mail isn't right. There is a third answer, which he didn't consider.
  493. # [23:37] <dbaron> I think the test in http://lists.w3.org/Archives/Public/www-style/2010Nov/0444.html is only considering 2 possible answers when there are really three
  494. # [23:37] <Bert> s/cas ein/case in/
  495. # [23:38] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%3E%0A%3Chead%3E%0A%3Ctitle%3ETest%20of%20position%3Aabsolute%20containing%20block%20when%20closest%20element%20differs%20from%20closest%20box%3C%2Ftitle%3E%0A%3C%2Fhead%3E%0A%3Cbody%3E%0A%3Cdiv%20style%3D%22margin%3A%200%20100px%22%3E%0A%3Cp%3EHere%20is%20a%20paragraph%20containing%20a%20%3Cspan%20style%3D%22position%3Arelative%3B%22%3Eposition%3Arelative%20span%20that%20is%
  496. # [23:38] <dbaron> 20split%20by%20a%20%3Cspan%20style%3D%22display%3Ablock%22%3Eblock-level%20element%20that%20contains%20a%20%3Cspan%20style%3D%22left%3A0%3B%20position%3Aabsolute%3B%20background-color%3Acyan%3B%22%3Eposition%3Aabsolute%20span%3C%2Fspan%3E%20...%20%3Cbr%20%2F%3E%20in%20the%20middle%20of%20it%3C%2Fspan%3E%20before%20this%20remainder%20of%20the%20position%3Arelative%20span%3C%2Fspan%3E%20and%20the%20rest%20of%20the%20paragraph.%3C%2Fp%3E%0A%3C%2Fdiv%3E%0A%3C%2Fbo
  497. # [23:38] <dbaron> dy%3E%0A%3C%2Fhtml%3E
  498. # [23:40] <dbaron> http://dbaron.org/css/test/2011/css21-issue-247
  499. # [23:41] <Bert> BB: Is this different from issue 215 from this morning?
  500. # [23:41] <Bert> DB: Issue is that relative pos "affects" the block inside, but not specified how.
  501. # [23:42] <Bert> ... Nobody does the behavior that I would have liked for that test case.
  502. # [23:43] <Bert> PL: So we should make it nunefined?
  503. # [23:43] <Bert> DB: Maybe we already did...
  504. # [23:44] <johnjan> Remain undefined in 2.1. Need to verify that this remains undefined after today's other edits.
  505. # [23:44] <Bert> EE: ... The other edits make inside inline undefined. Is that inside the box tree or the element tree?
  506. # [23:45] <dbaron> ACTION dbaron verify that once issue 215 is edited, that the case for issue 247 is also undefined
  507. # [23:45] * trackbot noticed an ACTION. Trying to create it.
  508. # [23:45] <trackbot> Created ACTION-309 - Verify that once issue 215 is edited, that the case for issue 247 is also undefined [on David Baron - due 2011-03-14].
  509. # [23:46] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-248
  510. # [23:46] <Bert> Topic: issue 248
  511. # [23:46] <Bert> s/nunefined/undefined/
  512. # [23:47] * Quits: anne (annevk@83.85.115.123) (Quit: anne)
  513. # [23:48] <dbaron> http://lists.w3.org/Archives/Public/www-style/2010Dec/0020.html
  514. # [23:48] <fantasai> Brad: It would make more sense from a web author's perspective for the relposed <span> to establish the containing block for any abspos elements inside it, even if they're inside a block that's inside the <span>.
  515. # [23:50] <Bert> DB: Interesting case is a zero-height float followed by a 1px high float and the latter is wider.
  516. # [23:51] <Bert> ... Zero-height float can only shorten line box if they have been pushed donw to fall in the middle of a line box.
  517. # [23:51] <Bert> s/donw/down/
  518. # [23:52] <Bert> ... Hard to find whether this is implemented correctly, because of other bugs.
  519. # [23:54] <Bert> ... There should be test cases in the test suite already.
  520. # [23:54] <Bert> ... Maybe the float-wrap-top set.
  521. # [23:54] * Joins: homata_ (homata_@58.158.182.50)
  522. # [23:57] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%3E%0A%20%20%3Cdiv%20style%3D%22float%3A%20left%3B%20width%3A%2050px%3B%20height%3A%206px%3B%20background%3Ayellow%22%3E%3C%2Fdiv%3E%0A%20%20%3Cdiv%20style%3D%22float%3A%20left%3B%20clear%3A%20left%3B%20width%3A%20100px%3B%20height%3A%200px%3B%20background%3Ared%22%3E%3C%2Fdiv%3E%0A%20%20%3Cdiv%3EHello%20world%3C%2Fdiv%3E%0A%3C%2Fdiv%3E
  523. # [23:57] <Bert> DB: IE seems to do the zero-height float correctly.
  524. # [23:58] <Bert> ... But probably the only browser to do so.
  525. # [23:58] * Quits: dsinger (dsinger@17.72.145.154) (Ping timeout)
  526. # [23:58] <Bert> ... There probably is no issue. But may need more tests to add later.
  527. # [23:59] <Bert> RESOLVED: No change for issue 248
  528. # [23:59] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-250
  529. # Session Close: Tue Mar 08 00:00:00 2011

The end :)