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

Options:

  1. # Session Start: Sun Jul 24 00:00:00 2011
  2. # Session Ident: #css
  3. # 03[00:39] * Joins: dbaron (dbaron@207.225.246.217)
  4. # 03[00:40] * Joins: karl (karlcow@128.30.54.58)
  5. # 03[01:18] * Joins: arno (arno@208.87.61.204)
  6. # 02[01:37] * Quits: arno (arno@208.87.61.204) (Quit: Leaving.)
  7. # 03[02:09] * Joins: TabAtkins_ (tabatkins@72.254.84.188)
  8. # 02[02:22] * Quits: dbaron (dbaron@207.225.246.217) (Connection reset by peer)
  9. # 03[02:22] * Joins: dbaron (dbaron@207.225.246.217)
  10. # 02[02:34] * Quits: dbaron (dbaron@207.225.246.217) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  11. # 03[03:12] * Joins: dbaron_phone (dbaron@66.87.29.42)
  12. # [03:15] <dbaron_phone> TabAtkins, did you see Peter's email (from Wed or so) regarding dinner tonight (i.e. in 20 minutes)?
  13. # 02[03:26] * Quits: Martijnc (Martijnc@84.192.44.100) (Quit: Martijnc)
  14. # 03[03:32] * Parts: dbaron_phone (dbaron@66.87.29.42)
  15. # 03[04:38] * Joins: nimbupani (Adium@24.18.47.160)
  16. # 03[04:45] * Joins: anne (annevk@198.134.89.196)
  17. # 02[05:04] * Quits: anne (annevk@198.134.89.196) (Quit: anne)
  18. # 02[05:32] * Quits: nimbupani (Adium@24.18.47.160) (Client exited)
  19. # 03[05:35] * Joins: nimbupani (Adium@24.18.47.160)
  20. # 03[05:35] * Parts: nimbupani (Adium@24.18.47.160)
  21. # 02[05:46] * Quits: TabAtkins_ (tabatkins@72.254.84.188) (Ping timeout)
  22. # 03[06:29] * Joins: TabAtkins_ (tabatkins@72.254.84.188)
  23. # 03[11:30] * Joins: Ms2ger (Ms2ger@91.181.41.169)
  24. # 02[12:38] * Quits: konaya (konaya@83.251.16.72) (Ping timeout)
  25. # 02[13:13] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  26. # 03[13:24] * Joins: Martijnc (Martijnc@84.192.44.100)
  27. # 03[14:36] * Joins: konaya (konaya@130.229.159.142)
  28. # 03[16:19] * Joins: nimbupani (Adium@24.18.47.160)
  29. # 03[16:20] * Parts: nimbupani (Adium@24.18.47.160)
  30. # 03[17:34] * Joins: sylvaing (sylvaing@72.254.95.170)
  31. # 03[17:49] * Joins: kimberlyblessing (Kimberly@72.254.58.198)
  32. # 03[17:50] * Joins: mollydotcom (mollyh@72.254.82.56)
  33. # 03[17:57] * Joins: alexmog_ (alexmog@72.254.57.72)
  34. # [17:58] <alexmog_> skype alex.mogilevsky
  35. # 03[17:58] * Joins: arronei (arronei@72.254.95.172)
  36. # 03[17:58] * Joins: plinss_ (plinss@72.254.91.11)
  37. # 03[17:59] * Joins: stearns (qw3birc@128.30.52.28)
  38. # 03[17:59] * Joins: johnjansen (qw3birc@128.30.52.28)
  39. # 03[18:00] * Joins: nimbupani (Adium@72.254.56.249)
  40. # 03[18:00] * Joins: glazou (glazou@72.254.94.5)
  41. # 03[18:01] * Joins: bradk (bradk@99.7.175.117)
  42. # 03[18:05] * Joins: shans (qw3birc@128.30.52.28)
  43. # 03[18:06] * Joins: arno (arno@72.254.90.86)
  44. # 03[18:06] * Joins: dbaron (dbaron@72.254.82.231)
  45. # 03[18:06] * Joins: sgalineau (sylvaing@72.254.95.170)
  46. # 02[18:07] * Quits: TabAtkins_ (tabatkins@72.254.84.188) (Ping timeout)
  47. # [18:07] <bradk> Hello.
  48. # [18:07] <arronei> Hello Brad
  49. # 02[18:08] * Quits: sgalineau (sylvaing@72.254.95.170) (Quit: sgalineau)
  50. # 03[18:08] * Joins: florian (florianr@72.254.58.176)
  51. # 03[18:10] * Joins: anne (annevk@72.254.92.35)
  52. # [18:10] <arno> Let's talk about the agenda… Looking at the wiki
  53. # [18:11] <arno> http://wiki.csswg.org/planning/seattle-2011
  54. # [18:11] <bradk> I have Skype now. Do you folks there have something that can keep multiple people connected in through skype for voice and/or video, or should I wait until there is a topic that I am particularly interested in?
  55. # 03[18:11] * Joins: TabAtkins_ (tabatkins@72.254.84.188)
  56. # [18:11] <arno> A few requests have been recorded, based on people's presence
  57. # [18:11] <arno> Nothing planned for today yet, lots for tomorrow
  58. # [18:12] <arno> Howcome: we could talk about flexbox today
  59. # 02[18:13] * Quits: johnjansen (qw3birc@128.30.52.28) (Quit: Page closed)
  60. # [18:14] <arno> Need to talk about 2 next F2F
  61. # [18:14] <bradk> Or do we have the regular Zakim line open all day?
  62. # [18:14] <arno> Adobe has proposed Bucharest, Romania as a possible location. Would be nice in spring.
  63. # [18:15] <arno> Kimberley: Comcast could host in Philly
  64. # 03[18:15] * Joins: vhardy (vhardy@72.254.56.182)
  65. # [18:15] <arno> glazou: I can look into hosting in Paris
  66. # [18:16] <arno> glazou: first items for today?
  67. # [18:16] <arno> fantasai: ISV feedback, we should send today
  68. # 03[18:19] * Joins: JohnJansen (qw3birc@128.30.52.28)
  69. # [18:20] <arno> glazou: we should add testing to agenda
  70. # [18:20] <fantasai> Introductions going around
  71. # [18:20] <fantasai> Molly notes that she is no longer working for Opera -> individual Invited Expert
  72. # [18:21] <bradk> Is there a e-maail address I should use to connect via skype? or facetime?
  73. # [18:22] <dbaron> bradk, see emails on w3c-css-wg
  74. # [18:23] <bradk> dbaron, ah I see. Thanks.
  75. # [18:23] <arno> Round of introductions:
  76. # [18:23] <arno> - Daniel Glazman - self
  77. # [18:23] <arno> - John Jansen - Microsoft
  78. # [18:23] <arno> - David Barrent
  79. # [18:23] <arno> - Alex Mogilevsky - Microsoft
  80. # [18:23] <arno> - Steve Ziles - Adobe
  81. # [18:23] <arno> - Alan Stearns - Adobe
  82. # [18:23] <arno> - Jay Stadten - Google
  83. # [18:23] <arno> - Tab Atkins - Google
  84. # [18:23] <arno> - Oliver - Opera
  85. # [18:23] <arno> - Florian Rivoal - Opera
  86. # [18:23] <arno> - Koji Ishii - self
  87. # [18:23] <arno> - Vincent Hardy - Adobe
  88. # [18:23] <arno> - Arno Gourdol - Adobe
  89. # [18:23] <arno> - Kimberly Blessing - Comcast, TV everywhere
  90. # [18:23] <arno> - Molly Holzschlag - self, molly.com, invited expert, no longer w/ Opera
  91. # [18:23] <arno> - Eric - Microsoft
  92. # [18:23] <arno> - Elika/fantasai - invited expert
  93. # [18:23] <arno> - Sylvain Gallineau - Microsoft
  94. # [18:24] <arno> - Divya Manian - Opera
  95. # [18:24] <arno> - Peter Linns - HP
  96. # [18:24] <shans> Jay Stadten -> Shane Stephens :)
  97. # [18:24] <arno> Tantek has joined us
  98. # [18:24] <dbaron> Present: Daniel Glazman (Disruptive Innovations), John Jansen (Microsoft), Tantek Çelik, David Baron (Mozilla), Alex Mogilevsky (Microsoft), Steve Zilles (Adobe), Alan Stearns (Adobe), Shane Stephens (Google), Tab Atkins (Google), Anne van Kesteren (Opera), Florian Rivoal (Opera), Koji Ishii, Vincent Hardy (Adobe), Arno Gourdol (Adobe), Kimberly Blessing (Comcast), Molly Holzchlag, Arron Eicholz (Microsoft), Elika Etemad (Invited Expert), Sylvain Galineau (Mic
  99. # [18:24] <dbaron> rosoft), Divya Manian (Opera), Peter Linss (HP)
  100. # [18:24] <nimbupani> Oliver - Anne van Kesteren
  101. # [18:25] <arno> glazou: let's start w/ ISV
  102. # [18:25] <dbaron> And Brad Kemper present via Skype
  103. # [18:26] <arno> glazou: let's start monday with object model, then regions/exclusions
  104. # [18:26] <arno> finish w/ gradient if we have time in the morning
  105. # [18:26] <arno> writing modes and grid in the afternoon... and positioning
  106. # [18:26] <arno> first topic of the day: ISV feedback
  107. # [18:26] <arno> any report on what's happening
  108. # [18:27] <fantasai> http://lists.w3.org/Archives/Member/w3c-css-wg/2011JulSep/0087.html
  109. # [18:27] <fantasai> latest version
  110. # [18:27] <arno> fantasai: haven't received feedback on this yet
  111. # [18:27] <fantasai> s/this/this version/
  112. # [18:28] <arno> will send to unicode, adobe, hania deshi folks and will cc style and internationalization
  113. # [18:28] <arno> glazou: steve, happy with the proposal?
  114. # [18:28] <arno> steve nods
  115. # [18:28] <arno> glazou: RESOLVED. Send the comment
  116. # [18:29] <arno> glazou: next up: Flexbox
  117. # [18:29] <alexmog_> http://wiki.csswg.org/spec/css3-flexbox
  118. # [18:30] <arno> alex: the major issue to discuss is getting multiline to work with everything else
  119. # [18:30] <arno> and look at where we are with flex definition and flex units
  120. # [18:30] <arno> ideally, talk more about alignment.
  121. # [18:31] <arno> a bit worried about it, lots of different options
  122. # [18:31] <arno> will need whiteboard to draw pictures...
  123. # [18:31] <arno> let's start with multiline and direction
  124. # [18:31] <arno> newer proposal is to use no-wrap, wrap and balance as options
  125. # [18:31] <arno> doesn't *have* to be there, but it's a possibility
  126. # [18:32] <arno> preferences toward wrap/no-wrap/balance vs. single/multiple
  127. # [18:32] <arno> fantasai: wrap/no-wrap is easier to understand, more similar to how we wrap text, whitespace
  128. # [18:33] <arno> Davidb: text-wrap has the default the other way around
  129. # [18:33] <arno> tantek: spelling in text-wrap has no dash
  130. # [18:34] <arno> s/text-wrap/whitespace
  131. # 06[18:35] * arronei time-machine: <integer>
  132. # [18:35] <arno> steve: we also use the word wrap in exclusions, in a different way
  133. # [18:35] <arno> alex: exclusion wrap causes exclusion to happen, text-wrap allows it to happen
  134. # [18:35] <arno> tantek: can we capture as an issue for exclusion to resolve
  135. # [18:35] <arno> ?
  136. # [18:36] <arno> i.e. consider a different erm
  137. # [18:36] <arno> s/erm/term/
  138. # [18:36] <arno> RESOLVED: we
  139. # 03[18:36] * Joins: tantek (tantek@72.254.89.121)
  140. # [18:36] <arno> RESOLVED: use wrap/no-wrap/balance
  141. # [18:36] <tantek> greetings
  142. # [18:37] <arronei> s/no-wrap/nowrap
  143. # [18:37] <tantek> arno, I thought we resolved use "nowrap | wrap"
  144. # [18:37] <arno> alex: multiple proposals on flex-direction issue
  145. # [18:37] <tantek> and postpone "balance" until it is needed/wanted
  146. # [18:37] <arno> tantek: correct…
  147. # [18:38] <arno> RESOLVED: use wrap/nowrap (no dash)
  148. # [18:38] <tantek> thanks arno
  149. # [18:38] <arno> glazou: want lines to go start and end,not left and right
  150. # [18:38] <arno> tab: no, sometimes you need left and right
  151. # [18:39] <arno> glazou: you need to take into account text directionality
  152. # [18:39] <tantek> there are cases for both
  153. # [18:39] <arno> tab: sometimes left and right are all that matters
  154. # [18:39] <arno> alex: does this need to be one property, or can line property be one
  155. # [18:39] <arno> and children direction another
  156. # [18:39] <arno> alex: with one property, it can become verbose
  157. # [18:40] <arno> see option 2
  158. # [18:40] <arno> sometimes want direction to be physical, sometimes mesh writing mode direction, it all creates a lot of permutations
  159. # [18:41] <arno> tantek: seems like a similar problems to background position ppp
  160. # [18:41] <arno> different dimensions, and lots permutations…
  161. # [18:41] <arno> fantasai: we don't have keywords for background position yet
  162. # [18:41] <arno> fantasai: they're different keywords
  163. # [18:41] <arno> tantek: we should emulate design pattern of background position
  164. # [18:42] <arno> alex: how would that translate?
  165. # [18:42] <arno> tab: looking at option 1, if we separate the keyword and remove the dash (have two keywords), the grammar becomes simpler
  166. # 02[18:42] * Quits: Ms2ger (Ms2ger@91.181.41.169) (Client exited)
  167. # [18:42] <arno> david: we don't want to mix logical and physical
  168. # [18:43] <arno> fantasai: i can see use cases for it
  169. # [18:43] <arno> fantasai: horizontal toolbar at the top of the screen, with logical ordering...
  170. # [18:44] <arno> davidb: the logical ordering could be vertical, you could end up making multiline in a way that makes no sense
  171. # [18:44] <TabAtkins_> [ lr | rl [ tb | bt ]? | [ tb | bt [ lr | rl ]? ] | (duplicated for logical)
  172. # [18:44] <arno> david: that means we would want either one property, or four...
  173. # 03[18:44] * Joins: szilles (chatzilla@72.254.60.135)
  174. # [18:44] <TabAtkins_> [ lr | rl [ tb | bt ]?] | [ tb | bt [ lr | rl ]? ] | (duplicated for logical)
  175. # [18:45] <tantek> tab did you mean? [ lr | rl [ tb | bt ]?] || [ tb | bt [ lr | rl ]? ]
  176. # [18:45] <arno> alex: is this space separated?
  177. # [18:45] <arno> tab: yes, just like option 1, but with a space instead of -
  178. # [18:45] <arno> davidb: what if the options for logical were simply forward and reverse?
  179. # [18:46] <arno> alex: was the same way for the primary direction
  180. # [18:46] <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Jun/0303.html
  181. # [18:46] <tantek> tab, oh wait I see what you're doing
  182. # [18:46] <arno> david: still has confusing situations where. if primary direction is logical (line flows ltr) and secondary direction....
  183. # [18:47] <arno> alex: before we had four options for directions
  184. # [18:47] <arno> direction didn't have any physical options
  185. # [18:47] <arno> we could get back to that set of options
  186. # [18:47] <arno> would get us 4 x 2 x 2, 16 options
  187. # [18:47] <TabAtkins_> [ lr | rl | tb | bt | se | es | ba | ab ] [forward | reverse]?
  188. # [18:48] <arno> the forward direction is always a good default
  189. # [18:48] <tantek> TabAtkins - I like that one
  190. # [18:48] <arno> fantasai: agree
  191. # [18:48] <arno> david: ab and ba are confusing (stand for before and after)
  192. # [18:48] <dbaron> (but could be perceived as above/below, which is backwards)
  193. # [18:48] <arno> but could be interpreted as above and below (which the opposite of the intend)
  194. # [18:49] <TabAtkins_> TabAtkins_: Instead we could use [inline | inline-reverse | block | block-reverse] for the logical directions.
  195. # [18:49] <dbaron> TabAtkins_, yeah
  196. # [18:49] <arno> alex: don't like combining orientation and direction
  197. # [18:50] <arno> glazou: what's the use case? switching from horizontal to vertical?
  198. # [18:50] <arno> alex: horizontal and vertical are common, reverse direction is rare
  199. # [18:50] <arno> tantek: those primary use cases should be documented (with diagramas)
  200. # [18:50] <arno> fantasai: your browser window is a good example
  201. # [18:51] <arno> steve: vertical = horizontal text, vertically stacked?
  202. # [18:52] <tantek> REQUEST: diagrams in the css3-flexbox editor's draft that illustrate the "two primary use cases" (as defined by alexmog)
  203. # [18:52] <arno> fantasai: i like we should be able to say "horizontal" or "vertical" and get good defaults
  204. # [18:52] <arno> david: I like tab's new proposal
  205. # [18:53] <arno> you get good horizontal/vertical defaults out of physical direction
  206. # [18:53] <TabAtkins_> [ lr | rl | tb | bt | block | block-reverse | inline | inline-reverse ] [ forward | reverse ]?
  207. # [18:53] <arno> david: doesn't give you wrap direction, but perhaps should be second keyword on wrap
  208. # [18:53] <arno> (i.e add reverse keyword)
  209. # 02[18:54] * Quits: konaya (konaya@130.229.159.142) (Ping timeout)
  210. # [18:54] <arno> david: so we could have "balance reverse"
  211. # [18:54] <TabAtkins_> flex-wrap: nowrap | [ wrap reverse? ]
  212. # 02[18:54] * Quits: szilles (chatzilla@72.254.60.135) (Ping timeout)
  213. # [18:54] <arno> line-wrapping default would be to use whatever direction you haven't used yet
  214. # [18:55] <arno> fantasai: imagine vertical toolbar on the side
  215. # [18:55] <arno> (makes gestures)
  216. # [18:55] <arno> david: don't want lots of possibilities that mean nothing
  217. # [18:56] <arno> fantasai: (draws on whiteboard)
  218. # [18:56] <arno> fantasai: tab's proposal is simple from a design perspective
  219. # [18:56] <bradk> I can't see the whiteboard
  220. # [18:56] <arno> but the keywords don't really make sense
  221. # [18:56] <TabAtkins_> fantasai: If you have a vertical toolbar on the left, you want new lines to stack to the right. But if you have it on the right, you want new lines on the left. This is unrelated to the logical directions.
  222. # [18:57] <arno> whiteboard: toolbar on right that moves toward left, and vice versa
  223. # [18:57] <arno> david: looking at examples, and don't know what they do, e.g. "flex-flow: reverse"
  224. # [18:57] <arno> david: why is there an implicit default of inline
  225. # [18:57] <arno> ?
  226. # [18:58] <arno> fantasai: the default is rows
  227. # [18:58] <glazou> daniel, david and tantek don't understand the meaning of the values
  228. # [18:58] <arno> fantasai: what is ltr ttb?
  229. # [18:58] <arno> alex: like wrap direction part of wrap property
  230. # [18:59] <dbaron> s/fantasai/dbaron/
  231. # [18:59] <arno> alex: we just need 4 physical, 2 logical and that's it
  232. # [18:59] <arno> tab: we would need to define validity across two properties...
  233. # [19:00] <arno> david: not sure i buy the use case (from fantasai)
  234. # [19:00] <arno> fantasai: if you have toolbars on the side, they're going to wrap towards the center
  235. # [19:01] <arno> if you have chinese labels, for example, you would still wrap the text inward
  236. # [19:01] <arno> fantasai: the layout of the UI would probably trump the text direction
  237. # 03[19:02] * Joins: kojiishi (kojiishi@72.254.57.252)
  238. # [19:02] <nimbupani> bradk: https://picasaweb.google.com/lh/photo/2rjkIQQ4ns1SRUe9gqNBZ4dZ5C9XFTqVazEUohMLkyU?feat=directlink
  239. # [19:02] <tantek> alexmog: I just looked at the 13 examples at http://wiki.csswg.org/spec/css3-flexbox/use-cases - which of those are the "two primary use-cases" ?
  240. # [19:02] <arno> nimbupani: thanks!
  241. # 03[19:02] * Parts: tantek (tantek@72.254.89.121)
  242. # 03[19:02] * Joins: tantek (tantek@72.254.89.121)
  243. # [19:03] <bradk> thnx
  244. # [19:03] <arno> fantasai: need to find civil engineering software in japanese
  245. # [19:03] <arno> they have the most horrible UI...
  246. # [19:04] <arno> tantek: which of the 13 use cases on the wikipage (see above) are primary?
  247. # [19:04] <arno> dbaron: I think he's talking about 2 primary direction patterns within these use cases
  248. # [19:04] <arno> alex: use cases are from tab and focussing on things that are better w/ tab spec
  249. # [19:05] <arno> tab: not true, they are extensive use cases. the fact they are better is not a consequence of me writing them
  250. # [19:05] <arno> tab: i haven't been cherry-picking
  251. # 03[19:05] * Joins: szilles (chatzilla@72.254.60.135)
  252. # [19:05] <arno> alex: they're not prioritized right now
  253. # [19:05] <arno> alex: simplest use case is horizontal toollbar
  254. # [19:05] <arno> tantek: that's number 5?
  255. # [19:06] <arno> glazou: am i the only finding those examples extremely difficult to read (rhetorical question)?
  256. # [19:06] <arno> glazou: CSS used to be easy to read
  257. # [19:06] <arno> tab: those examples are *really* difficult to do with CSS today, or require JavaScript
  258. # [19:07] <arno> tantek: could we order from simplest/most common to more complex
  259. # [19:07] <arno> REQUEST 1: order use cases from simplest/most common to more complex
  260. # [19:07] <arno> REQUEST 2: include some images/graphics illustrating them
  261. # [19:08] <arno> alex: can we narrow down to a couple options we like?
  262. # [19:08] <arno> tab: fantasai has illustrated well that physical and logical orientation are independent
  263. # [19:08] <arno> fantasai: although in some cases you *may* want them to be related
  264. # [19:09] <arno> alex: there can be some combinations that don't make sense.
  265. # [19:09] <arno> alex: but I'm not very concerned about this
  266. # [19:10] <arno> could use a dash instead of space
  267. # [19:10] <dbaron> tb | bt | lr | rl | [ tb | bt ] [ lr | rl ] | [ lr | rl ] [ tb | bt ] | [ block | inline ] reverse? reverse-line?
  268. # [19:10] <arno> tab: we traditionally only separate properties when they are useful to be cascaded separately, but that's not the case here
  269. # [19:10] <arno> or at least we haven't made that case
  270. # [19:10] <arno> glazou: even if you rotate an interface from landscape to portrait mode?
  271. # [19:11] <arno> steve: suggestion: people who have a scheme in mind apply them to at least two use case so we can better understand what the options are
  272. # [19:12] <arno> alex: direction vs. orientation or direction vs. flow-wrap direction, we don't want to separate into two properties
  273. # [19:12] <dbaron> tb | bt | lr | rl | [ tb | bt ] [ lr | rl ] | [ lr | rl ] [ tb | bt ] | [ block | inline ] wrap? reverse? reverse-line?
  274. # [19:12] <arno> may have a single set of keywords, separated by dashes or spaces
  275. # [19:12] <arno> we'll have diagrams tomorrow and proposal
  276. # [19:13] <arno> dbaron: also: is wrapping or not part of the same property?
  277. # [19:13] <arno> (see above)
  278. # [19:13] <arno> Alex: we got an action. time for more issue?
  279. # [19:14] <arno> ISSUE 3: flexbox has two ways to align transverse directions — confusing and still incomplete
  280. # [19:15] <arno> alex: if we're going to talk about flexbox tomorrow, might be better to talk about alignment issue then
  281. # [19:16] <arno> alex: alignment is currently happening by setting margins, only option is baseline or nothing
  282. # [19:16] <arno> but two ways to do alignment, which is confusing
  283. # [19:16] <arno> tab: currently happening using margins and padding
  284. # [19:16] <arno> alex: that's another problem: padding is not parent controls
  285. # [19:16] <arno> flexbox is dealing with margin boxes of its children
  286. # [19:17] <arno> some layouts don't have padding at all
  287. # [19:17] <arno> it may still be interesting to stay that padding only applies to normal flow, displayed inside blocs
  288. # [19:18] <arno> can't apply it generically
  289. # 02[19:18] * Quits: szilles (chatzilla@72.254.60.135) (Ping timeout)
  290. # [19:18] <arno> tab: yes, can't change other models
  291. # [19:18] <arno> we won't redefine what padding means, but padding is still something that flexbox can affect on children
  292. # [19:18] <arno> steve: what's the computed value of computing
  293. # [19:18] <arno> tab: the result of resolving the flex
  294. # [19:19] <arno> tantek: it's the used value, not the computed value
  295. # [19:19] <arno> tab: i tried to change this for transverse alignment
  296. # [19:19] <arno> it changed it from keywords because i wanted it to be easier to understand wrt the box model, where you use margins and padding for alignment
  297. # [19:20] <arno> alex: i would be ok with that if the align property disappeared
  298. # [19:20] <arno> tab: but we really want baseline alignment
  299. # [19:20] <arno> dbarron: using auto to align is really confusing
  300. # [19:20] <arno> tab: i used to think so, but not anymore
  301. # [19:21] <arno> fantasai: can be used to mean different things
  302. # [19:21] <arno> alex: so, get alignment back, but leave margins
  303. # [19:21] <arno> that's what grid-layout does right now
  304. # [19:21] <arno> it has a line property (before, after, stretch)
  305. # [19:22] <arno> if stretch, margin: auto margin-box will stretch to the whole box
  306. # [19:22] <arno> tab: that's weird, though
  307. # [19:22] <arno> old definition of stretch is to stretch the box, not the margins
  308. # [19:22] <arno> alex: flexbox is really dealing with margin boxes
  309. # [19:23] <arno> tab: so you're having alignment to be more powerful than margins
  310. # [19:23] <arno> alex: yeah, that's how it works now
  311. # [19:23] <arno> steve: that's what you have to do to support baseline, right?
  312. # [19:24] <arno> tab: if we make it work this way, i'd like to get flex pack to work the same way
  313. # [19:24] <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Jul/0406.html
  314. # 02[19:26] * Quits: arno (arno@72.254.90.86) (Quit: Leaving.)
  315. # 03[19:26] * Joins: arno (arno@72.254.90.86)
  316. # [19:26] <arno> tab: in the alignment direction there's no flexibility at all unless you align stretch
  317. # [19:27] <arno> then we try to resolve stretchy height, and if that doesn't take all the space then stretchy margins
  318. # [19:27] <arno> alex: we should use the same sequence as for the box model: margin, widths
  319. # [19:27] <arno> use the same order to resolve
  320. # [19:27] <arno> tab: so width and height resolve first
  321. # [19:28] <arno> tab: need to think about it, it might work
  322. # [19:28] <arno> want to make sure we have a consistent resolution, otherwise it's going to be very confusing
  323. # [19:28] <arno> steve: in the alignment direction, there is no flex?
  324. # [19:28] <dbaron> TabAtkins, I'd suggest "main axis/direction" and "cross axis/direction"
  325. # [19:28] <arno> alex: right
  326. # [19:29] <arno> molly: this consistency issue is very important for authors
  327. # [19:29] <arno> tab: i think it might work out. let me play with it a bit more.
  328. # [19:29] <arno> i will come back with a proposal for this tomorrow and we can vote on it (or decide it still sucks and talk about it some more)
  329. # [19:30] <arno> glazou: fifteen minutes break
  330. # 06[19:30] * fantasai loves dbaron's proposed terminology, let's use it!
  331. # 02[19:30] * Quits: vhardy (vhardy@72.254.56.182) (Quit: vhardy)
  332. # 02[19:30] * Quits: plinss_ (plinss@72.254.91.11) (Quit: plinss_)
  333. # 02[19:37] * Quits: florian (florianr@72.254.58.176) (Ping timeout)
  334. # 03[19:42] * Joins: plinss_ (plinss@72.254.91.11)
  335. # 03[20:00] * Joins: jdaggett (jdaggett@208.54.5.239)
  336. # [20:03] <arno> glazou: gavel, gavel, gavel
  337. # [20:03] <arno> and we're back from our fifteen-ish break
  338. # [20:03] <arno> glazou: back to flexbox. alex has the floor
  339. # 03[20:03] * Joins: szilles (chatzilla@72.254.60.135)
  340. # [20:03] <arno> alex: we'll have a proposal tomorrow to discuss
  341. # [20:03] <arno> regarding ISSUE 4
  342. # [20:04] <arno> consider 'true-center' as an align option for flexbox
  343. # [20:04] <bradk> link?
  344. # [20:04] <arno> http://www.html5rocks.com/en/tutorials/flexbox/quick/
  345. # [20:04] <stearns> http://www.html5rocks.com/en/tutorials/flexbox/quick/#toc-center
  346. # [20:05] <arno> resize text area until it's longer than the green box
  347. # [20:05] <arno> see section "Center stage: positioning in the middle"
  348. # [20:06] <arno> tantek: isn't that what text-align does today?
  349. # [20:06] <arno> alex: doesn't make a lot of sense for text, but useful for images
  350. # 03[20:06] * Joins: vhardy (vhardy@72.254.56.182)
  351. # [20:06] <arno> steve: related problem with exclusion positioning
  352. # [20:06] <arno> does true-center mean center of container?
  353. # [20:07] <arno> tab: it's the "center of mass"
  354. # [20:07] <arno> steve: interesting to discuss with irregularly shaped objects
  355. # [20:08] <arno> tab: question is do we want a way to describe it should stay centered even if larger than parent container?
  356. # [20:08] <arno> steve: what about scrollbars, then?
  357. # [20:08] <arno> alex: let's keep as an issue until we have a use case identified
  358. # [20:08] <arno> tab: so, not in spec at the moment, until we have a use case
  359. # [20:09] <arno> steve: can we add to the issue that center here means "center of object"
  360. # 02[20:09] * Quits: szilles (chatzilla@72.254.60.135) (Ping timeout)
  361. # [20:09] <arno> molly: the relation to overflow is an important one for authors/developers...
  362. # [20:09] <arno> alex: ISSUE 5: page breaking
  363. # 03[20:10] * Joins: szilles (chatzilla@72.254.60.135)
  364. # [20:10] <arno> flexbox paginates in both direction in IE
  365. # [20:11] <arno> tab: we need to solve it, alex has a proposal based on implementation experience
  366. # [20:11] <arno> steve: if we have a flexbox in a multi-col, does it collumnate?
  367. # [20:11] <arronei> old centering proposal from Ian, http://lists.w3.org/Archives/Member/w3c-css-wg/2002JulSep/0296.html
  368. # [20:11] <arno> s/collumnate/columnate/
  369. # [20:12] <arno> fantasai: centroid! geographic center is centroid'
  370. # 06[20:12] * glazou next challenge for CSS WG in this ftf : use "fixed Lorentz point 1" :-)
  371. # [20:13] <arno> tab: splitting display into display-inside and display-outside?
  372. # [20:13] <arno> dbaron: what are the use cases?
  373. # [20:13] <dbaron> s/dbaron/tantek/
  374. # [20:14] <arno> tab: use case is table cell (or list item) being a flexbox
  375. # [20:15] <arno> tab: ex. gmail, my list of messages is list item, and i want a item number in my list item
  376. # [20:15] <arno> tantek: in gmail, it's tabular data, not a list
  377. # [20:15] <arno> fantasai: you need a grid model, so they can align
  378. # [20:16] <arno> you would need a 2D flexbox, which we don't have
  379. # [20:16] <arno> tantek: this example doesn't seem to be a convincing use case
  380. # [20:17] <arno> alex: syntax that defines behavior doesn't match what any reasonable implementation is going to do, which is to treat those properties separately
  381. # [20:17] <arno> there's nothing wrong with having a table-cell treated as a flexbox (or a grid)
  382. # 02[20:17] * Quits: szilles (chatzilla@72.254.60.135) (Ping timeout)
  383. # [20:17] <arno> if in the future we're going to get more layout types that require a particular behavior on child element
  384. # [20:18] <arno> this lack of display-inside will become a blocking problem
  385. # [20:18] <arno> tantek: can we solve it when we have this future use case defined?
  386. # [20:18] <arno> dbaron: we keep adding new display types to work around this...
  387. # [20:19] <arno> steve: the spec is more understandable if there is an internal and external behavior defined, which are independent
  388. # [20:19] <arno> understanding the kind of objects we're dealing with is important to use it correctly
  389. # [20:19] <arno> tantek: are you saying if we introduce it now it simplifies flexbox?
  390. # [20:19] <arno> tab: yes, because i wouldn't have to introduce a new display-type value that still doesn't solve the table-cell issue
  391. # [20:20] <arno> glazou: do we need two different properties, or a pseudo-element called outside
  392. # [20:20] <dbaron> glazou: Do we need 2 properties (display-inside and display-outside) or an ::outside pseudo-element?
  393. # [20:20] <arno> tab: it wouldn't work for list-item
  394. # [20:21] <arno> fantasai: you can't an inline list item behavior by nesting any of the boxes we have today
  395. # [20:21] <arno> alex: if we make this addition, in what spec would we add it
  396. # [20:22] <arno> eric: that would be CSS3-box
  397. # [20:22] <arno> oliver: there's a version from 2007
  398. # [20:22] <arno> steve: there's a more recent editor's draft; bert has been working on it
  399. # [20:22] <arno> oliver: it's out of sync with 2.1, though
  400. # 03[20:22] * Joins: szilles (chatzilla@72.254.60.135)
  401. # [20:23] <arno> tab: we might want to try to revive box, or get bert to share what he's working on...
  402. # [20:23] <arno> tantek: would prefer the latter
  403. # [20:23] <arno> tab: you do want those properties to cascade separately, so two properties would make senese
  404. # [20:24] <arno> tantek: do the use case support only one of the two properties?
  405. # 02[20:24] * Quits: jdaggett (jdaggett@208.54.5.239) (Ping timeout)
  406. # [20:24] <arno> are there use cases for both?
  407. # [20:24] <arno> fantasai: imagine a toolbar...
  408. # [20:24] <arno> i can positing elements inside it using flexbox, table models, etc...
  409. # [20:24] <arno> but i only want to touch the outside, each items in it can have its own internal structure
  410. # [20:25] <arno> but i don't want to affect that
  411. # [20:25] <arno> tab: we do want to independently control bot
  412. # [20:25] <arno> bot -> both
  413. # [20:26] <arno> dbaron: a lot of CSS uses are not 5 line examples, they're very complicated
  414. # 02[20:26] * Quits: szilles (chatzilla@72.254.60.135) (Ping timeout)
  415. # 02[20:26] * Quits: arronei_ (arronei@131.107.0.89) (Ping timeout)
  416. # [20:26] <arno> tab: when using scripting, you'll want to be able to read the value and restore it
  417. # [20:26] <arno> tantek: but this doesn't resolve display: none
  418. # [20:27] <arno> tab: marker creation or display:noning could be hooked to another property
  419. # [20:27] <arno> tantek: that's the script example i was thinking about it: hiding and showing things
  420. # 03[20:27] * Joins: arronei_ (arronei@131.107.0.89)
  421. # [20:28] <arno> tab: would hate to have something special there if we can do something css-ly
  422. # [20:28] <arno> alex: are we ready to create an action?
  423. # [20:29] <arno> tantek: if you start splitting the display property, you'll need to look into display:noning and possibly more, with use cases
  424. # [20:29] <arno> then you can argument whether authors need it or not
  425. # [20:29] <arno> we could split it too far
  426. # [20:29] <arno> tab: i don't think we have to
  427. # [20:29] <bradk> I agree with tantek
  428. # [20:30] <arno> tantek: agree, but use cases will help us make sure of that, and not just use our opinions
  429. # [20:30] <arno> tab: the cases we have today are inside/outside, noning, potentially marker (if there's a use case)
  430. # [20:33] <arno> ACTION for tab: specify use case that will go as an issue in CSS3-box
  431. # 06[20:33] * trackbot noticed an ACTION. Trying to create it.
  432. # [20:33] <trackbot> Sorry, couldn't find user - for
  433. # [20:33] <arno> ACTION tab: specify use case that will go as an issue in CSS3-box
  434. # 06[20:33] * trackbot noticed an ACTION. Trying to create it.
  435. # [20:33] <trackbot> Created ACTION-342 - Specify use case that will go as an issue in CSS3-box [on Tab Atkins Jr. - due 2011-07-31].
  436. # [20:33] <arno> steve: assuming there are use cases for this, is this an issue we should pursue?
  437. # [20:34] <arno> alex: rephrasing: given our current understanding of the issue do we think display-inside is a good idea?
  438. # [20:34] <arno> tantek: i don't know
  439. # [20:34] <arno> alex: yes, i think it is a good idea, given our current understanding
  440. # [20:35] <arno> steve: didn't hear people violently opposed to doing it, but would like use case justifying doing it and driving its design
  441. # [20:35] <bradk> Based on what I understand know, I am generally against, as I think it adds complexity to authors that they don't need.
  442. # [20:35] <arno> glazou: what about existing keywords, i.e. inline-table
  443. # [20:35] <bradk> s/know/now/
  444. # [20:35] <arno> tab: they would become shorthands
  445. # [20:37] <arno> alex: would there be an issues with current implementation if you used all permutations of the two properties
  446. # [20:37] <bradk> It is reasonable to have displa-inside|outside as something used in spec language, without exposing it as values to authors.
  447. # [20:37] <arno> eric: like inline-run-in
  448. # [20:37] <arronei> s/eric/arron
  449. # 06[20:38] * dbaron wonders if we should also have display:walk-in and display:sit-in
  450. # 03[20:38] * Joins: szilles (chatzilla@72.254.60.135)
  451. # 06[20:38] * sylvaing display:sleep-in ?
  452. # [20:38] <arno> alex: ISSUE 7
  453. # 06[20:38] * tantek only if we can also have display:walk-out and display:sit-out
  454. # [20:39] <arno> tab: about floats
  455. # [20:39] <arno> spec currently says that floats are ignored and doing what it would do otherwise
  456. # [20:40] <tantek> just for kicks - here's a discussion of separating out display from 2004: http://lists.w3.org/Archives/Member/w3c-css-wg/2004JanMar/0311.html
  457. # [20:41] <tantek> quoting myself from those minutes (cc: TabAtkins): "TC: I still want the list-item-ness and none-ness separate." (lol)
  458. # [20:41] <arno> fantasai: it would be interesting for the float to be a flexbox item
  459. # [20:41] <arno> tab: what about vertical layout?
  460. # 02[20:41] * Quits: szilles (chatzilla@72.254.60.135) (Ping timeout)
  461. # [20:42] <dbaron> So in vertical layout float:left becomes float:top and float:right becomes sink:bottom?
  462. # [20:42] <arno> steve: why doesn't it get wrap in an anonymous block
  463. # [20:42] <arno> steve: so the question is: if i have a float in the middle of the run, what should happen
  464. # [20:42] <arno> ?
  465. # [20:43] <arno> fantasai: you should do what we do we tables
  466. # [20:43] <arno> tab: would love that. what do you do with tables?
  467. # [20:43] <arno> fantasai: we do…
  468. # 03[20:43] * Joins: dino (dino@67.127.245.58)
  469. # [20:43] <arno> dbaron: i would rather not, because nobody likes what we do
  470. # [20:44] <arno> glazout: time-out. many more flexbox issues...
  471. # [20:44] <dbaron> alex: I propose ignoring 'float' property on flexbox items.
  472. # [20:44] <arno> alex: propose to ignore float on flexbox children
  473. # [20:44] <fantasai> fantasai: We take the entire run of improper table children and wrap it in a table cell
  474. # [20:44] <arno> we already ignore float on absolute positioning
  475. # [20:45] <arno> and if you have something that used to be a float, let's say a block-flow placed in a flexbox
  476. # [20:45] <arno> you would expect to see a sequence a flexbox elements, but making it a float make it wrapped in an anonymous block, so the sequence is going to become a anonymous block
  477. # [20:46] <arno> can't really see useful applications of this, because it only happens when you don't have proper element hierarchy
  478. # [20:47] <arno> we're trying to make the fixups scenario somewhat more logical, but could create confusion and misinterpreation of intent when there is no clear benefit of doing that
  479. # [20:47] <arno> steve: if i have a string of text with a float in it, the flow is usually not broken up
  480. # [20:47] <arno> alex: problem is model of flexbox and float are different, and have different layout systems
  481. # [20:48] <arno> we have decided to make inline replaced element individual flex items because otherwise it creates confusion
  482. # [20:48] <tantek> aside: 2000 era discussion of split of display property: http://lists.w3.org/Archives/Member/w3c-css-wg/2000OctDec/0353.html
  483. # [20:49] <arno> steve: we both giving argument of consistency, in inconsistent ways
  484. # [20:49] <arno> alex: two issues: how to deal with floats, and current definition of fixups in flexbox
  485. # [20:50] <glazou> tantek: turning archeologist?-)
  486. # [20:51] <tantek> (btw we previously (2000) discussed outside/inside as role/model e.g. display-role:inline; display-model:block == display:inline-block; )
  487. # [20:51] <tantek> glazou: those who ignore history (of standards) are doomed to repeat (proposals).
  488. # [20:51] <dbaron> yeah, and I proposed renaming them to inside/outside so we could remember which was which :-)
  489. # [20:51] <dbaron> dbaron: I could see changing the wrapping rules to group all text and anything with display-outside:inline
  490. # [20:51] <glazou> tantek: and same mistakes...
  491. # [20:52] <dbaron> TabAtkins: though that raises issues with replaced elements
  492. # [20:52] <tantek> float is merely a display-role
  493. # [20:52] <tantek> so you add a new value display-role
  494. # [20:52] <tantek> and then float value other than none "sets" display-role: to float.
  495. # [20:53] <arno> fantasai: might make sense to have people assign display: block for buttons
  496. # [20:53] <arno> steve: i'm concerned about cut/paste and if things behave completely different depending on context
  497. # [20:54] <arno> alex: we can continue discussion on wiki
  498. # [20:54] <arno> alex: two more issues
  499. # [20:54] <tantek> glazou requested we move on from this issue so that we can have time for HTML5 [first] last call comments.
  500. # 06[20:54] * glazou we have 40 minutes before lunch...
  501. # [20:54] <arno> 1/ treating of absolute positioned content
  502. # 03[20:54] * Joins: szilles (chatzilla@72.254.60.135)
  503. # [20:54] <arno> 2/ inline element within fixups
  504. # [20:55] <arno> (1) is ISSUE 10, (2) is ISSUE 11
  505. # [20:55] <arno> alex: everywhere else, an anonymous empty line is invisible and have no effect
  506. # [20:56] <arno> here, we are creating a third element in between
  507. # 06[20:56] * glazou we move to next topic on agenda at 12:15 at the latest
  508. # [20:56] <arno> tab: if i did this just for flexbox it would be weird, but tables work the same way
  509. # [20:56] <arno> tantek: I think it's a bug
  510. # [20:57] <arno> fantasai: behavior is screwed up, but makes sense to implementor of layout engine
  511. # [20:57] <arno> dbaron: i think we should just advise author not to use absolute positioning
  512. # [20:57] <fantasai> s/but/only/
  513. # 02[20:58] * Quits: szilles (chatzilla@72.254.60.135) (Ping timeout)
  514. # [20:58] <arno> tab: you get an empty table cell
  515. # [20:58] <arno> fantasai: this is interoperably implemented today
  516. # [20:59] <arno> fantasai: i think it's enough of an edge case that we don't have to be consistent with tables, if we can find something better
  517. # [21:00] <JohnJansen> agree. I don't want to repeat what I think is a mistake simply for consistency
  518. # [21:00] <arno> fantasai: what if you have a ghost but it was not allowed to take any size
  519. # [21:00] <arno> tab: even if it doesn't take space, it will allocate extra packing space around it
  520. # [21:00] <arno> steve: you really want display: none
  521. # [21:01] <arno> fantasai: you could define so that it's infinitely thin and doesn't affect layout
  522. # [21:01] <arronei> table test case: http://test.csswg.org/suites/css2.1/20110323/html4/table-visual-layout-023.htm
  523. # [21:01] <fantasai> fantasai: you still need to define the auto position
  524. # [21:01] <arno> tab: flex-pack: justified puts the leftover space between items, so the extra space caused by the ghost wil lbe visible
  525. # 03[21:01] * Joins: szilles (chatzilla@72.254.60.135)
  526. # [21:02] <fantasai> ghost line was Tantek
  527. # [21:02] <arno> alex: i would prefer not having a (detectable) ghost altogether
  528. # [21:02] <tantek> ghosts should not be detectable
  529. # [21:02] <arno> tab: i remember how difficult it was for me to define it for table, until everyone did the interoperable weird behavior
  530. # [21:03] <arno> alex: let's not just create the ghost
  531. # [21:03] <tantek> sounds good - no ghosts
  532. # [21:03] <arno> dbarron: alt proposal: ignore absolute positioning
  533. # [21:04] <arno> how flexbox implementation has ignored floats and absolute positioning
  534. # [21:04] <arno> dbarron: it's a display-outside value
  535. # [21:04] <arno> fantasai: it should have been and effectively is a display-outside value
  536. # [21:05] <glazou> s/dbarron/dbaron
  537. # [21:05] <arno> alex: can't think of a meaningful scenario where you do what's on ISSUE 10
  538. # [21:05] <arno> oliver: if we do display-outside, would it have values like position and float?
  539. # [21:06] <arno> fantasai: display, as a shorthand, would have to reset display-outside
  540. # [21:06] <arno> tantek: maybe it's not a shorthand?
  541. # [21:06] <arno> fantasai: how would you make it not a shorthand?
  542. # [21:06] <glazou> arno: who is Oliver ???
  543. # [21:07] <glazou> arno: anne
  544. # [21:07] <arno> oliver -> anne
  545. # [21:07] <glazou> s/oliver/anne
  546. # [21:08] <arno> tantek: proposal to ignore abs pos, based on implementations
  547. # [21:08] <arno> if you want abs pos to mean something, provide use cases
  548. # [21:08] <arno> tab: i can find use cases
  549. # [21:09] <arno> ACTION tab: provide use cases illustrating value of abs case in context of ISSUE 10
  550. # 06[21:09] * trackbot noticed an ACTION. Trying to create it.
  551. # [21:09] <trackbot> Created ACTION-343 - Provide use cases illustrating value of abs case in context of ISSUE 10 [on Tab Atkins Jr. - due 2011-07-31].
  552. # [21:09] <arno> Alex: ISSUE 11
  553. # [21:09] <arno> glazou: the idea of foo generating anonymous box scares me
  554. # [21:10] <arno> an anonymous block gets created around the <span>
  555. # [21:11] <dbaron> dbaron: It could also just be seen as depending on whether your anonymous box construction algorithm operates top-down or bottom-up?
  556. # [21:11] <arno> dbaron: I think they're boxes, and you should define the anonymous box construction algo so that it gives you the result you want
  557. # [21:11] <arno> dbaron: i don't think it's defined already, but it could be defined
  558. # [21:12] <dbaron> (run that by Boris Zbarsky, though...)
  559. # [21:12] <arno> tab: it operates on box tree but happens before the block in inline fixup
  560. # 03[21:12] * Joins: florian (florianr@72.254.58.176)
  561. # [21:12] <arno> glazou: stop
  562. # [21:12] <arno> fantasai: we had action item to invite anton to WG. What happened?
  563. # [21:13] <arno> glazou: I think Bert was supposed to invite him.
  564. # [21:13] <arno> fantasai: would be good to have him editing CSS3-box
  565. # [21:14] <arno> ACTION glazou: check on the invitation of Anton to WG
  566. # 06[21:14] * trackbot noticed an ACTION. Trying to create it.
  567. # [21:14] <trackbot> Created ACTION-344 - Check on the invitation of Anton to WG [on Daniel Glazman - due 2011-07-31].
  568. # [21:14] <fantasai> Topic: HTML5 LC
  569. # [21:14] <fantasai> glazou: So who reviewed HTML5?
  570. # [21:14] <fantasai> Tantek: Define "review".
  571. # [21:14] <fantasai> dbaron: I reviewed some of the pseudo-class stuff, but not in the last 6 months.
  572. # [21:14] <fantasai> Anne: ... and the rendering section
  573. # [21:15] <fantasai> Tab: I looked at it
  574. # [21:15] <fantasai> dbaron: Every time I look at it, I feel it's not complete.
  575. # [21:15] <fantasai> discussion between glazou and anne wrt group comment vs individual comment
  576. # [21:16] <fantasai> glazou: We have to reply because the HTML5 spec defines things that are in the CSS scope.
  577. # [21:16] <fantasai> SteveZ: If we're letting them define what CSS says and we don't say anything about it
  578. # [21:16] <fantasai> dbaron: The pseudo-class stuff and rendering section don't define CSS
  579. # [21:16] <fantasai> ...
  580. # [21:17] <fantasai> glazou: I sent a note to ? saying that we were not pinged about the additions to selectors.
  581. # [21:18] <fantasai> glazou: CSSWG was not consulted about this.
  582. # [21:18] <fantasai> dbaron: Selectors says what :optional means, and HTML5 says when things are optional.
  583. # [21:19] <fantasai> Tantek: That's the correct split, if needed we should fix our spec to make that work. If HTML5 oversteps its definition, then that's a problem they need to fix
  584. # [21:19] <dbaron> dbaron: What was there other than :ltr/:rtl that the HTML WG shouldn't have done?
  585. # [21:19] <fantasai> anne lists some stuff
  586. # [21:20] <fantasai> glazou: Even if the split between the specs is valid, the lack of communication between CSSWG and HTMLWG is an issue.
  587. # [21:20] <fantasai> Tantek: It's a process issue.
  588. # [21:20] <fantasai> glazou: Yes, but in the end it has technical implications.
  589. # [21:20] <dbaron> ?: also some extensions in WebVTT: ::cue, :past, :future
  590. # [21:22] <fantasai> discussion about coordination and communication
  591. # [21:24] <fantasai> Tantek: I'm going to make some statmeents
  592. # [21:24] <fantasai> Tantek: This group is about advancing the Web platform.
  593. # [21:25] <fantasai> Tantek: We have a lot of the same goals and design principles.
  594. # [21:25] <fantasai> Tantek: We should communicate that we are receptive to ideas and feedback that fall under our scope.
  595. # [21:26] <fantasai> Tantek: That's the best way to encourage that communication.
  596. # 02[21:26] * Quits: szilles (chatzilla@72.254.60.135) (Ping timeout)
  597. # [21:26] <fantasai> Tantek: Good ideas happen everywhere. If we communicate that, we're more likely to get that feedback.
  598. # [21:27] <fantasai> Florian: I agree. Even if as a group we are offended, acting that way will not improve the situation .
  599. # 02[21:28] * Quits: dino (dino@67.127.245.58) (Quit: dino)
  600. # [21:28] <fantasai> Steve: .. We should take a positive approach towards improving communication.
  601. # [21:28] <fantasai> Steve: We should document what the split is. And request that when they want something on our side, they make that request.
  602. # [21:29] <fantasai> glazou: Does everyone agree with that?
  603. # [21:29] <dbaron> http://dev.w3.org/html5/spec/rendering.html#timed-text-tracks-0 says "Note: This section is intended to be moved to its own CSS module once an editor is found to run with it."
  604. # [21:29] <fantasai> glazou: I suggest that I don't write this ocmment
  605. # [21:29] <fantasai> Anne: HTMLWG is less of a centralized effort than CSSWG. It's hard to get a coordinated response.
  606. # [21:29] <fantasai> glazou: Still have a few technical issues to discuss.
  607. # [21:30] <fantasai> glazou: Wrt disabled attribute on style sheets -- it's not reflected in the markup.
  608. # [21:30] <fantasai> glazou: Makes it impossible to save the disabled status on the <link>
  609. # 03[21:31] * Joins: szilles (chatzilla@72.254.60.135)
  610. # [21:31] <fantasai> dbaron: How does that interact with fantasai's proposal of the interaction of alternate style sets from 4-7 years ago?
  611. # [21:31] <dbaron> anne: It's in WebKit and Gecko and in cssom
  612. # [21:32] <fantasai> fantasai: I thin hixie wrote a variation on that that was in one of his whatwg specs, which bz implemented.
  613. # [21:32] <fantasai> Tantek: Is there a bug report on this?
  614. # [21:32] <fantasai> anne: Wasn't it won'tfixed?
  615. # [21:33] <fantasai> glazou: There's also ::cue, :past and :future pseudo-classes
  616. # [21:34] <fantasai> dbaron: So that section has a note at the top saying that this section should move to a CSS spec once an editor is found
  617. # [21:34] <fantasai> fantasai: But they haven't told us that.
  618. # 02[21:34] * Quits: szilles (chatzilla@72.254.60.135) (Ping timeout)
  619. # 03[21:35] * Joins: szilles (chatzilla@72.254.60.135)
  620. # [21:36] <fantasai> anne: Those definitions are very specific to how WebVTT works
  621. # [21:36] <fantasai> fantasai: :past and :future would apply to other formats as well
  622. # [21:36] <fantasai> fantasai: e.g. reader
  623. # [21:37] <fantasai> glazou: Last comment I have is that HTML5 makes a lot of references to CSS editor's drafts and WDs, and says these references are normative
  624. # 02[21:37] * Quits: JohnJansen (qw3birc@128.30.52.28) (Quit: Page closed)
  625. # [21:38] <fantasai> glazou: I think it's a problem to normatively reference a CSS editor's draft.
  626. # [21:38] <fantasai> anne: They exist, you can reference them.
  627. # [21:38] <fantasai> glazou: They're unstable.
  628. # [21:38] <fantasai> sylvain: They're not normative.
  629. # [21:38] <fantasai> glazou: In the Consortium you cannot reference such a document.
  630. # 03[21:38] * Joins: paul_irish (paul_irish@76.14.88.222)
  631. # [21:38] <fantasai> glazou: THat's why some of our documents were blocked in the process.
  632. # 06[21:39] * tantek created http://wiki.csswg.org/spec/reviews/html5
  633. # [21:39] <fantasai> sylvain: If HTML5 wants to depend on something that prevents them from advancing, that's their problem
  634. # [21:40] <fantasai> Molly: But if people depend on something that's unstable and it changes, that's a problem for everyone.
  635. # [21:41] <fantasai> sylvain: So we have the issue. We have to call it out.
  636. # [21:42] <fantasai> <br type="lunch"/>
  637. # 02[21:43] * Quits: glazou (glazou@72.254.94.5) (Quit: glazou)
  638. # [21:43] <TabAtkins_> Regarding the :ltr/:rtl thing, it was added in response to <http://www.w3.org/Bugs/Public/show_bug.cgi?id=10808>, filed by the i18n WG.
  639. # 02[21:43] * Quits: nimbupani (Adium@72.254.56.249) (Client exited)
  640. # 02[21:43] * Quits: arno (arno@72.254.90.86) (Quit: Leaving.)
  641. # 02[21:43] * Quits: vhardy (vhardy@72.254.56.182) (Quit: vhardy)
  642. # 02[21:43] * Quits: tantek (tantek@72.254.89.121) (Quit: tantek)
  643. # 02[21:46] * Quits: TabAtkins_ (tabatkins@72.254.84.188) (Ping timeout)
  644. # 02[21:46] * Quits: szilles (chatzilla@72.254.60.135) (Ping timeout)
  645. # 02[22:01] * Quits: kojiishi (kojiishi@72.254.57.252) (Ping timeout)
  646. # 03[22:11] * Joins: konaya (konaya@83.251.16.72)
  647. # 02[22:13] * Quits: anne (annevk@72.254.92.35) (Ping timeout)
  648. # 02[22:21] * Quits: mollydotcom (mollyh@72.254.82.56) (Client exited)
  649. # 03[22:49] * Joins: ed (ed@88.131.66.80)
  650. # 03[23:04] * Joins: nimbupani (Adium@72.254.57.153)
  651. # 03[23:05] * Joins: szilles (chatzilla@72.254.89.133)
  652. # 03[23:06] * Joins: kojiishi (kojiishi@72.254.62.119)
  653. # 03[23:06] * Joins: anne (annevk@72.254.92.35)
  654. # 02[23:09] * Quits: szilles (chatzilla@72.254.89.133) (Ping timeout)
  655. # 03[23:10] * Joins: glazou (glazou@72.254.58.58)
  656. # 03[23:10] * Parts: glazou (glazou@72.254.58.58)
  657. # 03[23:10] * Joins: glazou (glazou@72.254.58.58)
  658. # 06[23:13] * alexmog_ just realized "sunset" is a technical term for phasing out support for a software product
  659. # 03[23:13] * Joins: mollydotcom (mollyh@72.254.82.56)
  660. # 03[23:13] * Joins: szilles (chatzilla@72.254.89.133)
  661. # 03[23:13] * Joins: tantek (tantek@72.254.89.121)
  662. # 06[23:13] * alexmog_ so "sunset cruise" could be technically named "IE6 cruise"
  663. # [23:13] <fantasai> ScribeNick: fantasai
  664. # [23:13] <fantasai> discussion of what order to discuss things in
  665. # 03[23:13] * Joins: vhardy (vhardy@72.254.56.182)
  666. # 03[23:14] * Joins: TabAtkins_ (tabatkins@72.254.60.218)
  667. # [23:14] <dbaron> ScribeNick: dbaron
  668. # [23:14] <dbaron> Topic: Scheduling of upcoming F2F meetings
  669. # [23:14] <dbaron> Peter: Let's try to get some concrete dates
  670. # 03[23:15] * Parts: florian (florianr@72.254.58.176)
  671. # [23:15] <dbaron> Peter: Daniel proposed last week of January or first week of February
  672. # [23:15] <dbaron> Daniel: Week of Jan 30 - Feb 3
  673. # [23:15] <dbaron> Peter: Let's figure out dates first, then places
  674. # 03[23:16] * Joins: arno (arno@72.254.90.86)
  675. # [23:16] <dbaron> SteveZ: Need to avoid MLK weekend and President's day weekend in the US, if families with children.
  676. # [23:16] <dbaron> dbaron: SXSW Interactive is March 9-13
  677. # [23:18] <dbaron> Molly: consider weather for Jan/Feb
  678. # [23:19] <tantek> http://wiki.csswg.org/planning/2012
  679. # [23:19] <dbaron> Daniel: La ... is a meeting space in the center of paris with a lot of meeting rooms, W3C has connections.
  680. # [23:19] <dbaron> Daniel: near Grand Boulevard metro station
  681. # [23:19] <tantek> Please add dates to avoid meetings on this wiki page: http://wiki.csswg.org/planning/2012
  682. # [23:19] <tantek> (I've added SXSW)
  683. # [23:20] <dbaron> Peter: I'm proposing 4 meetings next year, including TPAC
  684. # [23:21] <dbaron> David: If we spaced evenly...
  685. # [23:21] <dbaron> Daniel: Late July doesn't work for me next year
  686. # [23:21] <tantek> updated: http://wiki.csswg.org/planning/2012
  687. # [23:22] <dbaron> Daniel: end of April doesn't work for me; beginning of May does
  688. # [23:23] <dbaron> Florian: Golden week in Japan -- ok with me, what about others?
  689. # 03[23:24] * Joins: florian (florianr@72.254.58.176)
  690. # [23:24] <dbaron> Peter: so, First week of may?
  691. # [23:24] <dbaron> Koji: First week of May not very good for Japan, though second week is ok
  692. # [23:25] <dbaron> Peter: Week of may 7-11?
  693. # [23:25] <dbaron> WWW2012 is April 16-20 in Lyon
  694. # [23:26] <dbaron> Steve: I might be able to figure out AC meeting dates tomorrow.
  695. # [23:26] <dbaron> Peter: Let's get a stake in the ground.
  696. # [23:26] <dbaron> Peter: first week of August... July 30-August 3?
  697. # [23:27] <dbaron> Steve: might not work for me
  698. # [23:27] <dbaron> Steve: first 2 weeks in August bad for me
  699. # [23:27] <dbaron> Peter: August 13-17?
  700. # [23:27] <dbaron> Peter: ok, august 13-17
  701. # [23:28] <dbaron> Peter: ok, target is weeks of Jan 30-Feb 3, May 7-11, Aug 13-17
  702. # [23:28] <dbaron> ... plus TPAC, whenever it is
  703. # [23:28] <dbaron> Peter: locations?
  704. # [23:28] <dbaron> Peter: TPAC likely in Europe
  705. # [23:29] <bradk> Hawaii is nice
  706. # [23:30] <dbaron> Daniel: could do Paris in Febuary
  707. # [23:30] <dbaron> Peter: I can do any in San Diego
  708. # [23:30] <dbaron> Peter: But then we're 3 in a row on the US west coast.
  709. # [23:31] <dbaron> Kimberly: I could do Philadelphia, preferably May
  710. # [23:31] <dbaron> Bucharest, Adobe?
  711. # [23:31] <dbaron> s/?//
  712. # [23:31] <dbaron> Arno: Could do Hamburg as well if it makes a difference...
  713. # [23:32] <dbaron> [fast discussion of date/place combinations]
  714. # [23:32] <dbaron> Daniel: don't want 3 in a row in the US
  715. # 02[23:32] * Quits: szilles (chatzilla@72.254.89.133) (Ping timeout)
  716. # [23:33] <dbaron> Peter: so, Paris in January
  717. # [23:33] <bradk> http://maps.google.com/maps?q=microsoft&hl=en&ll=21.316243,-157.859459&spn=0.284973,0.260239&sll=20.128155,-157.016602&sspn=9.182145,8.327637&gl=us&z=12&iwloc=A
  718. # 03[23:34] * Joins: szilles (chatzilla@72.254.89.133)
  719. # [23:35] <dbaron> Peter: ok, Bucharest in May, and San Diego in August
  720. # [23:35] <anne> tantek, what is that wiki page we have on HTML issues?
  721. # [23:35] <anne> tantek, I filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=13346 on the :ltr and :rtl pseudo-classes needing to be changed to use :dir
  722. # [23:35] <dbaron> Peter: so we have something laid out, will narrow down later so people can book flights
  723. # [23:36] <dbaron> Topic: Selectors 4
  724. # [23:36] <tantek> anne - thanks! http://wiki.csswg.org/spec/reviews/html5
  725. # [23:36] <fantasai> http://dev.w3.org/csswg/selectors4/
  726. # [23:37] <dbaron> fantasai: I've done a little cleanup on the draft. I wanted people to know what's in here before FPWD.
  727. # [23:37] <dbaron> fantasai: Started with a copy of selectors 3, minus the pseudo elements which I think should be in a separate module.
  728. # 02[23:38] * Quits: szilles (chatzilla@72.254.89.133) (Ping timeout)
  729. # [23:38] <dbaron> fantasai: I added :links-here and :current
  730. # [23:39] <tantek> for Paris - would prefer more toward end of January than into February
  731. # [23:39] <tantek> IxDA is Feb 1-4
  732. # [23:39] <dbaron> Steve: Got reply -- AC likely Japan or Sophia in May, TPAC probably Lyon in October/November 2012.
  733. # [23:39] <dbaron> fantasai: :links-here used to be :local
  734. # [23:39] <dbaron> fantasai: oh, I like that better
  735. # [23:40] <dbaron> Daniel: or, more explicit, :local-link
  736. # [23:40] <dbaron> many: :local-link
  737. # [23:40] <anne> :local-link is bad
  738. # [23:40] <anne> is there :local-visited?
  739. # [23:40] <glazou> s/fantasai: :links-here/glazou: :links-here
  740. # [23:41] <dbaron> fantasai: two forms, :local-link says url poinst to the page we have now, and the other form takes an integer argument says how many levels of depth in the URL you match against
  741. # [23:41] <glazou> anne :local-link:visited ?
  742. # [23:41] <dbaron> fantasai: a level of 0 selects any link to the same domain, 1 any link to in the same path segment
  743. # [23:41] <dbaron> fantasai: allows easier styling of navigation on Web sites
  744. # [23:41] <dbaron> peter: I could also see a use for levels of subdomains
  745. # [23:41] <dbaron> fantasai: negatives?
  746. # [23:41] <dbaron> Tantek: subdomains are an anti-pattern; don't use them
  747. # [23:42] <dbaron> peter: they're useful
  748. # [23:42] <dbaron> glazou: Two questions: :not() extended from single simple selector to chain
  749. # [23:42] <dbaron> glazou: what do browsers think?
  750. # [23:42] <dbaron> glazou, hyatt wanted to extend
  751. # [23:42] <dbaron> s/,/:
  752. # [23:42] <dbaron> dbaron: fine with it
  753. # [23:43] <dbaron> florian: Happy with :matches(), extension to :not is similar
  754. # [23:43] <dbaron> glazou: Authors want column selector.
  755. # [23:44] <fantasai> http://dev.w3.org/csswg/selectors4/#table-pseudos
  756. # [23:44] <dbaron> fantasai: Have :nth-column(an+b), :nth-last-column(an+b), and :column(selector) in the spec
  757. # [23:45] <dbaron> glazou: columns don't really exist -- it's just the count of cells counting colspans
  758. # [23:45] <dbaron> TabAtkins: the table has columns, though
  759. # [23:45] <dbaron> TabAtkins: we're talking about conceptual columns, not column elements
  760. # [23:46] <dbaron> anne: And HTML needs to say how they apply to tables.
  761. # [23:46] <dbaron> fantasai: I think we could clarify the wording at the top of the section (Grid-Structural Selectors)
  762. # [23:46] <bradk> I had some ideas from 2007: http://lists.w3.org/Archives/Public/www-style/2007Nov/0108.html
  763. # [23:46] <dbaron> Tantek: Did you document the scope of the spec as not including pseudo-elements?
  764. # [23:46] <dbaron> fantasai: yes
  765. # [23:47] <dbaron> anne: how about :any-link, for :link or :visited. Every browser has that as proprietary (Gecko, WebKit, Opera).
  766. # [23:47] <dbaron> glazou: We need to write a spec for scoped style sheets.
  767. # [23:47] <dbaron> glazou: Do scoped style sheets add to specificity?
  768. # [23:48] <dbaron> dbaron: I'm not ok with another set of selectors terminology.
  769. # [23:49] <dbaron> dbaron: I'm ok with any of the previous sets.
  770. # [23:50] <tantek> glazou - can we do Paris 2012-01-29...31? (IxDa 2012 is 1 Feb to 4 Feb)
  771. # 03[23:50] * Joins: szilles (chatzilla@72.254.89.133)
  772. # [23:52] <dbaron> dbaron: I guess I'm ok with it if you're not *changing* terms.
  773. # [23:52] <dbaron> glazou: Do we need in selectors4 all that will be unchanged?
  774. # [23:53] <dbaron> fantasai: yes, things need improvement
  775. # [23:53] <dbaron> anne: case insensitive attribute matching
  776. # [23:53] <dbaron> anne: HTML now makes data model consistent between HTML and XHTML
  777. # [23:53] <dbaron> fantasai: Can you post to www-style?
  778. # [23:54] <dbaron> glazou: have to extend attribute selectors
  779. # [23:54] <dbaron> anne: It's an edge case -- most authors will just write in lowercase
  780. # [23:55] <dbaron> glazou: If you want to highlight based on a word in the title
  781. # [23:55] <dbaron> dbaron: I think you're making up a use case here.
  782. # [23:55] <dbaron> glazou: So I want strings rather than just tokens
  783. # [23:56] <dbaron> fantasai: What if unquoted things were case-insensitive?
  784. # [23:56] <dbaron> dbaron: That's a pretty big change.
  785. # [23:57] <dbaron> peter: Safer to have new syntax that says it's case-insensitive.
  786. # [23:57] <dbaron> peter: quotes with an i after the quotes -- just an identifier after the quotes
  787. # [23:58] <dbaron> fantasai: added :any-link
  788. # [23:58] <dbaron> dbaron: horrible name... probably my fault... can we find a better one?
  789. # [23:59] <dbaron> fantasai: :hyperlink?
  790. # [23:59] <dbaron> tantek: :hlink?
  791. # [23:59] <dbaron> glazou: document contains :dir(); HTML5 contains :ltr and :rtl
  792. # [23:59] <dbaron> anne: already raised as a bug on HTML5
  793. # Session Close: Mon Jul 25 00:00:01 2011

The end :)