/irc-logs / w3c / #css / 2010-03-29 / end

Options:

  1. # Session Start: Mon Mar 29 00:00:00 2010
  2. # Session Ident: #css
  3. # [01:19] * Quits: arronei (arronei@131.107.0.73) (Ping timeout)
  4. # [01:25] * Joins: arronei (arronei@131.107.0.94)
  5. # [01:29] * Joins: anne (annevk@76.253.3.102)
  6. # [01:31] * Quits: anne (annevk@76.253.3.102) (Connection reset by peer)
  7. # [01:32] * Joins: anne (annevk@76.253.3.102)
  8. # [04:42] * Quits: Curt` (DorkeyDear@76.243.205.159) (Quit: Leaving)
  9. # [04:46] * Quits: paul_irish (paul_irish@71.192.163.128) (Quit: Leaving...)
  10. # [04:50] * Joins: paul_irish (paul_irish@71.192.163.128)
  11. # [07:00] * Quits: anne (annevk@76.253.3.102) (Ping timeout)
  12. # [07:07] * Quits: TabAtkins (chatzilla@76.253.3.102) (Ping timeout)
  13. # [07:30] * Joins: TabAtkins (chatzilla@76.253.3.102)
  14. # [08:04] * Quits: TabAtkins (chatzilla@76.253.3.102) (Ping timeout)
  15. # [08:57] * Quits: dydz (dydz@75.37.27.246) (Quit: dydz)
  16. # [09:10] * Joins: dydz (dydz@75.37.27.246)
  17. # [10:23] * Joins: lstorset (lstorset@213.236.208.22)
  18. # [10:28] * Parts: lstorset (lstorset@213.236.208.22)
  19. # [10:35] * Joins: Lachy (Lachlan@83.170.95.133)
  20. # [10:54] * Quits: Lachy (Lachlan@83.170.95.133) (Quit: This computer has gone to sleep)
  21. # [11:41] * Joins: Lachy (Lachlan@64.208.192.130)
  22. # [11:41] * Joins: Lachy_ (Lachlan@83.170.95.133)
  23. # [11:44] * Quits: Lachy (Lachlan@64.208.192.130) (Ping timeout)
  24. # [11:51] * Quits: Lachy_ (Lachlan@83.170.95.133) (Quit: This computer has gone to sleep)
  25. # [12:34] * Joins: Lachy (Lachlan@64.208.192.130)
  26. # [12:35] * Quits: Lachy (Lachlan@64.208.192.130) (Quit: Leaving)
  27. # [13:41] * Joins: lstorset (lstorset@213.236.208.22)
  28. # [14:00] * Parts: lstorset (lstorset@213.236.208.22)
  29. # [16:27] * Joins: lstorset (lstorset@213.236.208.22)
  30. # [16:28] * Parts: lstorset (lstorset@213.236.208.22)
  31. # [16:52] * Joins: TabAtkins (chatzilla@76.253.3.102)
  32. # [17:04] * Quits: TabAtkins (chatzilla@76.253.3.102) (Ping timeout)
  33. # [17:07] * Joins: TabAtkins (chatzilla@76.253.3.102)
  34. # [17:37] * Quits: TabAtkins (chatzilla@76.253.3.102) (Ping timeout)
  35. # [17:46] * Joins: dbaron (dbaron@17.244.2.46)
  36. # [18:06] * Joins: plinss__ (plinss@17.244.3.217)
  37. # [18:09] * Joins: anne (annevk@17.244.3.72)
  38. # [18:12] * Joins: sylvaing (sylvaing@17.244.0.225)
  39. # [18:14] * Joins: dethbakin (dethbakin@17.244.1.225)
  40. # [18:14] * Joins: TabAtkins (chatzilla@17.244.2.48)
  41. # [18:15] * Quits: dbaron (dbaron@17.244.2.46) (Ping timeout)
  42. # [18:15] * Joins: ChrisL (ChrisL@128.30.52.169)
  43. # [18:15] * Joins: smfr (smfr@17.244.1.194)
  44. # [18:23] * Joins: css_projector (css_projec@17.201.14.208)
  45. # [18:23] <smfr> test
  46. # [18:25] <anne> win
  47. # [18:25] * Joins: dbaron (dbaron@63.245.220.11)
  48. # [18:26] * Joins: glazou (glazou@17.244.0.83)
  49. # [18:26] * dbaron wonders if css_projector has interesting highlight settings
  50. # [18:26] * TabAtkins doesn't get to show off his color scheme again. ;_;
  51. # [18:27] <TabAtkins> ScribeNick: TabAtkins
  52. # [18:28] <TabAtkins> plinss: Anyone with new topics?
  53. # [18:28] <sylvaing> http://wiki.csswg.org/planning/cupertino-2010
  54. # [18:28] * Joins: Arron (arronei@17.244.2.216)
  55. # [18:29] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
  56. # [18:30] <TabAtkins> plinss: k, no new topics.
  57. # [18:30] <TabAtkins> plinss: First topic, TPAC. Need to set our dates.
  58. # [18:30] <TabAtkins> ChrisL: Request for monday/tuesday?
  59. # [18:30] * Joins: dbaron (dbaron@63.245.220.11)
  60. # [18:31] <TabAtkins> glazou: Yes, from szilles and others. Want to make sure everyone is available for nov 1 and 2.
  61. # [18:31] * anne wonders what's going on in that other room
  62. # [18:31] * TabAtkins other room?
  63. # [18:32] * fantasai html5 political discussions, I think
  64. # [18:32] <TabAtkins> glazou: Two hotels around the venue, Hilton and something else.
  65. # [18:32] <TabAtkins> glazou: Early rates, roughly 110 euros/night.
  66. # [18:32] <TabAtkins> glazou: Cheaper in the center of Lyons, but it's further away, and no easy connection via public transport.
  67. # [18:33] <TabAtkins> glazou: Unless there's a strong objection to monday/tuesday, we should let the w3c know.
  68. # [18:33] <TabAtkins> RESOLVED: CSSWG meeting is on November 1 and 2.
  69. # [18:34] <TabAtkins> glazou: We also need to discuss at some point the dates/location of first meeting in 2011.
  70. # [18:34] <TabAtkins> glazou: Who's willing to host in 2011?
  71. # [18:35] <TabAtkins> dbaron: There's a bunch of us who could host in the Bay Area.
  72. # [18:35] <TabAtkins> glazou: Probably fair to host in Bay Area after 2 meetings in Europe.
  73. # [18:35] <TabAtkins> dbaron: I'd be happy to host. (Mozilla)
  74. # [18:36] <TabAtkins> howcome: Seems to be too early to set up dates yet.
  75. # [18:37] <TabAtkins> glazou: Anytime in March is good. No good in February.
  76. # [18:37] <TabAtkins> dbaron: MIT spring break is march 21-26, and thus probably the AC meeting.
  77. # [18:38] <TabAtkins> glazou: So, if we meet on the last week of March, or 2nd or 3rd week, it would be better.
  78. # [18:38] <dbaron> Easter 2011 is April 24
  79. # [18:38] <TabAtkins> glazou: Let's stick with the idea of a March meeting hosted by Mozilla, and move on for now.
  80. # [18:39] <TabAtkins> TOPIC: CSS 2.1 issues
  81. # [18:40] <TabAtkins> List of attendees: Dean, Simon, Anne, Steve, Beth, Sylvain, Alex, Chris, Bert, Arron, Elika, dbaron, Brad, Tab, Daniel, Peter, Hakon.
  82. # [18:40] <plinss__> http://wiki.csswg.org/spec/css2.1
  83. # [18:40] * Joins: howcome (howcome@17.244.0.146)
  84. # [18:41] * Joins: dino (dino@17.244.0.219)
  85. # [18:41] <dbaron> Present: Dean Jackson, Simon Fraser, Anne van Kesteren, Steve Zilles, Beth Dakin, Sylvain Galineau, Alex Mogilevsky, Chris Lilley, Bert Bos, Aaron Eicholtz, Elika Etemad, David Baron, Brad Kemper, Tab Atkins, Daniel Glazman, Peter Linss, Håkon Lie
  86. # [18:43] <TabAtkins> fantasai: Start with issue 60.
  87. # [18:43] <plinss__> http://wiki.csswg.org/spec/css2.1#issue-60
  88. # [18:43] * Joins: szilles (chatzilla@17.244.0.143)
  89. # [18:43] <TabAtkins> sylvaing: Issue 60 is from Anton Prouse and issues about z-index and stacking.
  90. # [18:43] <TabAtkins> sylvaing: There is no interop issues, it's mostly just cleanup and making sure that different parts of the spec agree.
  91. # [18:43] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-60
  92. # [18:44] <TabAtkins> sylvaing: I suggested minimal changes, and he accepted most of them, there's just a few things left. I think we can get it closed in a few days.
  93. # [18:44] <TabAtkins> sylvaing: Mostly it's just terminology and a few other things that are confusing.
  94. # [18:44] <TabAtkins> sylvaing: Like intermixing "stacking order" and "painting order" and such.
  95. # [18:44] <TabAtkins> sylvaing: So, mostly editorial. We'll try to close it.
  96. # [18:45] <TabAtkins> sylvaing: In 9.9.1, there are a few errors, but browsers follow Appendix E, which is the important one.
  97. # [18:45] * Joins: alexmog (alexmog@17.244.1.2)
  98. # [18:45] * glazou notes last time the CSS WG gathered 17 people in same room was long ago...
  99. # [18:47] <TabAtkins> howcome: Seems like it's more than editorial, like #4 there.
  100. # [18:48] <TabAtkins> sylvaing: Yeah, #4 was the one actual error where 9.9.1 is out of sync with appendix E, but browsers do the right thing there.
  101. # [18:48] * Joins: bradk (bradk@17.244.0.81)
  102. # [18:48] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
  103. # [18:48] <TabAtkins> szilles: My suggestion is that we reaffirm that Appendix E is the normative text.
  104. # [18:49] * Joins: dbaron (dbaron@63.245.220.11)
  105. # [18:49] <TabAtkins> howcome: Don't we already say that somewhere?
  106. # [18:49] <TabAtkins> szilles: I think we do, but it wouldn't hurt to affirm it as a Working Group.
  107. # [18:50] <TabAtkins> plinss: So we're agreed to accept Sylvain's changes?
  108. # [18:52] * Quits: TabAtkins (chatzilla@17.244.2.48) (Connection reset by peer)
  109. # [18:52] <fantasai> RESOLVED: Defer to Sylvain for resolution of Issue 60, Bert will verify when editing that the changes are only editorial.
  110. # [18:52] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-69
  111. # [18:53] * Joins: TabAtkins (chatzilla@17.244.2.48)
  112. # [18:54] * TabAtkins is back!
  113. # [18:54] <fantasai> In paged media where there is no viewport, a 'fixed' background is fixed with respect to the pa and is therefore replicated on every page."
  114. # [18:56] <fantasai> s/pa and/page box and/
  115. # [18:56] * Quits: dino (dino@17.244.0.219) (Quit: dino)
  116. # [18:57] * glazou dino leaves
  117. # [18:57] <TabAtkins> bradk: Should we mention something about box-decoration-break wrt fixed backgrounds?
  118. # [18:57] <TabAtkins> Arronei: Not in 2.1, but we'd have to in 3.
  119. # [18:58] <TabAtkins> szilles: What about bleeds?
  120. # [18:58] <TabAtkins> fantasai: Not addressed here. Backgrounds on the page box may bleed, but not on the document.
  121. # [18:58] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
  122. # [18:59] * Joins: dbaron (dbaron@63.245.220.11)
  123. # [18:59] <anne> I thought sending over 587 ought to work?
  124. # [18:59] <anne> meh
  125. # [18:59] <TabAtkins> howcome: There is a bleed property in gcpm.
  126. # [18:59] * TabAtkins anne, 587 doesn't work. dbaron decided that.
  127. # [18:59] <TabAtkins> RESOLVED: In paged media where there is no viewport, a 'fixed' background is fixed with respect to the pa and is therefore replicated on every page."
  128. # [19:00] <fantasai> page box
  129. # [19:00] <TabAtkins> plinss: Issue #111
  130. # [19:00] <TabAtkins> plinss: Font-weight bolder/lighter, synchronize with css3?
  131. # [19:00] <TabAtkins> fantasai: Did we want to do #71?
  132. # [19:00] <TabAtkins> Bert: I'm in the process of responding to that, but have email troubles.
  133. # [19:01] * Quits: sylvaing (sylvaing@17.244.0.225) (Quit: sylvaing)
  134. # [19:01] <TabAtkins> fantasai: issue 73, peter was supposed to write a note?
  135. # [19:01] * anne I thought that was the one that would work? what else is there?
  136. # [19:01] <TabAtkins> plinss: Not sure; it's been a while. I'll check.
  137. # [19:01] * anne oh well
  138. # [19:01] * TabAtkins anne, shrug.
  139. # [19:01] <fantasai> ACTION: Plinss find or write note for issue 73 by this afternono
  140. # [19:01] * trackbot noticed an ACTION. Trying to create it.
  141. # [19:01] <trackbot> Created ACTION-209 - Find or write note for issue 73 by this afternono [on Peter Linss - due 2010-04-05].
  142. # [19:01] <fantasai> s/nono/noon/
  143. # [19:03] <TabAtkins> fantasai: Issue 111?
  144. # [19:04] <TabAtkins> fantasai: Don't have a strong opinion on this.
  145. # [19:04] * glazou thinks he needs antibiotics...
  146. # [19:04] <TabAtkins> TabAtkins: So Daggett's suggestion was to make bolder/lighter act as if there were only four weights.
  147. # [19:04] <smfr> http://wiki.csswg.org/spec/css2.1#issue-111
  148. # [19:05] <TabAtkins> ChrisL: As long as you can get to the other weights someway.
  149. # [19:05] <TabAtkins> szilles: This isn't great, but it's less bad than others.
  150. # [19:05] <TabAtkins> Bert: This is the same text as in the Fonts module?
  151. # [19:05] <TabAtkins> szilles: Yes.
  152. # [19:05] <TabAtkins> Bert: I'm okay with that.
  153. # [19:05] * Joins: sylvaing (sylvaing@17.244.0.225)
  154. # [19:05] <TabAtkins> szilles: Obvious issue is, what do current browsers do with this?
  155. # [19:06] <TabAtkins> arronei: Currently, we test by having a list, and see if it's lighter or darker. Purely visual.
  156. # [19:06] <TabAtkins> szilles: Does the suggested algorithm keep this same behavior?
  157. # [19:06] <TabAtkins> Arronei: Should.
  158. # [19:07] <TabAtkins> RESOLVED: Accept Daggett's changed (from Fonts), back into CSS2.1.
  159. # [19:07] <TabAtkins> plinss: Related is issue 156.
  160. # [19:08] <TabAtkins> fantasai: ChrisL says "I'd prefer to see the mapping made normative."
  161. # [19:08] <TabAtkins> fantasai: Different mapping from issue 111.
  162. # [19:08] <fantasai> http://www.w3.org/TR/CSS21/fonts.html#font-boldness
  163. # [19:08] <fantasai> last bullet in the list
  164. # [19:08] <fantasai> "If there are fewer then 9 weights in the family"
  165. # [19:09] <TabAtkins> ChrisL: above that, it says "in typical cases", which makes it untestable.
  166. # [19:10] <TabAtkins> ChrisL: So, I'd like to drop that sentence.
  167. # [19:10] <TabAtkins> fantasai: OpenType fonts use a numerical scale, but they may not line up with multiples of 100.
  168. # [19:11] <TabAtkins> ChrisL: 4th bullet gives you a more precise description of that.
  169. # [19:11] <TabAtkins> ChrisL: I've seen things like a font with weights like 400 and 250, and that's fine. 200 and 300 aren't mapped explicitly.
  170. # [19:12] <TabAtkins> fantasai: You might actually want to map the 250 to 100.
  171. # [19:12] <TabAtkins> ChrisL: No, that'd expose more weights, but would put them in the wrong place. If you need precise mapping, just use @font-face.
  172. # [19:13] <TabAtkins> plinss: I think certain platforms made fonts map their weights wrong to get around bad heuristics.
  173. # [19:13] <TabAtkins> ChrisL: I haven't seen platform-specific weight tables like that.
  174. # [19:13] <TabAtkins> fantasai: I'm happy to make bullet 4 normative, but I'm less convinced about the other rules being normative.
  175. # [19:14] <TabAtkins> fantasai: I think mapping fonts to weights can be messy, and we shouldn't define that in css 2.1
  176. # [19:14] <TabAtkins> fantasai: But after the font has been mapped into the CSS font-weight scale, then we can follow the guidelines in bullet 4 to find missing weights.
  177. # [19:14] <TabAtkins> fantasai: That seems consistent.
  178. # [19:14] * Quits: sylvaing (sylvaing@17.244.0.225) (Quit: sylvaing)
  179. # [19:14] <TabAtkins> fantasai: The rules before that are about establishing the scale, and needs to be flexible to accomodate whatever twisted things we get into with fonts.
  180. # [19:15] * dbaron wonders if jdaggett should be around for this discussion
  181. # [19:15] <TabAtkins> fantasai: So the specific changes for this would be to pull bullet 4 out of the list and remove "typical".
  182. # [19:15] <fantasai> remove "default"
  183. # [19:16] <TabAtkins> s/typical/default/
  184. # [19:16] <fantasai> Chris: Replace "typical mappings" from the sentence below to "this mapping"
  185. # [19:16] <TabAtkins> RESOLVED: Pull bullet 4 of the font-weight mapping rules out into its own paragraph, tweak wording to imply exactness, not "typical" or "default".
  186. # [19:17] <TabAtkins> plinss: Next is issue 114.
  187. # [19:17] <TabAtkins> fantasai: let's defer until dbaron is back.
  188. # [19:17] <TabAtkins> plinss: Issue 115
  189. # [19:18] <TabAtkins> fantasai: Summary should be "Zero clearance should be distinguished from not having clearance".
  190. # [19:19] <TabAtkins> fantasai: There are some cases in which you have clearance, but it calculates to 0, and the spec isn't clear about distinguishing this from no clearance.
  191. # [19:19] <TabAtkins> fantasai: Some things happen when there isn't clearance (margin collapsing, frex).
  192. # [19:20] <TabAtkins> fantasai: So these other behaviors should still trigger when there is clearance, even if the value happens to compute to 0.
  193. # [19:20] <TabAtkins> alexmog: Any interop issues?
  194. # [19:21] <TabAtkins> plinss: Do we have testcases for current behavior?
  195. # [19:22] <TabAtkins> fantasai: I doubt we need any. It would require very unnatural code.
  196. # [19:22] <TabAtkins> fantasai: (to make 0 clearance act like no clearance)
  197. # [19:22] <TabAtkins> plinss: So do we have tests for clearance showing interop?
  198. # [19:22] <TabAtkins> fantasai: Sorta. Clearance is not the most interop portion of the spec.
  199. # [19:22] * Joins: dino (dino@17.244.86.57)
  200. # [19:23] <TabAtkins> arronei: According to test cases, we do have at least two browsers agreeing.
  201. # [19:24] <TabAtkins> alexmog: I'm not sure if the first change is just about this issue...
  202. # [19:24] <TabAtkins> fantasai: Check the second email, it overrides that.
  203. # [19:24] <TabAtkins> fantasai: We'd take everything *but* the first change from the first email, and then all the changes from the second email.
  204. # [19:24] * Joins: sylvaing (sylvaing@17.244.0.225)
  205. # [19:25] <TabAtkins> RESOLVED: Accept fantasai's proposals for issue 115.
  206. # [19:26] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-115
  207. # [19:27] <fantasai> all but the first change in http://lists.w3.org/Archives/Public/www-style/2009May/0186.html
  208. # [19:27] <fantasai> plus changes in http://lists.w3.org/Archives/Public/www-style/2009Aug/0394.html
  209. # [19:29] <TabAtkins> <br type=coffee>
  210. # [19:29] * Quits: bradk (bradk@17.244.0.81) (Quit: Computer has gone to sleep)
  211. # [19:30] * Joins: bradk (bradk@17.244.0.81)
  212. # [19:37] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
  213. # [19:37] * Joins: dbaron (dbaron@63.245.220.11)
  214. # [19:51] * Quits: szilles (chatzilla@17.244.0.143) (Ping timeout)
  215. # [19:52] * Quits: dino (dino@17.244.86.57) (Quit: dino)
  216. # [19:55] <fantasai> http://fantasai.inkedblade.net/style/specs/css2.1/zero-clearance
  217. # [19:56] * Joins: dino (dino@17.244.86.57)
  218. # [19:59] <TabAtkins> fantasai: issue 150
  219. # [19:59] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-115
  220. # [19:59] <TabAtkins> fantasai: If those changes look good we can close on it.
  221. # [19:59] <fantasai> http://fantasai.inkedblade.net/style/specs/css2.1/zero-clearance
  222. # [19:59] <fantasai> combined proposal
  223. # [19:59] <TabAtkins> s/issue 150/issue 115/
  224. # [20:00] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
  225. # [20:01] <TabAtkins> plinss: Bert sent an email for issue 71.
  226. # [20:02] <TabAtkins> Bert: We discussed this a year ago, and I looked at the minutes for that meeting.
  227. # [20:02] <TabAtkins> Bert: If you find at @-rule in the middle of a declaration block, the rule says to ignore the @-rule, but you *want* to ignore the whole block.
  228. # [20:02] <TabAtkins> Bert: I think the error is the rule for ignoring @ keywords is meant for the rules, not declarations.
  229. # [20:03] <TabAtkins> Bert: So I suggest to make that explicit.
  230. # [20:03] <fantasai> body {
  231. # [20:03] <fantasai> @foo {}
  232. # [20:03] <fantasai> background: green;
  233. # [20:03] <Bert> http://lists.w3.org/Archives/Public/www-style/2010Mar/0485.html
  234. # [20:03] <fantasai> }
  235. # [20:03] <fantasai> Does that handle this?
  236. # [20:03] <TabAtkins> fantasai: We wanted the rule to stop ignoring at the close brace.
  237. # [20:03] <TabAtkins> plinss: Is that what we want?
  238. # [20:04] <TabAtkins> plinss: In paged media, we have @page which can be mixed with other @ blocks.
  239. # [20:04] <TabAtkins> fantasai: Right; right now the rules say the background should *not* be green - they say we should ignore until the semicolon.
  240. # [20:04] <TabAtkins> plinss: So you want the background:green to apply.
  241. # [20:04] <TabAtkins> fantasai: Right.
  242. # [20:05] <TabAtkins> Bert: My proposal is to do what CSS 2.1 says. I thought that's what we decided last year.
  243. # [20:05] <TabAtkins> Bert: Which would mean we ignore up to the semicolon, so there would be no green.
  244. # [20:05] <TabAtkins> plinss: Any @ keyword followed by a block or a semicolon should be ignored up to the next block or semicolon; we don't need to go farther.
  245. # [20:05] <TabAtkins> howcome: Is that what browsers do today?
  246. # [20:05] <TabAtkins> Bert: Yes.
  247. # [20:06] <fantasai> body { color: @foo {} background: red; }
  248. # [20:06] <TabAtkins> plinss: So existing browsers would ignore the background:green?
  249. # [20:06] <fantasai> body { @foo {} background: green; }
  250. # [20:07] <TabAtkins> glazou: Right, that should be ignored up to the semicolon, since it's inside the value of color.
  251. # [20:07] <TabAtkins> glazou: But we didn't discuss @ rules inside @ rules.
  252. # [20:07] <TabAtkins> fantasai: That's what issue 71 is about.
  253. # [20:07] <fantasai> body { color @foo {}: red; }
  254. # [20:08] <TabAtkins> fantasai: After you start a declaration, as soon as you see a property, the @ rules become invalid tokens.
  255. # [20:08] * Quits: dino (dino@17.244.86.57) (Quit: dino)
  256. # [20:08] <TabAtkins> anne: In CSSOM, they always have to come at the end or the start.
  257. # [20:09] <fantasai> Bert: I thought we resolved in css3-page that the @rules come after the declarations
  258. # [20:09] <TabAtkins> plinss: We have the problem of the existing behavior.
  259. # [20:09] <TabAtkins> bradk: But changing existing behavior won't break any pages.
  260. # [20:10] <TabAtkins> howcome: What's the value of fixing this in 2.1?
  261. # [20:10] <TabAtkins> plinss: Compatibility with CSS3?
  262. # [20:11] <TabAtkins> anne: We need to know the parsing rules.
  263. # [20:11] <TabAtkins> howcome: If we decide it now, we could put it in css3.
  264. # [20:11] <TabAtkins> glazou: We have only one parser. It will be the same in 2 or 3.
  265. # [20:11] <TabAtkins> dbaron: The forward-compatible rules should be the same in all levels and should not change.
  266. # [20:11] <TabAtkins> howcome: I can probably live with fixing it.
  267. # [20:12] <TabAtkins> Bert: But if you start with / or something, it would not be green.
  268. # [20:12] <TabAtkins> glazou: But @ is an acceptable token inside a rule. A / is not.
  269. # [20:12] <TabAtkins> glazou: @page is a declaration block.
  270. # [20:12] <TabAtkins> plinss: It's something new, a mixed declaration and @ block.
  271. # [20:13] <TabAtkins> anne: Bert is right.
  272. # [20:13] <TabAtkins> anne: Declaration blocks don't currently have the notion of an @ block.
  273. # [20:13] <TabAtkins> Bert: I don't understand why we want to keep the @page construct, because that's where the error is.
  274. # [20:13] <TabAtkins> fantasai: @page is deployed.
  275. # [20:13] <TabAtkins> Bert: So is this.
  276. # [20:13] <TabAtkins> fantasai: @page is deployed *and used*. This error isn't used.
  277. # [20:14] * Joins: dbaron (dbaron@17.244.2.46)
  278. # [20:14] <TabAtkins> fantasai: There are multiple impls. HP, Canon, Prince?
  279. # [20:14] <TabAtkins> fantasai: Antennae House and Epson.
  280. # [20:15] <TabAtkins> anne: Question is, do we want to change the parsing to allow @ blocks inside of declaration blocks in the future?
  281. # [20:15] <TabAtkins> howcome: We can do cool stuff with it, and we can create nightmares.
  282. # [20:16] <TabAtkins> ChrisL: I'd like to see named stylesets, bundles of properties applied at once.
  283. # [20:17] <TabAtkins> howcome: You want to represent these structures in the object model?
  284. # [20:17] <TabAtkins> anne: Yes. [explanation of @page stuff]
  285. # [20:17] <TabAtkins> howcome: That's a special fix for @page. We're talking about generic things.
  286. # [20:17] <TabAtkins> anne: Yeah, if it was generic, we'd want a generic structure that @page could inherit from.
  287. # [20:17] * Quits: dbaron (dbaron@17.244.2.46) (Ping timeout)
  288. # [20:17] * Joins: dbaron (dbaron@17.244.2.46)
  289. # [20:17] * Quits: dbaron (dbaron@17.244.2.46) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  290. # [20:17] * Joins: dbaron (dbaron@63.245.220.11)
  291. # [20:18] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  292. # [20:18] <RRSAgent> logging to http://www.w3.org/2010/03/29-CSS-irc
  293. # [20:18] * dbaron RRSAgent, make logs public
  294. # [20:18] * RRSAgent I have made the request, dbaron
  295. # [20:18] <TabAtkins> anne: We have the problem for @page, for what goes inside of @page, that we need to solve one way or another. We can make it special or we can make it generic.
  296. # [20:18] <ChrisL> rrsagent, this meeting spans midnight
  297. # [20:18] <RRSAgent> ok, ChrisL; I will not start a new log at midnight
  298. # [20:19] <TabAtkins> Bert: I proposed some time ago to create a 3rd type of block that would allow @page.
  299. # [20:19] <dbaron> Present: Dean Jackson, Simon Fraser, Anne van Kesteren, Steve Zilles, Beth Dakin, Sylvain Galineau, Alex Mogilevsky, Chris Lilley, Bert Bos, Aaron Eicholtz, Elika Etemad, David Baron, Brad Kemper, Tab Atkins, Daniel Glazman, Peter Linss, Håkon Lie, David Singer
  300. # [20:19] <TabAtkins> Bert: But I think people wouldn't want that.
  301. # [20:19] <dbaron> (that was the list of who was present earlier; Dean Jackson and David Singer are not currently present)
  302. # [20:20] <TabAtkins> anne: That wouldn't solve the earlier problem, the background wouldn't be green.
  303. # [20:20] <TabAtkins> Bert: Right, but it would let you do what @page wants.
  304. # [20:20] <TabAtkins> plinss: I'd prefer to see, if we see an @ rule, we parse it as a block, throw it away as invalid, and don't trash more than that.
  305. # [20:21] <TabAtkins> Bert: But that's inconsistent. Any other unknown token would throw away until the next semicolon.
  306. # [20:21] <TabAtkins> szilles: @ already has the role of being special.
  307. # [20:22] <TabAtkins> glazou: I think we agree that if an @ occurs inside a value isn't an @ rule.
  308. # [20:22] <TabAtkins> glazou: Frex, if the first token inside the brace is an @ token, we'd like it to be an @ rule.
  309. # [20:22] <TabAtkins> Bert: If that's a change, we can't do it.
  310. # [20:22] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
  311. # [20:22] <TabAtkins> glazou: It's something new that wouldn't break anything.
  312. # [20:22] * Joins: dbaron (dbaron@63.245.220.11)
  313. # [20:22] <TabAtkins> Bert: It's in the spec.
  314. # [20:23] <TabAtkins> howcome: This is a change in the eternal grammar.
  315. # [20:23] <TabAtkins> anne: It doesn't change valid stylesheets. I think it's fine.
  316. # [20:23] <TabAtkins> Bert: We have the error-recovery rules for consistency; you're changing the rules, so you're losing consistency.
  317. # [20:24] <TabAtkins> glazou: We are fighting about extensibility all the time.
  318. # [20:24] <TabAtkins> Bert: Things like adding to a shorthand is different, it fits in the grammar.
  319. # [20:25] <TabAtkins> Bert: Show me a place in CSS3 that is incompatible with the forward-compatible rules.
  320. # [20:25] <TabAtkins> plinss: @page
  321. # [20:25] <TabAtkins> ChrisL: @page is interoperably implemented. I don't see the benefit of changing it; we should allow it, and use the extension point it allows to do new things.
  322. # [20:26] <TabAtkins> howcome: This is a change in the eternal grammar, but we don't really have a great use-case.
  323. # [20:26] <TabAtkins> howcome: A green background isn't a good use-case.
  324. # [20:26] <TabAtkins> howcome: It's interoperable today, I'm not sure we should change it.
  325. # [20:27] <TabAtkins> howcome: We're suggesting this change to get a generic extension mechanism.
  326. # [20:27] <TabAtkins> plinss: We have @page, which allows intermingling of @ rules in a declaration block.
  327. # [20:27] <TabAtkins> plinss: If it's *only* valid here, with special rules and special error recovery, that's very surprising.
  328. # [20:27] <TabAtkins> howcome: Do we allow @page at the place where we're talking about?
  329. # [20:28] <alexmog> adding a semicolon to the use case makes it green, interoparably: body { @foo {}; background: green; }
  330. # [20:28] <TabAtkins> plinss: No, not right now. But @page acts like a declaration block, and allows more @ rules in it.
  331. # [20:28] <TabAtkins> glazou: [gives an example showing @page]
  332. # [20:28] <fantasai> plinss: If error-recovery from @foo inside @page's declaration block is different from in other declaration blocks, that's very surprising
  333. # [20:29] <TabAtkins> glazou: In @page, if you see another @page{}, it parses to that } and throws it away, allowing the next rules to work.
  334. # [20:29] * Joins: szilles (chatzilla@17.244.0.143)
  335. # [20:29] <TabAtkins> glazou: But if you have @page{ @foo {} background: green; }, the background is thrown away. That's very surprising.
  336. # [20:30] <TabAtkins> plinss: The problem is that an unknown @ rule at one point in the stylesheet, it parses to the }. If you put it at another spot, and it doesn't parse to the }, that's weird.
  337. # [20:31] <TabAtkins> dbaron: We already have that in some places. If an @rule appears in a value, or in a selector, it just makes an invalid value or selector.
  338. # [20:31] <dbaron> ... never mind what I said
  339. # [20:31] <TabAtkins> szilles: What anne just pointed out, if we have a single recovery mechanism, CSSOM can have a generic recovery mechanism.
  340. # [20:32] <TabAtkins> glazou: Non-generic means one parsing impl for @page, and another for other @ rules.
  341. # [20:32] <fantasai> We have different parsing of @keywords in different parts of the style sheet with or without the change we're proposing.
  342. # [20:32] <TabAtkins> glazou: That's ugly.
  343. # [20:32] <fantasai> For example, @keyword inside a declaration is still ignored as an invalid token
  344. # [20:32] <fantasai> However, having different parsing rules within a declaration block
  345. # [20:32] <fantasai> depending on whether the declaraiton block is inside @page or elsewhere,
  346. # [20:32] <fantasai> that is confusing
  347. # [20:32] <TabAtkins> alexmog: I'm agreeing with what Bert is saying. I'm not seeing use-cases, but we have interop against it.
  348. # [20:32] <fantasai> and it is a burden on implementors to implement two different types of error-recovery
  349. # [20:33] <anne> advantages: 1) consistent rules for authors 2) one code path for implementors
  350. # [20:33] <TabAtkins> alexmog: We'll have syntax that is ignored in older browsers but paid attention to in newer browsers.
  351. # [20:33] <TabAtkins> alexmog: We can just add a semicolon to the end of the @block and all browsers ignore it. It's not the prettiest, but it achieves the goal.
  352. # [20:34] <TabAtkins> anne: Advantages is consistent rules for authors, and implementors.
  353. # [20:34] <TabAtkins> alexmog: How much time until browsers have changed sufficiently to allow it?
  354. # [20:35] <TabAtkins> TabAtkins: No more time than it would take for any new @ rule to be usable.
  355. # [20:35] <TabAtkins> plinss: He has a good point. If we introduce a new @ rule, then authors using it will have their next declaration swallowed in older browsers.
  356. # [20:35] <TabAtkins> anne: But can't it sometimes be a start of a selector then?
  357. # [20:35] <TabAtkins> fantasai: No.
  358. # [20:36] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
  359. # [20:36] <TabAtkins> anne: If you recommend putting a semicolon after every @ rule, it is the start of a selector, and you don't get a green background.
  360. # [20:37] <TabAtkins> anne: IE "@foo {}; body { background: green; }" kills the body block.
  361. # [20:37] <TabAtkins> Bert: Oh, no, not ; after everything.
  362. # [20:37] * Quits: alexmog (alexmog@17.244.1.2) (Ping timeout)
  363. # [20:37] * Joins: alexmog (alexmog@17.244.1.2)
  364. # [20:37] <TabAtkins> anne: I think we can just recommend that authors put the @ blocks at the end of the declaration block.
  365. # [20:38] <TabAtkins> plinss: I think it will be really confusing if you would recommend putting ; at the end of @ blocks inside a declaration block, but not at the end of ones outside a declaration block.
  366. # [20:38] * fantasai has no opinion
  367. # [20:38] <TabAtkins> Bert: I think we made a mistake on @page, not in the grammar.
  368. # [20:39] <TabAtkins> plinss: I think we made a mistake in the grammar, instead.
  369. # [20:39] <TabAtkins> fantasai: I think you can't stick an @ rule without braces is invalid inside a declaration block in the core grammar.
  370. # [20:40] <TabAtkins> fantasai: We have some options. We could do nothing, which means no @ rules inside declaration blocks ever.
  371. # [20:40] <TabAtkins> fantasai: And then just have Paged Media declare that @ rules have to be at the end.
  372. # [20:40] <TabAtkins> plinss: The problem is that the longer we put it out, the more entrenched we'll get.
  373. # [20:40] <TabAtkins> Bert: Not expensive? It's been in the spec for years!
  374. # [20:41] <TabAtkins> anne: What kind of implementations are you thinking of?
  375. # [20:41] <TabAtkins> Bert: TVs, etc.
  376. # [20:41] <TabAtkins> glazou: They're all consistent right now, though, so nobody uses it anyway. It can't even be used as a browser selector.
  377. # [20:42] <TabAtkins> plinss: The problem isn't that it's an error now, but in a few years when we have a spec that uses @ rules in that area.
  378. # [20:42] <TabAtkins> anne: In a few years we'll have an upgraded set of browsers.
  379. # [20:43] <TabAtkins> szilles: So older browsers will throw it away, so nothing weird. Anne observes that if you put them at the end, it will prevent any rules from being dropped.
  380. # [20:43] <TabAtkins> Bert: So let's just put them at the end.
  381. # [20:43] <TabAtkins> fantasai: It's still invalid by the grammar.
  382. # [20:44] <TabAtkins> howcome: Eternal grammar isn't 'eternal', but I think it should still be harder to change than just writing a spec that says something different.
  383. # [20:44] <TabAtkins> howcome: We should have a very good reason to do it, and I haven't seen that reason.
  384. # [20:44] <TabAtkins> szilles: It simplifies the CSSOM model, for one. It simplifies parsing for CSS. It simplifies parsing for authors.
  385. # [20:45] * Quits: alexmog (alexmog@17.244.1.2) (Ping timeout)
  386. # [20:45] * Joins: alexmog (alexmog@17.244.1.2)
  387. # [20:46] <TabAtkins> @mixin(border-rules)(n) { -moz-border-radius: n; -webkit-border-radius: n; border-radius: n; } div{ @mixin(border-rule, 8px) }
  388. # [20:46] * TabAtkins bad syntax, but shrug.
  389. # [20:46] <TabAtkins> Bert: Why do you need an @rule in the one place where it's not allowed?
  390. # [20:46] * dbaron notes http://www.sas.upenn.edu/~baron/baron.css is CSS written by his dad
  391. # [20:47] <TabAtkins> plinss: Because @rule already has rules for swallowing things to the end of a block.
  392. # [20:47] <TabAtkins> glazou: If you remember the time before CSS2, we didn't have @page.
  393. # [20:47] <TabAtkins> glazou: Declaration were *only* for style rules. When we came up for @page, we suddenly had a new place for declarations.
  394. # [20:47] <TabAtkins> glazou: We want to be able to reuse an existing construct in the same way.
  395. # [20:48] <TabAtkins> glazou: It would open up a new type of contributions for authors that we can't usually do.
  396. # [20:49] <TabAtkins> Bert: Imagine changing XML.
  397. # [20:49] <TabAtkins> glazou: We did that when we added @media.
  398. # [20:49] <TabAtkins> Bert: That in 1998.
  399. # [20:50] <TabAtkins> szilles: I recommend the chairs take a straw poll.
  400. # [20:51] <TabAtkins> anne: And the options are 1) special handling of @page, or 2) generic handling?
  401. # [20:52] <anne> ... and 3) require at-rules at the end for @page
  402. # [20:52] <TabAtkins> plinss: Given the current definition of @page, legacy handling would mean swalling @margin rules inside of it, because @page contains a declaration block, which doesn't allow @ rules inside of it.
  403. # [20:53] * Quits: szilles (chatzilla@17.244.0.143) (Ping timeout)
  404. # [20:53] <TabAtkins> Bert: 3rd proposal, which has no chance, is to change Paged Media.
  405. # [20:53] <TabAtkins> s/3rd/4th/
  406. # [20:54] <TabAtkins> Bert: And pull out @margin rules from the @page blocks.
  407. # [20:54] <TabAtkins> fantasai: They should have probably been outside from the beginning, but right now we might as well remove them.
  408. # [20:54] <TabAtkins> howcome: Where would you put them if they were outside?
  409. # [20:54] * Joins: ChrisL (ChrisL@128.30.52.169)
  410. # [20:55] <ChrisL> CSS the Eternal Temple http://i40.tinypic.com/2nlwrjn.jpg
  411. # [20:55] <TabAtkins> howcome: [illustrates the change]
  412. # [20:55] <Bert> (One proposed change is in 13.2 say:... followed by a block of declarations <ins>and at-rules</ins>.)
  413. # [20:55] <TabAtkins> fantasai: Yeah, but we've got multiple implementations in printers, and so it can't be changed now.
  414. # [20:57] <TabAtkins> plinss: What's the point of putting @ at the end? It seems like an arbitrary place.
  415. # [20:57] <TabAtkins> fantasai: It makes it clearer how inheritance works.
  416. # [20:58] <TabAtkins> howcome: So how do we deal with @page containing @top-left and such?
  417. # [20:58] <TabAtkins> Bert: Right now, we don't. It's just invalid.
  418. # [20:58] <TabAtkins> Bert: We could create a special thing, not a declaration block, that would allow it.
  419. # [20:59] <TabAtkins> plinss: I'm reading the parsing rules, and I'm not seeing anything in CSS that says special handling of @ rules depending on the position.
  420. # [20:59] <TabAtkins> plinss: It doesn't say we only do this based on where it was.
  421. # [20:59] <TabAtkins> Bert: Right, but we discussed that it should behave that way.
  422. # [20:59] <TabAtkins> plinss: Please show me in the spec where it says it should behave the way you say it shoudl behave.
  423. # [20:59] <TabAtkins> Bert: The two points above that.
  424. # [21:00] <TabAtkins> Bert: The question is only if there is an exception if the @ keyword appears right after a semicolon.
  425. # [21:00] <TabAtkins> dbaron: We don't specify what happens when the formal grammar disagrees with the prose.
  426. # [21:00] <TabAtkins> plinss: But the formal grammar doesn't define the recovery rules, only the prose does.
  427. # [21:01] <dbaron> dbaron: we usually go with whatever's more specific
  428. # [21:01] <TabAtkins> howcome: What if we used ::top-left or something?
  429. # [21:01] <TabAtkins> fantasai: Still invalid in a declaration block. Should have been @page::top-left, but shrug.
  430. # [21:02] <TabAtkins> Straw Poll:
  431. # [21:02] <TabAtkins> 1) Generic Handling
  432. # [21:02] <TabAtkins> 2) Special handling for @page in any order (current spec)
  433. # [21:02] <TabAtkins> 3) Special handling, but @rules at the end.
  434. # [21:03] * sylvaing ::nth-strawpoll(2n+1)
  435. # [21:03] <TabAtkins> 4) Change Paged Media to nuke margin boxes and rewrite @page.
  436. # [21:03] <TabAtkins> smfr: 1
  437. # [21:03] <TabAtkins> anne: 1
  438. # [21:03] <TabAtkins> szilles: 1
  439. # [21:03] <bradk> 1 generic
  440. # [21:03] <TabAtkins> dbaron: 1
  441. # [21:03] <TabAtkins> s/dbaron/dethbakin/
  442. # [21:06] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
  443. # [21:06] * Joins: dbaron (dbaron@63.245.220.11)
  444. # [21:07] <TabAtkins> sylvaing: abstain
  445. # [21:07] <TabAtkins> alexmog: 3 or 4, whatever doesnt' change CSS 2.1
  446. # [21:08] <TabAtkins> ChrisL: 1
  447. # [21:08] <TabAtkins> Bert: Prefer 4, second is 3. could also live with 2. Can't live with 1
  448. # [21:08] <TabAtkins> arronei: 1
  449. # [21:08] <sylvaing> sylvaing abstains in the absence of a use-case
  450. # [21:08] <TabAtkins> fantasai: anything but 4, defer to dbaron
  451. # [21:08] <TabAtkins> dbaron: 4
  452. # [21:09] <TabAtkins> bradk: 1
  453. # [21:09] <TabAtkins> TabAtkins: 1
  454. # [21:09] <TabAtkins> glazou: 1
  455. # [21:09] <TabAtkins> plinss: 1
  456. # [21:09] <TabAtkins> howcome: 3
  457. # [21:09] <TabAtkins> dsinger: 1
  458. # [21:10] <fantasai> I think HP would raise a formal objection for 4
  459. # [21:10] <TabAtkins> glazou: Twelve for #1, three or four for 3 and 4.
  460. # [21:12] <TabAtkins> dsinger: We have agreement on *not* 2.
  461. # [21:12] <TabAtkins> plinss: And we cant' do 4 because of existing impls.
  462. # [21:12] <TabAtkins> glazou: Existing impls do 2, so we're rejecting the current impls!
  463. # [21:13] <TabAtkins> fantasai: Not sure if existing impls do 2, maybe they do 1?
  464. # [21:13] <TabAtkins> ChrisL: How would you tell the difference?
  465. # [21:13] <TabAtkins> fantasai: Just pop my testcase into a supporting impl.
  466. # [21:13] <anne> <!DOCTYPE html><style> body { @foo {} background: green; } </style>
  467. # [21:14] <ChrisL> it would be good to gather that implementation experience for printers that currently handle @page
  468. # [21:14] <TabAtkins> body {
  469. # [21:14] <TabAtkins> @foo {
  470. # [21:14] <TabAtkins> }
  471. # [21:14] <TabAtkins> background: green;
  472. # [21:14] <TabAtkins> }
  473. # [21:15] * fantasai has access to two printer implementations at home
  474. # [21:15] <TabAtkins> glazou: People will write it like Tab has, what will they expect?
  475. # [21:15] <TabAtkins> howcome: Prince considers this an error, and doesn't show a green background.
  476. # [21:15] <TabAtkins> fantasai: So it implements 2?
  477. # [21:16] * Quits: dbaron (dbaron@63.245.220.11) (Connection reset by peer)
  478. # [21:16] <TabAtkins> anne: Or 3, we can't tell.
  479. # [21:16] <TabAtkins> plinss: Elika, can you test with your printers and get back to us?
  480. # [21:17] <TabAtkins> fantasai: Would be good to get AH. Can we ping Murakami-san?
  481. # [21:17] <TabAtkins> fantasai: 3 would just mean normal 2.1 error-recovery mode.
  482. # [21:17] <TabAtkins> plinss: We'll come back when we get more implementations.
  483. # [21:18] * Quits: dethbakin (dethbakin@17.244.1.225) (Quit: dethbakin)
  484. # [21:19] * Joins: dbaron (dbaron@17.244.2.46)
  485. # [21:19] <TabAtkins> howcome: Is there anyone that can't live with 3?
  486. # [21:19] <TabAtkins> anne: #3 is actually pretty weird.
  487. # [21:20] <TabAtkins> anne: So if you had @ rules, normal rules, then more @ rules, presumably you should ignore all the normal rules since the appearance of the @ implies the end?
  488. # [21:20] <TabAtkins> howcome: I think we can live with #3 now, and then make #1 valid later.
  489. # [21:21] <TabAtkins> dsinger: Can we write that we can possibly allow #1 later? Warn people about it?
  490. # [21:21] <TabAtkins> plinss: I don't think there's any point to saying "Sometime in the future, we might add future-proofing."
  491. # [21:21] <ChrisL> :)
  492. # [21:21] <TabAtkins> dsinger: No, just that we might add a feature in the future that may require more generic handling, so don't depend on certain types of handling.
  493. # [21:22] * Joins: dbaron_ (dbaron@63.245.220.11)
  494. # [21:22] * Quits: dbaron (dbaron@17.244.2.46) (Ping timeout)
  495. # [21:23] <TabAtkins> howcome: There is no hole right now. You're creating a hole and then insisting it needs to be filled.
  496. # [21:23] <TabAtkins> anne: Paged Media doesnt' actually require them to be at the end.
  497. # [21:23] <TabAtkins> plinss: In my perspective, it's a bug in 2.1.
  498. # [21:24] <TabAtkins> plinss: In 2.1, we say when you see an @rule, swallow until the next block or semicolon. We don't say to do that only at the rule level.
  499. # [21:24] <TabAtkins> plinss: We need to make this clear one way or another. Bert's proposal is to say that applies only at the ruleset level, most others are saying apply at all levels.
  500. # [21:24] <TabAtkins> howcome: We have impl issues with that.
  501. # [21:25] <TabAtkins> plinss: We have an existing spec that needs @rules like this, and at least two more ideas I know of want that.
  502. # [21:25] <TabAtkins> Bert: But no one implements it like that anyway.
  503. # [21:25] <TabAtkins> plinss: Right. But my reading of CSS is that you throw away an invalid @ rule as a unit.
  504. # [21:26] <TabAtkins> Bert: Only at the toplevel.
  505. # [21:26] <TabAtkins> plinss: But CSS doesn't say that.
  506. # [21:26] <TabAtkins> howcome: This is a new situation. Bert is arguing *for* the browsers, Peter is arguing against?
  507. # [21:27] <TabAtkins> plinss: This isn't progressing. We'll get more examples. Until then we're not convincing anyone.
  508. # [21:27] <TabAtkins> szilles: Can we set a time for jdaggett's call? By my calc, 6am in Tokyo is 2pm here.
  509. # [21:27] <TabAtkins> szilles: Is 3pm okay for us (7am for him)?
  510. # [21:28] <TabAtkins> plinss: We have a lot of things for him to weigh in on.
  511. # [21:28] <TabAtkins> plinss: I'd like him as early as possible. I suggest we ask him when he's comfortable.
  512. # [21:28] * Joins: dino (dino@17.202.116.62)
  513. # [21:28] <TabAtkins> szilles: And then I"ll ask another Adobe employee to attend.
  514. # [21:28] <TabAtkins> <br type=lunch duration=1h>
  515. # [21:28] * Quits: glazou (glazou@17.244.0.83) (Quit: glazou)
  516. # [21:29] * Quits: bradk (bradk@17.244.0.81) (Quit: Computer has gone to sleep)
  517. # [21:29] * Quits: dbaron_ (dbaron@63.245.220.11) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  518. # [21:29] * Quits: plinss__ (plinss@17.244.3.217) (Quit: plinss__)
  519. # [21:31] * Quits: smfr (smfr@17.244.1.194) (Quit: smfr)
  520. # [21:31] * Quits: Arron (arronei@17.244.2.216) (Ping timeout)
  521. # [21:32] * Quits: sylvaing (sylvaing@17.244.0.225) (Ping timeout)
  522. # [22:03] * Joins: dethbakin (dethbakin@17.244.64.200)
  523. # [22:07] * Quits: dethbakin (dethbakin@17.244.64.200) (Quit: dethbakin)
  524. # [22:37] * Joins: Lachy (Lachlan@85.196.122.246)
  525. # [22:39] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
  526. # [22:43] * Joins: bradk (bradk@17.244.0.81)
  527. # [22:43] * Joins: sylvaing (sylvaing@17.244.0.225)
  528. # [22:43] * Joins: dbaron (dbaron@63.245.220.11)
  529. # [22:44] * Joins: glazou (glazou@17.244.0.83)
  530. # [22:44] * Joins: plinss__ (plinss@17.244.3.217)
  531. # [22:45] * Joins: smfr (smfr@17.244.1.194)
  532. # [22:45] * Joins: Arron (arronei@17.244.2.216)
  533. # [22:46] * Quits: glazou (glazou@17.244.0.83) (Quit: glazou)
  534. # [22:47] * Quits: alexmog (alexmog@17.244.1.2) (Ping timeout)
  535. # [22:47] * Joins: alexmog (alexmog@17.244.1.2)
  536. # [22:47] * Joins: glazou (glazou@17.244.0.83)
  537. # [22:47] * Joins: ChrisL (ChrisL@128.30.52.169)
  538. # [22:49] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-114
  539. # [22:49] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-109
  540. # [22:49] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-26
  541. # [22:50] <fantasai> dbaron: The way the spec currently says that vertical-align in table cells works is
  542. # [22:50] <fantasai> ScribeNick: fantasai
  543. # [22:50] <fantasai> dbaron: You have a table
  544. # [22:50] <fantasai> dbaron: like this
  545. # [22:51] <fantasai> dbaron draws a table with 2 rows 2 cols
  546. # [22:51] <fantasai> dbaron: And you have a table cell likes this
  547. # [22:51] <fantasai> dbaron draws a cell box in the upper half of the first cell
  548. # [22:51] <fantasai> dbaron: The spec says ... and it says that the 'height' property sets the height of a cell box
  549. # [22:52] <fantasai> dbaron: Suppose it says the cell height is 200px
  550. # [22:52] <fantasai> dbaron: The cell box will be 200px
  551. # [22:52] <fantasai> dbaron: and if the row is 200px high
  552. # [22:52] <fantasai> dbaron: the cell box stays put, and its contents are clearly not vertical-align: bottom
  553. # [22:53] <fantasai> dbaron: Nobody does this, everybody aligns the contents to the bottom
  554. # [22:53] * Joins: jer (jer@17.244.2.51)
  555. # [22:53] <fantasai> s/.../vertical-align aligns the cell box inside the cell/
  556. # [22:54] * Parts: jer (jer@17.244.2.51)
  557. # [22:54] <fantasai> dbaron: There are 2 possible solutions here, with different implications, and different browsers pick different ones
  558. # [22:54] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
  559. # [22:54] <fantasai> dbaron: One alternative is to say that instead of 'height' setting the height of the cell box, it sets a minimal height for the row
  560. # [22:54] <fantasai> dbaron: The other solution is to say that you have two boxes
  561. # [22:55] <fantasai> dbaron: one of which wraps around the content, the other one of which wraps around that, and vertical-align aligns both of them, but the height only sets the height of the outer one
  562. # [22:55] <fantasai> dbaron: The tricky cases are where you have baseline alignment
  563. # [22:56] <fantasai> dbaron: You can get a case where baseline alignment requires more space than either cell would require alone
  564. # [22:56] <fantasai> dbaron: e.g. if you have a large-text box of auto height
  565. # [22:57] <fantasai> dbaron: and a small-text cell of large height
  566. # [22:57] <fantasai> dbaron: the baselines align
  567. # [22:57] <fantasai> dbaron: but the second box extends way below the bottom of the first
  568. # [22:57] <fantasai> dbaron draws this on the board
  569. # [22:58] <css_projector> http://dbaron.org/css/test/2010/css21-issue-26
  570. # [22:59] <fantasai> dbaron shows http://www.brunildo.org/test/td_height1.html
  571. # [23:00] <fantasai> fantasai: I would not expect vertical-align to increase the size of the cell there
  572. # [23:06] <fantasai> I would expect height to set the height of the same box that you paint borders and backgrounds on, not on the anonymous content holder inside it
  573. # [23:07] <smfr> http://www.w3.org/TR/CSS21/tables.html#height-layout
  574. # [23:10] <fantasai> fantasai: Does height include the padding?
  575. # [23:10] <fantasai> fantasai: border-widths?
  576. # [23:12] <fantasai> Looks like height in Mozilla is a border-box height
  577. # [23:14] * Joins: ChrisL (ChrisL@128.30.52.169)
  578. # [23:14] <fantasai> fantasai thinks we should say that the height sets the border-box height of the cell box
  579. # [23:14] * anne wonders why the efforts to describe the table layout model stopped
  580. # [23:14] <fantasai> The contents of the cell are wrapped in an anonymous box, and that is aligned inside the cell
  581. # [23:15] * fantasai because Markus swapped departments
  582. # [23:15] <fantasai> Alex: What do Mozilla and WebKit do for flexbox?
  583. # [23:15] <fantasai> dbaron: I'm not so concerned with that
  584. # [23:17] <fantasai> Steve: So you have two boxes, one that most properties apply to, and then the box that wraps the contents of the cell, that gets vertical-aligned
  585. # [23:17] <fantasai> Steve: The first box has border, padding, etc.
  586. # [23:19] <fantasai> dbaron: We should figure out what we want so that someone can write a proposal
  587. # [23:19] <fantasai> dsinger asks a question
  588. # [23:19] * sylvaing :nth-box-nth-removed { vertical-align:...
  589. # [23:19] <fantasai> dbaron: baseline alignment is a relative thing. You take all the cells in the row and baseline-align their contents.
  590. # [23:20] <fantasai> dbaron: If the height of the row is taller than the height of the aligned set of content, it's undefined what happens
  591. # [23:21] <fantasai> Steve: So your question is that ... can we give names to these things?
  592. # [23:21] <fantasai> dbaron: One of them is called the cell box, but it's not what you'd think of as the cell box
  593. # [23:25] <fantasai> dbaron: The simplest change it to go with IE and Opera and say that 'height' on the cell sets the minimum height of the row
  594. # [23:26] * anne ... it was dbaron and saloni writing it though
  595. # [23:26] * anne ... (each their own version)
  596. # [23:26] * fantasai not saloni, it was shuo
  597. # [23:26] * Quits: glazou (glazou@17.244.0.83) (Quit: glazou)
  598. # [23:26] * fantasai and it was because Markus was pushing it
  599. # [23:27] <anne> http://dev.w3.org/csswg/css3-tables-algorithms/Overview.src.htm
  600. # [23:28] * fantasai saloni's name is on their because she was supposed to take over, she didn't actually work on it much
  601. # [23:28] * fantasai shuo and markus and erika were the ones who actually did work on it
  602. # [23:28] <fantasai> howcome talks about making a bar chart
  603. # [23:29] <fantasai> dbaron: An explicit height on a table cell does not cause even the contents of that cell from increasing the height of the cell
  604. # [23:29] <fantasai> dbaron: Everything's like minimum heights in tables
  605. # [23:29] <fantasai> Alex agrees with Opera's interepretation
  606. # [23:30] <fantasai> Steve: If you want the other behavior, you can put a fixed height on a <div> inside
  607. # [23:30] <fantasai> plinss: Shouldn't require markup changes for layout
  608. # [23:31] <fantasai> fantasai: This is the most intuitive interpretation.
  609. # [23:32] <fantasai> fantasai: If I was an author, I'd associate the height of the table cell with the height of the box that has borders and backgrounds on it, not some invisible thing inside it
  610. # [23:32] <fantasai> ACTION: dbaron write proposal for IE-Opera behavior for issue 26
  611. # [23:32] * trackbot noticed an ACTION. Trying to create it.
  612. # [23:32] * RRSAgent records action 1
  613. # [23:32] <trackbot> Created ACTION-210 - Write proposal for IE-Opera behavior for issue 26 [on David Baron - due 2010-04-05].
  614. # [23:32] <fantasai> Simon: Hyatt doesn't really care which way this goes
  615. # [23:33] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-114
  616. # [23:35] * Joins: szilles (chatzilla@17.244.3.121)
  617. # [23:36] <fantasai> fantasai explains that the spec is unclear about what is allowed and what is invalid
  618. # [23:37] <fantasai> Arron has a bunch of testcases showing that results are very different across browsers
  619. # [23:38] <fantasai> There are two proposals for clarifying the spec
  620. # [23:38] <fantasai> one would make unquoted font names a series of identifier tokens
  621. # [23:38] <fantasai> the other would make them a series of nmchars tokens
  622. # [23:38] <fantasai> Chris suggests recommending quotes
  623. # [23:38] <fantasai> The spec already recommends quotes
  624. # [23:40] * Joins: dethbakin (dethbakin@17.246.18.154)
  625. # [23:40] * Quits: dethbakin (dethbakin@17.246.18.154) (Quit: dethbakin)
  626. # [23:40] * Joins: dethbakin (dethbakin@17.246.18.154)
  627. # [23:41] <fantasai> dbaron: right now in Gecko you have to escape or quote numbers
  628. # [23:43] * Joins: jer (jer@17.244.2.51)
  629. # [23:44] <fantasai> several: Let's allow everything
  630. # [23:44] <ChrisL> everything but comma
  631. # [23:44] <fantasai> fantasai: I don't like that, because you have to have some exceptions, which is what we have already, and it's already causing interop problems
  632. # [23:44] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Mar/0395.html
  633. # [23:45] <fantasai> http://www.w3.org/TR/CSS21/fonts.html#font-family-prop
  634. # [23:46] <fantasai> Chris: How about making a grammar for what the prose already says
  635. # [23:47] * Quits: alexmog (alexmog@17.244.1.2) (Connection reset by peer)
  636. # [23:47] * Joins: alexmog (alexmog@17.244.1.2)
  637. # [23:50] <fantasai> discussion of what mistakes web authors are likely to make
  638. # [23:50] <ChrisL> some font families that might be useful for tests - "101 Dalmations" "3.14 Pi" "Twenty 4px"
  639. # [23:51] <fantasai> dbaron: right now the spec has document conformance reqs but no ua conformance reqs
  640. # [23:53] <fantasai> arron: If you run the testcases, you'll see a lot of constency except for numbers and brackets
  641. # [23:54] <fantasai> <br type=cookies>
  642. # [23:57] <fantasai> Topic: CSS2.1 Test Suite
  643. # [23:57] <fantasai> glazou: First issue is about inode strain on the server
  644. # [23:59] <fantasai> bert: it's not about space, it's our mirroring system
  645. # [23:59] <fantasai> Alex: Would adding another 15000 tests facilitate upgrading the system? :)
  646. # [23:59] <fantasai> Chris: It's generating emails to the mirrors for each file
  647. # Session Close: Tue Mar 30 00:00:00 2010

The end :)