/irc-logs / w3c / #css / 2012-02-07 / end

Options:

  1. # Session Start: Tue Feb 07 00:00:00 2012
  2. # Session Ident: #css
  3. # [00:03] * Quits: jdaggett (jdaggett@81.56.65.178) (Quit: jdaggett)
  4. # [00:06] * Quits: tantek (tantek@90.46.85.61) (Quit: tantek)
  5. # [00:13] * Quits: nimbu (Adium@24.18.47.160) (Quit: Leaving.)
  6. # [00:55] * Quits: TabAtkins_ (tabatkins@90.46.85.61) (Ping timeout)
  7. # [00:58] * Quits: kojiishi (kojiishi@90.46.85.61) (Ping timeout)
  8. # [01:03] * RRSAgent excuses himself; his presence no longer seems to be needed
  9. # [01:03] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
  10. # [02:30] * plinss is now known as plinss_away
  11. # [02:41] * plinss_away is now known as plinss
  12. # [02:47] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
  13. # [03:01] * Joins: karl (karlcow@128.30.54.58)
  14. # [03:24] * Joins: arron (Arron@24.17.123.244)
  15. # [03:31] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
  16. # [05:18] * Joins: jdaggett (jdaggett@81.56.65.178)
  17. # [06:11] * Quits: ed (ed@88.131.66.80) (Ping timeout)
  18. # [06:23] * Joins: ed (ed@88.131.66.80)
  19. # [06:43] * plinss is now known as plinss_away
  20. # [07:28] * Joins: arron (Arron@24.17.123.244)
  21. # [07:34] * shans is now known as shans_away
  22. # [07:43] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
  23. # [08:02] * Joins: TabAtkins_ (tabatkins@90.46.85.61)
  24. # [08:05] * Joins: tantek (tantek@90.46.85.61)
  25. # [08:29] * Quits: jdaggett (jdaggett@81.56.65.178) (Quit: jdaggett)
  26. # [08:30] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  27. # [08:30] <RRSAgent> logging to http://www.w3.org/2012/02/07-css-irc
  28. # [08:33] * Joins: dbaron (dbaron@89.80.183.188)
  29. # [08:33] * dbaron RRSAgent, pointer?
  30. # [08:33] * RRSAgent See http://www.w3.org/2012/02/07-css-irc#T07-26-04
  31. # [08:34] * dbaron RRSAgent, make logs public
  32. # [08:34] * RRSAgent I have made the request, dbaron
  33. # [08:34] * Quits: dbaron (dbaron@89.80.183.188) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  34. # [08:43] * Quits: TabAtkins_ (tabatkins@90.46.85.61) (Ping timeout)
  35. # [08:45] * Quits: tantek (tantek@90.46.85.61) (Quit: tantek)
  36. # [08:46] * Joins: glazou (glazou@128.93.135.193)
  37. # [08:50] <glazou> test
  38. # [08:50] <glazou> RRSAgent, make logs public
  39. # [08:50] <RRSAgent> I have made the request, glazou
  40. # [08:50] * plinss_away is now known as plinss
  41. # [09:00] * Quits: glazou (glazou@128.93.135.193) (Quit: glazou)
  42. # [09:01] * plinss is now known as plinss_away
  43. # [09:14] * Joins: glazou (glazou@128.93.135.193)
  44. # [09:16] * plinss_away is now known as plinss
  45. # [09:23] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  46. # [09:24] * Joins: kojiishi (kojiishi@128.93.135.158)
  47. # [09:25] * Joins: dbaron (dbaron@128.93.135.77)
  48. # [09:26] * Joins: jdaggett (jdaggett@128.93.135.115)
  49. # [09:26] * jdaggett tries to wake up...
  50. # [09:30] * Joins: TabAtkins_ (tabatkins@74.125.122.49)
  51. # [09:32] * sylvaing_away is now known as sylvaing
  52. # [09:33] <sylvaing> scribenick: sylvaing
  53. # [09:33] * Joins: howcome (howcome@128.93.135.80)
  54. # [09:33] * Joins: smfr (smfr@128.93.134.211)
  55. # [09:33] <sylvaing> howcome: I think we agreed we want to achieve modern magazine designs
  56. # [09:33] * Joins: vhardy_ (qw3birc@128.30.52.28)
  57. # [09:33] <sylvaing> howcome: we disagree how to reach that goal
  58. # [09:34] <sylvaing> howcome: I prefer a declarative approach
  59. # [09:34] <sylvaing> howcome: others prefer a hybrid approach that involves script
  60. # [09:34] * Joins: florian (florianr@128.93.135.177)
  61. # [09:34] * Joins: tantek (tantek@128.93.135.10)
  62. # [09:34] * Quits: dglazkov (u4270@88.198.6.68) (Ping timeout)
  63. # [09:34] <sylvaing> steve: I thought we came out of the discussion thinking that we needed declarative as well as scripting
  64. # [09:35] <TabAtkins_> q+
  65. # [09:35] * Zakim sees TabAtkins_ on the speaker queue
  66. # [09:35] * Joins: Rossen (Rossen@128.93.134.230)
  67. # [09:35] * fantasai agrees 100% with howcome and Bert on this topic and has nothing more to say.
  68. # [09:36] * Joins: antonp (805d8798@207.192.75.252)
  69. # [09:36] * Joins: dglazkov (u4270@88.198.6.68)
  70. # [09:37] <sylvaing> <successful re-enactment of yesterday's discussion>
  71. # [09:37] * Quits: florian (florianr@128.93.135.177) (Quit: florian)
  72. # [09:37] <sylvaing> tab: allowing the last region be auto-sized would help a lot
  73. # [09:38] * Joins: alexmog_ (qw3birc@128.30.52.28)
  74. # [09:38] <sylvaing> tab: being able to flow a region into a grid cell (which used to exist with ::slot) would also help
  75. # [09:38] * Joins: florian (florianr@128.93.135.177)
  76. # [09:38] <sylvaing> tab: with those two combined, a large number of these layouts would be possible
  77. # [09:38] <alexmog_> q+
  78. # [09:38] * Zakim sees TabAtkins_, alexmog_ on the speaker queue
  79. # [09:38] <TabAtkins_> ack
  80. # [09:38] <TabAtkins_> zakim, ack
  81. # [09:39] <Zakim> I don't understand 'ack', TabAtkins_
  82. # [09:39] <TabAtkins_> q-
  83. # [09:39] * Zakim sees alexmog_ on the speaker queue
  84. # [09:39] <sylvaing> vincent: the first one is something we have as an issue.
  85. # [09:39] <sylvaing> vincent: we also talked about making multicol a region; in particular make the last region a multicol
  86. # [09:39] <sylvaing> vincent: we'd also like to make a proposal for page templating
  87. # [09:40] * Joins: jet (jet@128.93.134.233)
  88. # [09:40] <sylvaing> rossen: our goal is to present a page template at the next f2f which would address basic region auto-generation needs
  89. # [09:40] <sylvaing> rossen: so this would allow us to go back to the regions spec now and work on known issues
  90. # [09:41] <sylvaing> alexmog: I think we generally disagree on the order of implementation
  91. # [09:41] * Joins: tantek_ (tantek@128.93.135.73)
  92. # [09:42] <sylvaing> howcome: my concern is that the first implementations coming out will force the creation of dummy divs through script
  93. # [09:42] <sylvaing> alexmog: we only aim to enable implementation in this space and gather feedback
  94. # [09:43] * Joins: ChrisL (ChrisL@128.30.52.169)
  95. # [09:43] <sylvaing> alexmog: I'd like to discuss issues in the regions spec.
  96. # [09:43] <tantek> the Microsoft implementation of regions is -ms- prefixed right?
  97. # [09:43] * ChrisL maybe we should all implement the microsoft solution, but all with the -ms- prefix
  98. # [09:43] <sylvaing> tantek, yes
  99. # [09:44] <sylvaing> howcome: i think a page template spec is necessary
  100. # [09:44] <sylvaing> howcome: regions and page templates should come together is necessary
  101. # [09:44] <vhardy_> q+
  102. # [09:44] * Zakim sees alexmog_, vhardy_ on the speaker queue
  103. # [09:45] <plinss> ack
  104. # [09:45] <alexmog_> q-
  105. # [09:45] * Zakim sees vhardy_ on the speaker queue
  106. # [09:46] <sylvaing> vincent: I see it as a two step process. if we do allow regions to be multicol elements I think it mixes well with your solution
  107. # [09:46] <sylvaing> vincent: this provides a progression that doesn't require scripting
  108. # [09:46] <plinss> ack vhardy_
  109. # [09:46] * Zakim sees no one on the speaker queue
  110. # [09:46] <sylvaing> tab: is there any reason why all regions couldn't be multicols?
  111. # [09:46] <sylvaing> vincent: no
  112. # [09:47] <sylvaing> alexmog: can we put region issues on the agenda?
  113. # [09:48] <sylvaing> howcome: sure, i just don't want to make a general decision on whethe this is the right way forward until we have visibility into your general model
  114. # [09:49] <sylvaing> vincent: as a way forward we'll submit a page template, add support for multicols and paged overflow
  115. # [09:50] <sylvaing> vincent: at the f2f we can show something that's much more complete
  116. # [09:50] <sylvaing> florian: that way we'll be able to compare complete solutions based on use-cases
  117. # [09:51] <sylvaing> howcome: we should also look at Bert's proposal
  118. # [09:51] <sylvaing> s/proposal/use-cases
  119. # [09:52] <sylvaing> howcome: we need a set of use-cases to evaluate the various proposals
  120. # [09:53] <sylvaing> jdaggett: I think it would also be useful to share presentation material like this on www-style in advance so as to gather feedback from a wider group
  121. # [09:53] <Bert> q+ to give example of what looking at a complete example can give
  122. # [09:53] * Zakim sees Bert on the speaker queue
  123. # [09:54] <sylvaing> rossen: valid feedback, thank you
  124. # [09:55] <sylvaing> ACTION: vhardy Draft a page template proposal for the May f2f
  125. # [09:55] * trackbot noticed an ACTION. Trying to create it.
  126. # [09:55] * RRSAgent records action 1
  127. # [09:55] <trackbot> Created ACTION-422 - Draft a page template proposal for the May f2f [on Vincent Hardy - due 2012-02-14].
  128. # [09:56] <sylvaing> TOPIC: Regions issues
  129. # [09:58] <dbaron> vhardy: Should I put it on dev.w3.org?
  130. # [09:58] <sylvaing> Bert: region styling using @-rule is different from pseudo-element styling and creates inconsistencies
  131. # [09:58] <dbaron> daniel: of course; we have things there that aren't even in the charter; I won't entertain objections to that
  132. # [09:59] * Joins: astearns (qw3birc@128.30.52.28)
  133. # [09:59] <sylvaing> vincent: there was feedback at the last meeting on the way we presented issues and I wanted to start by showing how we dealt with that
  134. # [09:59] <sylvaing> vincent projects css3-regions ED
  135. # [09:59] <sylvaing> vincent: we're filing all the spec issues in Bugzilla
  136. # [10:00] <sylvaing> vincent: before then we only had issue markers in the spec
  137. # [10:00] <sylvaing> vincent: now all the issues in the spec link back to bugzilla, and the short description is shown in the margin
  138. # [10:02] <sylvaing> vincent: this is done in a scripted manner and matches them with the spec and appends them a report at the end of the spec. it lets you know whether new issues are not marked in the spec. this helps editing.
  139. # [10:05] <sylvaing> vincent: let me know how to make it more useful
  140. # [10:05] <dbaron> I didn't follow what the buttons at the bottom were supposed to do.
  141. # [10:05] <ChrisL> inline bug links in the spec are very useful
  142. # [10:05] <ChrisL> tools better in a subdirectory instead of littering the root
  143. # [10:05] <sylvaing> ACTION: vhardy Create a shared directory to post the bug helper script and document it on the wiki
  144. # [10:05] * RRSAgent records action 2
  145. # [10:05] * trackbot noticed an ACTION. Trying to create it.
  146. # [10:05] <trackbot> Created ACTION-423 - Create a shared directory to post the bug helper script and document it on the wiki [on Vincent Hardy - due 2012-02-14].
  147. # [10:07] <sylvaing> first bug was https://www.w3.org/Bugs/Public/show_bug.cgi?id=15159 to add use-cases
  148. # [10:07] <sylvaing> we've done that
  149. # [10:07] <sylvaing> http://wiki.csswg.org/spec/css3-regions/regions-use-cases
  150. # [10:08] <sylvaing> howcome: in addition to the CSS and HTML, it'd be useful to see any script that is needed to flow in more content
  151. # [10:09] <sylvaing> howcome: do you encourage others to add more to the wiki page?
  152. # [10:09] <sylvaing> vincent: yes
  153. # [10:10] <sylvaing> ACTION: vhardy make a generic use-case page linking to proposed markup solutions
  154. # [10:10] * RRSAgent records action 3
  155. # [10:10] * trackbot noticed an ACTION. Trying to create it.
  156. # [10:10] <trackbot> Created ACTION-424 - Make a generic use-case page linking to proposed markup solutions [on Vincent Hardy - due 2012-02-14].
  157. # [10:10] <sylvaing> RESOLVED bug 15159 is closed
  158. # [10:11] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15733
  159. # [10:11] * Joins: szilles (chatzilla@128.93.134.251)
  160. # [10:11] <sylvaing> vincent: this is about creating regions declaratively
  161. # [10:11] <sylvaing> howcome: let's close it once there is a proposal
  162. # [10:12] <sylvaing> vincent: this will be solved in the template proposal
  163. # [10:12] <sylvaing> vincent: we'll update the bug to reference the pending action
  164. # [10:13] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15131
  165. # [10:14] <sylvaing> vincent: originally the spec had a section on how regions integrated with different layout systems since regions don't create layout. this was taken out
  166. # [10:14] <sylvaing> vincent: then we explained how a region could be selected or created but this was not to be covered in the spec
  167. # [10:15] <sylvaing> vincent: but we were left with this example and we were asked to update it
  168. # [10:16] <sylvaing> vincent: the goal should be to indicate there is an overflow area and that should be item 4 in Figure 1
  169. # [10:17] <sylvaing> vincent: the point of the example is to show there is a catch-all area
  170. # [10:17] <sylvaing> ACTION: vhardy Make item 4 a multicolumn overflow
  171. # [10:17] * RRSAgent records action 4
  172. # [10:17] * trackbot noticed an ACTION. Trying to create it.
  173. # [10:17] <trackbot> Created ACTION-425 - Make item 4 a multicolumn overflow [on Vincent Hardy - due 2012-02-14].
  174. # [10:18] <sylvaing> howcome: <creep-laugh type="evil">
  175. # [10:20] <sylvaing> vincent: Bug 15186 is about auto-generation and is to be revisited with future proposals. Same for 15187.
  176. # [10:21] <Bert> (The example of 15131 doesn't really add a layout-based solution, does it? I still see empty HTML elements...)
  177. # [10:21] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15811
  178. # [10:21] <sylvaing> alexmog: we are not proposing to flow content from external resources at the moment
  179. # [10:22] <ChrisL> q+
  180. # [10:22] * Zakim sees Bert, ChrisL on the speaker queue
  181. # [10:22] <Bert> q-
  182. # [10:22] * Zakim sees ChrisL on the speaker queue
  183. # [10:22] <sylvaing> alexmog: providing flow from external resources could be out of scope, or the Regions spec shouldn't restrict the origin of a resource
  184. # [10:23] <sylvaing> ChrisL: I don't think it should be out of scope since the alternative would be to write script to pull in content
  185. # [10:23] <sylvaing> alexmog: out of scope may be the wrong term
  186. # [10:24] <dbaron> q+
  187. # [10:24] * Zakim sees ChrisL, dbaron on the speaker queue
  188. # [10:24] <sylvaing> alexmog: can regions assume that every element or node comes from the same origin?
  189. # [10:24] <plinss> ack next
  190. # [10:24] * Zakim sees ChrisL at the head of the speaker queue
  191. # [10:24] * Zakim sees dbaron on the speaker queue
  192. # [10:24] <sylvaing> alexmog: I think it's useful to assume it but it is limiting
  193. # [10:25] * Bert thinks flowing <iframe seamless data="foo.html"> into a chain of regions would be cool...
  194. # [10:25] <sylvaing> dbaron: given the seamless iframes feature of HTLM5, I'm not sure how much this matters
  195. # [10:25] <plinss> ack next
  196. # [10:25] * Zakim sees dbaron at the head of the speaker queue
  197. # [10:25] * Zakim sees no one on the speaker queue
  198. # [10:25] <sylvaing> dbaron: if you assume you have seamless iframes then you don't need features in CSS
  199. # [10:25] <ChrisL> is there a benefit to assuming that all the nodes are in the same document?
  200. # [10:25] * Bert put suspects that <iframe> will be a rectangle, like other replaced elts.
  201. # [10:25] <ChrisL> alex: yes, you can determine element order
  202. # [10:26] <dbaron> ack dbaron
  203. # [10:26] * Zakim sees no one on the speaker queue
  204. # [10:26] <sylvaing> alexmog: but we want to allow indirection into a different document without changing the style of this document
  205. # [10:26] <sylvaing> alexmog: seamless iframes does not have that option
  206. # [10:26] <sylvaing> alexmog: I have a options on the wiki but I am not yet ready to commit to any of them
  207. # [10:27] * Parts: florian (florianr@128.93.135.177)
  208. # [10:27] <sylvaing> http://wiki.csswg.org/spec/css3-regions#issue-24creating-a-named-flow-from-external-resource
  209. # [10:27] <dbaron> TabAtkins: there are security concerns with integrating iframes and, e.g., determining the height of the contents, without using the mechanisms in seamless iframes
  210. # [10:27] <vhardy_> http://wiki.csswg.org/spec/css3-regions#issue-24creating-a-named-flow-from-external-resource
  211. # [10:28] * Joins: florian (florianr@128.93.135.177)
  212. # [10:29] <sylvaing> alexmog: one option involves using an iframe element; another uses a separate property; a third uses a flow rule. we can discuss these but work remains to evaluate the solutions as well as understand seamless iframes
  213. # [10:29] <sylvaing> tabatkins: this should be discussed on www-style as there are issues with it
  214. # [10:29] * Quits: kojiishi (kojiishi@128.93.135.158) (Ping timeout)
  215. # [10:29] <sylvaing> alexmog: the Regions spec should note that the content of a named flow may come from another document
  216. # [10:29] <sylvaing> vincent: should we retitle the bug?
  217. # [10:30] <glazou> break time at 10:45am
  218. # [10:30] <sylvaing> vincent: we can note in the spec that the current version assumes the content comes from the same document pointing to an issue to resolve it later
  219. # [10:31] <glazou> TabAtkins_: selectors 4 after the break ?
  220. # [10:31] <TabAtkins_> glazou: I'm okay with that. Check with fantasai, since I think it's generally her topic.
  221. # [10:32] <sylvaing> Bert: this is not really a Regions issue but a general question of whether we can have replaced elements that are reflowing
  222. # [10:32] <sylvaing> vincent: how do we deal with this issue?
  223. # [10:33] <sylvaing> bert: put it on the agenda
  224. # [10:33] <glazou> fantasai: ok with that ?
  225. # [10:34] <sylvaing> ACTION: alexmog to rework 15811 as a general issue of replaced content and flow
  226. # [10:34] * trackbot noticed an ACTION. Trying to create it.
  227. # [10:34] <trackbot> Sorry, couldn't find user - alexmog
  228. # [10:34] * RRSAgent records action 5
  229. # [10:35] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15858
  230. # [10:36] <sylvaing> vincent: the spec identifies the ICB for elements in regions
  231. # [10:36] <sylvaing> vincent: the defintiion was modeled on the page spec which uses the first page
  232. # [10:36] <sylvaing> vincent: based on use-cases involving a page preview we thought of using the first region as the ICB for the flowed content
  233. # [10:37] <sylvaing> vincent: feedback has been that this may not be always useful, and that the normal ICB should be used
  234. # [10:37] <sylvaing> vincent: we can also keep what we have
  235. # [10:37] <sylvaing> vincent: or we can provide a switch
  236. # [10:38] <sylvaing> alexmog: this is also relates to regions' interaction with stacking contexts
  237. # [10:38] <plinss> q?
  238. # [10:38] * Zakim sees no one on the speaker queue
  239. # [10:39] <sylvaing> alexmog: if you model regions based on columns then they're not containing blocks for absolutely positoned elements
  240. # [10:39] <Bert> q+ to mention that the 'gr' units seems enough in my experiments.
  241. # [10:39] * Zakim sees Bert on the speaker queue
  242. # [10:39] <sylvaing> anton: it's difficult to understand when you'll want to position within a region or within the wider document. a switch may be too hard to understand
  243. # [10:40] <sylvaing> plinss: from past feedback, we may want to be able to declare something to be a containing block
  244. # [10:41] <sylvaing> plinss: i like having a switch to control whether an element positions relative to the ICB but it shouldn't be region-specific. It should be in css3-break and apply to pages and maybe columns
  245. # [10:41] <sylvaing> vincent: so regions should not discuss this at all
  246. # [10:42] <sylvaing> ACTION: vhardy to move the issue to css3-break and remove the text from Regions
  247. # [10:42] * trackbot noticed an ACTION. Trying to create it.
  248. # [10:42] * RRSAgent records action 6
  249. # [10:42] <trackbot> Created ACTION-426 - Move the issue to css3-break and remove the text from Regions [on Vincent Hardy - due 2012-02-14].
  250. # [10:42] <sylvaing> Bert: I've found tha the gr unit should be enough to position objects independently of their containing block
  251. # [10:43] <sylvaing> steve: if you're simulating multicolumns or something like it, you need a different mechanism
  252. # [10:44] <sylvaing> alexmog: you may want positioned elements in your flow to start in a region and cover the next one, you don't want to be constrained by your container or its stacking context.
  253. # [10:46] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15116
  254. # [10:46] <sylvaing> vincent: I don't have a proposal yet.
  255. # [10:46] <sylvaing> ACTION: vhardy to update region styling
  256. # [10:46] * trackbot noticed an ACTION. Trying to create it.
  257. # [10:46] * RRSAgent records action 7
  258. # [10:46] <trackbot> Created ACTION-427 - Update region styling [on Vincent Hardy - due 2012-02-14].
  259. # [10:48] <sylvaing> bert: there might potential confusion between styling the region itself and styling on the elements that end up in a region.
  260. # [10:50] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15828
  261. # [10:50] <fantasai> glazou: would prefer css3-background / css3-text, save selectors 4 for tomorrow. Or later. I think I need more time to collect my thoughts and dig up examples from www-style
  262. # [10:51] <sylvaing> we were missing properties in the CSSOM
  263. # [10:51] <Bert> (If the div defines a grid and has a child p, then 'div::slot(a) {background: red}' sets a bg on the region, while 'p::slot(a) {background: yellow}' sets a bg only on the part of the p that ends up inside that region.)
  264. # [10:51] <sylvaing> we added a way to retrive flows by name and return a collection of existing named flows
  265. # [10:51] <sylvaing> (previous two comments by vincent)
  266. # [10:51] <glazou> fantasai: I want to have a chance to give my opinion on Tab's Hierarchies during this ftf
  267. # [10:52] <sylvaing> tabatkins: I'll suggest a different interface
  268. # [10:52] <sylvaing> glazou: <break>
  269. # [10:52] * Quits: glazou (glazou@128.93.135.193) (Quit: glazou)
  270. # [11:05] * Joins: glazou (glazou@128.93.135.193)
  271. # [11:05] * sylvaing is now known as sylvaing_away
  272. # [11:09] * sylvaing_away is now known as sylvaing
  273. # [11:12] * Quits: Rossen (Rossen@128.93.134.230) (Ping timeout)
  274. # [11:12] * Quits: jet (jet@128.93.134.233) (Ping timeout)
  275. # [11:15] <fantasai> Scribe: fantasai
  276. # [11:15] <vhardy_> ScribeNick: vhardy
  277. # [11:15] <fantasai> Topic: Nesting Style Rules
  278. # [11:15] <TabAtkins_> http://dev.w3.org/csswg/css3-hierarchies/
  279. # [11:15] <glazou> http://dev.w3.org/csswg/css3-hierarchies/
  280. # [11:16] * Joins: Rossen (Rossen@128.93.134.230)
  281. # [11:16] <vhardy_> daniel: i want to discuss this because people discovered the document and started to discuss it as if it was a wg draft. I modified it.
  282. # [11:16] <vhardy_> ... it is a modification of the grammar. Technically, it is not in the charter.
  283. # [11:16] <vhardy_> ... it is about nesting rules and reconstructing the selector based on the parent rule.
  284. # [11:16] <vhardy_> ... the goal is to simplify the selector of the children rules. This has been requested for a long time.
  285. # [11:17] <vhardy_> ... I have a lot of issues and questions.
  286. # [11:17] <vhardy_> ... first the OM. Not enough. Selector text on the style rule is not enough.
  287. # [11:18] <vhardy_> ... selector text is not meaningful, you need to reconstruct looking at the parent style rules.
  288. # [11:18] <vhardy_> tab: right now, there is only the nested selector. WOuld be more useful if we provided the expanded the selector, including the parent selectors.
  289. # [11:18] <vhardy_> peter: if you are going to change that, add an attribute to only get the local selector text.
  290. # [11:19] <vhardy_> daniel: there is a way to navigate the children rules from the parent rule, but not from the children rules to the parent rules.
  291. # [11:19] <vhardy_> tab: we are following media queries.
  292. # [11:19] <vhardy_> daniel: you do not say so.
  293. # [11:19] * Quits: howcome (howcome@128.93.135.80) (Ping timeout)
  294. # [11:19] <vhardy_> tab: we are going to say we follow the structure of the @media rules. If something is missing, we will fix both of them.
  295. # [11:19] <vhardy_> daniel: I have a problem with example #5.
  296. # [11:20] <vhardy_> .... the third nested 'thing' have a rule followed by a declaration followed by a rule. This is an issue in the OM, becaues the declaration is stored in one 'thing' and nested rules are in another. Order cannot be maintained.
  297. # [11:20] <vhardy_> tab: I agree you should put your properties first.
  298. # [11:20] <vhardy_> daniel: the order should be mandatory.
  299. # [11:21] <vhardy_> tab: seems fine.
  300. # [11:21] <vhardy_> florian: I noted that the nested things last rather than first works better. That is where they should be if mandatory.
  301. # [11:22] <vhardy_> daniel: you are using the &. That could be an issue for embeded stylesheets because of encoding rules.
  302. # [11:22] <vhardy_> tab: not a problem in HTML.
  303. # [11:22] <vhardy_> daniel: I do not like the & because there are people will forget to use &amp;
  304. # [11:22] <vhardy_> ... I think we should discourage that. I think this is a problem.
  305. # [11:22] <vhardy_> tab: Ok, I'll look for a replacement.
  306. # [11:23] <vhardy_> daniel: editability is a problem. When an editor needs to add a stylerule, you can look for a stylerule with the same selector. With nesting, it is way more complicated. You need to look for a nested style rules as well. It complexifies.
  307. # [11:23] <vhardy_> tab: if you have the full selector, does that simplify your work?
  308. # [11:24] * Joins: jet (jet@128.93.134.233)
  309. # [11:24] <vhardy_> daniel: when you insert a rule, you have to look for all the rules that have an effect in the cascade and modify them.
  310. # [11:24] <vhardy_> ... I understand this is an important request from the user community, but I would like a clear issue created about editability.
  311. # [11:24] <vhardy_> .... for example, what will happen to legacy browsers.
  312. # [11:25] <vhardy_> tab: they will ignore the nested selectors.
  313. # [11:25] <vhardy_> daniel: will that be used?
  314. # [11:25] <vhardy_> tab: people love that feature.
  315. # [11:26] <vhardy_> jdagget: for things where we have not really taken on a module, could we have a clear marker, something that says this is a 'proposal', not an editor draft.
  316. # [11:26] <vhardy_> tab: yes, that is fine.
  317. # [11:26] <vhardy_> jdagget: the word 'proposal would be ok.
  318. # [11:26] <vhardy_> tab, others: ok.
  319. # [11:26] <vhardy_> steve: moving from proposal to ED is an action of the wg.
  320. # [11:26] <vhardy_> all: yes.
  321. # [11:26] <vhardy_> jdagget: I think this is better to have it here than on someone's blog.
  322. # [11:27] <vhardy_> ... should be a proposal until the group takes it on.
  323. # [11:27] <vhardy_> chris: I did not quite understand the 'expand' the selector thing.
  324. # [11:27] <glazou> http://dev.w3.org/csswg/css3-hierarchies/#nesting-selector
  325. # [11:28] <vhardy_> tab: yes, you have the entire selector.
  326. # [11:28] <vhardy_> chris: then it is duplicated.
  327. # [11:29] <vhardy_> tab: we are talking about selector text in the OM, not in the stylesheet. What is editable is still the short form.
  328. # [11:29] * Joins: alexmog__ (qw3birc@128.30.52.28)
  329. # [11:29] <ChrisL> example 4
  330. # [11:29] <ChrisL> div, p {
  331. # [11:29] <ChrisL> & .keyword, & .constant {color: red;}
  332. # [11:29] <ChrisL> }
  333. # [11:30] <ChrisL> is same as
  334. # [11:30] <ChrisL> div .keyword {color:red;}
  335. # [11:30] <ChrisL> div .constant {color:red;}
  336. # [11:30] <ChrisL> p .keyword {color:red;}
  337. # [11:30] <ChrisL> p .constant {color:red;}
  338. # [11:30] <vhardy_> daniel: In example 4, I would like a change. The parent rule has a group of selectors. The nested rule has a group of selector, if one of the selectors is invalid, the whole is invalid. So use groups in the expanded version of the example.
  339. # [11:30] * Quits: tantek (tantek@128.93.135.10) (Ping timeout)
  340. # [11:30] <vhardy_> tab: changing the example right now.
  341. # [11:30] * Quits: tantek_ (tantek@128.93.135.73) (Ping timeout)
  342. # [11:30] <vhardy_> daniel: I have a suggestion for editability.
  343. # [11:31] * Quits: alexmog_ (qw3birc@128.30.52.28) (Ping timeout)
  344. # [11:34] <vhardy_> ... if you set the selector text, the implementation will need to match with as many parent selectors as possible to compute part of the selector only, and set that part of not. If it fails to compute the parent selector, it will throw an error. This is required, because the selector text is writable.
  345. # [11:35] <vhardy_> jdaggett: one way to implement it, then we could do it a parse time only thing.
  346. # [11:35] <vhardy_> (discussion about how this would be the same as the current server side solutions).
  347. # [11:35] <vhardy_> jdaggett: but it would make it easier to manipulate.
  348. # [11:35] <vhardy_> daniel: I do not think this is something we can _not_ do.
  349. # [11:36] <vhardy_> dbaron: I am not happy about the selector text expansion.
  350. # [11:36] <vhardy_> ... it seems a bit lossy in that you might want the thing with the &, it will be hard to get that.
  351. # [11:36] <vhardy_> daniel: the part with the & is the selector text of the parent rule.
  352. # [11:36] <vhardy_> dbaron: no, the local part.
  353. # [11:36] <vhardy_> (all) we are introducing a way to get the local part.
  354. # [11:37] <vhardy_> dbaron: one advantage of making the new one expanded is that we can make it read-only.
  355. # [11:37] <vhardy_> daniel: I do not have a strong opinion, either way.
  356. # [11:37] <vhardy_> ... I just need both for reading and oupting.
  357. # [11:38] <vhardy_> ... to compute the style, I need both.
  358. # [11:38] <vhardy_> ... for writing I only need the local part.
  359. # [11:38] <vhardy_> ... with that, I think editors can work with such a specification, it is doable.
  360. # [11:38] <vhardy_> ... this said, the question is, do we want to work on this?
  361. # [11:38] <vhardy_> ... do we have CSS grammar in the charter for the next 3 years.
  362. # [11:39] <vhardy_> tab: we have other specs, that will modify the grammar or tweak it.
  363. # [11:39] <vhardy_> ... CSS conditionals will do that for example.
  364. # [11:39] <vhardy_> daniel: section 2 of the charter says that CSS syntax is discontinued.
  365. # [11:39] <vhardy_> chris: this just means that draft is not further developed.
  366. # [11:40] <vhardy_> daniel: if we want to work on that, we have to find a landing spot in the existing charter deliverables or extand the charter.
  367. # [11:40] <vhardy_> chris: or we can fit in the existing charter.
  368. # [11:40] <vhardy_> ... syntax is in the scope section, so we are fine.
  369. # [11:40] <vhardy_> daniel: I needed to check that.
  370. # [11:40] <vhardy_> jdagget: the bigger question is the priority.
  371. # [11:41] <vhardy_> ... it is possibly disruptive. There are a lot of things to work out.
  372. # [11:41] <vhardy_> daniel: this is the kind of item that the author community is looking for.
  373. # [11:41] <vhardy_> tab: error recovery rules are working nicely here.
  374. # [11:41] <vhardy_> jdagget: this has a non trivial cost. We already have a lot that we need to get done.
  375. # [11:42] <vhardy_> chris: yes, we have a priority list already.
  376. # [11:42] <vhardy_> ... the important question is the relative priority.
  377. # [11:42] <vhardy_> peter: is there interest from implementors to implement this.
  378. # [11:42] <vhardy_> ... if there is only one implementor, then we will not get to REC.
  379. # [11:43] <vhardy_> florian: from an Opera point of view, I can easily see how people want that, but it is not at the top of our priority list.
  380. # [11:43] <vhardy_> vhardy: we think this is an important feature for web authors.
  381. # [11:44] <vhardy_> sylvain: no plans right now.
  382. # [11:44] <vhardy_> dbaron: there is a bunch of other things that are higher priorities.
  383. # [11:44] <vhardy_> sylvain: selector 4 is more important.
  384. # [11:46] <vhardy_> daniel: I think it is clear there will not be commitment from the wg members to work on this right now.
  385. # [11:46] <vhardy_> peter: do we want to keep this on the shelve as a proposal or do we take it as a WD?
  386. # [11:46] <vhardy_> jdagget: I think we should keep it as a proposal and ask Tab to mark it as a proposal.
  387. # [11:47] * jdaggett vhardy_: two t's pleaseā€¦ jdaggett
  388. # [11:47] <vhardy_> vhardy: what are the more important things?
  389. # [11:47] <vhardy_> ACTION: Tab to mark the nested selector spec. as a proposal.
  390. # [11:47] * trackbot noticed an ACTION. Trying to create it.
  391. # [11:47] * RRSAgent records action 8
  392. # [11:47] <trackbot> Created ACTION-428 - Mark the nested selector spec. as a proposal. [on Tab Atkins Jr. - due 2012-02-14].
  393. # [11:48] * Joins: tantek (tantek@128.93.135.73)
  394. # [11:49] <vhardy_> vhardy: from the feedback we get, nested selectors, mixins and variables are really important.
  395. # [11:52] * Joins: tantek_ (tantek@128.93.135.10)
  396. # [11:52] * Quits: tantek_ (tantek@128.93.135.10) (Quit: tantek_)
  397. # [11:54] * Joins: tantek_ (tantek@128.93.135.10)
  398. # [11:54] * Joins: howcome (howcome@128.93.135.80)
  399. # [11:54] <fantasai> http://dev.w3.org/csswg/css-line-grid/
  400. # [12:00] <vhardy_> Topic: Fullscreen
  401. # [12:01] <dbaron> http://lists.w3.org/Archives/Public/www-archive/2012Feb/0004.html
  402. # [12:02] <vhardy_> daniel: Art is asking if we have comments / objections to Web apps working on this.
  403. # [12:02] <vhardy_> chris: I think it should be in web apps.
  404. # [12:02] <vhardy_> tantek: there are presentation aspects, right?
  405. # [12:02] <vhardy_> daniel: yes, there are presentation side effects.
  406. # [12:02] <vhardy_> ... but it is mainly an API.
  407. # [12:03] <vhardy_> tantek: this is already in our charter. Art is asking to propose it for their Web apps charter. Why the extra work to put it in the web apps group.
  408. # [12:03] <vhardy_> chris: Anne is willing to do it in the web apps group and he is a member there.
  409. # [12:03] <vhardy_> daniel: there is, in our charter, to do full screen only for CSS, not in general.
  410. # [12:03] <vhardy_> ... it is not limited to css.
  411. # [12:03] <vhardy_> fantasai: then it should be a joined effort.
  412. # [12:04] <vhardy_> daniel: yes, the css part we do, the api they do.
  413. # [12:04] <fantasai> s/joined/joint/
  414. # [12:04] <vhardy_> chris: while we are talking about this type of cooperation, it strikes me that the CSS OM is that something that should be done as a joint effort between the two groups.
  415. # [12:04] * Joins: CGI232 (805d87e1@128.30.52.43)
  416. # [12:05] <vhardy_> tantek: I think we have broader dissipation in this group from different companies. From an early exposure to commit patent ip, this group is better than the Web apps group, seeing what happened with touch events.
  417. # [12:05] * sylvaing is now known as sylvaing_away
  418. # [12:05] <vhardy_> ... css wg is better than web apps in that way.
  419. # [12:05] <vhardy_> ... so the work should be done here.
  420. # [12:06] <vhardy_> tantek: the web apps wg does not have as many companies, so if the work is done in the CSS wg, we stand a better chance to get disclosures/exclusions sooner than later.
  421. # [12:06] <vhardy_> ... touch events has been blocked by a patent from Apple.
  422. # [12:06] <vhardy_> ... since they are not in the web apps working group, they could do that.
  423. # [12:06] <vhardy_> tantek: so it is better to do this work, from an IP point of view, in the CSSWG.
  424. # [12:07] <vhardy_> florian: what are the implications of joint work?
  425. # [12:07] <vhardy_> chris: the union of the membership of both groups has the same disclosure obligations over the entire spec.
  426. # [12:07] <vhardy_> tantek: I have not problem co-editing with Anne.
  427. # [12:08] <vhardy_> s/not/no
  428. # [12:08] <vhardy_> daniel: my next question: does the group feel taht the argument tantek give about size and IPr rule are the arguments I should present to Art?
  429. # [12:08] <vhardy_> florian: working jointly is the option we should present.
  430. # [12:09] <vhardy_> bert: the argument about members is not strong, because they have Apple and they have companies that we do not have.
  431. # [12:10] <vhardy_> tantek: for example, Flash has a fullscreen API and Adobe is not a member of the Web Apps wg.
  432. # [12:10] <vhardy_> peter: I agree with you, but if you are trying to bring everybody under the tent, then you may force someone out of the tent. This is a risk.
  433. # [12:11] <vhardy_> florian: however, full screen is already in the charter.
  434. # [12:11] <vhardy_> tantek: but hte disclosure requirements happen at FPWD time.
  435. # [12:11] <vhardy_> daniel: so we will propose for a joint effort?
  436. # [12:12] <vhardy_> ACTION: daniel to answer Art about joint work between CSS and Web Apps WG on fullscreen CSS and APIs.
  437. # [12:12] * trackbot noticed an ACTION. Trying to create it.
  438. # [12:12] <trackbot> Sorry, amibiguous username (more than one match) - daniel
  439. # [12:12] <trackbot> Try using a different identifier, such as family name or username (eg. dglazman, dweck2)
  440. # [12:12] * RRSAgent records action 9
  441. # [12:13] <vhardy_> Topic: Schedule for Snapshot 2012: end or start of the year?
  442. # [12:13] <vhardy_> peter: last time we discussed it, we said we would do a snapshot every year.
  443. # [12:14] <vhardy_> bert: is that what worked before 2012 or starting 2012?
  444. # [12:14] <vhardy_> chris: if you publish at the end of 2012, then people think they are dealing with an old spec.
  445. # [12:14] <vhardy_> fantasai: we can publish at any point, but the question, is, do we expect to add things to the snapshot (and have test suite).
  446. # [12:15] <vhardy_> .. I thinjk we are just going to republish with a new date.
  447. # [12:15] <vhardy_> s/thinjk/think
  448. # [12:15] <vhardy_> dbaron: 2d transform could be there.
  449. # [12:15] <vhardy_> peter: media queries.
  450. # [12:15] <vhardy_> tab: images will have a test suite.
  451. # [12:16] <vhardy_> fantasai: we also need at least an implementation that passes most of the testsuite and failures understood.
  452. # [12:16] <vhardy_> chris: this is still a prediction: we expect things to get out of CR soon.
  453. # [12:16] <vhardy_> fantasai: yes, e.g., MQ made it because we understood the failures and there was a test suite and implementation.
  454. # [12:16] <vhardy_> chris: if the point is to publish one every year, then we would sometimes republish the same thing.
  455. # [12:17] <vhardy_> peter: we should publish at least once a year. We may publish several times a year.
  456. # [12:17] <vhardy_> ... it is just a note about the current state of the world and we update as necessary but at least once a yaer.
  457. # [12:18] <vhardy_> steve: we need to indicate some level of stability, but publishing a new number if there is no changes is not useful.
  458. # [12:18] <vhardy_> peter: i think there is a benefit.
  459. # [12:18] <vhardy_> ... if there isn't one that is current, which one do you look at?
  460. # [12:18] <vhardy_> steve: the most recent one.
  461. # [12:19] <vhardy_> peter: this is the problem with open type projects. If something is not updated, you do not know if this is because people did not publish the update or because nothing is happening. This has value.
  462. # [12:19] <vhardy_> steve: ok, understood.
  463. # [12:19] <vhardy_> peter: so I would like to publish snapshot 2012 asap and we will republish immediately if new things are eligible.
  464. # [12:19] <vhardy_> bert: I think that is too often.
  465. # [12:20] <vhardy_> ... publishing often seems unstable.
  466. # [12:20] <vhardy_> chris: we need to communicate that the stability state has changed.
  467. # [12:20] <vhardy_> bert: ... people can wait 6 months.
  468. # [12:21] <vhardy_> chris: we give people a short spec. that says what is stable.
  469. # [12:21] <vhardy_> peter: the snapshot is a note, it is easy to publish. It is for communication.
  470. # [12:21] <vhardy_> tantek: I think we should update the snapshot everytime a spec. goes to CR.
  471. # [12:22] <vhardy_> several: that is not the criteria, the criteria is that the spec. is almost ready to exit CR.
  472. # [12:22] <vhardy_> steve: once a year is fine.
  473. # [12:22] <vhardy_> tantek: I propose to publish at the begining of the year.
  474. # [12:22] <vhardy_> several: yes.
  475. # [12:24] <vhardy_> RESOLUTION: the CSS snapshot will be published once a year, at the begining of the year, and every time a new specification meets the criteria for being listed in the snapshot note.
  476. # [12:24] <vhardy_> ACTION: Fantasai to publish snapshot 2012 ASAP>
  477. # [12:24] * RRSAgent records action 10
  478. # [12:24] * trackbot noticed an ACTION. Trying to create it.
  479. # [12:24] <trackbot> Created ACTION-429 - Publish snapshot 2012 ASAP> [on Elika Etemad - due 2012-02-14].
  480. # [12:25] <vhardy_> Topic: Media Queries REC http://lists.w3.org/Archives/Public/public-css-testsuite/2012Jan/0001.html
  481. # [12:27] <vhardy_> fantasai: we need an implementation report.
  482. # [12:27] <vhardy_> florian: what is the status of the test suite?
  483. # [12:27] <vhardy_> peter: it was being reworked.
  484. # [12:27] <vhardy_> fantasai: that does not make the tests invalid.
  485. # [12:27] <vhardy_> chris: this is a case of what you use for generating the report.
  486. # [12:27] <vhardy_> (history of the test suite and who contributed).
  487. # [12:28] <vhardy_> peter: the test suite has sufficient coverage of the spec?
  488. # [12:28] <dbaron> http://www.w3.org/Style/CSS/Test/MediaQueries/20100726/
  489. # [12:29] <ChrisL> http://www.w3.org/Style/CSS/Test/MediaQueries/20100726/
  490. # [12:29] <vhardy_> dbaron: I think we need to publish a new snapshot of the test suite.
  491. # [12:29] <vhardy_> ACTION: fantasai to publish a new snapshot of the MQ test suite.
  492. # [12:29] * trackbot noticed an ACTION. Trying to create it.
  493. # [12:29] * RRSAgent records action 11
  494. # [12:29] <trackbot> Created ACTION-430 - Publish a new snapshot of the MQ test suite. [on Elika Etemad - due 2012-02-14].
  495. # [12:30] <plinss> MQ test suite source: http://hg.csswg.org/test/file/tip/contributors/anne/submitted/mediaqueries
  496. # [12:31] <vhardy_> daniel: implementation reports by?
  497. # [12:31] <vhardy_> Mozilla, Opera
  498. # [12:32] <vhardy_> ACTION: dbaron to provide an implementation report for the MQ test suite.
  499. # [12:32] * RRSAgent records action 12
  500. # [12:32] * trackbot noticed an ACTION. Trying to create it.
  501. # [12:32] <trackbot> Created ACTION-431 - Provide an implementation report for the MQ test suite. [on David Baron - due 2012-02-14].
  502. # [12:32] <vhardy_> ACTION: florian to provide an implementation report for the MQ test suite.
  503. # [12:32] * trackbot noticed an ACTION. Trying to create it.
  504. # [12:32] * RRSAgent records action 13
  505. # [12:32] <trackbot> Created ACTION-432 - Provide an implementation report for the MQ test suite. [on Florian Rivoal - due 2012-02-14].
  506. # [12:33] <ChrisL> testing Opera.next Version
  507. # [12:33] <ChrisL> 12.00 alpha
  508. # [12:33] <ChrisL> Build
  509. # [12:33] <ChrisL> 1272
  510. # [12:34] <ChrisL> Passed: 254
  511. # [12:34] <ChrisL> Failed: 107
  512. # [12:35] <vhardy_> ACTION: smfr to provide an implementation report for the MQ test suite.
  513. # [12:35] * RRSAgent records action 14
  514. # [12:35] * trackbot noticed an ACTION. Trying to create it.
  515. # [12:35] <trackbot> Created ACTION-433 - Provide an implementation report for the MQ test suite. [on Simon Fraser - due 2012-02-14].
  516. # [12:37] * Quits: glazou (glazou@128.93.135.193) (Quit: glazou)
  517. # [12:37] <vhardy_> ===== LUNCH BREAK ======
  518. # [12:37] * Quits: jdaggett (jdaggett@128.93.135.115) (Quit: jdaggett)
  519. # [12:37] * Quits: jet (jet@128.93.134.233) (Quit: jet)
  520. # [12:40] * Quits: vhardy_ (qw3birc@128.30.52.28) (Ping timeout)
  521. # [12:40] * Quits: szilles (chatzilla@128.93.134.251) (Ping timeout)
  522. # [12:40] * Quits: smfr (smfr@128.93.134.211) (Quit: smfr)
  523. # [12:41] * Joins: Ms2ger (Ms2ger@94.224.25.87)
  524. # [12:42] * plinss is now known as plinss_away
  525. # [12:42] * Quits: tantek_ (tantek@128.93.135.10) (Quit: tantek_)
  526. # [12:42] * Joins: lhnz (lhnz@188.223.83.48)
  527. # [12:43] * Quits: tantek (tantek@128.93.135.73) (Quit: tantek)
  528. # [12:43] * Quits: howcome (howcome@128.93.135.80) (Ping timeout)
  529. # [12:43] * Quits: TabAtkins_ (tabatkins@74.125.122.49) (Ping timeout)
  530. # [12:43] * Quits: Rossen (Rossen@128.93.134.230) (Ping timeout)
  531. # [12:44] * Quits: dbaron (dbaron@128.93.135.77) (Ping timeout)
  532. # [12:45] * Quits: lhnz (lhnz@188.223.83.48) (Quit: Leaving)
  533. # [13:09] * Quits: Ms2ger (Ms2ger@94.224.25.87) (Ping timeout)
  534. # [13:15] * Joins: Ms2ger (Ms2ger@94.224.25.87)
  535. # [13:21] * sylvaing_away is now known as sylvaing
  536. # [13:23] * Quits: Ms2ger (Ms2ger@94.224.25.87) (Ping timeout)
  537. # [13:24] * Joins: Ms2ger (Ms2ger@94.224.25.87)
  538. # [13:24] * Zakim excuses himself; his presence no longer seems to be needed
  539. # [13:24] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  540. # [13:28] * Quits: Ms2ger (Ms2ger@94.224.25.87) (Quit: Leaving)
  541. # [13:44] * Joins: jdaggett (jdaggett@128.93.135.115)
  542. # [14:11] * Joins: smfr (smfr@128.93.134.211)
  543. # [14:14] * Joins: tantek (tantek@128.93.135.10)
  544. # [14:15] * plinss_away is now known as plinss
  545. # [14:17] <smfr> http://wiki.csswg.org/planning/paris-2012
  546. # [14:17] * Joins: tantek_ (tantek@128.93.135.73)
  547. # [14:17] * Joins: glazou (glazou@128.93.135.193)
  548. # [14:17] * Joins: dbaron (dbaron@128.93.135.77)
  549. # [14:17] <fantasai> Scribe: fantasai
  550. # [14:17] <fantasai> Topic: WebKit Prefix Conversations
  551. # [14:17] <fantasai> plinss: Had various offline conversations.
  552. # [14:18] <fantasai> plinss: Tantek / roc talking about creating this list of properties they're considering for webkit prefixing
  553. # [14:18] <fantasai> plinss: Would like that list given to WG ASAP
  554. # [14:18] * Joins: kojiishi (kojiishi@128.93.135.158)
  555. # [14:18] <fantasai> plinss: Rather than vendors making blog posts saying "this is what we're going to do", would rather vendors brought these lists to us so we can reset our priorities
  556. # [14:19] <fantasai> plinss: There is market interest in these properties. They are ready to be implemented, or already implemented, interoperably by multiple vendors. Therefore they meet the criteria to be standardized
  557. # [14:19] <fantasai> plinss: No reason they shouldn't be standardized immediately.
  558. # [14:20] <fantasai> plinss: If vendors feel there is sufficient market pressure tha it's rucial to their business, that should be our highest priority.
  559. # [14:20] <fantasai> plinss: So I would like to get buy-in from the group that this is the right approach.
  560. # [14:20] <fantasai> plinss: Would like commitment from vendors considering this to talk to us, let us address this as quickly as possible.
  561. # [14:20] * Joins: jet (jet@128.93.134.233)
  562. # [14:20] <fantasai> Florian: I'm convinced this is a good idea. Concerned it's not sufficient, but regardless we need to do it.
  563. # [14:21] <fantasai> plinss: I accept it may not be sufficient. I hope it is. But we should as a WG do what we can to alleviate this market pressure.
  564. # [14:21] <fantasai> plinss: Asking for commitment to get this list from vendors asap, and bring it first to WG not to vendor blogs
  565. # [14:22] <fantasai> glazou: .... expand the evangelism commmunity.
  566. # [14:22] <fantasai> glazou: let's try everything before going to the last resort
  567. # [14:22] <fantasai> glazou: I have two options for the article. Can call community at large.
  568. # [14:23] <fantasai> Florian: Idea is a call to the community at large to be responsible for how they use prefixes.
  569. # [14:23] <fantasai> Florian: vendors have tried that on their own, he's suggesting to do it together.
  570. # [14:23] <fantasai> plinss: I think if we have 2-3 vendors effectively agree on an implementation, whether it's because they like it or they're locked into it, that's sufficient for us to declare that it's enough for us to drop prefixes.
  571. # [14:23] <fantasai> plinss: Then we can call on all sites to drop prefixes.
  572. # [14:24] <fantasai> glazou: Want to move from de facto to de jure standards.
  573. # [14:24] <fantasai> tantek: Daniel, such an article might help. Need to point out 2 things.
  574. # [14:24] <fantasai> tantek: First, point out that -webkit- is hurting the web.
  575. # [14:24] <fantasai> tantek: 2 problems. First is UA-sniffing, only providing modern web content to webkit
  576. # [14:24] <fantasai> tantek: 2nd problem is that there are numerous features that work effectively interoperably across browsers
  577. # [14:25] <fantasai> tantek: That if those sites put multiple prefixes today, without any change from this group, they would work.
  578. # [14:25] <fantasai> glazou: Even if we're not sure that it will work, I think it is worht trying. I don't want us to take last resort option without trying.
  579. # [14:26] <fantasai> tantek: We'd rather sites provided full content to Mozilla and have it break, than provide dumb content to us. I think we're fixing things fast enough that we can respond to that. But it's the webkit-only coding that is harmful.
  580. # [14:26] <fantasai> glazou: Let's suppose it works a bit, and you see a trend of websites adding properties and not sniffing. Will that be sufficient for you to decide to wait?
  581. # [14:26] <fantasai> tantek: Will look at data on a case-by-case basis. If data changes, conclusions may change.
  582. # [14:26] <fantasai> plinss: Need to tackle this on all fronts.
  583. # [14:27] <fantasai> plinss: Need to evaluate list of properties, resolve to drop prefixes for those that are ready.
  584. # [14:27] <fantasai> tantek: I don't want to provide a list of properties, because I don't want anything that developers can depend on.
  585. # [14:28] <fantasai> fantasai: What about providing a list to the CSSWG list?
  586. # [14:28] <fantasai> tantek: Might change over time.
  587. # [14:28] <fantasai> Florian: Peter asked for the list to set priorities.
  588. # [14:28] <fantasai> Alan: Should emphasize that can use all prefixed versions right now, and without any changes by us, will work today.
  589. # [14:28] <fantasai> Alan: And we should be trying to drop prefixes on the things that work in that way.
  590. # [14:29] <fantasai> Tantek: We already have that focus in the WG. But things that are outstanding measures in the WG.
  591. # [14:29] <fantasai> ...
  592. # [14:29] <fantasai> plinss: The moment you have sufficient data about one property. If nothing else, send it to Daniel and I, so that we can make it #1 priority on the next telecon.
  593. # [14:30] <fantasai> plinss: My assertion is, just like we were driving 2.1 to REC, that was highest priority. I'm offering you and Opera and MS, that level of priority if you get to that point on any property.
  594. # [14:30] <fantasai> plinss: That will be the #1 focus of the group to drop that prefix.
  595. # [14:30] <fantasai> tantek: Ok. I'm willing to put that on css-wg list. Don't want to kick of some kind of flamewar on www-style. Minutes of discussion will of course be public.
  596. # [14:31] <fantasai> tantek: We may wind up posting list to wiki page, but we have better things to do than write blog posts aobut it.
  597. # [14:31] <fantasai> plinss: If we can help the situation by dropping the prefix, we will drop the prefix.
  598. # [14:32] <ChrisL> pointer to prefixing policy doc?
  599. # [14:33] * Joins: TabAtkins_ (tabatkins@74.125.122.49)
  600. # [14:33] <smfr> http://www.w3.org/TR/CSS/#experimental
  601. # [14:34] <fantasai> fantasai: Note that we do have a loophole in the vendor-prefixing policy that the WG can declare an experimental property to be implemented prefixless *for legacy reasons*. This was originally for things like text-overflow, but existing webkit-only content on the web also qualifies as a legacy reason.
  602. # [14:34] <fantasai> fantasai: So if we have a spec that we cannot move fast enough to CR, we can use that loophole to drop prefixes immediately.
  603. # [14:36] <fantasai> fantasai: [says stuff]
  604. # [14:36] <fantasai> smfr: [1-3 months]
  605. # [14:36] <fantasai> fantasai: Will that happen?
  606. # [14:37] <fantasai> smfr: We can make that happen.
  607. # [14:37] <fantasai> Tantek: How about we go to CR with open issues?
  608. # [14:38] <fantasai> fantasai: What's the point of that? The CR transition requires no open issues. If your problem is you want to drop prefixes with open issues, then drop prefixes before CR.
  609. # [14:38] * Joins: szilles (chatzilla@128.93.134.251)
  610. # [14:38] <fantasai> jdaggett: You can defer issues, e.g. mark things undefined.
  611. # [14:39] <fantasai> Tantek:
  612. # [14:40] <fantasai> Tantek: You'll get issues faster than you can evaluate them, just like 2.1
  613. # [14:40] <fantasai> fantasai: We haven't had that problem to the extent we had it with 2.1 with our CSS3 modules
  614. # [14:40] <fantasai> fantasai: What do you want out of moving to CR?
  615. # [14:40] <fantasai> Tantek: Dropping prefixes
  616. # [14:40] <fantasai> fantasai: So let's drop prefixes and not change the definition of CR, what's the problem?
  617. # [14:40] <fantasai> Tantek: ...
  618. # [14:41] <fantasai> Tantek: I think it's more important to use CR as a marker for dropping prefixes than a marker for closing issues.
  619. # [14:41] <fantasai> Tantek: ...
  620. # [14:42] <fantasai> plinss: To make progress faster, as a group, we can drop prefixes before CR. And if there's a singificant portion that is stable and has no issues, is ready to go to CR, we split the spec.
  621. # [14:42] <fantasai> plinss: And we are also willing to run through issues and solve or defer them quickly.
  622. # [14:42] <fantasai> plinss: We have three different avenues and we're willing to use them all as needed.
  623. # [14:42] <fantasai> Tantek: Sounds good.
  624. # [14:43] <fantasai> Topic: Backgrounds and Borders
  625. # [14:43] <TabAtkins_> ScribeNick: TabAtkins_
  626. # [14:43] <fantasai> http://www.w3.org/Style/CSS/Tracker/products/11
  627. # [14:43] <TabAtkins_> fantasai: Bert and I have been going through the B&B issues.
  628. # [14:43] <TabAtkins_> fantasai: There are a couple open ones, with proposed reoslutions, but we need the WG to evaluate them.
  629. # [14:44] <TabAtkins_> fantasai: First is bidi reordering and the application of box-decoration:break
  630. # [14:44] <fantasai> http://dev.w3.org/csswg/css3-background/#the-box-decoration-break
  631. # [14:44] * Joins: vhardy_ (qw3birc@128.30.52.28)
  632. # [14:44] <TabAtkins_> fantasai: After the discussion with dbaron, I edited in text that says UAs *may* apply box-decoration to control rendering at bidi-imposed breaks.
  633. # [14:44] <fantasai> "UAs may also apply ā€˜box-decoration-breakā€™ to control rendering at bidi-imposed breaks, i.e. when bidi reordering causes an inline to split into non-contiguous fragments. Otherwise such breaks are always handled as ā€˜sliceā€™. "
  634. # [14:44] <TabAtkins_> fantasai: Otherwise, such breaks are handled as slice.
  635. # [14:44] <TabAtkins_> fantasai: Are people happy with this?
  636. # [14:45] <TabAtkins_> TabAtkins_: Is there a particular reason to keep it optional right now?
  637. # [14:45] * Joins: glenn (gadams@174.29.105.126)
  638. # [14:45] <TabAtkins_> dbaron: We don't have a strict definition of where bidi breaks happen.
  639. # [14:45] <TabAtkins_> dbaron: And we probably, in reality, want to split breaks into two groups, one of which pays attention ot the property, and the other which always slices.
  640. # [14:45] <TabAtkins_> fantasai: This is a weird edge case, so this lets the UA do whatever makes sense right now.
  641. # [14:46] <TabAtkins_> fantasai: The default behavior is 'slice' (the easy case), so the suggested solution is to optionally apply 'break' when specified if the UA has a good way to do it.
  642. # [14:47] <TabAtkins_> dbaron: Is it conformant to do a split between the two?
  643. # [14:47] <TabAtkins_> fantasai: I don't think it's conformant with this wording.
  644. # [14:47] <TabAtkins_> dbaron: I think it's the most sensible behavior, at least given by the way we consider these breaks to exist.
  645. # [14:47] <TabAtkins_> fantasai: That's why we have the term "contiguous".
  646. # [14:48] <TabAtkins_> dbaron: I want tests in the test suite for this.
  647. # [14:48] <TabAtkins_> fantasai: Ok.
  648. # [14:48] <TabAtkins_> [no further objections]
  649. # [14:48] <TabAtkins_> fantasai: Next issue is the corner transitions in border-radius
  650. # [14:48] <fantasai> http://dev.w3.org/csswg/css3-background/#corner-transitions
  651. # [14:49] <TabAtkins_> fantasai: The spec as I brought up before is *completely* wrong. But we don't have a good definition for the right behavior, so the idea right now is to make it officially undefined for now.
  652. # [14:49] <fantasai> Color and style transitions must be contained within the segment of the border that intersects the smallest rectangle that contains both border radii as well as the center of the inner curve (which may be a point representing the corner of the padding edge, if the border radii are smaller than the border-width).
  653. # [14:49] <fantasai> If one of these borders is zero-width, then the other border takes up the entire transitional area. Otherwise, the center of color and style transitions between adjoining borders must be proportional to the ratio of the border widths such that a function of its location is continuous with respect to this ratio. However it is not defined what these transitions look like or how ā€œproportionalā€ maps to a point on the curve.
  654. # [14:49] <TabAtkins_> fantasai: This way, the spec is at least not *wrong*, and we can figure out the correct behavior in level 4.
  655. # [14:50] <TabAtkins_> fantasai: [explains the above text]
  656. # [14:51] <TabAtkins_> plinss: Didn't we discuss this at TPAC?
  657. # [14:51] <TabAtkins_> fantasai: We did, and concluded we needed to investigate a lot more before we could correctly specify it.
  658. # [14:51] <TabAtkins_> fantasai: This way, we're defining the important bits that people rely on.
  659. # [14:52] <TabAtkins_> fantasai: Like that a zero-width border won't contribute any visible color.
  660. # [14:53] <TabAtkins_> fantasai: And that larger borders are proportional in some way.
  661. # [14:53] <TabAtkins_> sylvaing: What's the important bit, precisely, and who depends on it?
  662. # [14:54] <TabAtkins_> fantasai: One example is a box with only a border on top that curves around. The sides will usually just be currentColor, and authors don't expect that to show up.
  663. # [14:54] * Joins: drublic (drublic@77.2.157.148)
  664. # [14:55] <TabAtkins_> tantek_: I think we could instead hook that to border-style. If the side is border-style:none, don't show any of the dest color. But if it's solid, even if it's 0px, when you do a gradient it should fade to that.
  665. # [14:55] * Joins: howcome (howcome@128.93.135.80)
  666. # [14:55] * Joins: Rossen (Rossen@128.93.134.230)
  667. # [14:56] <TabAtkins_> Bert: I think that's what Konqueror does.
  668. # [14:56] <fantasai> fantasai: So you want to replace 'zero-width' with 'none or hidden'.
  669. # [14:56] <TabAtkins_> dbaron: I think that removes the continuity argument.
  670. # [14:56] <TabAtkins_> Bert: Not sure. We need more research, or to leave it open.
  671. # [14:57] <TabAtkins_> tantek_: I'm okay with leaving it open, I just wanted to present it as a use-case.
  672. # [14:57] <TabAtkins_> fantasai: So if you wanted to use a double or dashed border...
  673. # [14:57] <TabAtkins_> tantek_: Borders historically have been places where we allow impls to give better results, rather than locking them into an LCD.
  674. # [14:58] <TabAtkins_> fantasai: So we still want to define, at least in the 'none' case, that the entire visible border is the color of the non-'none' border.
  675. # [14:58] <TabAtkins_> fantasai: But that makes dbaron unhappy.
  676. # [14:59] <TabAtkins_> dbaron: I don't think the color at the corner is ever what's desirable.
  677. # [14:59] <TabAtkins_> fantasai: So how should we resolve this?
  678. # [15:00] <TabAtkins_> dbaron, smfr: I'm happy leaving it as it is.
  679. # [15:01] <TabAtkins_> plinss: Can we resolve to accept the text in the editor's draft?
  680. # [15:01] <TabAtkins_> [no objection]
  681. # [15:01] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/214
  682. # [15:01] <TabAtkins_> fantasai: Next issue, define the default shadow color.
  683. # [15:01] <TabAtkins_> RESOLVED: Accept the ED text for border-transitions.
  684. # [15:02] <TabAtkins_> RESOLVED: Accept the proposed resolution for bidi splits and box-break
  685. # [15:02] <fantasai> Options mentioned so far:
  686. # [15:02] <fantasai> - black
  687. # [15:02] <fantasai> - rgba(0,0,0,0.5)
  688. # [15:02] <fantasai> - currentColor
  689. # [15:02] <fantasai> - currentColor except it doesn't compute until after inheritance
  690. # [15:02] <fantasai> - make <color> required
  691. # [15:02] <TabAtkins_> fantasai: There's a bunch of options: 'black', 'rgba(0,0,0,.5)', 'currentColor', 'currentColor, but used-value time', or require it be defined.
  692. # [15:03] <TabAtkins_> dbaron: Are we discussing box-shadow, or text-shadow as well? And what do the specs currently say?
  693. # [15:03] <TabAtkins_> fantasai: Both, and they shoudl be consistent. They both say "UA defined" right now.
  694. # [15:05] <TabAtkins_> dbaron: Gecko seems to use currentColor for both shadows, almost.
  695. # [15:05] <TabAtkins_> dbaron: I think, though, that on text-shadow, if the text decorations are a different color form the text, the default shadow *on the decorations* will match the decoration color.
  696. # [15:06] <fantasai> fantasai: Ok, so 6 options (for text-shadow; doesn't make a difference for box-shadow)
  697. # [15:06] <TabAtkins_> plinss: Any opinions?
  698. # [15:08] <dbaron> data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"color%3A orange%3B text-shadow%3A 20px 20px">hello<%2Fspan><%2Fspan>
  699. # [15:08] <TabAtkins_> dbaron: Above data url confirms Gecko's text-shadow handling.
  700. # [15:09] <TabAtkins_> smfr: I think WebKit defaults to transparent.
  701. # [15:11] <TabAtkins_> fantasai: We could still make it required.
  702. # [15:11] <TabAtkins_> dbaron: I'm not comfortabl ewith a syntax change at this point.
  703. # [15:11] <TabAtkins_> dbaron: Opera doesn't shadow decorations at all.
  704. # [15:11] <fantasai> Tab: When we do equivalent of fill on text, filling text with images, what will text-shadow do then?
  705. # [15:12] <fantasai> Florian: Will it behave like stained glass or not?
  706. # [15:12] <fantasai> smfr: I think black as a default color would be easier to understand.
  707. # [15:12] <fantasai> Tab: Given we have random answers right now, we could pick anything.
  708. # [15:13] <dbaron> data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"text-decoration:line-through;color%3A orange%3B text-shadow%3A 20px 20px">hello<%2Fspan><%2Fspan>
  709. # [15:14] <fantasai> [people run tests on various UAs]
  710. # [15:15] <TabAtkins_> sylvaing: IE10 shadows text and decorations both with the currentColor.
  711. # [15:18] <fantasai> [discussing defaulting to black]
  712. # [15:18] <fantasai> Bert: we have an implementation: Konqueror defaults to black
  713. # [15:18] <dbaron> http://www.w3.org/TR/1998/REC-CSS2-19980512/text.html#text-shadow-props says to use the current color
  714. # [15:19] <TabAtkins_> [everyone checks what the default for box-shadow is in UAs]
  715. # [15:20] <dbaron> data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"text-decoration:line-through;color%3A orange%3B text-shadow%3A 20px 20px;box-shadow: 40px 40px">hello<%2Fspan><%2Fspan>
  716. # [15:23] <fantasai> Proposed to make box-shadow default to the value of the 'color' property on the element being shadowed. computed value doesn't have a color if it's not specified.
  717. # [15:23] <fantasai> RESOLVED: box-shadow as above
  718. # [15:23] <TabAtkins_> fantasai: We fixed some definitions surrounding border-image and SVG. We need review to ensure they're correct.
  719. # [15:24] * Quits: glenn (gadams@174.29.105.126) (Ping timeout)
  720. # [15:24] <TabAtkins_> fantasai: [explains the text in the spec]
  721. # [15:24] <fantasai> http://dev.w3.org/csswg/css3-background/#the-border-image-source
  722. # [15:24] <fantasai> If the image must be sized to determine the slices (for example, for SVG images with no intrinsic size), then it is sized as for an auto-sized background, using the border image area as the default object size in place of the background positioning area.
  723. # [15:26] <TabAtkins_> fantasai: If the image has an intrinsic size, you don't need to size it to cut it.
  724. # [15:28] <TabAtkins_> ChrisL: It won't tile in the sense tha tyou have only one copy of the image.
  725. # [15:29] <karl> RRSagent, pointer?
  726. # [15:29] <RRSAgent> See http://www.w3.org/2012/02/07-css-irc#T14-21-48
  727. # [15:29] <TabAtkins_> dbaron: It seems there may be a solution wher eyou just end up with one copy of the imgae.
  728. # [15:29] <TabAtkins_> dbaron: Except you're doing sizing before doing slicing to fill the border.
  729. # [15:29] <karl> RRSAgent, make logs public
  730. # [15:29] <RRSAgent> I have made the request, karl
  731. # [15:29] <karl> RRSAgent, draft minutes
  732. # [15:29] <RRSAgent> I have made the request to generate http://www.w3.org/2012/02/07-css-minutes.html karl
  733. # [15:30] <TabAtkins_> [some discussion]
  734. # [15:30] <TabAtkins_> dbaron: I guess it's fine.
  735. # [15:30] <dbaron> (I still don't really know what it means, but I don't think it matters.)
  736. # [15:30] * Joins: glenn (gadams@174.29.118.145)
  737. # [15:31] <TabAtkins_> RESOLVED: Accept the ED text for border-image-slice.
  738. # [15:32] <TabAtkins_> fantasai: next issue is animations.
  739. # [15:32] <Bert> ISSUE-215?
  740. # [15:32] * trackbot getting information on ISSUE-215
  741. # [15:32] <trackbot> ISSUE-215 -- Animatability of box-shadow: none to box-shadow: <shadow> -- raised
  742. # [15:32] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/215
  743. # [15:32] <TabAtkins_> fantasai: We added the animatable field to the spec.
  744. # [15:32] <TabAtkins_> fantasai: It should match transitions in general.
  745. # [15:32] <TabAtkins_> fantasai: One different area is the box-shadow property.
  746. # [15:33] <TabAtkins_> fantasai: We currently say "animatable: yes, but not between inset and outset". We'll deal with that kind later.
  747. # [15:33] <ChrisL> specifying animatability on all properties is good
  748. # [15:33] <TabAtkins_> fantasai: And we say that transition to/from an absent shadow is between "0 0 transparent".
  749. # [15:33] <TabAtkins_> fantasai: So you can transition between box-shadow:none and box-shadow:<something>
  750. # [15:34] <TabAtkins_> tantek_: Is there a reference to what we mean by "animatable"?
  751. # [15:34] * Quits: glenn (gadams@174.29.118.145) (Ping timeout)
  752. # [15:34] <TabAtkins_> fantasai: yeah, the transitions spec.
  753. # [15:34] <TabAtkins_> tantek_: So that's a normative dependency?
  754. # [15:35] <TabAtkins_> Bert: Not quite.
  755. # [15:35] <TabAtkins_> dbaron: The idea is that specs that happen before Transitions, Transitions defines how they work. Ones published afterwards, the spec defines how they work.
  756. # [15:35] <TabAtkins_> dbaron: We're maybe racing with Transitions with this spec, but it's not a big deal.
  757. # [15:36] <TabAtkins_> ChrisL: But every spec will end up with animation information?
  758. # [15:36] <TabAtkins_> dbaron: Yes, when they next update.
  759. # [15:36] <ChrisL> ok, good
  760. # [15:36] <TabAtkins_> tantek_: For specs that are ahead in progress of Transitions, we should have Transitions contain that information.
  761. # [15:37] <TabAtkins_> dbaron: I don't agree.
  762. # [15:38] <TabAtkins_> fantasai: Unless someone has a *really good reason* why this is a process problem, we shouldn't worry about it. It's better to be consistent and have all the specs work the same way.
  763. # [15:38] <TabAtkins_> plinss: At TPAC we discussed transitioning between inset/outset shadows.
  764. # [15:38] <TabAtkins_> TabAtkins_: I don't think we have a good answer for it yet.
  765. # [15:38] <TabAtkins_> fantasai: We'll address it in level 4.
  766. # [15:38] <TabAtkins_> plinss: Okay.
  767. # [15:39] <TabAtkins_> fantasai: That's all the issues, so Bert and I need to compile the list of changes.
  768. # [15:40] <fantasai> ACTION fantasai: if animating from none to inset shadow, need none to behave as '0 0 transparent inset'
  769. # [15:40] * RRSAgent records action 15
  770. # [15:40] * trackbot noticed an ACTION. Trying to create it.
  771. # [15:40] <trackbot> Created ACTION-434 - If animating from none to inset shadow, need none to behave as '0 0 transparent inset' [on Elika Etemad - due 2012-02-14].
  772. # [15:40] <TabAtkins_> smfr: Issue - If going from 'none' to an inset shadow, need to support the 'none' being treated as "0 0 transparent inset".
  773. # [15:40] <dbaron> (or for a list being shorter)
  774. # [15:40] <dbaron> (and none really gets treated as a 0-length list)
  775. # [15:40] <TabAtkins_> RESOLVED: Accept ED text for all animatable properties.
  776. # [15:40] * Joins: glenn (gadams@174.29.122.52)
  777. # [15:41] <TabAtkins_> fantasai: So Bert and I will make the edits and compile the list of changes, then present beofr eth enext telcon.
  778. # [15:41] <TabAtkins_> fantasai: So question, can we republish CR with the changes, or do we need to go back to LC.
  779. # [15:42] <TabAtkins_> szilles: Did you do anything that would invalidate an existing impl?
  780. # [15:43] <TabAtkins_> fantasai: Yes, we made the default shadow color more precise.
  781. # [15:43] <TabAtkins_> ChrisL: You can do the minimum 3-week LC, and say you're not accepting any new features, but are only looking for feedback on the list of recent changes.
  782. # [15:44] * Quits: glenn (gadams@174.29.122.52) (Ping timeout)
  783. # [15:44] <TabAtkins_> tantek_: Can we just go to LC directly?
  784. # [15:44] <TabAtkins_> tantek_: Or CR directly?
  785. # [15:45] <TabAtkins_> [process discussion]
  786. # [15:46] <TabAtkins_> plinss: We could potentially do a testsuite and go from LC straight to PR.
  787. # [15:47] <TabAtkins_> fantasai: Last time we tried that with Selectors, it sat in LC for several years.
  788. # [15:47] * Quits: smfr (smfr@128.93.134.211) (Quit: smfr)
  789. # [15:47] <TabAtkins_> tantek_: I think that sending it back to LC ocmmunicates that it's unstable, which is wrong. That part of W3C process is broken.
  790. # [15:48] <TabAtkins_> fantasai: I agree with Tantek that the process is broken, and we need a way to errata a CR in-place.
  791. # [15:49] <TabAtkins_> fantasai: We have two options. Go through LC, make it quick, and get back to CR. Second is to make box-shadow default color undefined and stay in CR.
  792. # [15:51] * Joins: glenn (gadams@174.29.108.64)
  793. # [15:52] <TabAtkins_> [angry discussion about process]
  794. # [15:54] <fantasai> RESOLVED: Republish Backgrounds and Borders as LC in order to errata it as CR. Include an explanation of why we're publishing a LC -- that it's still a CR-level draft, we just need to make errata 'cuz the process doesn't allow for errata in CR.
  795. # [15:55] * Quits: glenn (gadams@174.29.108.64) (Ping timeout)
  796. # [15:55] <astearns> the errata list should probably highlight the single issue that made LC required
  797. # [15:55] <TabAtkins_> Topic: Image Values
  798. # [15:56] <TabAtkins_> fantasai: If anyone has any issues about LC, please raise them.
  799. # [15:56] <TabAtkins_> sylvaing: I have a question about gradients. Does anyone know how long they'll keep their prefixes around?
  800. # [15:56] <TabAtkins_> sylvaing: It looks like FF has changed to accept the new grammar.
  801. # [15:56] <TabAtkins_> dbaron: We attempted to make an additive change so we would support more of th enew syntax values, but not remove support for anything yet.
  802. # [15:57] * Joins: smfr (smfr@128.93.134.211)
  803. # [15:57] * Joins: miketaylr (miketaylr@187.105.255.109)
  804. # [15:57] <TabAtkins_> dbaron: I don't plan to remove things fro mthe -moz-gradient; I plan to remove that stuff when we unprefix.
  805. # [15:57] <TabAtkins_> dbaron: We'll probably keep the prefix around for a bit, considering how used it is.
  806. # [15:57] <TabAtkins_> florian: We'll probably drop our prefix the moment we go to unprefixed.
  807. # [15:58] <TabAtkins_> smfr: We implemented gradients before the angle change, which means we can't update without breaking stuff.
  808. # [15:58] <TabAtkins_> smfr: So we probably won't be able to drop prefixes for a long time.
  809. # [15:58] <TabAtkins_> smfr: We can definitely do unprefixed correctly, though.
  810. # [15:59] <fantasai> Tab: smfr suggests moving element() to L4
  811. # [15:59] <fantasai> Tab: right now only Mozilla implements. If nobody else has plans, perhaps better to shift to L4?
  812. # [15:59] <fantasai> dbaron: How many implementations do we have of the other stuff?
  813. # [16:00] <fantasai> Tab: The other stuff is relatively simple
  814. # [16:00] <TabAtkins_> dbaron: Why are we removing the hard-but-popular instead of the simple-but-nobody-cares?
  815. # [16:00] <fantasai> fantasai: If the spec is stable, then we should take it to CR and mark it at-risk.
  816. # [16:00] <fantasai> fantasai: If the spec is unstable, then we should hold it back.
  817. # [16:01] <TabAtkins_> TabAtkins_: Simon, would you be okay if we kept element() as at-risk as we go into CR?
  818. # [16:01] <TabAtkins_> smfr: Yes.
  819. # [16:01] * Joins: glenn (gadams@71.218.123.58)
  820. # [16:02] <TabAtkins_> dbaron: Are enough things marked as at-risk?
  821. # [16:02] <TabAtkins_> dbaron: Do we have two impls of objec-tposition and image-resolution? And the rest of object-fit?
  822. # [16:02] <TabAtkins_> fantasai: We have two impls of image-resolution.
  823. # [16:03] <TabAtkins_> florian: We have some code for object-*, but I don't know the status.
  824. # [16:03] <TabAtkins_> plinss: What about a testsuite?
  825. # [16:03] <TabAtkins_> sylvaing: We have some gradients test. We'll contribute them.
  826. # [16:03] <TabAtkins_> TabAtkins_: I plan to make testsuite my next priority.
  827. # [16:04] <TabAtkins_> fantasai: There's an issue from the community about the gradient syntax.
  828. # [16:05] * Quits: glenn (gadams@71.218.123.58) (Ping timeout)
  829. # [16:06] <dbaron> Florian: We've debated this to death already. What we have is a compromise, and it satisfies more people than any other compromise we've had.
  830. # [16:06] <fantasai> fantasai: It was a coin toss.
  831. # [16:07] <TabAtkins_> dbaron: I suggest we mark everything but gradients as at-risk. I don't want any of the other features to hold up gradients.
  832. # [16:07] <TabAtkins_> [several]: That's fine.
  833. # [16:08] <TabAtkins_> RESOLVED: Mark everything in Images 3 as at-risk except gradients.
  834. # [16:08] <TabAtkins_> RESOLVED: Move Images 3 to CR after the above change.
  835. # [16:08] <fantasai> fantasai^: and it made the updated syntax less compatible with what's out there already
  836. # [16:13] * Joins: ksweeney (ksweeney@63.119.10.10)
  837. # [16:13] * Joins: arron (Arron@24.17.123.244)
  838. # [16:13] * Joins: glenn (gadams@174.29.101.38)
  839. # [16:20] * Quits: glenn (gadams@174.29.101.38) (Ping timeout)
  840. # [16:24] * Parts: arron (Arron@24.17.123.244)
  841. # [16:24] * Joins: arron (Arron@24.17.123.244)
  842. # [16:27] * Joins: glenn (gadams@174.29.119.75)
  843. # [16:30] <TabAtkins_> Topic: 2.1 errata
  844. # [16:30] <TabAtkins_> antonp: We've got about 88 issues on the bug tracker, with about 20 more I'm tracking and need to carry over.
  845. # [16:30] <TabAtkins_> antonp: The remaining will need a lot of work to decide what's even wrong.
  846. # [16:30] <TabAtkins_> antonp: The majority of the stuff on the list is not hard, and I think just needs to be approved.
  847. # [16:30] <smfr> https://www.w3.org/Bugs/Public/buglist.cgi?product=CSS&component=CSS%20Level%202&;resolution=---
  848. # [16:31] <TabAtkins_> antonp: So, we're not going to do 88 bugs in the next hour. What's our strategy, and our timeline?
  849. # [16:31] * Quits: glazou (glazou@128.93.135.193) (Client exited)
  850. # [16:31] <TabAtkins_> antonp: There are a few that I think could benefit form a discussion now, 6 in particular.
  851. # [16:31] <TabAtkins_> antonp: Which we could do easiest first, or hardest first.
  852. # [16:31] * Joins: glazou (glazou@128.93.135.193)
  853. # [16:31] * Quits: glenn (gadams@174.29.119.75) (Ping timeout)
  854. # [16:31] <TabAtkins_> antonp: So, first, general strategy to get them fixed, then we can discuss some specific ones.
  855. # [16:32] * Quits: szilles (chatzilla@128.93.134.251) (Ping timeout)
  856. # [16:32] <TabAtkins_> fantasai: I think a good strategy would be to put a couple on each telcon, so we burn them down eventually, and for each, put a proposal on it.
  857. # [16:32] <TabAtkins_> fantasai: So each weak, we have one or two CSS 2.1 issues to look at that the WG can discuss.
  858. # [16:32] <fantasai> s/weak/week/
  859. # [16:32] <TabAtkins_> dbaron: I find it easier to think about a bunch at once, rather than switching regularly.
  860. # [16:32] <TabAtkins_> antonp: Is that because of topic? The topics divide up well.
  861. # [16:33] <TabAtkins_> antonp: And then there are many easy editorial-like ones that can push through fairly easily.
  862. # [16:33] <TabAtkins_> dbaron: Okay. And I think it's good to come up with a proposal.
  863. # [16:33] <TabAtkins_> fantasai: And if there isn't one, we should be discussing who's writing a proposal.
  864. # [16:33] <TabAtkins_> antonp: Another question, what's our timeline for all of this?
  865. # [16:33] <TabAtkins_> antonp: What are the reqs for an errata document?
  866. # [16:34] <TabAtkins_> fantasai: It's continuously maintained. As soon as we resolve, it goes on Bert's list to write the errata.
  867. # [16:34] <TabAtkins_> fantasai: We'd like to publish an updated 2.1 Rec sometime this year.
  868. # [16:34] <TabAtkins_> fantasai: Ideally around June, but we can push it to August or whatever if necessary, if we have a few more bugs to handle.
  869. # [16:34] <TabAtkins_> florian: I think most important is to resolve them faster than reported.
  870. # [16:35] <TabAtkins_> florian: i don't think it's quite necessary to have them all resolved at the same time.
  871. # [16:35] <TabAtkins_> antonp: Sounds reasonable.
  872. # [16:35] <TabAtkins_> antonp: Most of these are small, editorial tweaks. Only a small number require real thinking.
  873. # [16:35] <TabAtkins_> antonp: So, do we now want to actually look at some of these beasts?
  874. # [16:36] <TabAtkins_> antonp: We have two on margin-collapsing, one is kinda hard as it contradicts an old resolution.
  875. # [16:36] * sylvaing has a nagging suspicion Anton considered issue 60 as easy
  876. # [16:38] * Parts: ksweeney (ksweeney@63.119.10.10)
  877. # [16:38] * Joins: glenn (gadams@71.218.123.30)
  878. # [16:39] <dbaron> http://www.w3.org/TR/CSS21/box.html#collapsing-margins
  879. # [16:40] <fantasai> ScribeNick: fantasai
  880. # [16:40] <fantasai> Anton draws on the board
  881. # [16:40] <fantasai> Anton: Partial margin collapsing could have been the perfect solution, but also kindof hard.
  882. # [16:40] <fantasai> Anton: This is the rewrite of the old margin collapsing stuff
  883. # [16:40] <fantasai> (points to screen)
  884. # [16:40] <tantek_> note: for ASCII art, here is a handy web-based visual editor: http://www.asciiflow.com/
  885. # [16:41] <fantasai> Anton: I'm using this wording b/c far better than the old wording, and forpurposes I'm discussing is exactly the same.
  886. # [16:41] <fantasai> Anton: This is the situation wh have. We have a box with a min-height. And it has one child, and the child is self-collapsing.
  887. # [16:41] <fantasai> Anton: The result of collapsing the child is this here (points at dotted rectangle inside solid rectangle). It is about to collapse with the parent's top margin.
  888. # [16:42] <fantasai> Anton: Problem is it also wants to collapse with the bottom margin.
  889. # [16:42] <fantasai> Anton: Not defined what happens there. Does this collapsed margin collapse with the bottom or the top or what?
  890. # [16:42] <fantasai> Anton: There was a discussion of min-height and max-height and their effect on collapsing.
  891. # [16:42] <fantasai> dbaron: At one point a distinction between whether min-height prevented collapsing through or collapsing the last child's bottom margin with the parent's margin when the margin was not collapsed with the parent's top margin
  892. # [16:43] <fantasai> Steve: Sounds like you aid the case is already complete.
  893. # [16:43] <fantasai> dbaron: It's a hard compromise we ended up with
  894. # [16:43] <fantasai> Anton: There are one or two tiny things that need to be rethought, but not relevant to this case.
  895. # [16:44] <fantasai> dbaron: There was one issue I object to in the rewrite, because it made a case where the spec was self-contradictory be defined here.
  896. # [16:44] <fantasai> Anton: I believe it exists as a contradiction here.
  897. # [16:44] <fantasai> Anton: This is the contradiction.
  898. # [16:44] <fantasai> dbaron: I agree there's a contradiction in what to do here.
  899. # [16:44] <fantasai> dbaron: Last time we discussed it, didn't think about that.
  900. # [16:44] <fantasai> dbaorn: old spec contradicted itself with what collapsed with what.
  901. # [16:45] <fantasai> Anton: Think that transferred across. No difference, except this spec there's a slight.. it uses adjoining when it means collapsing and vice versa.
  902. # [16:45] <arron> do we have a test page that shows what anton drew on the board?
  903. # [16:45] <fantasai> Anton: Adjoining is now a non-transitive issue. Collapsing is a transitive issue.
  904. # [16:45] <fantasai> Anton: Collapsing is transitive because a collapsed margin ... Oh, hang on, maybe it's not an issue.
  905. # [16:45] <fantasai> dbaron: I thought we wanted adjoining to be transitive?
  906. # [16:46] <fantasai> fantasai: I tried. I couldn't do it.
  907. # [16:46] <fantasai> dbaron: The old contradiction was that there awas a statement that these 2 things collapse, and these two things don't.
  908. # [16:46] <fantasai> fantasai: I think most of the old text is in that note.
  909. # [16:46] * Joins: alexmog_ (alexmog@128.93.135.194)
  910. # [16:46] <fantasai> Anton: To approach this problem, worth pointing out what discussions were had in the past.
  911. # [16:46] <fantasai> Anton: Was a very important case in the past where you've got your box here, you've actually got a genuine child non-collapsing child
  912. # [16:47] <fantasai> Anton: And the non-collapsing child has a margin which is really long... *draws margin that flows out of the box*
  913. # [16:47] <fantasai> Anton: and parent has a bottom margin.
  914. # [16:47] <fantasai> Anton: This child with the bottom margin, the height of that margin is bigger than the min-height of the box.
  915. # [16:47] <fantasai> Anton:What happens here? Does this force the parent to become bigger?
  916. # [16:48] <fantasai> Anton: Doing something differnet with min-height and max-height causes discontinuities.
  917. # [16:48] <fantasai> dbaron: They were dropped because something we really wanted to do and couldn't get two implementations passing the test suite, but what we decided to do didn't make sense.
  918. # [16:48] <fantasai> Alex: We have resisted conditional margin collapsing that depends on content actually hitting min-height or not. min-height has an effect or doesn't have an effect.
  919. # [16:49] <fantasai> Alex: All other aspects of margin collapsing can be calculated before layout starts.
  920. # [16:49] <fantasai> Alex: ....
  921. # [16:49] <fantasai> Anton: The reason then that we have ourselves in a weird situation because of that.
  922. # [16:49] <fantasai> Anton: Now, because there's no instructions about min-height in the spec anymore, we have a strange situation where this was a self-collapsing element *points at first drawing*
  923. # [16:49] <fantasai> Anton: Another interesting issue, now, *draws solid box inside bigger solid box*
  924. # [16:50] <fantasai> Anton: Spec says that the bottom margin of this small child collapses with the margin on the parent, even though the box is plenty big enough to contain the child and its margin
  925. # [16:50] * arron appreciates fantasia's descriptions of what is drawn on the board.
  926. # [16:51] <fantasai> Anton: From what I can tell from the minutes and resolutions, it was recognized that the resolution didn't solve all the problems, and it was recognized that it wasn't solved, would have to be solved later
  927. # [16:51] <fantasai> Anton: Seems to me fundamental problem, should this margin collapse with the one down there?
  928. # [16:51] <alexmog_> +---------------+
  929. # [16:51] <alexmog_> | |
  930. # [16:51] <alexmog_> +-|---------------|--+ +
  931. # [16:51] <alexmog_> | | | | |
  932. # [16:51] <alexmog_> | +---------------+ | |
  933. # [16:51] <alexmog_> | margin 1 | |
  934. # [16:51] <alexmog_> | | | min-height
  935. # [16:51] * Joins: glenn_ (gadams@174.29.125.223)
  936. # [16:51] <fantasai> Anton: Here you can do something sensible.
  937. # [16:51] <alexmog_> | | |
  938. # [16:51] <alexmog_> | | |
  939. # [16:51] <alexmog_> | | |
  940. # [16:51] <alexmog_> | | |
  941. # [16:51] <alexmog_> +--------------------+ v
  942. # [16:51] <alexmog_> margin 2
  943. # [16:51] * Quits: glenn (gadams@71.218.123.30) (Ping timeout)
  944. # [16:51] <fantasai> Anton: In the case where you've got a non-self-collapsing child, as the last child
  945. # [16:52] <fantasai> Anton: You can do something sensible to collapse its bottom margin with the paretn's bottom margin.
  946. # [16:52] <fantasai> Anton: You have to choose, but you can spec somehting sensible.
  947. # [16:52] <fantasai> Anton: But in the case wher eyou have self-collapsing margin, you can't
  948. # [16:52] <fantasai> Anton: How does this margin manifest itself? You have a positive-height box, but it's supposed to be self-collapsing.
  949. # [16:52] <fantasai> dbaron: See 2 posslbe changes to spec to fix this.
  950. # [16:53] <fantasai> dbaron: Minimal one is to change the third bullet under the third bullet in definition of adjoining.
  951. # [16:53] <fantasai> "bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height"
  952. # [16:53] <fantasai> dbaron: To add the condition that either the parent has zero computed min-height, or the bottom margin of the last in-flow child does not collapse with the top margin of the parent.
  953. # [16:53] <fantasai> dbaron: Thought we had a condition like that in the spec.
  954. # [16:54] <fantasai> dbaron: And this condition with an either-or: either parent has zero computed-min-height, or, bottom margin of the last child doesn't collapse with the top margin of the parent.
  955. # [16:55] <fantasai> dbaron: What I'd really prefer is to reduce the condition by saying it's just "and the parent has a computed zero min-height"
  956. # [16:55] <dbaron> change from: "bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height"
  957. # [16:56] <dbaron> change to option 1 (minimal): "bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height and (the parent has a zero computed min-height or the bottom margin of the last in-flow child does not collapse with the top margin of the parent)"
  958. # [16:56] <fantasai> Alex: I think reason min-height is not mentioned there is that we don't want to prevent margin collapsing when min-height didn't take effect.
  959. # [16:56] <dbaron> change to option 1 (preferred, but I don't remember why we didn't do it before): "bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height and the parent has a zero computed min-height"
  960. # [16:56] <fantasai> Alex: If you have min-height of 1px, min-height will not make a difference, but will prevent margin collapsing.
  961. # [16:56] <fantasai> Anton: exactly
  962. # [16:57] <fantasai> Anton: Seem to be definitely in past resolutions to not distinguish cases of whether min-height takes effect or not.
  963. # [16:57] <fantasai> Anton: But I think you can't have continuity if you think to that.
  964. # [16:57] <fantasai> dbaron: ...
  965. # [16:57] <fantasai> Alex: min-height has an effect, and bottom margin doesn't collapse with top margin, your position will change ....
  966. # [16:58] <fantasai> Anton: reoslution in the past ...
  967. # [16:58] <fantasai> Anton: we have to say that those can collapse
  968. # [16:58] <fantasai> Anton: Brings us back to this case (points at solid solid boxes)
  969. # [16:58] <fantasai> Alex: .. is pretty rare, and making that work, with all of the complications that we have
  970. # [16:58] <fantasai> Alex: If we make it work, will be pretty complicated, but we're not sure how much we really need it.
  971. # [16:59] <fantasai> Anton: Confirming that we don't exclude min-height in general that would be collapsing here.
  972. # [16:59] <fantasai> Alex: One case you've shown doesn't make any sense, but keep severything predictable
  973. # [16:59] <fantasai> Anton: Important to decide what we want in this case, b/c will help us understand the contradictory case.
  974. # [16:59] <fantasai> Anton: David your solution is then appropriate for this (middl picture of collapsed margin isnide min-height box)
  975. # [16:59] <fantasai> Anton: Self-collapsing sits at the top, doesn't make sens to collapse to the bottom.
  976. # [17:00] <fantasai> Anton: In this case you need to break collapsing with the bottom.
  977. # [17:00] <fantasai> fantasai: I think we discussed this situation wrt defining the position of the self-collapsed element, not here for how to collapse it.
  978. # [17:01] <fantasai> Anton: Yeah, the border position is well-defined. Just not defined how it collapses.
  979. # [17:01] <fantasai> Anton: The border position sets up a hypothetical situation where you don't have these collapsing.
  980. # [17:01] <fantasai> Anton: There is an issue where if you've got a min-height, you begin by doing the calculation based on the normal height, and you do the CH 10 calculations to determine your height.
  981. # [17:02] <fantasai> Anton: If that's less than the min-height, then you do your calculations again.
  982. # [17:02] <fantasai> Anton: assuming that the height is then set to the specifie dmin-height.
  983. # [17:02] <fantasai> Anton: In all of these cases, incidentally, height is assumed to be 'auto'.
  984. # [17:02] <fantasai> Anton: There's a note in Ch 10.7, that tries to explain something about margin collapsing. But I can't understand what that note is saying in relation to this.
  985. # [17:03] <fantasai> Anton: If you're recalculating b/c you're assuming auto height, then assuming ehgiht = min-height, you run into differnet rules in marign collapsing.
  986. # [17:03] <fantasai> Anton: Confusing note in 10.7, doj't know whether it's trying to address this situation or not.
  987. # [17:03] <dbaron> These steps do not affect the real computed values of the above properties. The change of used 'height' has no effect on margin collapsing except as specifically required by rules for 'min-height' or 'max-height' in "Collapsing margins" (8.3.1).
  988. # [17:03] <dbaron> (note in 10.7)
  989. # [17:04] <fantasai> dbaron: I think what the second sentence means is that the change of used height has no effect on margin collapsing, period. however min-height or max-height might have an effect as defined in 8.3.1
  990. # [17:04] <fantasai> Anton: So, you do all your calculations with height, but not big enough b/c have min-height, and have to redo the calculations
  991. # [17:04] <fantasai> dbaron: Note says that you don't recompute anything wrt margin collapsing. it stays the way it was.
  992. # [17:05] <fantasai> Anton: As in, all relationships of what collapses with what stays the same
  993. # [17:05] <fantasai> dbaron: yes
  994. # [17:05] <fantasai> Bert: Your rewrite of that sentence into the two parts is what I understand, yes.
  995. # [17:05] <fantasai> fantasai also agrees
  996. # [17:05] <dbaron> Possible rewrite of note: These steps do not affect the real computed values of the above properties. The change of used 'height' has no effect on margin collapsing. 'min-height' and 'max-height' only affect margin collapsing as specified by the rules in in "Collapsing margins" (8.3.1).
  997. # [17:06] <fantasai> Anton: Ok, with that interpretation of the note... I think that doesn't add anything new to this.
  998. # [17:06] <fantasai> Anton: Think suggestion of preventing margin-collapsing in this case is enough to solve the problem, and doesn't contradict what's intended by the other rules
  999. # [17:07] * miketaylr is now known as miketaylr|
  1000. # [17:07] * Joins: nimbu (Adium@24.18.47.160)
  1001. # [17:07] <fantasai> Anton points at child inside larger box case
  1002. # [17:07] <fantasai> Anton: I don't think there's anything that says if this margin collapses with the other margin, which border it sticks to.
  1003. # [17:08] <fantasai> Anton: You'll get strange behavior either way, but not defined where the collapsed margin resides
  1004. # [17:08] <fantasai> Florian: If you say they dont' collapse... but that brings up other problems.
  1005. # [17:08] <fantasai> dbaron: Where do we define where the position of the next block is?
  1006. # [17:09] <fantasai> Anton: There is a whole issue on where is actually the top content edge
  1007. # [17:09] <fantasai> dbaron: We do actually define ... in [really convoluted case]
  1008. # [17:09] <fantasai> Anton: You might be right, there might be a loophole in a special case. But in the general case not defined.
  1009. # [17:09] <fantasai> ...
  1010. # [17:10] <fantasai> Anton: If we're going to collapse these two things, then it shoudl go to the parent. Otherwise it's really odd.
  1011. # [17:10] <fantasai> dbaron: 9.4.1 says the vertical distance between 2 sibling blocks is determined by the margin properties
  1012. # [17:10] <fantasai> Anton: With a big leap of faith you can make that work.
  1013. # [17:10] <fantasai> Bert: I know I tried to rewrite that in the Box Module...
  1014. # [17:11] <fantasai> fantasai: I think for things that are a bit handwavy and need a leap of faith.. well, it's an old spec. We need to rewrite all this, and shouldn't do that rewrite as 2.1
  1015. # [17:11] <fantasai> fantasai: Should just fix errors in it.
  1016. # [17:12] <fantasai> fantasai: So I believe there are two issues here.
  1017. # [17:12] <fantasai> fantasai: One is that if you have a self-collapsing only child and a min-height, don't collapse the child with the bottom parent margin
  1018. # [17:13] <fantasai> fantasai: Other one is, if a parent and child margins collapse, the collapsed margin is attached to the border edge of the parent.
  1019. # [17:13] * Quits: alexmog_ (alexmog@128.93.135.194) (Quit: alexmog_)
  1020. # [17:13] * Joins: alexmog_ (alexmog@128.93.135.194)
  1021. # [17:13] <fantasai> dbaron: I think we should say where the top of a block goes. Which right now we dont'
  1022. # [17:14] <fantasai> Anton: So we note this down as something that needs to be turned into proposed text, discuss that text on the telecon.
  1023. # [17:14] <fantasai> ACTION Anton: Record these two issues and the conclusion, point to these minutes, write a next-action to propose text.
  1024. # [17:14] * trackbot noticed an ACTION. Trying to create it.
  1025. # [17:14] * RRSAgent records action 16
  1026. # [17:14] <trackbot> Created ACTION-435 - Record these two issues and the conclusion, point to these minutes, write a next-action to propose text. [on Anton Prowse - due 2012-02-14].
  1027. # [17:15] <fantasai> Anton: Absolute positioning is defined in terms of the top margin edge of something.
  1028. # [17:15] <fantasai> Anton points us to definition of static position
  1029. # [17:15] <fantasai> dbaron: static position doesn't really matter, because UAs may approximate.
  1030. # [17:15] <fantasai> dbaron: I'd try 10.1 or 10.6.4 (?)
  1031. # [17:15] * Quits: alexmog_ (alexmog@128.93.135.194) (Quit: alexmog_)
  1032. # [17:15] <Rossen> http://www.w3.org/TR/CSS21/visudet.html#static-position
  1033. # [17:16] * Quits: miketaylr| (miketaylr@187.105.255.109) (Quit: Leaving...)
  1034. # [17:16] <fantasai> dbaron quotes from the spec the part about "... would have been the first box of the element ... specified clear had been none ..."
  1035. # [17:16] <dbaron> More precisely, the static position for 'top' is the distance from the top edge of the containing block to the top margin edge of a hypothetical box that would have been the first box of the element if its specified 'position' value had been 'static' and its specified 'float' had been 'none' and its specified 'clear' had been 'none'. (Note that due to the rules in section 9.7 this might require also assuming a different computed value for 'display'.)
  1036. # [17:17] <dbaron> (from 10.6.4)
  1037. # [17:17] <fantasai> Anton: Issue is that it says that the static position for top is from the top edge of the containing block.. to the top margin edge of the hypothetical position
  1038. # [17:18] <fantasai> Anton: So you need to know the top margin edge, which is not well-defined in most cases.
  1039. # [17:18] <fantasai> s/most/some/
  1040. # [17:18] <fantasai> Anton: If margins don't collapse, it's obvious where it is.
  1041. # [17:18] <fantasai> Anton: But when you have margin collapsing in general... you have this blob in the middle. can you really say where the top margin edge is?
  1042. # [17:18] <fantasai> Alex: top of the collapsed margin
  1043. # [17:19] <fantasai> dbaron: Does anyone know why we say top margin edge of the first child box rather than top content edge of the box itself?
  1044. # [17:19] <fantasai> dbaron: That might solve the problem. Or may be different and not what we mean.
  1045. # [17:20] <fantasai> Bert: ...
  1046. # [17:20] <fantasai> dbaron: nevermind that question
  1047. # [17:20] <fantasai> Anton: Top margin edge is not a wel-defined concept, except in exceptional cases
  1048. # [17:20] <fantasai> dbaron: I'm going to suggest this issue lead to someone writing test csaes to find out what implementations actually do
  1049. # [17:21] <fantasai> Anton: I think this was discussed by Oyvind from Opera, who wrote testcases, found there isn't an issue in practice, but spec doesn't reflect the practice.
  1050. # [17:21] <fantasai> Anton: Don't think we should define a top margin edge.
  1051. # [17:21] <fantasai> Anton: Example is, in the bug tracker somehwere.
  1052. # [17:21] <fantasai> Anton: There's very weird kind of things when you've got self-collapsing elements trapped in the middle of a collapsed margin
  1053. # [17:22] <fantasai> anton: Where the self-collapsing element has a 20px top margin, but when you calculate it's border position doesn't allow for a top margin of 20px
  1054. # [17:22] <fantasai> anton: There aren't enough pixels above the top border edge
  1055. # [17:22] <fantasai> Anton: B/c of this don't think we should define where the top margin edge.
  1056. # [17:22] <fantasai> Anton: Instead I think where it relies on the top marign edge, seems to be a consesnus that we should define it relation to the border edge, which is well-defined
  1057. # [17:23] <fantasai> Anton: We define static position in terms of the border edge, and then add the top margin edge onto it
  1058. # [17:23] <fantasai> Anton: as a correction
  1059. # [17:23] <fantasai> Steve: That seems to have the effect that in the collapsed margin case, ...
  1060. # [17:24] <fantasai> Anton: It would be this height above its border edge...
  1061. # [17:24] <fantasai> Anton: defining the top margin edge to be up here *points above the collapsed margin* doesn't make sense to me, so would rather not do that
  1062. # [17:25] <fantasai> Anton: [my suggestion] seems to match implementations
  1063. # [17:26] <fantasai> Alex: Example of what's defined as margin edge?
  1064. # [17:26] <fantasai> Anton: It's not defined. The text defines static position (10.6.4) in terms of the top margin edge, which is not defined.
  1065. # [17:26] <smfr> http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-height
  1066. # [17:27] <tantek> (ASIDE: regarding using -webkit- prefix, clarification re: Lea Verou - she's advocated using *both* vendor prefixed properties (multiple vendors) and the unprefixed version after them. See her talk http://www.slideshare.net/LeaVerou/css3-a-practical-introduction-ft2010-talk from Front-Trends 2010 for example. An actual example of -webkit- *only* prefix examples (thus implied advocacy) is Google's http://slides.html5rocks.com/ , e.g.
  1067. # [17:27] <tantek> http://slides.html5rocks.com/#css-columns has three -webkit- property declarations starting with -webkit-column-count )
  1068. # [17:27] <fantasai> dbaron: So, I'm ok with whatever bzbarsky is ok with, because I defer everything about static position to him.
  1069. # [17:27] <fantasai> dbaron: I also don't especially care. i think it's a horrible concept.
  1070. # [17:28] <Bert> (Something like: "More precisely, the static position for 'top' is a length A - B, where A is the distance from the top edge of the containing block to the top border edge of a hypothetical box that would have been the first box of the element if its specified 'position' value had been 'static' and its specified 'float' had been 'none' and its specified 'clear' had been 'none'; and B is the top margin of the element.")
  1071. # [17:28] <fantasai> Anton: b/c spec doesn't make sense as it is, important to make testcases, and check that proposed wording doesn't change the behavior of those test cases.
  1072. # [17:29] <fantasai> [Alex and Anton discuss the issue]
  1073. # [17:31] <fantasai> Alex: top: auto means it won't move in reasonable cases
  1074. # [17:31] <fantasai> Anton: ...
  1075. # [17:32] <fantasai> Alex: I'm not proposing recollapsing. Saying that for purposes of that position, margin is used [...]
  1076. # [17:34] <fantasai> Anton: The way i understand there's inline and block. Inline, no margins. If you make inline abspos, it will be shifted down by its margin.
  1077. # [17:34] <fantasai> fantasai disagrees
  1078. # [17:34] <fantasai> fantasai: Inline has a margin, it just doesn't affect line height
  1079. # [17:34] <fantasai> Alex: for block, we know very well ...
  1080. # [17:34] <fantasai> Alex: It's top margin, which we don't have to collapse with anything b/c it's positioned.
  1081. # [17:35] <fantasai> Alex: It's inline, it's out of flow.
  1082. # [17:35] <fantasai> Alex: To determine the static, all you do is look at the bottom of this line, and it's ... in the current flow and that's it
  1083. # [17:35] <fantasai> Alex: The top margin used for static calculation has now been collapsed
  1084. # [17:35] <fantasai> Alex: It's not even a block for purposes of static layout
  1085. # [17:35] <fantasai> Alex: it's a hypothetical situation
  1086. # [17:35] <fantasai> Alex: For hypothetical situation, nothing to collapse
  1087. # [17:35] <fantasai> Anton: Doesn't explain final result
  1088. # [17:36] * Joins: leaverou (leaverou@80.187.200.37)
  1089. # [17:36] <fantasai> Alex: Does. because abpsos elements are out-of-flow that have in-flow static position, determined by anonymous line
  1090. # [17:36] <fantasai> Anton: You're saying that abspos elements leave an inline-level placeholder
  1091. # [17:36] <fantasai> Anton: Even if they're blocks.
  1092. # [17:37] <fantasai> Anton: The spec definitely doesn't say that at the moment.
  1093. # [17:37] <fantasai> Anton: In tables it does.
  1094. # [17:37] <fantasai> Alex: Having something abspolutely positioned... a line.
  1095. # [17:37] <fantasai> Alex: element has no right ot colalpse with anything else because it has never been a block.
  1096. # [17:37] <fantasai> Alex: only hypotehtical
  1097. # [17:38] <fantasai> Alex: it's happening relative to that imaginary line, as if that was a line with some kind of content
  1098. # [17:38] <fantasai> Alex: With that no collapsing would happen
  1099. # [17:38] <fantasai> Anton: Where is the position of that line?
  1100. # [17:38] <fantasai> Anton: I see, would be anonymous self-collapsing block.
  1101. # [17:38] <fantasai> Anton: I'm fairly certain it doesn't leave behind a placeholder currently in the spec
  1102. # [17:38] <fantasai> Alex: ...
  1103. # [17:39] <fantasai> Alex: Abspos element is inline content
  1104. # [17:39] <fantasai> Alex: That for all other purposes is empty, but it has very well defined position
  1105. # [17:39] <fantasai> Anton: I understand the argument you're making, but I don't think the spec there.
  1106. # [17:40] <fantasai> Anton: Spec says to treat it as non-abspos to find its position, and if it's a physical inline-level box. You're redoing layout with a different assumption.
  1107. # [17:40] * tantek notes that this one issue has now taken 1 hr of f2f time.
  1108. # [17:40] <fantasai> Anton: But your'e saying when i's abpsos, it leaves behind a placeholder that affects layout.
  1109. # [17:40] * fantasai is not the chair
  1110. # [17:40] <fantasai> Alex: ...
  1111. # [17:40] <fantasai> Alex: That defines inline position of abspos
  1112. # [17:41] <fantasai> Alex: our implementation also has a line which might be empty which has a.. ok Rossen disagrees.
  1113. # [17:41] <fantasai> Anton: I honestly don't think that's what the spec says.
  1114. # [17:42] * Joins: lar_zzz (Adium@79.226.88.78)
  1115. # [17:42] <fantasai> Alex: I think it's good idea to define hypothetical position precisely.
  1116. # [17:42] <fantasai> Alex: Rossen do you disagree with anything I said?
  1117. # [17:42] <fantasai> Rossen: abspos elements that are blocks, ... we do not collapse margins
  1118. # [17:42] <fantasai> Rossen: So, we will not use the collapsed position for abspos elements.
  1119. # [17:42] <fantasai> Rossen: This is what everyone currently does
  1120. # [17:42] <fantasai> Rossen: I agree with Alex on something he said in the beginning.
  1121. # [17:43] * Joins: Ms2ger (Ms2ger@91.181.83.228)
  1122. # [17:43] <fantasai> Rossen: which is, if we insist to keep this top margin position, then we also need to specify it if the margin didn't collapse
  1123. # [17:43] <fantasai> Rossen: When it said you must treat it as if it's positoin static, and float is what it was, et.c etc. You'd add another one that says "And margins of this element did not collapse"
  1124. # [17:43] <fantasai> s/rossen/Anton/
  1125. # [17:43] <fantasai> Rossen: But that to me seems to open a can of worms.
  1126. # [17:44] <fantasai> Anton: Your'e saying if it was a static block, imagine you had a static block, and its' float was not reset to none, and clear really ahd an effect, and imagine that it didn't collapse any margins...
  1127. # [17:44] <fantasai> Anton: But you have to be more specific: not collapse which margins?
  1128. # [17:44] <fantasai> Alex: ...
  1129. # [17:44] <fantasai> Anton: Part of ccalculating stitc position is you ignore margins..?
  1130. # [17:45] <fantasai> Anton: b/c what happens with its children and their marigns, which used to collapse/not collapse
  1131. # [17:45] <fantasai> Anton; i think testcases are the way to go here.
  1132. # [17:45] <fantasai> s/;/:/
  1133. # [17:45] <fantasai> Anton: Don't think it's as simple as saying "don't collapse margins"
  1134. # [17:45] <fantasai> Anton: Of course won't collapse it's margins when its positioned anyway
  1135. # [17:45] <fantasai> Anton: b/c won't collapse once it's been abspos
  1136. # [17:46] <fantasai> Alex: ... a lot of simplifications to not overcomplicate the positioning
  1137. # [17:46] <fantasai> Alex: A lot of ... are not going to happen the same way as in normal layout
  1138. # [17:46] <fantasai> Anton: I don't have an opinion on this, just as the moment it's not currently well-defined.
  1139. # [17:46] <fantasai> Anton: Need a way to define it. Which *might* be placeholders, or [...]
  1140. # [17:46] <fantasai> Rossen: Asked for action item to have a section on that in css3-positioning
  1141. # [17:47] <fantasai> Anton: We still need to do something for CSS2.1, because the text doesn't make sense atm because it relies on an undefined concept.
  1142. # [17:47] * Parts: smfr (smfr@128.93.134.211)
  1143. # [17:47] <fantasai> Anton: The proposal on the list was to do it in terms of border position, then tweak it to account for the margin.
  1144. # [17:47] <fantasai> Alex: UAs are free to make a guess, so that makes it completely free.
  1145. # [17:48] * Joins: smfr (smfr@128.93.134.211)
  1146. # [17:49] <fantasai> fantasai: So, we've been discussing this for awhile. How about you write proposed text in terms of the border edge, since it seems that's a good way to go. And if Alex wants to implement that in terms of a placeholder in a line box in a self-collapsing anonymous block, that's fine.
  1147. # [17:49] * Quits: antonp (805d8798@207.192.75.252) (Quit: http://www.mibbit.com ajax IRC Client)
  1148. # [17:50] <fantasai> fantasai: Just make sure there's testcases and the spec *results* match implementation *results*
  1149. # [17:50] <fantasai> ACTION Anton: write proposed text and testcases
  1150. # [17:50] * RRSAgent records action 17
  1151. # [17:50] * trackbot noticed an ACTION. Trying to create it.
  1152. # [17:50] <trackbot> Created ACTION-436 - Write proposed text and testcases [on Anton Prowse - due 2012-02-14].
  1153. # [17:50] <fantasai> Anton: Does the root element establish a BFC root
  1154. # [17:50] <fantasai> ?
  1155. # [17:51] * Joins: arno (arno@192.150.10.200)
  1156. # [17:51] <fantasai> dbaron: I think it's established by the ICB, not the root element
  1157. # [17:52] <fantasai> Rossen: If you want to model the browser window, how would you do it? you would create a <div> with fixed size, and make it overflow: auto so you get scrollbars. That's your viewport
  1158. # [17:52] <fantasai> Rossen: This is what we do in IE.
  1159. # [17:52] <fantasai> Rossen: ICB is not exception to anything
  1160. # [17:52] <fantasai> Rossen: It's just an element, just not accessible to OM
  1161. # [17:53] <fantasai> Rossen: If this is what you mean, then I agree it should be a BFC.
  1162. # [17:53] <fantasai> Rossen: If you mean the root element, then should be driven by properties.
  1163. # [17:53] <fantasai> Florian: I believe in Opera we treat the root element as an abspos.
  1164. # [17:54] <fantasai> Rossen: Up to impleemnter, but if you model this as an element, but needs to have auto scrollbars, so needs to be a BFC.
  1165. # [17:54] <fantasai> fantasai: Root element is not the ICB
  1166. # [17:55] <fantasai> Anton: I'm talking about the document root element
  1167. # [17:56] <dbaron> https://www.w3.org/Bugs/Public/
  1168. # [17:56] <dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15702
  1169. # [17:57] <dbaron> https://bug590491.bugzilla.mozilla.org/attachment.cgi?id=469029
  1170. # [17:57] <fantasai> dbaron suggests people to run this testcase
  1171. # [17:57] <fantasai> dbaron: Question is, where is the orange bar?
  1172. # [17:58] <fantasai> dbaron: chrome has changed to match Gecko since this was written
  1173. # [17:59] <fantasai> deferred to tomorrow
  1174. # [17:59] <TabAtkins_> http://wiki.csswg.org/spec/process
  1175. # [17:59] <fantasai> Topic: Spec Process
  1176. # [18:00] <fantasai> Tantek: Started to try document our spec development process, and how we try to move faster within W3C process
  1177. # [18:00] <fantasai> Tantek: Top is complaints we have
  1178. # [18:00] <fantasai> Tantek: Trying to look at positive side here, how to improve in the future
  1179. # [18:00] <fantasai> tantek: Have some principles
  1180. # [18:00] <fantasai> Tantek: Publish early and often to show interest/activity
  1181. # [18:00] <fantasai> Tantek: Transparently note objections/issues
  1182. # [18:01] <fantasai> Tantek: Advance as rapidly impelmentations and tests show interop
  1183. # [18:01] <fantasai> Tantek: Drop /postpone features lacking implementations rather than trying to keep things togethers.
  1184. # [18:01] * Joins: antonp (805d8798@78.129.202.38)
  1185. # [18:01] <fantasai> Tantek: In short, I think any editor, anyone in CSSWG shoudl be able to check in editor's draft that agrees with the charter.
  1186. # [18:01] <fantasai> Tantek: When objections are noted, editor's responsiblity to include in the draft.
  1187. # [18:02] <fantasai> glazou: ... No, not possible. Would break discusison of [...]
  1188. # [18:02] <fantasai> glazou: Any idea must be proposable to the WG, and our role afterwards to decide whther to inlcude charter
  1189. # [18:02] <fantasai> plinss: Stike requirement that it be in the Chater
  1190. # [18:02] <fantasai> ChrisL: That first point is about transition *to* editor's draft
  1191. # [18:02] <fantasai> plinss: For example Tab's hierarchies thing. He's not creating an editor's draft, he's creating a proposal.
  1192. # [18:03] <fantasai> plinss: From idea to proposal document, anyone can chekc anything in, doesn't have to match our charter
  1193. # [18:03] <fantasai> plinss: To move from proposal to ED, need to have a charter discussion
  1194. # [18:03] <fantasai> Tantek: Next one is important. Sometiems takes way too long for EDs to bpulsiehd as FPWD. We need to be much be more active about this.
  1195. # [18:03] <fantasai> Tantek: Suggest that as soon as something is implemented, we push it to FPWD.
  1196. # [18:04] <fantasai> ChrisL: Why wait that long? Does that mean without implementation, you can't publish FPWD?
  1197. # [18:04] <fantasai> Tantek: No, this is saying to treat it as a forcing function.
  1198. # [18:05] * Quits: leaverou (leaverou@80.187.200.37) (Ping timeout)
  1199. # [18:05] <fantasai> glazou: I have one big concern with this step. if the implementation impelments something that is not stabilized, and even under strong scrutiny and criticism, the implementation won't reflect the discussion and the fact that it's not stabilized
  1200. # [18:05] <fantasai> q+
  1201. # [18:05] <fantasai> glazou: This is WHATWG approach that specs do not matter, only implementers do
  1202. # [18:05] <dbaron> q+
  1203. # [18:05] <fantasai> zakim, q+
  1204. # [18:05] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  1205. # [18:05] <fantasai> q+
  1206. # [18:05] * Zakim sees fantasai on the speaker queue
  1207. # [18:06] <fantasai> ChrisL: earlier is better b/c of IP timer
  1208. # [18:06] <fantasai> ChrisL: As soon as there's a list of features, even not clear what they are, that's when you want to push for FPWD
  1209. # [18:06] <glazou> Zakim, ack dbaron
  1210. # [18:06] <Zakim> I see fantasai on the speaker queue
  1211. # [18:06] <fantasai> dbaron: So, what it looks to me,
  1212. # [18:07] <fantasai> dbaron: If someone believes there is something in a draft they believe should not be in CSS, the first point to object is the PR boat.
  1213. # [18:07] <ChrisL> because there is a 150 day exclusion period. and any feature not in that fpwd can still be excluded following last call
  1214. # [18:07] <fantasai> Tantek: No, edit'rs draft. Has to be documented in the editor's draft.
  1215. # [18:07] <fantasai> dbaron: But what does that note lead to? Does the note end up in a PR?
  1216. # [18:07] <fantasai> Tantek: Point of note is to list it as there being contention.
  1217. # [18:08] <fantasai> glazou: Note that editor's draft can be modified without WG approval.
  1218. # [18:08] <plinss> ack fantasai
  1219. # [18:08] * Zakim sees no one on the speaker queue
  1220. # [18:08] <dbaron> fantasai: I think one of dbaron's points -- that the current policy of the WG that we go to FPWD when there's agreement that we want to work on it.
  1221. # [18:08] <dbaron> fantasai: And if we don't get to that agreement we don't publish as FPWD.
  1222. # [18:08] <dbaron> fantasai: We have to get consensus in the WG that we want to work on it before we go to FPWD, and that's not reflected here.
  1223. # [18:09] <dbaron> Tantek: That's part of the goal is to prevent somebody to stop something from being published just by objecting.
  1224. # [18:09] <dbaron> q+
  1225. # [18:09] * Zakim sees dbaron on the speaker queue
  1226. # [18:09] <dbaron> plinss: She's talking about whether there's even consensus to work on the draft.
  1227. # [18:09] <dbaron> sylvain: Take the hierarchies example earlier today.
  1228. # [18:09] <fantasai> plinss: I don't think it makes sense to publish FPWD of something where there's no consensus to work on it.
  1229. # [18:10] <fantasai> fantasai^: [something about ijppementation plus draft menas I have a standard to put on /tr as representing WG consensus\
  1230. # [18:10] <fantasai> ]
  1231. # [18:10] <fantasai> Steve: But you don't get ED without a consensus
  1232. # [18:10] <fantasai> Tantek: if you have a shipping implementation, you should get FPWD
  1233. # [18:10] <fantasai> glazou: I strongly object to that.
  1234. # [18:10] <fantasai> plinss: We have things we've publishe dand then lost interest in.
  1235. # [18:10] <fantasai> plinss: Don't think we need a forcing function here.
  1236. # [18:11] <dbaron> So I think a problem with this model is that these transitions lead to implementations as well.
  1237. # [18:12] <fantasai> fantasai: Why are we distinguishing Proposal vs. Editor's Draft Without FPWD? If we have agrement to work on something, it should go to PFWD. Why not have it on /TR?
  1238. # [18:12] <fantasai> dbaron: I think the underlying issue that this idea doesn't consider is that all of these transitions themselves cause implementations.
  1239. # [18:12] <fantasai> dbaron: The act of putting something on dev.w3.org increases the possibility of implementation.
  1240. # [18:12] <fantasai> dbaron: Pushing to FPWD makes it more likely.
  1241. # [18:12] <fantasai> dbaron: We have the power to influence what gets implemented. And we should consider how we use it.
  1242. # [18:13] <fantasai> Tantek: Problem is we are being behind. Editor's drafts are being published an dimplemented. W3C Process is being circumvented, and nobody's talking about it.
  1243. # [18:13] <fantasai> Tantek: Stuff is happening, let's move forward.
  1244. # [18:13] <fantasai> glazou: An editor's draft can be modified without WG approval.
  1245. # [18:13] <dbaron> s/to FPWD/to FPWD maybe/
  1246. # [18:13] <fantasai> glazou: Which means a member of this WG can edit a draft, and the draft gos to FPWD without approval of the WG. I don't want that.
  1247. # [18:14] * Joins: leaverou (leaverou@80.187.200.37)
  1248. # [18:14] <fantasai> Florian: Your model assumes any proposal is a positive one.Which is not necessarily true.
  1249. # [18:14] <plinss> ack dbaron
  1250. # [18:14] * Zakim sees no one on the speaker queue
  1251. # [18:14] <fantasai> Florian: I think if something ships and we don't have a WD, we should be considering it. But we shouldn't automatically go to draft. It should be a trigger to consider it.
  1252. # [18:14] <fantasai> glazou: It should go on the radar of WG. But that's already the case.
  1253. # [18:15] <fantasai> plinss: If these are phrased as these force us to discuss it, that's fine.
  1254. # [18:15] <fantasai> glazou: A WD is published automatically? *shakes head*
  1255. # [18:15] <fantasai> plinss: We can't publish a transition without a group resolution.
  1256. # [18:15] <fantasai> Steve: I was just going to say, W3C took action to change submissions from TRs to put them in a different place b/c they found the system was being gamed by ppl writing things and submitting them and saying they're now a W3C spec, 'cuz now on the W3C site.
  1257. # [18:16] <fantasai> Steve: So there is reason for what Florian and Daniel said. Need consideration to keep people gaming the system.
  1258. # [18:16] <fantasai> Tantek: It's worse now. /TR doesn't matter anymore. Editor's drafts are being implemented.
  1259. # [18:16] <fantasai> Steve: Saying that you're shipping a W3C standard...
  1260. # [18:16] <fantasai> Tantek: They say they're implementing a W3C standard and link to editor's draft
  1261. # [18:16] <fantasai> jdaggett: That's a little bit of a separate issue.
  1262. # [18:16] <fantasai> Steve: I don't believe we're contributing to that piece of it.
  1263. # [18:17] <fantasai> jdaggett: I think you're tyring to accelerate things base d on impelemtations bieng available.
  1264. # [18:17] <fantasai> jdaggett: Problem is you start spitting out specs in chunks. deifnitely be more confusing.
  1265. # [18:17] <fantasai> smfr: We just did that with css3-images
  1266. # [18:17] <fantasai> Steve: We're collecting implementation reality. That's a good thing.
  1267. # [18:17] <fantasai> plinss: As long as you have interoperable implementations, then ..
  1268. # [18:17] <fantasai> jdaggett: You realize this means this is beginning of every spec is one property. Every property has one spec.
  1269. # [18:18] <fantasai> Florian: Not necessarily. Did for gradients because there is urgency on gradients themselves.
  1270. # [18:18] <fantasai> glazou: Don't make it one implementation. Make it two. Then you don't have a working draft, you have a CR. You can even ahve impleementation reports and move fast.
  1271. # [18:18] <fantasai> glazou: Have browser vendors propose things that are more stable.
  1272. # [18:19] <fantasai> Tantek: Let me finish summarizing.
  1273. # [18:19] <fantasai> Tantek: From WD to LC, as soon as any feature has two itneroperable implementations, according to test suites etc,
  1274. # [18:19] <fantasai> Tantek: The draft goes to Last Call. Any features that are not implemented at all get listed as at-risk.
  1275. # [18:19] <fantasai> Tantke: Next step is CR.
  1276. # [18:19] <fantasai> glazou: For step 2 have a problem.
  1277. # [18:20] <fantasai> glazou: In history of WG, we have never made test suites before CR. Not sure that members have showed enough commitment to require test suites before CR.
  1278. # [18:20] <fantasai> glazou: We've tried.
  1279. # [18:20] <fantasai> glazou: Unless we move to CR, no point.
  1280. # [18:20] <fantasai> ChrisL: But we can encourage that. And often people post samples.
  1281. # [18:20] <fantasai> ChrisL: Just collect examples in your spec and you have some tests.
  1282. # [18:20] <fantasai> glazou: I can live with it, we can try.
  1283. # [18:20] <fantasai> plinss: Reality is as soon as someone writes impelmetnation, they are writing their own tests. They just need to write them in W3C format.
  1284. # [18:21] <fantasai> Tantek: Anyone can show a test that disproves your interop.
  1285. # [18:21] <fantasai> Tantek: During LC period.
  1286. # [18:21] <fantasai> Tantek: That resets 6-week LC period.
  1287. # [18:21] <fantasai> Tantek: At the end of that LC period, it goes to CR. Then everything with no implementations get dropped. Everything with only one implementation gets at-risk.
  1288. # [18:21] <fantasai> Tantek: During CR period, eidtor can iterate based on implementation experience.
  1289. # [18:21] <fantasai> glazou: I think this part of automati cprocess I agree more.
  1290. # [18:22] <dbaron> I've sent the whiteboard photos from the 2.1 discussion to www-style, but they haven't gotten through yet.
  1291. # [18:22] <dbaron> er, to www-archive
  1292. # [18:22] <fantasai> glazou: At the end of LC review period, shift to CR *unless* LC period has shown blockers.
  1293. # [18:22] <fantasai> glazou: Can have interoperably implemented with design issues that may harm the Web in the future
  1294. # [18:22] <fantasai> Steve: non-internationalizable, etc.
  1295. # [18:22] <dbaron> http://lists.w3.org/Archives/Public/www-archive/2012Feb/0011.html
  1296. # [18:22] <dbaron> http://lists.w3.org/Archives/Public/www-archive/2012Feb/0010.html
  1297. # [18:22] <fantasai> Florian: We can set these as expectations, but not automatic. Look at them one by one.
  1298. # [18:23] <dbaron> with timestamps in CET
  1299. # [18:23] <dbaron> (in the message body)
  1300. # [18:23] <fantasai> Tantek: At the end of 6mo CR period
  1301. # [18:23] <arron> dbaron, thanks for doing that I will hopefully be able to understand the 2.1 conversation better now.
  1302. # [18:23] <dbaron> and metadata in UTC
  1303. # [18:23] * Quits: ChrisL (ChrisL@128.30.52.169) (Client exited)
  1304. # [18:23] <fantasai> Tantek: Then it "automatically" goes to PR, and any feature not interop by test suite gets dropped.
  1305. # [18:23] <fantasai> Tantek: When I say dropped, I mean postponed.
  1306. # [18:23] <fantasai> Tantek: You just missed the train.
  1307. # [18:24] <dbaron> fantasai: Maintaining multiple versions of the same draft is annoying; don't want to do that just so we can do CR->REC every 6 months.
  1308. # [18:24] * Quits: glenn_ (gadams@174.29.125.223) (Ping timeout)
  1309. # [18:24] <fantasai> Tantek: Trying to provide path for editor's accelerating their wok.
  1310. # [18:24] <fantasai> work
  1311. # [18:24] * Quits: jdaggett (jdaggett@128.93.135.115) (Quit: jdaggett)
  1312. # [18:25] * Quits: smfr (smfr@128.93.134.211) (Quit: smfr)
  1313. # [18:25] <fantasai> Florian: As long as these are expectations, not automatic triggers, it's okay.
  1314. # [18:26] * Quits: glazou (glazou@128.93.135.193) (Quit: glazou)
  1315. # [18:26] <fantasai> Meeting closed.
  1316. # [18:26] * Quits: jet (jet@128.93.134.233) (Quit: jet)
  1317. # [18:26] * Quits: astearns (qw3birc@128.30.52.28) (Ping timeout)
  1318. # [18:27] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
  1319. # [18:27] * Quits: alexmog__ (qw3birc@128.30.52.28) (Ping timeout)
  1320. # [18:27] * Quits: florian (florianr@128.93.135.177) (Ping timeout)
  1321. # [18:27] * Quits: vhardy_ (qw3birc@128.30.52.28) (Ping timeout)
  1322. # [18:27] * Quits: Rossen (Rossen@128.93.134.230) (Ping timeout)
  1323. # [18:27] * Quits: CGI232 (805d87e1@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
  1324. # [18:28] * plinss is now known as plinss_away
  1325. # [18:28] * Parts: antonp (805d8798@78.129.202.38)
  1326. # [18:28] * Quits: TabAtkins_ (tabatkins@74.125.122.49) (Ping timeout)
  1327. # [18:29] * Joins: ksweeney (ksweeney@63.119.10.10)
  1328. # [18:30] * Quits: dbaron (dbaron@128.93.135.77) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  1329. # [18:31] * Joins: glenn (gadams@174.29.100.187)
  1330. # [18:31] * Quits: glenn (gadams@174.29.100.187) (Client exited)
  1331. # [18:34] * Quits: kojiishi (kojiishi@128.93.135.158) (Ping timeout)
  1332. # [18:35] * Quits: tantek_ (tantek@128.93.135.73) (Quit: tantek_)
  1333. # [18:35] * Quits: tantek (tantek@128.93.135.10) (Quit: tantek)
  1334. # [18:36] * sylvaing is now known as sylvaing_away
  1335. # [18:36] * plinss_away is now known as plinss
  1336. # [18:37] * Quits: howcome (howcome@128.93.135.80) (Ping timeout)
  1337. # [18:46] * Quits: leaverou (leaverou@80.187.200.37) (Ping timeout)
  1338. # [18:47] * plinss is now known as plinss_away
  1339. # [18:50] * Joins: leaverou (leaverou@80.187.200.37)
  1340. # [18:55] * Parts: lar_zzz (Adium@79.226.88.78)
  1341. # [18:57] * Quits: leaverou (leaverou@80.187.200.37) (Ping timeout)
  1342. # [19:00] * Joins: leaverou (leaverou@80.187.200.37)
  1343. # [19:13] * Joins: miketaylr (miketaylr@187.105.255.109)
  1344. # [19:17] * Quits: leaverou (leaverou@80.187.200.37) (Quit: leaverou)
  1345. # [19:35] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
  1346. # [19:37] * Joins: arno (arno@192.150.10.200)
  1347. # [19:39] * Quits: drublic (drublic@77.2.157.148) (Ping timeout)
  1348. # [20:07] * Parts: ksweeney (ksweeney@63.119.10.10)
  1349. # [20:11] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
  1350. # [20:16] * Quits: karl (karlcow@128.30.54.58) (Quit: :tiuQ tiuq sah woclrak)
  1351. # [20:36] * Zakim excuses himself; his presence no longer seems to be needed
  1352. # [20:36] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  1353. # [20:38] * Joins: arronei (arronei@131.107.0.118)
  1354. # [20:39] * Quits: arronei_ (arronei@131.107.0.112) (Ping timeout)
  1355. # [20:41] * Joins: glenn (gadams@192.160.73.102)
  1356. # [21:17] * Joins: arno (arno@192.150.10.200)
  1357. # [22:03] <Ms2ger> vhardy, hope you don't mind the bugspam :)
  1358. # [22:03] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
  1359. # [22:05] * Joins: arno (arno@192.150.10.200)
  1360. # [22:11] * Joins: lar_zzz (Adium@79.226.88.78)
  1361. # [22:11] * Joins: drublic (drublic@77.2.136.131)
  1362. # [22:24] * plinss_away is now known as plinss
  1363. # [22:26] * Quits: Ms2ger (Ms2ger@91.181.83.228) (Quit: nn)
  1364. # [22:37] * Quits: lar_zzz (Adium@79.226.88.78) (Quit: Leaving.)
  1365. # [22:47] * Joins: jdaggett (jdaggett@81.56.65.178)
  1366. # [22:55] * Quits: jdaggett (jdaggett@81.56.65.178) (Quit: jdaggett)
  1367. # [23:09] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
  1368. # [23:09] * Joins: arno (arno@192.150.10.200)
  1369. # [23:31] * Quits: miketaylr (miketaylr@187.105.255.109) (Quit: Leaving...)
  1370. # [23:36] * Joins: TabAtkins_ (tabatkins@90.46.85.61)
  1371. # Session Close: Wed Feb 08 00:00:00 2012

The end :)