/irc-logs / w3c / #css / 2014-01-28 / end

Options:

  1. # Session Start: Tue Jan 28 00:00:00 2014
  2. # Session Ident: #css
  3. # [00:00] <TabAtkins> <br type=break dur=15min>
  4. # [00:00] <dbaron> #now { coffee-break-after: always }
  5. # [00:13] <fantasai> s/type=break/type=coffee/
  6. # [00:13] <fantasai> break, type of break is kinda redundant, really
  7. # [00:13] <fantasai> s/, type of/ of type/
  8. # [00:20] * Quits: florian (~Adium@public.cloak) ("Leaving.")
  9. # [00:21] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
  10. # [00:21] * Joins: dwim (~dwim@public.cloak)
  11. # [00:21] <smfr> glenn: we are in a break
  12. # [00:21] * Joins: florian (~Adium@public.cloak)
  13. # [00:24] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
  14. # [00:24] * Joins: dwim (~dwim@public.cloak)
  15. # [00:25] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
  16. # [00:29] <TabAtkins> fantasai: Versus <br type='lunch'>
  17. # [00:30] * sgalineau agreed to edit css-animations again, if that needs recording….
  18. # [00:30] <dbaron> Rossen_, Gecko actually does have a special behavior for tables next to BFCs in quirks mode...
  19. # [00:30] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
  20. # [00:30] * Joins: dwim (~dwim@public.cloak)
  21. # [00:31] <TabAtkins> glazou: Agenda+ this afternoon, about Counter Styles.
  22. # [00:32] <fantasai> Topic: Animations
  23. # [00:32] <fantasai> ScribeNick: fantasai
  24. # [00:32] <fantasai> krit: Currently, animations spec states that animations start time is easier if the document load event is firing
  25. # [00:32] <fantasai> krit: or when property is resolved for current element
  26. # [00:32] <fantasai> krit: whatever happens later is actually start time
  27. # [00:32] <fantasai> krit: I don't think this is what impl do
  28. # [00:33] <fantasai> krit: implementations start animations once style is resolved
  29. # [00:33] <fantasai> krit: maybe we should remove sentence about document load
  30. # [00:33] <fantasai> dbaron: I agree with the change. Thought we already had
  31. # [00:33] * glazou TabAtkins how much time?
  32. # [00:33] <fantasai> RESOLVED: Remove bit about waiting for document load event before starting animations
  33. # [00:34] <fantasai> Topic: Backgrounds and Borders
  34. # [00:34] <fantasai> fantasai: Anyone have issues on css3-background?
  35. # [00:34] <fantasai> krit: putting values between <box> values in background shorthand?
  36. # [00:34] <fantasai> fantasai: should be fixed
  37. # [00:35] <fantasai> fantasai: nope, not fixed, I'll fix it...
  38. # [00:37] <TabAtkins> glazou: 5m if people don't argue, 20m if they do.
  39. # [00:37] <fantasai> RESOLVED: Publish css3-background as LC with above edit, 3-week LC period
  40. # [00:39] * astearns la5t call
  41. # [00:39] * Quits: kawabata2 (~kawabata@public.cloak) (Client closed connection)
  42. # [00:39] <dbaron> previous last calls: http://www.w3.org/TR/2009/WD-css3-background-20091015/ http://www.w3.org/TR/2010/WD-css3-background-20100612/ http://www.w3.org/TR/2012/WD-css3-background-20120214/ http://www.w3.org/TR/2014/WD-css3-background-20140116/
  43. # [00:40] * sgalineau it's last calls all the way down
  44. # [00:41] <dbaron> ok, strike the last one
  45. # [00:41] <dbaron> (though it is actually currently on the TR page, but /TR/css3-background/ doesn't point to it)
  46. # [00:41] * ChrisL csswg last call drinking game
  47. # [00:41] <plh> s|http://www.w3.org/TR/2014/WD-css3-background-20140116/||
  48. # [00:42] <fantasai> Topic: CSS2.2
  49. # [00:42] <fantasai> Bert: Discussing updating CSS2.1
  50. # [00:42] <fantasai> Bert: The main thing keeping us from that was some tests
  51. # [00:42] <fantasai> Bert: I wrote some tests
  52. # [00:42] <fantasai> Bert: Found that things were not implemented
  53. # [00:42] <fantasai> Bert: specifically, the scinot parsing is not implemented
  54. # [00:43] * sgalineau http://w3cmemes.tumblr.com/post/48718009851/if-you-name-it-last-call-to-get-it-done-youre
  55. # [00:43] <fantasai> Bert: I haven't checked other errata
  56. # [00:43] <fantasai> Bert: Wondering if they also have no implementations
  57. # [00:43] <fantasai> SimonSapin: I have 2 implementations, but they are not independent
  58. # [00:44] <fantasai> SimonSapin: WeasyPrint and Servo
  59. # [00:44] <fantasai> dbaron: Should take about 5m to implement in Gecko
  60. # [00:44] <fantasai> dbaron: need to remove an SVG check
  61. # [00:45] <fantasai> ChrisL: SciNot was added to SVG everywhere, asked CSS to add it, and they said no. And then was recently added
  62. # [00:45] <fantasai> ...
  63. # [00:46] <ChrisL> ... so the implementations need to remove their special checks that disallow scinot in properties
  64. # [00:47] <fantasai> discussion of going to LC
  65. # [00:47] <fantasai> ChrisL: There's a bunch of tests someone posted as well
  66. # [00:48] <fantasai> [discussion of where to find tests, etc.]
  67. # [00:48] <dbaron> I really want to reopen some ancient RESOLVED-INVALID bug to put this patch on... but I can't find one.
  68. # [00:49] <fantasai> plinss: Is the document ready to publish as LC?
  69. # [00:49] <fantasai> Bert: yes, just have to change the status
  70. # [00:49] <fantasai> fantasai: Did you kill the entire changes section, other than the most recent set?
  71. # [00:50] <fantasai> ACTION Bert Cut down changes section to just the changes from CSS2.1REC2011
  72. # [00:50] * trackbot is creating a new ACTION.
  73. # [00:50] <trackbot> Created ACTION-606 - Cut down changes section to just the changes from css2.1rec2011 [on Bert Bos - due 2014-02-03].
  74. # [00:50] <Bert> -> http://wiki.csswg.org/spec/css2.2 volunteers for CSS2 errata tests
  75. # [00:51] <fantasai> ChrisL: What about undetectable changes?
  76. # [00:51] <fantasai> fantasai: Just say they're undetectable in the impl report?
  77. # [00:52] <fantasai> ChrisL: Also, how do we find existing tests that might need changes?
  78. # [00:52] <fantasai> ChrisL: Will need a new edition of the test suite
  79. # [00:52] <fantasai> plinss: I can build one
  80. # [00:52] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
  81. # [00:54] <fantasai> plinss: So, publish LC?
  82. # [00:54] <fantasai> fantasai: Concerned some people will freak out, if we stay in LC for 6months+.
  83. # [00:56] <fantasai> fantasai: Maybe put everything together and then go to LC very shortly since it's all set to move forward
  84. # [00:56] <fantasai> dbaron: What if we put it at shortname CSS22, then nobody will everyone look at it
  85. # [00:56] <fantasai> Tantek proposes waiting for the Process change
  86. # [00:57] <fantasai> florian: Once we have the tests, then we can rush.
  87. # [00:57] <fantasai> ChrisL: Once we have the tests we know where we are
  88. # [00:57] <fantasai> tantek: excellent, we've rationalized procrastination
  89. # [00:58] <fantasai> Topic: Counter Styles
  90. # [00:58] <fantasai> TabAtkins: Only one issue open
  91. # [00:58] <fantasai> TabAtkins: Nobody can give me consistent answers on the extended cjk numbering styles
  92. # [00:59] <fantasai> TabAtkins: Already have one that goes to 10^5. One that goes to 10^16, optional
  93. # [00:59] <glenn> +1 to drop
  94. # [00:59] <fantasai> TabAtkins: I think it's sufficient, what we have already
  95. # [00:59] * plh makes a 20k list in CJK
  96. # [00:59] <fantasai> TabAtkins: Can address ina future level if someone can give me a real answer
  97. # [01:00] <fantasai> TabAtkins: Are people ok with that?
  98. # [01:00] <fantasai> Kawabata-san nods
  99. # [01:01] <fantasai> fantasai: I'm ok, if it's undefined above 10k. mozilla implements beyond that, don't want to make them incompliant
  100. # [01:01] <fantasai> dbaron: Were there disagreements on informal or formal?
  101. # [01:02] * ChrisL does html still have a list start attribute?
  102. # [01:02] <glazou> wait, shepazu just officially joined the CSS WG !!!
  103. # [01:02] <fantasai> plh: Maybe ask i18n?
  104. # [01:02] <fantasai> TabAtkins: Haven't, no. Asked some native speakers
  105. # [01:04] <fantasai> fantasai: Say beyond 10K could either switch to cjk-decimal, or extend beyond (you figure out how)
  106. # [01:04] * plh hopes the answer to David isn't 42
  107. # [01:04] <fantasai> TabAtkins: The main issues are around when you drop ones and zeroes
  108. # [01:04] <fantasai> TabAtkins: Everyone agrees on the first 4 digits
  109. # [01:04] <fantasai> TabAtkins: beyond 10K becomes a problem
  110. # [01:06] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
  111. # [01:06] <fantasai> plinss proposes scientific notation
  112. # [01:06] <fantasai> fantasai proposes engineering notation
  113. # [01:06] * Joins: dwim (~dwim@public.cloak)
  114. # [01:06] <fantasai> RESOLVED: Drop extended algorithm for CJK (10K+)
  115. # [01:07] <dbaron> 八e九 ?
  116. # [01:10] <fantasai> plh: should i18n review this?
  117. # [01:10] <fantasai> fantasai: it's optional anyway
  118. # [01:10] <fantasai> RESOLVED: Counter Styles to CR, once Tab finish off the DoC
  119. # [01:11] <fantasai> Topic: -webkit-print-color-adjust
  120. # [01:11] <fantasai> florian: We discussed this awhile ago
  121. # [01:11] <florian> http://wiki.csswg.org/ideas/print-backgrounds
  122. # [01:12] <fantasai> fantasai: we concluded 2-6 doesn't work
  123. # [01:12] <fantasai> s/fantasai/florian/
  124. # [01:12] <fantasai> florian: 7 is what webkit does
  125. # [01:12] <fantasai> florian: 8 I don't remember
  126. # [01:12] <fantasai> florian: Suggest we go with what webkit does, with a non-silly name
  127. # [01:13] <fantasai> florian: By default browsers will adjust colors to have white background, to save ink
  128. # [01:13] <fantasai> florian: This property can switch that behavior off, print what's specified
  129. # [01:14] <fantasai> florian: gives author ability to say when things are important
  130. # [01:15] <fantasai> TabAtkins, florian: Doesn't affect user's ability to control things; handle that via user stylesheet mechanism
  131. # [01:15] <fantasai> florian: We need a name, a spec, and a description
  132. # [01:15] <fantasai> fantasai: Colors 4
  133. # [01:15] <fantasai> florian: So, inherits, applies anywhere, and mode where browser does whatever it wants
  134. # [01:15] <fantasai> ChrisL: i.e. initial value is auto
  135. # [01:15] <fantasai> florian: suggest 'economy', to be a little more explicit than auto...
  136. # [01:16] <fantasai> plh: how about a 'never' value
  137. # [01:16] <plh> s/plh: how about a 'never' value//
  138. # [01:16] * plh was kidding
  139. # [01:16] <fantasai> ChrisL: Need on, off, and auto
  140. # [01:17] <fantasai> TabAtkins: Default behavior is whatever user wants, which happens to be save-ink by default
  141. # [01:17] <fantasai> ChrisL: Right so, that's auto
  142. # [01:18] <fantasai> fantasai: No, just two. 'economy' is initial value, but user can set to 'true-colors' in user style sheet
  143. # [01:18] * plh wonders if we'll have the value "print-10000-random-pages-instead-of-the-one-I-requested"
  144. # [01:19] <fantasai> discussion of how the user-stylesheet cascade works
  145. # [01:19] <fantasai> Bert: Aren't you now giving the user 3 choices rather than 2?
  146. # [01:19] <fantasai> TabAtkins: ...
  147. # [01:19] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
  148. # [01:19] * Joins: dwim (~dwim@public.cloak)
  149. # [01:19] <fantasai> Bert: User has options Save, Don't Save, Do what author said
  150. # [01:20] * ChrisL force-printhead-flushing: always | sometimes | on-low-ink-level
  151. # [01:20] <fantasai> Bert: Property only has 2 values, but user has 3 options
  152. # [01:20] <fantasai> TabAtkins: Blink doesn't give user any options. Depends on what the browser wants to expose
  153. # [01:21] <fantasai> florian: We don't mandate what the UA puts in its prefs.
  154. # [01:21] <fantasai> florian: we just give them more info to work with, if they want to
  155. # [01:21] <fantasai> Bert: Wonder what the user thinks, seeing these options
  156. # [01:21] <fantasai> TabAtkins: That's not our job, that's the UX designers' job.
  157. # [01:22] <dbaron> filed https://bugzilla.mozilla.org/show_bug.cgi?id=964529 (with patch) for supporting scientific notation in Gecko
  158. # [01:22] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
  159. # [01:22] * Joins: dwim (~dwim@public.cloak)
  160. # [01:22] <fantasai> [discussion of what customization options are appropriate for a browser to expose]
  161. # [01:23] * fantasai is not minuting this
  162. # [01:24] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
  163. # [01:24] * Joins: dwim (~dwim@public.cloak)
  164. # [01:26] <fantasai> Bert: How do I say, I really want to save ink?
  165. # [01:26] <fantasai> ..
  166. # [01:26] <fantasai> dbaron: I don't think we'd expose a 3-way toggle
  167. # [01:26] <fantasai> dbaron: The reason we have this magic initial behavior is because authors generally don't think about printing
  168. # [01:26] <fantasai> dbaron: This property is only used if an author *is* thinking about printing.
  169. # [01:26] <fantasai> dbaron: If an author uses it, we trust them to have thought about printing
  170. # [01:27] <fantasai> plinss: We thought of other heuristics to see whether author thought about printing. They weren't good enough heuristics. But this could be
  171. # [01:28] <fantasai> plinss: Does anyone object to adding this property?
  172. # [01:28] <fantasai> Bert: I disagree with this. Why aren't print style sheet enough?
  173. # [01:28] <fantasai> Tab rants about "future legacy"
  174. # [01:29] <fantasai> tantek, TabAtkins: Authors right now use borders as backgrounds, to force the printing of "backgrounds"
  175. # [01:29] <fantasai> Basically lots of hacks. This would allow a clean way to solve the problem
  176. # [01:29] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
  177. # [01:30] * Joins: dwim (~dwim@public.cloak)
  178. # [01:30] <fantasai> RESOLVED: Add this property with names TBD
  179. # [01:31] <dbaron> print-economy: auto | as-specified ?
  180. # [01:31] <ChrisL> economy | premium
  181. # [01:32] <dbaron> economy | premium | super94 ??
  182. # [01:32] <fantasai> Topic: Selectors 4
  183. # [01:33] <fantasai> TabAtkins: Simon brought up issue of how exactly do we write the ancestor selector
  184. # [01:33] <fantasai> TabAtkins: If I want to select <p> containing <img>
  185. # [01:33] <fantasai> TabAtkins: currently written as !p > img
  186. # [01:33] <fantasai> TabAtkins: jquery writes it as p:has(img)
  187. # [01:33] <fantasai> TabAtkins: I understand the arguments for the first one
  188. # [01:33] <fantasai> TabAtkins: on the other hand, difficult to do multiple branches
  189. # [01:34] <fantasai> glazou: How do you do !p ~ img
  190. # [01:34] <Rossen__> p:can-haz(img)
  191. # [01:34] <fantasai> SimonSapin: p:has(~img)
  192. # [01:35] <fantasai> TabAtkins: Any arguments about this being intuitive are nil, because jquery people use it all the time
  193. # [01:35] <fantasai> fantasai: That proves it's useful, doesn't prove it's intuitive
  194. # [01:35] <fantasai> glazou: Seems to me we are inserting more and more ugliness in Selectors. No, don't think we shoudl do :has
  195. # [01:35] <fantasai> SimonSapin: We only have this syntax with :matches() and :not()
  196. # [01:36] <fantasai> SimonSapin: for same reason as shadow dom combinators, I think it's better to have a name than random meaning for ascii characters
  197. # [01:36] <fantasai> glazou: At some point in the past we also had p:subject
  198. # [01:36] <fantasai> glazou: The history of that proposal. Initially I submitted to WG as !p
  199. # [01:36] <fantasai> glazou: Then ! was rejected due to negation
  200. # [01:36] <fantasai> glazou: we went to :subject
  201. # [01:36] <tantek> IMO the whole use of "!" in CSS has been a disaster.
  202. # [01:36] <fantasai> glazou: now back to !p
  203. # [01:36] * Rossen__ p:cannot-haz(img)
  204. # [01:36] <tantek> !p is terrible
  205. # [01:36] <astearns> +1 tantek
  206. # [01:36] <plh> +1
  207. # [01:37] <tantek> (nearly) every documentation about "! important" makes some joke about it being unintuitive.
  208. # [01:37] <fantasai> glazou: I think opening a parentheses and starting with a combinator is awkward
  209. # [01:37] * astearns p:+1(img)
  210. # [01:38] <fantasai> plinss: This preserves the fact that the rightmost thing is the one you're selecting
  211. # [01:38] <fantasai> TabAtkins: Also, ! it's very confusing where exactly it can go
  212. # [01:39] <fantasai> TabAtkins: e.g. :matches() and :any() can take !, but :ancestor() can't.
  213. # [01:39] * plh wants to write !!p~img
  214. # [01:39] <tantek> I agree they are not equivalent
  215. # [01:39] <fantasai> fantasai: If :has() is equivalent to !, then why different?
  216. # [01:39] * Rossen__ p:can-haz(^^div > ^ p:cannot-has(img))
  217. # [01:39] * fantasai actually suggested !! earlier
  218. # [01:39] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
  219. # [01:39] * liam wants :hasn't()
  220. # [01:40] * dauwhe ^^:has(~cheezburger)
  221. # [01:41] * MaRakow .yin:has(^.yang)
  222. # [01:41] <fantasai> fantasai: ! on the rightmost compounds selector doesn't change the meaning of the selector
  223. # [01:42] <fantasai> various examples thrown around
  224. # [01:42] <fantasai> shepazu: As a non-CSS person, I'd be able to guess what :has() means, whereas for ! can't do that
  225. # [01:43] <fantasai> ...
  226. # [01:43] <fantasai> shepazu: Any problems with jQuery?
  227. # [01:43] <dbaron> one of the examples was "div:ancestor(!.light-theme) > foo", where fantasai and glazou say the ! doesn't change anything since the ! is only moving the subject of what's inside the ()
  228. # [01:44] <fantasai> tantek: No, the meanings are identical
  229. # [01:44] * gsnedders agrees with shepazu here for all nothing it is worth
  230. # [01:44] <fantasai> s/tantek/TabAtkins/
  231. # [01:44] * dbaron wonders if we should take a straw poll at some point
  232. # [01:45] * liam assuming !x implies not(x)
  233. # [01:45] <fantasai> TabAtkins: It takes a relative selector, which is a selector that starts with a combinator (possibly an implied descendant combinator)
  234. # [01:45] * Rossen__ liam, you're !right
  235. # [01:46] <dbaron> for the record, I'm for :has()
  236. # [01:46] <smfr> http://dev.w3.org/csswg/selectors4/
  237. # [01:46] * Quits: eliezerb_2nd (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
  238. # [01:47] * fantasai thinks !! is better than !
  239. # [01:47] <fantasai> TabAtkins goes through the Selectors spec to see what needs to be cut
  240. # [01:48] * liam ‽
  241. # [01:48] <fantasai> :matches() and :not()
  242. # [01:48] <fantasai> dbaron considers :matches()
  243. # [01:48] * glazou fantasai I could live with !! :-)
  244. # [01:48] <fantasai> dbaron: Don't know why we restrict :matches() to compound selectors in the fast profile
  245. # [01:49] * astearns fantasai: it could be 2+ bangs, with each additional ! adding some amount of specificity
  246. # [01:49] * fantasai :(
  247. # [01:50] <fantasai> TabAtkins: c:matches(a c, b c) hits more combinatorial cases
  248. # [01:50] * Parts: leif (~lastorset@public.cloak) (leif)
  249. # [01:50] * Joins: leif (~lastorset@public.cloak)
  250. # [01:50] <fantasai> SimonSapin: bz points out that with some new things, like parent selector, would need to do hard things
  251. # [01:50] <fantasai> dbaron: I think if the syntax makes sense to allow combinators, then allow it
  252. # [01:50] * glazou we're adding so many parenthesis to selectors this will soon look like Lisp :-)
  253. # [01:51] <fantasai> TabAtkins writes out example
  254. # [01:51] <fantasai> q c:matches(a c,b c) expands to
  255. # [01:51] <fantasai> q a c,
  256. # [01:51] <fantasai> q b c,
  257. # [01:51] <fantasai> a q c,
  258. # [01:52] <fantasai> a.q c,
  259. # [01:52] <fantasai> b q c
  260. # [01:52] <fantasai> b.q c
  261. # [01:52] * fantasai forgot lots of dots. just put them in front of all the letters
  262. # [01:53] <fantasai> TabAtkins explains that people often do just the common combinations, this would allow them to exactly express what they want
  263. # [01:53] <fantasai> dbaron asks about :nth-last-match(), and what exactly it means
  264. # [01:53] <fantasai> dbaron: OK, think that's alright
  265. # [01:54] <fantasai> [brief discussion of :not()]
  266. # [01:55] <fantasai> RESOLVED: complex selectors in :matches/:not to move to fast profile, assuming bz agrees
  267. # [01:55] <fantasai> TabAtkins: Case-sensitivity, the 'i' flag of attribute selectors.
  268. # [01:55] <fantasai> TabAtkins: I think we're planning to implement this
  269. # [01:56] <fantasai> glazou: Is that implemented in gecko
  270. # [01:56] <fantasai> dbaron: no
  271. # [01:56] <fantasai> glazou: I have a patch for that
  272. # [01:56] <fantasai> TabAtkins: Linguistic pseudos are new
  273. # [01:56] <fantasai> fantasai: :dir() has implementation in mozilla
  274. # [01:57] <fantasai> fantasai: :lang() was expanded to do lists, that's implemented in MS
  275. # [01:57] <fantasai> SimonSapin: Also does full BCP47 matching, a bit more complex
  276. # [01:57] <fantasai> keeping that
  277. # [01:58] <fantasai> TabAtkins: Location pseudos
  278. # [01:58] <fantasai> TabAtkins: :any-link is shortcut for :matches(:link,:visited)
  279. # [01:58] <fantasai> dbaron: Gecko has it for over a decade
  280. # [01:58] <fantasai> TabAtkins: :local-link()
  281. # [01:58] <fantasai> fantasai: I think that one we will need to defer
  282. # [01:59] <fantasai> TabAtkins: :target already done
  283. # [01:59] <fantasai> TabAtkins: :scope has been around for awhile
  284. # [01:59] <fantasai> dbaron: When does :scope apply in normal style sheets?
  285. # [01:59] <fantasai> TabAtkins quotes from spec -- equivalent to :root
  286. # [01:59] <fantasai> dbaron: OK
  287. # [02:00] <fantasai> TabAtkins: Drag and drop pseudos. Do we have any implementations of the functionality?
  288. # [02:00] <fantasai> fantasai: There's an implementation of some kind of drag and drop thing, don't remember which one
  289. # [02:01] <fantasai> fantasai: Suggest we add an action to find out what, exactly, is implemented. Otherwise keep it
  290. # [02:01] <fantasai> fantasai: Seems like we hashed over this enough that the definition is relatively stabel
  291. # [02:01] * Joins: rhauck (~Adium@public.cloak)
  292. # [02:01] <fantasai> fantasai: Does anyone have any concerns or feel like this might need more work?
  293. # [02:02] <fantasai> TabAtkins: We have time-dimensional pseudos, defined for WebVTT.
  294. # [02:02] <fantasai> TabAtkins: Anyone know if they're implemented anywhere?
  295. # [02:03] <fantasai> ACTION fantasai: make sure timeline is defined for Speech
  296. # [02:03] * trackbot is creating a new ACTION.
  297. # [02:03] * RRSAgent records action 2
  298. # [02:03] <trackbot> Created ACTION-607 - Make sure timeline is defined for speech [on Elika Etemad - due 2014-02-04].
  299. # [02:03] <fantasai> TabAtkins: New input pseudos, mainly :placeholder-shown
  300. # [02:03] <fantasai> dbaron: We used to implement it under a different name, then removed it
  301. # [02:03] <fantasai> dbaron: Does WebKit do pseudo-class or pseudo-element
  302. # [02:04] <fantasai> TabAtkins: There was an issue raised by hixie wrt dropping :read-only and :read-write, because no known ues
  303. # [02:05] <fantasai> tantek: I have mixed feelings on that. Would prefer more data
  304. # [02:05] <fantasai> ACTION TabAtkins Run a search on use of :read-only and :read-write
  305. # [02:05] * trackbot is creating a new ACTION.
  306. # [02:05] <trackbot> Error finding 'TabAtkins'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
  307. # [02:06] <fantasai> fantasai: For :placeholder-shown, do we have implementations?
  308. # [02:06] <fantasai> dbaron: We have implementations for the functionality, might not match spec
  309. # [02:07] <fantasai> TabAtkins: :user-error implemented by Moz under a different name
  310. # [02:07] <fantasai> dbaron: :moz-ui-invalid
  311. # [02:07] <tantek> FYI http://wiki.csswg.org/spec/css4-ui
  312. # [02:07] <tantek> has collected a bunch of these
  313. # [02:08] <tantek> as well as http://wiki.csswg.org/spec/selectors4#ideas-to-consider
  314. # [02:08] <fantasai> dbaron: We also have the opposite, :moz-ui-valid
  315. # [02:08] <fantasai> TabAtkins: That's just :not(:user-error)
  316. # [02:08] <fantasai> fantasai: Not necessarily. Could be triggering only over time period that :user-error could trigger
  317. # [02:08] <fantasai> fantasai: e.g. turning something green instead of red
  318. # [02:10] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
  319. # [02:10] <fantasai> ACTION: fantasai and Tab to investigate :moz-ui-valid
  320. # [02:10] * trackbot is creating a new ACTION.
  321. # [02:10] * RRSAgent records action 3
  322. # [02:10] <trackbot> Created ACTION-608 - And tab to investigate :moz-ui-valid [on Elika Etemad - due 2014-02-04].
  323. # [02:10] <fantasai> glazou: :blank's definition is really confusingly worded, fix it
  324. # [02:10] * Joins: emalasky1 (~Adium@public.cloak)
  325. # [02:11] <fantasai> ACTION fantasai fix :blank's definition to make sense
  326. # [02:11] * trackbot is creating a new ACTION.
  327. # [02:11] <trackbot> Created ACTION-609 - Fix :blank's definition to make sense [on Elika Etemad - due 2014-02-04].
  328. # [02:11] <fantasai> TabAtkins: Are we keeping :blank?
  329. # [02:11] <dbaron> glazou: change "excludes" to "allows"
  330. # [02:11] <fantasai> fantasai: A bit concerned about the name, makes me think of form elements
  331. # [02:12] <fantasai> dave: Also have a :blank page selector
  332. # [02:12] <dbaron> Gecko has :blank under the name :-moz-only-whitespace
  333. # [02:13] <fantasai> SimonSapin: Does it depend on computed value of white-space?
  334. # [02:13] <fantasai> fantasai: No, that also needs clarification
  335. # [02:13] <fantasai> TabAtkins: OK, naming issue , but keeping it
  336. # [02:14] <fantasai> TabAtkins: An+B.. probably need to kill this section in favor of Syntax
  337. # [02:14] <fantasai> fantasai: might leave some informative notes
  338. # [02:15] <fantasai> TabAtkins: :nth-match(), keep or punt?
  339. # [02:15] <fantasai> dbaron: Keep. This is one of the most wanted features
  340. # [02:15] <fantasai> fantasai: One problem with this. Imagine a table
  341. # [02:15] <fantasai> fantasai: I want to color every other row silver, that is shown and not collapsed
  342. # [02:16] <fantasai> fantasai: So instead of :nth-child, I use :nth-match
  343. # [02:16] * Quits: emalasky (~Adium@public.cloak) (Ping timeout: 180 seconds)
  344. # [02:16] <fantasai> (this is also a problem with :nth-child)
  345. # [02:16] <fantasai> fantasai: The data is complex, and I split the data into sections using multiple <tbody>
  346. # [02:17] <fantasai> fantasai: Now there might be 2 white rows adjacent to each other
  347. # [02:18] <fantasai> dbaron: One possibility, might be weird, might be to keep the restriction of not having combinators inside :nth-match() and :nth-last-match()
  348. # [02:18] <fantasai> dbaron: and use that to change what scope you're matching
  349. # [02:18] <fantasai> dbaron: So for this example, you'd use ...
  350. # [02:19] <fantasai> dbaron: note, this wouldn't make the fast profile
  351. # [02:19] * Joins: eliezerb (~Eliezer@public.cloak)
  352. # [02:21] <fantasai> fantasai: We do have some space to play around before the 'of' (anything after that keyword will be consumed as a selector, including idents and commas)
  353. # [02:21] <fantasai> ...
  354. # [02:21] <dbaron> (I'm proposing putting relative selectors inside :nth-match, essentially, but with a default of child rather than descendant.)
  355. # [02:21] <fantasai> fantasai: or, we could expand :nth-child() to take the syntax of :nth-match()
  356. # [02:21] <fantasai> TabAtkins: thoughts?
  357. # [02:22] <fantasai> fantasai: I think it's more clear. :nth-match() could be interpreted as matching against the tree, not just against children
  358. # [02:23] <fantasai> RESOLVED: Drop :nth-match(), move functionality to :nth-child()
  359. # [02:23] <fantasai> TabAtkins: Next one is the refernece combinator
  360. # [02:23] <fantasai> glazou: This is based as an ID attribute
  361. # [02:24] <fantasai> glazou: What if we have a reference between elements, but there's no DTD declaring IDREF relationship?
  362. # [02:24] <fantasai> TabAtkins: There's no relationship other than structure in XML
  363. # [02:24] * Quits: smfr (~smfr@public.cloak) (smfr)
  364. # [02:24] <fantasai> TabAtkins: You can never have a reference combinator of any kind for XML
  365. # [02:25] * Joins: eliezerb_2nd (~Eliezer@public.cloak)
  366. # [02:25] <fantasai> fantasai: OK, so there's two things here
  367. # [02:26] <fantasai> fantasai: You need to know which is the ID attribute. You need that for ID selectors anyway
  368. # [02:26] <fantasai> fantasai: whether that's via DTD, or HTML spec, or xml:id
  369. # [02:26] <tantek> clilley: no one uses xml:id any more
  370. # [02:27] <fantasai> glazou: It's easier just to look for the first occurance, don't worry about if it's an ID attribute or not
  371. # [02:27] * liam not clear why you can't have a reference combinator for XML - it'd require either DTD markup support or xml:id support though
  372. # [02:27] <fantasai> fantasai: I think we should drop this feature. no implementations, not a high request
  373. # [02:27] <fantasai> dbaron: I'm a bit queasy about this being a combinator, rather than a pseudo-class like :matches()
  374. # [02:28] <fantasai> dbaron: Also don't even want to see the term IDREF
  375. # [02:28] * liam - or relaxing the ID/IRREF-ness requirement
  376. # [02:28] <fantasai> dbaron: Say language-specific knowledge if you need to, but don't say IDREF
  377. # [02:28] * Quits: eliezerb (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
  378. # [02:28] <dbaron> dbaron: But also happy to punt to next level.
  379. # [02:28] <fantasai> TabAtkins: OK, so put for now, fix later
  380. # [02:28] <fantasai> Bert: Been wanting it for labels and inputs
  381. # [02:29] <fantasai> Bert: Maybe with !! etc. could handle those cases
  382. # [02:29] <liam> [the equivalent in XPath is a frequently-asked question, people want it all the time, even without id/idref]
  383. # [02:30] <fantasai> plinss: in simple cases, can do that, but some cases might be in e.g. different table cells, harder
  384. # [02:30] <fantasai> TabAtkins: Column combinator, which is ||
  385. # [02:31] <dbaron> dbaron: I'd prefer a :column pseudo-class
  386. # [02:31] <dbaron> :column()
  387. # [02:31] <fantasai> fantasai: It's a combinator because it describes the relationship between two elements, which is what a combinator *is*
  388. # [02:31] <fantasai> TabAtkins: Do we want to keep here, or punt to next level?
  389. # [02:32] <fantasai> Bert: How do you know what's part of the column?
  390. # [02:32] * Joins: smfr (~smfr@public.cloak)
  391. # [02:32] <fantasai> Tab, fantasai: Markup magic.
  392. # [02:32] <fantasai> ChrisL: CSS display
  393. # [02:33] <fantasai> fantasai: no, only based on markup
  394. # [02:33] <fantasai> [discussion of whether to keep or punt]
  395. # [02:35] <dbaron> dbaron: we could add :column-hover and :column-active // fantasai: or change definition of :hover and :active so it works on columns
  396. # [02:35] <fantasai> fantasai: Main issue seems to be whether this is a pseudo-class or a combinator
  397. # [02:35] <fantasai> glazou: I can live either way
  398. # [02:36] <fantasai> fantasai: Oh! You (dbaron) wanted to have an = combinator. We could use that for rows.
  399. # [02:36] * dbaron notes fantasai and ChrisL have arrived at the = and # combinators
  400. # [02:36] <fantasai> fantasai: If you have a spanning cell, you can't tell it belongs to the third row by child selector.
  401. # [02:36] <fantasai> fantasai: So use || for column relationship, and = for row relationship
  402. # [02:37] <fantasai> TabAtkins: I hate column combinator now...
  403. # [02:37] <fantasai> ...
  404. # [02:38] <fantasai> dbaron: Tab is proposing that td:column(.foo) matches td that is in a column either with a class of foo, or that contains a cell with class of foo
  405. # [02:38] <fantasai> TabAtkins: This works equivalently for pseudo-class and combinator syntax. This is the column relationship selector.
  406. # [02:38] <fantasai> dbaron: I might prefer 2 separate selectors, but ok with it...
  407. # [02:40] <fantasai> TabAtkins: So, are we keeping in 4 or punting to 5 and what do we agree on?
  408. # [02:40] <fantasai> dbaron: I think it might be worth getting some author feedback.
  409. # [02:40] <fantasai> dbaron: I would like to see it stay in 4
  410. # [02:40] <fantasai> dbaron: I would like to hear author feedback on syntaxes and whether td matching is wanted
  411. # [02:41] <fantasai> dbaron: I suspect pseudo-class will be more preferred, but not sure. Would prefer to ask authors
  412. # [02:41] * dauwhe U+1D11E
  413. # [02:41] <fantasai> glazou: td selection is really useful
  414. # [02:42] <fantasai> dbaron: Not arguing that, wondering if should be same feature or different ones
  415. # [02:42] <fantasai> ...
  416. # [02:42] <fantasai> glazou brings up issue of hidden rows, selecting every other row
  417. # [02:43] <fantasai> ACTION TabAtkins Add this as an example for :nth-child()
  418. # [02:43] * trackbot is creating a new ACTION.
  419. # [02:43] <trackbot> Error finding 'TabAtkins'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
  420. # [02:43] * fantasai grumbles
  421. # [02:43] <dbaron> tr:nth-child(even of :not(.hidden)) ?
  422. # [02:44] <fantasai> glazou: Specificity, question wrt reference combinator. Think it should be counted somewhere.
  423. # [02:44] <fantasai> TabAtkins: We're punting to L5
  424. # [02:45] * dbaron wonders if tab is *specifically* opposed to making specificity more complicated :-)
  425. # [02:45] <fantasai> glazou: Keep track of it
  426. # [02:45] <fantasai> TabAtkins: OK, topic's done!
  427. # [02:47] <dbaron> Topic: Pseudo-elements
  428. # [02:47] <dbaron> Tab: need somebody to edit the spec
  429. # [02:47] <dbaron> tantek?: Authors are asking why ::selection isn't specified
  430. # [02:47] <dbaron> Tab: dbaron had a proposal to address issues
  431. # [02:47] <dbaron> dbaron: need to see if it's web-compatible
  432. # [02:48] <tantek> tantek was just pointing out the recent thread where author(s) asked about status of ::selection in specs since it appears to be implemented cross-browser.
  433. # [02:49] <dbaron> Topic: bikeshedding display
  434. # [02:49] <dbaron> fantasai: I propose renaming 'box' to 'display-box'
  435. # [02:49] <dbaron> SimonSapin: So still violating naming convention of shorthands, since it's not part of the shorthand.
  436. # [02:49] * dbaron is unsure
  437. # [02:49] <fantasai> reasons being:
  438. # [02:50] <fantasai> a) display-box connects authors with display, so that will help them transition from display: none
  439. # [02:50] <fantasai> b) display properties are all about box generation. This is about box generation
  440. # [02:50] <fantasai> c) We have in some cases properties which look like longhands of a shorthand, but are actually independent because we have a specific reason for them to be independent, even though they are closely related
  441. # [02:51] <fantasai> TabAtkins: Ok, that makes sense to me.
  442. # [02:51] <dbaron> Tab: What about naming of what I currently have as display-extras, for list-item value?
  443. # [02:52] <dbaron> dbaron: Isn't there an association with display-outside, when marker is outside?
  444. # [02:52] <dbaron> dbaron: what happens when you give a display:table-cell an outside marker?
  445. # [02:58] * Quits: ChrisL (clilley@public.cloak) ("Client combusted")
  446. # [02:59] * Quits: glazou (~glazou@public.cloak) (glazou)
  447. # [03:00] * Quits: florian (~Adium@public.cloak) ("Leaving.")
  448. # [03:01] * Quits: yamamoto (~yamamoto@public.cloak) ("Page closed")
  449. # [03:01] <fantasai> ...
  450. # [03:01] <fantasai> SteveZ_: display-decoration?
  451. # [03:01] <fantasai> TabAtkins: better than display-extras
  452. # [03:01] <fantasai> [various discussion of list bullets, unminuted]
  453. # [03:01] <fantasai> Meeting closed.
  454. # [03:02] * Quits: AdobeSeattle (~AdobeSeattle@public.cloak) ("Page closed")
  455. # [03:02] * Quits: smfr (~smfr@public.cloak) (smfr)
  456. # [03:02] <fantasai> action to all to read MQ4
  457. # [03:02] * trackbot is creating a new ACTION.
  458. # [03:02] <trackbot> Error finding 'to'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
  459. # [03:02] <glenn> signing off for the day
  460. # [03:02] * Quits: glenn (~gadams@public.cloak) ("Leaving...")
  461. # [03:02] <liam> meeting :hasn't(participants)
  462. # [03:02] * Joins: leif1 (~lastorset@public.cloak)
  463. # [03:02] * Quits: leif (~lastorset@public.cloak) ("Leaving.")
  464. # [03:03] * Quits: plh (plehegar@public.cloak) ("Leaving")
  465. # [03:03] * Joins: lmcliste_ (~lmclister@public.cloak)
  466. # [03:03] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
  467. # [03:04] * Quits: leif1 (~lastorset@public.cloak) (Client closed connection)
  468. # [03:04] * Joins: leif (~lastorset@public.cloak)
  469. # [03:04] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
  470. # [03:04] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
  471. # [03:04] * Quits: Rossen__ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
  472. # [03:05] * Quits: koji (~koji@public.cloak) (Client closed connection)
  473. # [03:05] * Joins: koji (~koji@public.cloak)
  474. # [03:06] * Quits: emalasky1 (~Adium@public.cloak) (Ping timeout: 180 seconds)
  475. # [03:11] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
  476. # [03:12] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
  477. # [03:12] * Quits: SteveZ_ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
  478. # [03:13] * Quits: tantek (~tantek@public.cloak) (tantek)
  479. # [03:15] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
  480. # [03:20] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
  481. # [03:21] * Quits: eliezerb_2nd (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
  482. # [03:28] * Joins: eliezerb_2nd (~Eliezer@public.cloak)
  483. # [03:33] * Quits: eliezerb_2nd (~Eliezer@public.cloak) ("Leaving")
  484. # [03:34] * Joins: eliezerb (~Eliezer@public.cloak)
  485. # [03:35] * Quits: eliezerb (~Eliezer@public.cloak) ("Leaving")
  486. # [03:36] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
  487. # [03:40] * Joins: eliezerb (~Eliezer@public.cloak)
  488. # [03:41] <Zakim> plinss, you asked to be reminded at this time to go home
  489. # [03:55] * Joins: nikos (~Thunderbird@public.cloak)
  490. # [04:32] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
  491. # [04:42] * Zakim excuses himself; his presence no longer seems to be needed
  492. # [04:42] * Parts: Zakim (zakim@public.cloak) (Zakim)
  493. # [04:57] * Quits: eliezerb (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
  494. # [05:03] * Joins: emalasky (~Adium@public.cloak)
  495. # [05:11] * Joins: florian (~Adium@public.cloak)
  496. # [05:11] * Joins: dauwhe (~dauwhe@public.cloak)
  497. # [05:13] * Joins: lmcliste_ (~lmclister@public.cloak)
  498. # [05:27] * Joins: dauwhe_ (~dauwhe@public.cloak)
  499. # [05:27] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
  500. # [05:27] * Quits: nikos (~Thunderbird@public.cloak) (nikos)
  501. # [05:30] * TabAtkins is in the downstairs hot tub, if anyone wants to join.
  502. # [05:32] <liam> 1°F / -17C here so it sounds like a wonderful idea but it'd take a while I'm afraid
  503. # [05:32] <liam> hope your laptop is hot-tub proof :D
  504. # [05:34] <TabAtkins> liam: It's not, but I'm careful, and it's sitting on a towel.
  505. # [05:35] <liam> :D
  506. # [05:36] <liam> supposedly my laptop has a waterproof keyboard, there's videos of people pouring glasses of water onto them... but the vents are underneath & can suck up water, which kinda defeats the advantage
  507. # [05:36] * Joins: koji (~koji@public.cloak)
  508. # [05:37] <TabAtkins> Uh, yeah.
  509. # [05:38] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
  510. # [05:41] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
  511. # [05:48] * Joins: leif (~lastorset@public.cloak)
  512. # [05:49] * Parts: leif (~lastorset@public.cloak) (leif)
  513. # [05:57] * Joins: Rossen__ (~Rossen@public.cloak)
  514. # [05:57] * Quits: florian (~Adium@public.cloak) ("Leaving.")
  515. # [06:08] * Joins: dauwhe (~dauwhe@public.cloak)
  516. # [06:09] * Quits: koji (~koji@public.cloak) (Client closed connection)
  517. # [06:10] * Joins: koji (~koji@public.cloak)
  518. # [06:13] * Joins: nikos (~Thunderbird@public.cloak)
  519. # [06:17] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
  520. # [06:39] * Joins: tantek (~tantek@public.cloak)
  521. # [06:39] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
  522. # [06:47] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
  523. # [06:51] <SimonSapin> proposed definition for :blank
  524. # [06:51] <SimonSapin> The :blank pseudo-class is like to the :empty pseudo-class, except that it additionally matches elements that only contain characters affected by whitespace processing. [CSS3TEXT]
  525. # [06:51] <SimonSapin> looks good?
  526. # [06:54] <liam> all characters are _affected_ by whitespace, maybe you mean that are classed as whitespace in [reference]?
  527. # [06:54] <liam> well, maybe it's clear enough
  528. # [07:00] * Joins: florian (~Adium@public.cloak)
  529. # [07:01] * Quits: florian (~Adium@public.cloak) ("Leaving.")
  530. # [07:01] <SimonSapin> well, Text doesn’t really classify characters
  531. # [07:03] <liam> then how is the reference to CSS 3 text helping? maybe it's the HTML spec that's needed? dunno
  532. # [07:03] <liam> (I don't mean, it's not helping, I mean, I don't understand how it's helping)
  533. # [07:13] <SimonSapin> TabAtkins: https://dvcs.w3.org/hg/csswg/rev/e3a564cf9e04
  534. # [07:13] * Joins: florian (~Adium@public.cloak)
  535. # [07:17] * Joins: jet (~junglecode@public.cloak)
  536. # [07:18] * Parts: jet (~junglecode@public.cloak) (jet)
  537. # [07:21] * Joins: dbaron (~dbaron@public.cloak)
  538. # [07:21] <dbaron> 𐑤. 𐑛𐑱𐑝𐑦𐑛 𐑚𐑨𐑮𐑩𐑯 is my name in Shavian.
  539. # [07:22] <liam> hah I didn't know it was inUnicode
  540. # [07:22] <tantek> looks like some scruff in need of a shave
  541. # [07:22] * Quits: florian (~Adium@public.cloak) (Client closed connection)
  542. # [07:22] * Joins: florian (~Adium@public.cloak)
  543. # [07:23] <dbaron> it's in Plane 1.
  544. # [07:23] <dbaron> (near the beginning of Plane 1)
  545. # [07:24] * liam sees it in gucharmap
  546. # [07:25] * fantasai waves
  547. # [07:27] <liam> :)
  548. # [07:27] * liam sorry not to be in Seattle, I bet they actually have liquid ice over there
  549. # [07:28] * Quits: florian (~Adium@public.cloak) ("Leaving.")
  550. # [07:44] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
  551. # [07:45] * Joins: tantek (~tantek@public.cloak)
  552. # [07:53] * Quits: Rossen__ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
  553. # [08:00] * Joins: emalasky (~Adium@public.cloak)
  554. # [08:10] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
  555. # [08:25] * Quits: tantek (~tantek@public.cloak) (tantek)
  556. # [08:32] * Joins: stakagi (~stakagi@public.cloak)
  557. # [08:39] * Joins: Ms2ger (~Ms2ger@public.cloak)
  558. # [08:54] * Quits: stakagi (~stakagi@public.cloak) (Client closed connection)
  559. # [08:59] * Joins: tantek (~tantek@public.cloak)
  560. # [09:00] <tantek> TabAtkins: http://wiki.csswg.org/tools/bikeshed
  561. # [09:11] * Joins: koji (~koji@public.cloak)
  562. # [09:12] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
  563. # [09:12] * Joins: tantek (~tantek@public.cloak)
  564. # [09:18] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
  565. # [09:24] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
  566. # [09:24] * Joins: emalasky (~Adium@public.cloak)
  567. # [09:32] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
  568. # [09:36] * Quits: Henke37 (~Henrik@public.cloak) (Client closed connection)
  569. # [09:49] * Joins: emalasky (~Adium@public.cloak)
  570. # [09:54] * Quits: logbot (~logbot@public.cloak) (Client closed connection)
  571. # [09:55] * Joins: logbot (~logbot@public.cloak)
  572. # [09:55] * Quits: logbot (~logbot@public.cloak) (Client closed connection)
  573. # [09:56] * Joins: logbot (~logbot@public.cloak)
  574. # [09:58] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
  575. # [10:12] * Quits: logbot (~logbot@public.cloak) (Client closed connection)
  576. # [10:12] * Joins: logbot (~logbot@public.cloak)
  577. # [10:42] * Quits: tantek (~tantek@public.cloak) (tantek)
  578. # [11:36] * Joins: darktears (~darktears@public.cloak)
  579. # [12:05] * leaverou_away is now known as leaverou
  580. # [12:11] * leaverou is now known as leaverou_away
  581. # [14:02] * Joins: florian (~Adium@public.cloak)
  582. # [14:03] * Joins: eliezerb (~Eliezer@public.cloak)
  583. # [14:14] * Joins: mihnea (~sid16310@public.cloak)
  584. # [15:08] * Quits: florian (~Adium@public.cloak) ("Leaving.")
  585. # [15:24] * Joins: florian (~Adium@public.cloak)
  586. # [16:15] * Joins: koji (~koji@public.cloak)
  587. # [16:23] * Joins: emalasky (~Adium@public.cloak)
  588. # [16:33] * Joins: eliezerb_2nd (~Eliezer@public.cloak)
  589. # [16:33] * Quits: eliezerb (~Eliezer@public.cloak) (Client closed connection)
  590. # [16:37] * Joins: zcorpan (~zcorpan@public.cloak)
  591. # [16:39] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
  592. # [16:44] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
  593. # [16:48] * Joins: jet (~junglecode@public.cloak)
  594. # [16:50] * Quits: koji (~koji@public.cloak) (Client closed connection)
  595. # [16:54] * Quits: florian (~Adium@public.cloak) ("Leaving.")
  596. # [16:59] * Joins: emalasky (~Adium@public.cloak)
  597. # [17:01] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
  598. # [17:05] * Joins: SteveZ (~SteveZ@public.cloak)
  599. # [17:25] * Joins: koji (~koji@public.cloak)
  600. # [17:37] * Quits: koji (~koji@public.cloak) (Client closed connection)
  601. # [17:39] * Joins: lmcliste_ (~lmclister@public.cloak)
  602. # [17:39] * Joins: koji (~koji@public.cloak)
  603. # [17:41] * Joins: rhauck (~Adium@public.cloak)
  604. # [17:41] * Joins: Rossen__ (~Rossen@public.cloak)
  605. # [17:42] * Joins: glazou (~glazou@public.cloak)
  606. # [17:47] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
  607. # [17:54] * Joins: dbaron (~dbaron@public.cloak)
  608. # [17:57] * Joins: dauwhe (~dauwhe@public.cloak)
  609. # [17:57] * Joins: tantek (~tantek@public.cloak)
  610. # [17:58] * Joins: smfr (~smfr@public.cloak)
  611. # [18:00] * Joins: AdobeSeattle (~AdobeSeattle@public.cloak)
  612. # [18:00] * Quits: jet (~junglecode@public.cloak) (jet)
  613. # [18:03] * Joins: florian (~Adium@public.cloak)
  614. # [18:06] * Joins: plh (plehegar@public.cloak)
  615. # [18:07] <tantek> good morning
  616. # [18:07] * Quits: koji (~koji@public.cloak) (Client closed connection)
  617. # [18:07] * Joins: leif (~lastorset@public.cloak)
  618. # [18:07] * Joins: koji (~koji@public.cloak)
  619. # [18:08] <glazou> ScribeNick: tantek
  620. # [18:08] <tantek> Agenda item 60 minutes Media Queries
  621. # [18:09] <florian> http://lists.w3.org/Archives/Public/www-style/2013Nov/0122.html
  622. # [18:09] <TabAtkins> Topic: Media Queries
  623. # [18:09] <tantek> florian: MQ3
  624. # [18:09] <tantek> … errata
  625. # [18:09] <tantek> … need to fix example in a REC
  626. # [18:09] <tantek> … we have an errata for MQ3 but that typo is not in it
  627. # [18:10] <tantek> plh: updating errata is easy
  628. # [18:10] <tantek> plh: but a new REC is harder
  629. # [18:10] <tantek> florian: updating errata is good enough
  630. # [18:10] <tantek> fantasai: you can fix the typo in place
  631. # [18:11] <tantek> florian: whoever can touch these documents please fix
  632. # [18:11] <tantek> bert: I can fix the errata
  633. # [18:11] <florian> http://lists.w3.org/Archives/Public/www-style/2013Nov/0125.html
  634. # [18:11] <tantek> florian: the other MQ3 topic
  635. # [18:12] <tantek> … it says something about never having to evaluate a style sheet
  636. # [18:12] <tantek> … I have proposed wording
  637. # [18:12] <tantek> … do we want to change this in level 3?
  638. # [18:12] <tantek> … or we can just do it in 4
  639. # [18:12] <tantek> … in level 4 it is already fixed.
  640. # [18:12] <tantek> glazou: fix it in both
  641. # [18:12] <tantek> glazou: no objections, resolved.
  642. # [18:12] <tantek> dbaron: does it make it clear that it is unless explicitly specified
  643. # [18:13] <tantek> florian: yes
  644. # [18:13] <tantek> dbaron: it might be good if it was "… that it overrides this rule"
  645. # [18:13] <tantek> tab: ok
  646. # [18:13] <SimonSapin> +1 dbaron
  647. # [18:13] <dbaron> explicitly specified that it overrides this rule
  648. # [18:13] <tantek> tab: MQ4 changes
  649. # [18:13] * Joins: yamamoto (~yamamoto@public.cloak)
  650. # [18:13] <tantek> tab: I am going to ask for first public WD
  651. # [18:14] <tantek> tab: we are deprecating a bunch of media types, replacing them with media features
  652. # [18:14] <dbaron> (This is based on an interesting idea I read about... I think it was from Canadian law ... there are a set of legal rights that the government can't override unless the law overriding the right explicitly says that it violates that right... so that it can't happen by accident or be hidden.)
  653. # [18:14] <tantek> tab: TV never succeeded because your screen style sheets were not allowed
  654. # [18:14] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
  655. # [18:15] * Joins: kawabata3 (~kawabata3@public.cloak)
  656. # [18:15] <tantek> tab: MQ4 proposes saying: media types are a legacy feature
  657. # [18:16] <tantek> explicitly supporting: all, screen, print, speech
  658. # [18:16] <tantek> tab: no one is publishing tv style sheets
  659. # [18:16] <tantek> tab: beyond epsilon
  660. # [18:17] <tantek> florian: what we did with projection was fairly strange
  661. # [18:17] * fantasai thought it was rpetty useful, though
  662. # [18:17] * Joins: shepazu (schepers@public.cloak)
  663. # [18:17] <tantek> (we meaning "Opera" here)
  664. # [18:17] <tantek> glazou: what about number of screens and resolutions of screens?
  665. # [18:17] <tantek> glazou: we are concerned about the second screen experience
  666. # [18:18] <tantek> tab: yes. please bring it up in an email thread.
  667. # [18:18] <tantek> tab: also, new range context syntax
  668. # [18:18] <tantek> tab: authors seems excited about this
  669. # [18:18] <glazou> +1
  670. # [18:19] <tantek> tab: old min/max features still supported, but they just map to the inequalities versions
  671. # [18:19] <tantek> tab: could be convinced to add !=
  672. # [18:19] * plh in css, not equals is written ^^=
  673. # [18:19] <tantek> tab: single equal or double qual?
  674. # [18:19] * fantasai not =^^= ?
  675. # [18:19] <tantek> ^.%
  676. # [18:20] <dbaron> smfr: what about != ?
  677. # [18:20] <dbaron> dbaron: what about = ?
  678. # [18:20] <tantek> (too many talkings)
  679. # [18:20] <dbaron> dbaron: also want value < feature, given that they have value < feature < value
  680. # [18:20] <dbaron> tab: yes
  681. # [18:21] <tantek> bert: we have avoided < > in CSS to allow it better in HTML
  682. # [18:21] <tantek> tab: it works now
  683. # [18:21] <tantek> bert: HTML hasn't changed
  684. # [18:21] <tantek> tab/bert: CDATA arguments
  685. # [18:21] <tantek> shepazu: HTML5 has parser than handles it
  686. # [18:22] <tantek> bert: not just browser, talking about HTML, XML etc.
  687. # [18:22] <tantek> bert: you have to escape it in some cases
  688. # [18:22] <tantek> tab: if no one escapes it they won't have a problem
  689. # [18:22] <tantek> bert: if you use SGML you're going to have a bad day
  690. # [18:23] <tantek> tab: we should add = sign
  691. # [18:23] <glazou> (laughter)
  692. # [18:23] <tantek> resolution: add "="
  693. # [18:23] * dauwhe I have styled docbook with CSS, but I'd be fine with escaping < if needed in that situation.
  694. # [18:23] <glazou> RESOLVED: add =
  695. # [18:23] <tantek> tab: we need a use case for not equals
  696. # [18:23] <tantek> RESOLVED: add =
  697. # [18:23] <dbaron> RESOLUTION: add value < feature syntax
  698. # [18:23] * Joins: sgalineau (~sgalineau@public.cloak)
  699. # [18:23] <tantek> RESOLVED: add value op name form
  700. # [18:24] <tantek> tab: in addition to name op value form
  701. # [18:24] <tantek> tab: we are looking for use cases for the != form
  702. # [18:24] <tantek> tab: MQ4 syntax has been rewritten but should be functionally equivalent
  703. # [18:25] <dbaron> Tab: We agreed to add full and/or/not logic like @supports, but I haven't done that yet; plan to.
  704. # [18:25] <tantek> glazou: if we're using media features instead of media types we're going to replicate that list of features many times in many @-rules and I don't want to see that
  705. # [18:25] <tantek> florian: not in the spec now but we should talk about it
  706. # [18:26] <glazou> we need a way to declare a user-defined media type based on a list of features
  707. # [18:26] <tantek> florian: another minor change, when you just evaluate a media feature inside a parantheses we used to special case it
  708. # [18:26] <tantek> tab: none is now falsy as well as 0
  709. # [18:26] <tantek> tab: it prevents us from going down the route of having a boolean that takes 0 and 1
  710. # [18:26] <tantek> tab: new media features
  711. # [18:27] <tantek> tab: "updates" feature (name pending) - how quickly the screen updates
  712. # [18:27] <tantek> … updates: none is like printing
  713. # [18:27] <tantek> … updates: slow is saying not good enough for animations, like e-ink
  714. # [18:27] <tantek> … updates:normal can handle animations
  715. # [18:27] <tantek> … open to input on names and frequencies
  716. # [18:28] <tantek> florian: rate sounds like a number
  717. # [18:28] <dbaron> dauwhe: Call this refresh-rate rather than updates?
  718. # [18:28] <dbaron> (before florian)
  719. # [18:28] <tantek> florian: and we don't want that
  720. # [18:28] * sgalineau update-frequency high/low?
  721. # [18:28] <tantek> tab: next two is how you deal with overflow
  722. # [18:28] <fantasai> Also, mention animations in the description of 'normal'
  723. # [18:28] <tantek> … "overflow-block"
  724. # [18:28] <tantek> … none or scroll
  725. # [18:29] <tantek> fantasai: opera had a mode where it could do forced page breaks or otherwise it would scroll which was cool for presentations
  726. # [18:29] <tantek> tab: is that addressed by paged?
  727. # [18:29] <tantek> fantasai: I think it is a new one
  728. # [18:30] <tantek> dbaron: it is can-you-make-page-breaks, not does-overflow-go-into-new-pages
  729. # [18:30] <tantek> tab: it only applies if you are paged already
  730. # [18:30] <tantek> tab: better to have two variants of pages?
  731. # [18:30] <tantek> fantasai: it would devolve into the same feature
  732. # [18:30] <tantek> florian: would have to name it something else
  733. # [18:30] <tantek> smfr: terminology is very confusing
  734. # [18:30] <tantek> … overflow block and scrolling is already used in CSS
  735. # [18:30] <tantek> tab: we tried to use parallel naming but that might be confusing
  736. # [18:31] <tantek> tab: better names are requested!
  737. # [18:31] <tantek> smfr: content doesn't overflow the screen, it overflows the viewport
  738. # [18:31] <tantek> tab: you're right that should be viewport
  739. # [18:31] <tantek> tab: can we split paged into two values that better capture it
  740. # [18:31] <tantek> tab: and we'll solicit better names for the properties themselves.
  741. # [18:31] <tantek> tab: sound good?
  742. # [18:32] <tantek> (no objections voiced)
  743. # [18:32] <tantek> tab: (more new features)(
  744. # [18:32] <tantek> tab: "pointer"
  745. # [18:32] <tantek> tab: "none"
  746. # [18:32] <tantek> florian: like paper, TV without a cursor
  747. # [18:32] <tantek> tab: … other value, like a mouse
  748. # [18:33] * Quits: florian (~Adium@public.cloak) ("Leaving.")
  749. # [18:33] <tantek> … pointer: coarse | fine vs. hover: none | hover
  750. # [18:34] * Joins: florian (~Adium@public.cloak)
  751. # [18:34] <tantek> (markup discussion of spec example)
  752. # [18:34] <tantek> tab: "hover" is a new media feature
  753. # [18:34] * Joins: koji (~koji@public.cloak)
  754. # [18:35] <tantek> … whether hover is supported or not
  755. # [18:35] <tantek> florian: we are not addressing the keyboard
  756. # [18:35] <tantek> (disappointed in minute taker for not capturing an overflow joke)
  757. # [18:36] <tantek> tab: some devices can match multiple values
  758. # [18:36] <tantek> tab: e.g. chrome pixel is both touch and pointing device
  759. # [18:36] <tantek> tab: e.g. both coarse and fine
  760. # [18:36] <tantek> tab: in general we say match according to primary input devices
  761. # [18:37] * Joins: rhauck (~Adium@public.cloak)
  762. # [18:37] <tantek> tab: if it's just a possible input, don't match
  763. # [18:37] <tantek> florian: connecting a mouse to a tv does not turn it into a desktop
  764. # [18:37] <tantek> tab: next, "lumosity"
  765. # [18:37] <tantek> s/lumosity/luminosity
  766. # [18:37] <tantek> smfr: this is the wrong term
  767. # [18:37] <tantek> glazou: we should use device API terms
  768. # [18:38] <fantasai> glazou: This is called light-level
  769. # [18:38] <tantek> glazou: there are a lot of device APIs we could add as media queries
  770. # [18:38] <tantek> glazou: e.g. new samsung phones have capability of detecting to see if someone is looking at the phone
  771. # [18:38] <tantek> plinss: so you can restyle the page to look different when you're not looking at it
  772. # [18:38] <tantek> (laughter)
  773. # [18:39] <tantek> tab: should be careful with things useful declaratively or just in script
  774. # [18:39] * sgalineau 'we have 5m page non-views'
  775. # [18:39] <tantek> tab: but there's a goldmine of things we should add
  776. # [18:39] <tantek> shepazu: have to be careful with pointer events
  777. # [18:40] <tantek> tab: we should capture that luminosity should be named light-level
  778. # [18:40] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
  779. # [18:40] * glazou ahem do we need a 'css' media feature ?-)
  780. # [18:40] <tantek> tab: script
  781. # [18:40] <tantek> tab: whether or not ecmascript is supported on the current document
  782. # [18:40] <tantek> shepazu: "script" in the CSS context might be confused with i18n script
  783. # [18:41] * Joins: sgalineau (~sgalineau@public.cloak)
  784. # [18:41] <tantek> shepazue: how about procedural scripting? something other than "script"
  785. # [18:41] <tantek> fantasai: should be something about languages
  786. # [18:41] <tantek> shepazu: scripting would be less confusing
  787. # [18:41] <tantek> fantasai: none | js | dart
  788. # [18:42] <tantek> tab: switch "enabled" to be actual scripting language names
  789. # [18:42] * plh -webkit-js ?
  790. # [18:42] <tantek> tab: a third value might be useful (in addition to none | enabled)
  791. # [18:42] <tantek> tab: UAs like opera mini run scripts on page load and then never again
  792. # [18:43] <tantek> tab: is that useful ?
  793. # [18:43] <tantek> plinss: similar to printting
  794. # [18:43] <tantek> … so yes it is useful
  795. # [18:43] <tantek> tab: then I want two different features
  796. # [18:43] <tantek> tab: whether scripting is allowed at all
  797. # [18:43] <tantek> tab: and then another feature for supported language(s)
  798. # [18:43] <tantek> florian: I don't think there is a pressing need for detecting which language
  799. # [18:43] <tantek> fantasai: what about user pref'd off?
  800. # [18:43] <tantek> tab: those are just "none"
  801. # [18:44] <tantek> plinss: there are many sites that say, "your scripting is turned off, please turn it on" - horrible thing to say if you can't turn it on
  802. # [18:44] <tantek> dbaron: there are plenty of sites that do that via a div in markup and set it to display none in script
  803. # [18:44] <tantek> plinss: … (couldnt' hear)
  804. # [18:45] <tantek> tab: the way the syntax is defined, both such values should be falsy
  805. # [18:45] <tantek> tab: we could make the set of falsy values extensible
  806. # [18:45] <tantek> florian: ?
  807. # [18:45] <tantek> tab: if it gets fine grained enough you need a JS API
  808. # [18:46] <tantek> florian: (something) might eventually be needed
  809. # [18:46] <tantek> tab: will leave it as an open issue - do we want two flavors of none?
  810. # [18:46] <tantek> tab: will add a feature for can-only-run-script-on-load
  811. # [18:47] <tantek> ???: fingerprinting concerns?
  812. # [18:47] <tantek> tab: a lot of them are already exposed in other ways
  813. # [18:47] <tantek> … if there are new exposures, open to ways to deal with that
  814. # [18:47] <SimonSapin> s/???/SimonSapin/
  815. # [18:47] * sgalineau heard Tab say 'axes' and not 'axises'
  816. # [18:47] <tantek> glazou: devices, keyboards
  817. # [18:47] <tantek> glazou: some devices have keyboard that slides out
  818. # [18:48] <tantek> tab: captured by "work properly" vs "horrible"
  819. # [18:48] <tantek> tab: lots of open questions about keyboards
  820. # [18:49] <tantek> tab: many sets of devices these days
  821. # [18:49] <tantek> tab: yesterday we discussed print economy
  822. # [18:49] <tantek> tab: some things that are static will want full backgrounds
  823. # [18:49] <tantek> tab: some things like printers may want to do economy mode
  824. # [18:49] <tantek> simon: ...
  825. # [18:50] <tantek> florian: is that what media queries are for?
  826. # [18:50] <tantek> florian: e.g. if black everywhere is expensive...
  827. # [18:50] <tantek> tab: yes, that's my basic thought
  828. # [18:50] <tantek> tab: the property allows you to opt into the browser's blunt hammer - e.g. economize ink usage
  829. # [18:50] <SimonSapin> s/.../If ink-economy is a CSS property, it may be problematic to query it with MQ
  830. # [18:50] <tantek> tab: it might be valuable to allow more fine grain user / author input
  831. # [18:51] <tantek> tab: microsoft has a high-contrast media query
  832. # [18:51] <tantek> tab: how does it work?
  833. # [18:51] <tantek> rossen: the latter (that you've been put into high contrast mode and you should adapt)
  834. # [18:51] <tantek> tab: also, inverted
  835. # [18:51] <tantek> tab: is it forced or requested?
  836. # [18:51] <tantek> rossen: same way
  837. # [18:52] <tantek> plh: we looked into that related to the canvas API
  838. # [18:52] <tantek> plh: re: custom focus ring
  839. # [18:52] <tantek> plh: only supposed to draw focus ring if special request from user
  840. # [18:52] <tantek> plh: it is not clear if browser has access to the information
  841. # [18:52] <tantek> plh: e.g. on Windows it is controlled by the OS
  842. # [18:52] <tantek> plh: but did not tell the browser
  843. # [18:52] <tantek> plh: you may want to be careful
  844. # [18:52] <tantek> plh: maybe some privacy implication
  845. # [18:53] <tantek> plh: people using high contrast may have some disability and may not want to give that information
  846. # [18:53] <tantek> tab: there was a discussion in Shenzen about this
  847. # [18:53] <tantek> tab: all that indieUI mediaqueries, do we want them in MQ4 or leave them in an extension?
  848. # [18:53] <tantek> plh: maybe wait a while before you do that
  849. # [18:53] <tantek> plh: to see how successful they are
  850. # [18:54] <tantek> bert: otherwise people will have hard time finding them
  851. # [18:54] <tantek> fantasai: best to pull them all into one spec
  852. # [18:54] <tantek> tab: they don't have that many
  853. # [18:54] <tantek> tab: but a bunch of them should be pulled in
  854. # [18:54] <tantek> fantasai: concerns e.g. with inversion is there are various ways of inverting
  855. # [18:54] <tantek> tab: we need a way to say this is an image, don't invert it
  856. # [18:54] <tantek> tab: but still want a mq for inversion to turn off shadows
  857. # [18:55] <tantek> tab: being able to actually alter your styling in response, beyond just un-inverting images, is still useful
  858. # [18:55] <tantek> tab: I will look into pulling in indieUI things we've discussed
  859. # [18:55] <tantek> fantasai: another one ...
  860. # [18:55] <tantek> tab: kina
  861. # [18:55] <tantek> kinda
  862. # [18:55] <tantek> fantasai: e.g. opera with dark theme
  863. # [18:55] <tantek> tab: that's interesting
  864. # [18:55] <tantek> tab: might be a good direction to go in, preferred theming
  865. # [18:56] <tantek> tab: final issue - view-mode
  866. # [18:56] <tantek> tab: seems half reasonable
  867. # [18:57] <tantek> tab: should properly pull it in and get it properly tested in real browsers
  868. # [18:57] <tantek> smfr: generally deprecating media types, bunch of other specs refer to them
  869. # [18:58] <tantek> smfr: e.g. animations says if you're media type print you should not animate
  870. # [18:58] <tantek> smfr: things they can be converted to?
  871. # [18:58] <tantek> tab: animations should just refer to the "updates" media feature
  872. # [18:58] <tantek> simonsapin: media line?
  873. # [18:58] <tantek> (in property definitions)
  874. # [18:58] <tantek> tab: we should fix that
  875. # [18:58] * Quits: kawabata3 (~kawabata3@public.cloak) ("Page closed")
  876. # [18:58] * Joins: kawabata (~kawabata@public.cloak)
  877. # [18:59] <tantek> bert: I use some of these media types!
  878. # [18:59] <tantek> bert: they should keep working
  879. # [18:59] <tantek> bert: they work in opera
  880. # [18:59] <tantek> bert: projection, handheldd
  881. # [19:00] <tantek> florian: not since 2007
  882. # [19:00] <tantek> bert: also in openwave
  883. # [19:00] <tantek> bert: deprecating is fine, but don't change their meaning
  884. # [19:00] <tantek> tab: old browsers can do what they want
  885. # [19:00] * Joins: MaRakow (~MaRakow@public.cloak)
  886. # [19:00] <tantek> florian: new browsers won't match them
  887. # [19:00] <tantek> bert: that's a problem
  888. # [19:00] <tantek> tab: won't work on my phone
  889. # [19:00] <tantek> bert: they have bad browsers
  890. # [19:00] <tantek> tab: these media types are not used in practice
  891. # [19:00] <tantek> bert: no
  892. # [19:01] <tantek> plh: perhaps deprecate but still support instead of drop?
  893. # [19:01] <tantek> shepazu: we're talking about for browsers made today and in the future
  894. # [19:01] <tantek> bert: ok to add new functionality
  895. # [19:01] <tantek> bert: but not ok to break existing documents
  896. # [19:02] <tantek> tab: but those don't work in 99.99% of devices
  897. # [19:02] <tantek> bert: but that's a bug in those browsers
  898. # [19:02] <tantek> bert: so how do I get my projection?
  899. # [19:02] <tantek> glazou: projection is completely undefined
  900. # [19:03] <tantek> bert: but it works
  901. # [19:04] <tantek> tantek: projection only worked in one implementation. claiming we should support those documents is like saying all browsers should support -webkit- prefix features.
  902. # [19:04] <dbaron> dbaron: The thing Opera did with projection is nothing like what the spec said.
  903. # [19:04] <tantek> bert: but projection was in a standard
  904. # [19:04] <tantek> (lots of talking)
  905. # [19:05] <tantek> florian: this document at an editorial level was a major rewrite
  906. # [19:05] <tantek> florian: please review to make sure we didn't change meaning of existing features (unintentionally)
  907. # [19:05] <tantek> glazou: next step
  908. # [19:05] <tantek> tab: request FPWD
  909. # [19:05] <tantek> glazou: who agrees on FPWD
  910. # [19:05] <tantek> glazou: who objects
  911. # [19:05] <tantek> glazou: consensus FPWD MQ4
  912. # [19:06] <tantek> tab: also I need to be an editor
  913. # [19:06] <dbaron> (probably about 2/3 or more of the room in favor, and no objections)
  914. # [19:06] * Quits: florian (~Adium@public.cloak) ("Leaving.")
  915. # [19:06] <tantek> glazou: who will publish it? staff contact?
  916. # [19:07] <tantek> shepazu: had a long conversation Sunday about projection
  917. # [19:07] <tantek> shepazu: use cases
  918. # [19:07] <tantek> shepazue: 1 notes on screen but not visible on projector (second screen thing)
  919. # [19:07] <tantek> shepazu: 2 change contrast when it is being projected, higher contrast
  920. # [19:07] <tantek> 3 full screen on the projection and not necessarily on your main screen
  921. # [19:08] <tantek> florian: e.g. if you try to replicate Powerpoint in a browser
  922. # [19:08] <tantek> shepazu: if you mirror screens, is that OS level and you can't effect? we aren't sure how we're going to address all this
  923. # [19:08] <tantek> smfr: two of those things sounded like you wanted two views of the same document
  924. # [19:08] <tantek> clilley: there are other contexts we've discussed that
  925. # [19:08] <glazou> RESOLVED: FPWD of MQ4, editor and ChrisL ; Tab added as editor
  926. # [19:08] <tantek> glazou: time
  927. # [19:09] * Joins: florian (~Adium@public.cloak)
  928. # [19:09] * fantasai did not understand that resolution, please rewrite what was meant?
  929. # [19:09] <fantasai> RESOLVED: FPWD of MQ4
  930. # [19:09] <tantek> RESOLVED: publish FWPD of MQR, add Tab as editor
  931. # [19:09] <fantasai> ok, thanks :)
  932. # [19:09] <tantek> RESOLVED: publish FWPD of MQ4, add Tab as editor
  933. # [19:09] <tantek> new topic
  934. # [19:09] <tantek> Topic: baseline grids
  935. # [19:09] <tantek> astearns speaking/ presenting
  936. # [19:10] <tantek> … had a problem, and with CSS in general
  937. # [19:10] <tantek> … (sets up projector)
  938. # [19:10] <tantek> … have been using this as an example of baseline grids
  939. # [19:10] <tantek> … they have side by side content, and none of the baselines align across columns
  940. # [19:11] <tantek> … it would be great to have a way to share a baseline grid
  941. # [19:11] * plh can't stop thinking "Alan Is Watching You" when looking at the image
  942. # [19:11] <tantek> … so that the columns could share baselines in body text
  943. # [19:11] <tantek> … it would be great if CSS could address this problem
  944. # [19:11] <tantek> … having line boxes align to a grid is a first step
  945. # [19:11] <tantek> … you want a way to say I want these lines to participate in a grid and others not
  946. # [19:12] <tantek> … e.g. body text stays on the grid
  947. # [19:12] <tantek> … or giving blocks a way to align to the grid in interesting ways
  948. # [19:12] <tantek> … e.g. having the first baseline of the element align to the grid
  949. # [19:12] <tantek> … or having the entire block center on the grid
  950. # [19:12] <tantek> … in either case you get a much better layout
  951. # [19:13] <tantek> fantasai: I have a proposal but it depends on the Line Box Module
  952. # [19:13] <tantek> simonsapin: line-grid module?
  953. # [19:13] <tantek> astearns: yes
  954. # [19:13] <fantasai> fantasai: I wrote a proposal, but the WG decided it wanted to put in the line Box module, which is not in a publishable state
  955. # [19:13] <tantek> szilles: critical part, what gets aligned, and how big is it
  956. # [19:13] <fantasai> fantasai: So I'm not allowed to publish it
  957. # [19:14] <tantek> astearns: does fantasai's proposal handle it?
  958. # [19:14] <dauwhe> http://dev.w3.org/csswg/css-line-grid/
  959. # [19:14] <tantek> szilles: not clear
  960. # [19:14] * hober IIRC we based -webkit-line-clamp on fantasai's proposal
  961. # [19:14] <tantek> szilles: the way CSS does line boxes, not clear if you can determine the baselines
  962. # [19:15] <tantek> astearns: there has to be because flexbox does some first baseline based alignment
  963. # [19:15] <SimonSapin> fantasai, Line Box, is it Line Layout / css-inline ?
  964. # [19:15] <tantek> clilley: would be nice to see more alignment
  965. # [19:15] <tantek> clilley: second comment, also drop caps, n lines below the baseline
  966. # [19:16] <tantek> clilley: 3 other alphabets align to top line etc.
  967. # [19:16] <fantasai> clilley^: e.g. align by-lines to each other at the bottom
  968. # [19:16] <tantek> astearns: sometimes it's not the baseline, sometimes it's some other typographic measure
  969. # [19:16] <tantek> astearns: CJK
  970. # [19:17] <tantek> fantasai: center baseline
  971. # [19:17] <tantek> szilles: e.g. don't want to take ruby into account when doing the alignment
  972. # [19:17] <fantasai> s/CJK/e.g. CJK centers the content/
  973. # [19:17] <fantasai> s/center baseline/actually, it aligns to a baseline as well -- happens to be the central baseline rather than alphabetic baseline/
  974. # [19:17] <tantek> astearns: ...
  975. # [19:18] <tantek> astearns: (other problems)
  976. # [19:18] <tantek> szilles: also widows and orphans
  977. # [19:18] <fantasai> s/.../problem of aligning lines to baseline grid while bottom-aligning the content
  978. # [19:18] <tantek> bert: ...
  979. # [19:19] <Bert> (Like leader(), but vertical.)
  980. # [19:19] <tantek> astearns: the main relationship depends on the order in the block direction
  981. # [19:19] <tantek> astearns: how tall it is when you are bottom aligning it, then relates to grid, then loop
  982. # [19:19] <tantek> astearns: I would like to work on this
  983. # [19:19] <tantek> astearns: perhaps I can help co-edit Line Box Module
  984. # [19:20] <tantek> szilles: ...
  985. # [19:20] <tantek> fantasai: let's publish both of them, and continue working on both
  986. # [19:20] <tantek> clilley: ?
  987. # [19:20] <tantek> fantasai: I proposed line-grid module
  988. # [19:20] <tantek> fantasai: but WG asked me to make it work with line box module
  989. # [19:21] * Quits: florian (~Adium@public.cloak) ("Leaving.")
  990. # [19:21] <tantek> florian: how can we depend on baselines without defining them?
  991. # [19:21] <tantek> tantek: because baselines are shipping
  992. # [19:21] <tantek> fantasai: once they both exist, cross referencing would be better
  993. # [19:21] <tantek> clilley: if they both reference 2.1, just publish
  994. # [19:21] <tantek> fantasai: that would be better
  995. # [19:21] <TabAtkins> Tantek, *something* is shipping, which vaguely resembles what we typically call "baselines". That doesn't mean it's something we can write further features on top of.
  996. # [19:21] <tantek> clilley much more eyes on it by publishing it
  997. # [19:22] <tantek> TabAtkins, flexbox would seem to be an existence disproof of that statement. ;)
  998. # [19:22] <tantek> (as a further feature on top of "baselines")
  999. # [19:22] <fantasai> http://dev.w3.org/csswg/css-line-grid/
  1000. # [19:22] <fantasai> http://dev.w3.org/csswg/css-inline/
  1001. # [19:22] <TabAtkins> Flexbox is a minor violation of that statement. It only barely touches baselines. ^_^
  1002. # [19:22] <tantek> fantasai: these are the two modules we are talking about
  1003. # [19:23] <tantek> glazou: are we done?
  1004. # [19:23] <tantek> astearns: I would like to start with fantasai's proposal
  1005. # [19:23] <tantek> shepazu: I second that
  1006. # [19:24] <tantek> glazou: but where?
  1007. # [19:24] <tantek> fantasai: ok to publish as its own module
  1008. # [19:24] <tantek> fantasai: and merge later
  1009. # [19:25] * Joins: florian (~Adium@public.cloak)
  1010. # [19:25] <tantek> glazou: summarize?
  1011. # [19:25] <tantek> dbaron: so I don't entirely understand what the line grid spec is saying
  1012. # [19:25] <tantek> dbaron: should we - if we're going to publish this can discuss it a few minutes
  1013. # [19:25] <tantek> florian: we reviewed it in Kyota
  1014. # [19:26] <tantek> s/Kyota/Kyoto
  1015. # [19:26] <tantek> dbaron: the line-grid property seems global rather than an ancestor chain which seems weird
  1016. # [19:26] <tantek> dbaron: seems to imply a temporal things
  1017. # [19:26] <tantek> dbaron: would be better if it said ancestor
  1018. # [19:26] <tantek> dbaron: that should be clarified
  1019. # [19:26] <tantek> bert: seems overkill. should be ok to say this element defines a grid or not.
  1020. # [19:27] <tantek> bert: you don't need an identifier for that
  1021. # [19:27] <tantek> szilles: the reason you need identifier is you may have two grids going at the same time. one for figures and one for text
  1022. # [19:27] <tantek> bert: seems a bit far fetched
  1023. # [19:27] <tantek> bert: would like to see it based on ancestors first
  1024. # [19:28] <tantek> szilles: would prefer some discussion first
  1025. # [19:28] <tantek> clilley: we discussed at hamburg
  1026. # [19:29] <tantek> szilles: issues raised in Hamburg were not handled
  1027. # [19:29] <tantek> clilley: it is ready for FPWD
  1028. # [19:29] <tantek> clilley: if there are outstanding issues, then put them into the draft and publish
  1029. # [19:29] <tantek> tantek: agree with chris
  1030. # [19:31] <tantek> fantsai: it wasn't discussed in Hamburg, it was discussed in Kyoto 2.5 years ago
  1031. # [19:31] <tantek> s/fantsai/fantasai
  1032. # [19:31] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
  1033. # [19:31] <tantek> glazou: we agree that we add known issue to the document?
  1034. # [19:31] <smfr> i assume we're talking about http://dev.w3.org/csswg/css-line-grid/
  1035. # [19:31] <tantek> smfr, yes
  1036. # [19:31] <tantek> fantasai: only known issue: wanting to simplify to only use ancestors, not identifiers
  1037. # [19:31] <tantek> szilles: my issue, does it consider ruby?
  1038. # [19:31] <tantek> fantasai: ?
  1039. # [19:32] <tantek> glazou: why are we blocking this?
  1040. # [19:33] <tantek> RESOLVED add astearns, fantasai as editors to line-grid module, published FPWD css-line-grid
  1041. # [19:33] <tantek> dbaron: I'd like to see that wording thing fixed.
  1042. # [19:33] <tantek> fantasai: ok I'll fix it
  1043. # [19:33] * Quits: koji (~koji@public.cloak) (Client closed connection)
  1044. # [19:33] <tantek> BREAK 15 minutes
  1045. # [19:33] * Joins: koji (~koji@public.cloak)
  1046. # [19:34] * Joins: lmcliste_ (~lmclister@public.cloak)
  1047. # [19:40] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
  1048. # [19:44] * Quits: florian (~Adium@public.cloak) ("Leaving.")
  1049. # [19:50] * Joins: florian (~Adium@public.cloak)
  1050. # [19:50] * Joins: koji (~koji@public.cloak)
  1051. # [19:51] <sgalineau> scribenick: sgalineau
  1052. # [19:51] <sgalineau> topic: css3-color
  1053. # [19:52] <sgalineau> chris: to discuss the state of implementation and test suite
  1054. # [19:52] <sgalineau> fantasai: any testcases from anyone on currentColor?
  1055. # [19:52] <sgalineau> dbaron: I think I added one for the new behavior...
  1056. # [19:53] <dbaron> I added contributors/mozilla/submitted/css3-transitions/currentcolor-animation-001.html
  1057. # [19:53] <sgalineau> fantasai: currentColor used to compute to the value of color
  1058. # [19:53] <sgalineau> fantasai: instead it now inherits
  1059. # [19:53] <sgalineau> dbaron: the test I added for another behavior derived from this change, namely animation implication
  1060. # [19:54] <sgalineau> dbaron: you'd need to use currentColor on background and test its inheritance
  1061. # [19:54] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22color%3A%20red%3B%20border-color%3A%20currentColor%22%3E%0A%3Cdiv%20style%3D%22border-style%3A%20solid%3B%20border-color%3A%20inherit%22%3E%3C%2Fdiv%3E%0A%3C%2Fdiv%3E
  1062. # [19:54] <dbaron> contributors/mozilla/submitted/css3-color/t44-currentcolor-inherited-c.xht
  1063. # [19:55] <dbaron> is a direct test for the erratum
  1064. # [19:55] <fantasai> http://test.csswg.org/shepherd/testcase/t44-currentcolor-inherited-c/name/t44-currentcolor-inherited-c/
  1065. # [19:55] <sgalineau> chrisl: is this test waiting for review? I am happy to review
  1066. # [19:56] * Joins: ChrisL (clilley@public.cloak)
  1067. # [19:56] <fantasai> r=fantasai
  1068. # [19:56] <SimonSapin> SimonSapin: Servo should implement the new behavior, but I haven’t tested it explicitly
  1069. # [19:56] <sgalineau> ACTION chris Review dbaron's test
  1070. # [19:56] * trackbot is creating a new ACTION.
  1071. # [19:56] <trackbot> Created ACTION-610 - Review dbaron's test [on Chris Lilley - due 2014-02-04].
  1072. # [19:56] * Joins: adenilson (~anonymous@public.cloak)
  1073. # [19:56] * sgalineau David discovers that it's tests all the way down
  1074. # [19:56] <dbaron> http://test.csswg.org/shepherd/search/name/t44-currentColor/
  1075. # [19:56] <dbaron> the two plinss tests are for the old behavior
  1076. # [19:57] <sgalineau> fantasai: does anyone implement it?
  1077. # [19:57] <sgalineau> simonsapin: Servo...maybe?
  1078. # [19:57] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
  1079. # [19:57] <sgalineau> fantasai: does any impl pass David's test?
  1080. # [19:57] <dbaron> http://test.csswg.org/shepherd/repository/5af75de6ab2b85d4233bd429e9897820c28180b4/contributors/mozilla/submitted/css3-color/t44-currentcolor-inherited-c.xht
  1081. # [19:57] <sgalineau> chris: Firefox does not.
  1082. # [19:58] <sgalineau> Rossen: no pass in IE either
  1083. # [19:58] <smfr> no pass in WebKit
  1084. # [19:59] <sgalineau> fantasai: we needed current color for an inheritable property: text-emphasis
  1085. # [19:59] <sgalineau> fantasai: we wanted the initial value to be something that said use the current color
  1086. # [19:59] <SimonSapin> After changing the test to not use CDATA (we don’t support XML), Servo passes the test
  1087. # [20:00] <sgalineau> fantasai: so it was a matter of adding a new keyword or redefining currentColor
  1088. # [20:00] <sgalineau> fantasai: the change made no difference for current use of the keyword
  1089. # [20:00] <sgalineau> fantasai: so we were able to make the change even though it was incompatible
  1090. # [20:00] <SimonSapin> WeasyPrint passes too
  1091. # [20:01] <sgalineau> dirk: I don't think the SVG WG reached consensus
  1092. # [20:01] <sgalineau> fantasai: if we don't want to make this change we need a different keyword
  1093. # [20:01] * ChrisL new-current-color
  1094. # [20:01] * fantasai current-color would work. currentColor is not current-color ;)
  1095. # [20:01] <sgalineau> dbaron: in Gecko we have a second implementation of currentColor because we can't use the old currentColor
  1096. # [20:03] <sgalineau> SimonSapin: Servo and WeasyPrint pass this test
  1097. # [20:03] <sgalineau> fantasai: anyone implement text-emphasis?
  1098. # [20:03] <sgalineau> <crickets>
  1099. # [20:03] <tantek> I am ok with this change to currentColor
  1100. # [20:03] <fantasai> SimonSapin, do Servo and WeasyPrint both pass the entire CSS3 Color test suite?
  1101. # [20:03] <tantek> this seems like a good improvement to currentColor
  1102. # [20:04] * fantasai would like to improve it by adding a hyphen, but that ship may have sailed
  1103. # [20:04] <SimonSapin> fantasai, I don’t know, since that suite is not automated
  1104. # [20:04] * Joins: stakagi (~stakagi@public.cloak)
  1105. # [20:05] * krit fantasai wasn't currentColor coming from SVG anyway?
  1106. # [20:05] * sgalineau notes minuting is much easier when people in the room use IRC instead
  1107. # [20:05] * krit SVG has had it for 14 years now :P
  1108. # [20:05] <SimonSapin> fantasai, they do pass color3*.json in https://github.com/SimonSapin/css-parsing-tests , but that’s only parsing
  1109. # [20:05] * astearns also, a mostly-silent room is soothing
  1110. # [20:06] <sgalineau> Topic: reverse lists
  1111. # [20:06] <sgalineau> tab: the lists module correctly handles HTML list rendering
  1112. # [20:06] <sgalineau> tab: except for the reverse attribute which counts backwards
  1113. # [20:06] <sgalineau> tab: if you look at the list module right now the style sheet resets the counter to some magic thing so we can't express this
  1114. # [20:06] * krit didn't we resolve that CSS has less magic?
  1115. # [20:07] <sgalineau> tab: so do we keep it magic or do we have a way to represent the number of children of an element
  1116. # [20:07] <TabAtkins> http://dev.w3.org/csswg/css-lists/#ua-stylesheet
  1117. # [20:07] <sgalineau> simonsapin: right now this is a non-normative stylesheet so we could consider this magic for now
  1118. # [20:07] <sgalineau> dbaron: i think we should address this eventually but this is not a priority right now. and the way we do address it should not just be some hack like counting the number of children
  1119. # [20:08] <sgalineau> dbaron: though it's possible html defines it as...
  1120. # [20:08] * Joins: MaRakow_ (~MaRakow@public.cloak)
  1121. # [20:08] <sgalineau> simonsapin: html suggests to count the number of <li>
  1122. # [20:08] <sgalineau> plinss: and does the display value impact the count?....
  1123. # [20:09] <SimonSapin> s/suggests/specifies/
  1124. # [20:09] <dbaron> it sounds like <ol reversed><li><li value="20"><li></ol> gives 3, 20, 19, which isn't quite expected...
  1125. # [20:09] <sgalineau> fantasai: so at the present level counter-reset is set to a magic value at the current level
  1126. # [20:09] <dbaron> I'd rather have had a mechanism that gave 21, 20, 1
  1127. # [20:09] <fantasai> fantasai: So, the HTML has a preshint-level rule that sets counter-reset on the list element to the number of <li> in the list
  1128. # [20:10] <fantasai> dbaron, that doesn't make any sense to me
  1129. # [20:10] <SimonSapin> http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#attr-ol-reversed
  1130. # [20:10] <dbaron> reversed means "works the normal way but counts in the other direction"
  1131. # [20:10] <glazou> it is expected because reversing a list is only setting start a counter-increment: -1
  1132. # [20:10] <sgalineau> RESOLVED: keep counter-reset magic for reverse lists in level 3
  1133. # [20:10] <sgalineau> Topic: Transforms
  1134. # [20:10] <fantasai> dbaron: hm, fair enough. I interpreted it as "count downwards", which I suppose matches the attr name less
  1135. # [20:10] <SimonSapin> s/reverse/<ol reversed>/
  1136. # [20:11] <fantasai> dbaron, I think counting downwards is easier to conceptualize as counters, though
  1137. # [20:11] <SimonSapin> dbaron, I don’t think any behavior makes sense in that example
  1138. # [20:11] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
  1139. # [20:12] <sgalineau> smfr: previously i tried to clarify a couple of areas
  1140. # [20:12] <sgalineau> smfr: i would like to revise the current text slightly
  1141. # [20:13] <sgalineau> smfr: there would be a small behavior change but current interop is good
  1142. # [20:13] <sgalineau> smfr: 1) how preserve-3d works 2) what elements in the document cause flattening to happen are the two topics
  1143. # [20:13] <sgalineau> <shows testcase>
  1144. # [20:13] <sgalineau> two elements with 3d transforms applied to them
  1145. # [20:13] <sgalineau> no preserve-3d
  1146. # [20:13] <sgalineau> two siblings
  1147. # [20:14] * Quits: smfr (~smfr@public.cloak) (Client closed connection)
  1148. # [20:14] <sgalineau> these elements intersect with each other but not their parent
  1149. # [20:14] <sgalineau> today the spec says this is just a painting effect
  1150. # [20:15] <sgalineau> in webkit we do support intersection. i would like this to be the right behavior because it simplifies the explanation of preserve-3d
  1151. # [20:15] * TabAtkins fantasai, I strongly object to having both currentcolor and current-color. ^_^
  1152. # [20:15] <sgalineau> …<next test>
  1153. # [20:16] <sgalineau> …in this new model, if you wanted to prevent intersection you would need the parent to force flattening with transform-style:flat
  1154. # [20:16] * Ms2ger wants currentColour
  1155. # [20:16] <sgalineau> …the next question is when does a transformed element intersect with its parent?
  1156. # [20:17] <sgalineau> …<shows test where preserve-3d is applied to the parent>
  1157. # [20:17] <sgalineau> …intersection is where there is little interop
  1158. # [20:17] <sgalineau> ACTION smfr Share transform testcases with the group
  1159. # [20:17] * trackbot is creating a new ACTION.
  1160. # [20:17] <trackbot> Created ACTION-611 - Share transform testcases with the group [on Simon Fraser - due 2014-02-04].
  1161. # [20:18] <sgalineau> tab: so webkit make the siblings intersect in their own space then flatten
  1162. # [20:18] <sgalineau> smfr: the spec currently explains it using '3d rendering context' established by preserve-3d
  1163. # [20:19] <sgalineau> smfr: it says such elements can intersect with each other based on z-depth (not document z-index)
  1164. # [20:19] <sgalineau> smfr: so sometimes elements are a 3d rendering context, otherwise they're not
  1165. # [20:19] <sgalineau> smfr: instead I'd like to say that every element is in a 3d rendering context but sometimes it's only one element deep
  1166. # [20:19] <sgalineau> smfr: similar to stacking contexts
  1167. # [20:20] <sgalineau> dbaron: I thought i understood until we compared to stacking contexts...
  1168. # [20:20] <sgalineau> smfr: today you're sometimes in a 3d rendering context, sometimes you're not
  1169. # [20:20] <sgalineau> smfr: whereas with css contexts, all elements belong to a stacking context
  1170. # [20:21] <sgalineau> dbaron: the default with stacking contexts is to not make a new one; it sounds like with 3d rendering contexts the default would be to make a new one?
  1171. # [20:21] <sgalineau> smfr: I think I'm proposing to change that also
  1172. # [20:21] <sgalineau> smfr: now I'm considering that transform-style:flat creates a 3d rendering context
  1173. # [20:22] <sgalineau> smfr: preserve-3d extends this context through the element
  1174. # [20:22] <sgalineau> smfr: I'm proposing to transform-style: auto as an initial value instead of the current 'flat'
  1175. # [20:23] <sgalineau> smfr: if you have two elements with 3d transforms; parent has preserve-3d. its ancestor is flat
  1176. # [20:23] <sgalineau> smfr: the spec is ambiguous as to how/whether elements inserted above those child elements can cause flattening
  1177. # [20:24] <sgalineau> dbaron: the spec says this is containing-block based
  1178. # [20:24] <sgalineau> smfr: right. so it wasn't clear whether stacking contexts or containing blocks were involved
  1179. # [20:24] <sgalineau> smfr: the reason for 'auto' makes the determination of 3d rendering context unambiguous
  1180. # [20:26] <sgalineau> smfr: some things cause flattening like opacity, filters….if an element has a 2d or 3d transforms and transform-style:auto then it should be flattened
  1181. # [20:27] <sgalineau> dbaron: I'm trying to understand how this works with the various z-ordering rules that require various things to interleave
  1182. # [20:28] <sgalineau> dbaron: before this only things that established a stacking context could be preserve-3d
  1183. # [20:28] <sgalineau> dbaron: if you don't establish a stacking context things can interleave
  1184. # [20:28] <sgalineau> dbaron: I'm not sure what this means in this new model
  1185. # [20:28] <sgalineau> smfr: the spec would have to say that the root has transform-style:flat
  1186. # [20:28] <sgalineau> smfr: in the new model, the root creates a 3d rendering context
  1187. # [20:29] <sgalineau> smfr:...
  1188. # [20:30] <sgalineau> smfr: transform--style:flat establishes a 3d rendering context; you render the 3d transform descendants, including intersections...
  1189. # [20:30] <sgalineau> smfr: then you composite those above the untransformed parents...
  1190. # [20:30] <sgalineau> dbaron: suppose the root has another child with a z-index
  1191. # [20:31] <sgalineau> dbaron: so you flatten all the 3d stuff and render it with infinite z-index in that stacking context?
  1192. # [20:31] <sgalineau> smfr: I think so
  1193. # [20:32] * Joins: adenilson (~anonymous@public.cloak)
  1194. # [20:32] <sgalineau> smfr: when you have neg z-index, it renders behind…in this model, 3d descendants don't intersect with the plane of what creates the 3d rendering context....
  1195. # [20:32] <sgalineau> smfr: I don't think there is a way that z-index can trump the 3d rendering contexts
  1196. # [20:32] <sgalineau> dbaron: I agree
  1197. # [20:32] <sgalineau> dbaron: it would be great to have a write-up of this
  1198. # [20:32] <sgalineau> smfr: I have one in draft form, with test cases
  1199. # [20:33] <sgalineau> dirk: this fixes a lot of issues we currently have in the spec
  1200. # [20:33] <sgalineau> dbaron: I think the intersection of this with stacking contexts sounds OK
  1201. # [20:34] <sgalineau> dbaron: what this means is that in the default case, if you specify a 3d transform on one thing in the doc and nothing else, then this thing is above everything in the document
  1202. # [20:34] <sgalineau> smfr: yes
  1203. # [20:34] <sgalineau> dbaron: it seems kind of reasonable. but is it web compatible?
  1204. # [20:35] <sgalineau> dbaron: I'd like to hear from our transform experts...
  1205. # [20:35] <sgalineau> dbaron: i'm worried about compat but compat is also messy right now in this area
  1206. # [20:35] <sgalineau> smfr: i think this model helps explain perspective as well i.e. it doesn't cross 3d rendering context boundaries
  1207. # [20:36] <sgalineau> dirk: i agree we want more people to check out the proposal
  1208. # [20:36] <sgalineau> dirk: over email
  1209. # [20:36] <sgalineau> dbaron: yes
  1210. # [20:36] <sgalineau> smfr: I will send the proposal to www-style
  1211. # [20:37] <sgalineau> plinss: I'm a bit about the interaction with z-index...
  1212. # [20:37] <sgalineau> plinss: could we rationalize the two models?
  1213. # [20:39] <sgalineau> Bert wonders whether flattening is necessary
  1214. # [20:39] <sgalineau> dbaron, smfr, dirk: a bunch of things require it
  1215. # [20:39] <sgalineau> Bert: it is hard to explain transform-style
  1216. # [20:39] <sgalineau> smfr: this will help explain it.
  1217. # [20:39] <sgalineau> chris: you'll be able to say it's like stacking contexts!
  1218. # [20:40] * Joins: smfr (~smfr@public.cloak)
  1219. # [20:41] <sgalineau> ACTION smfr to send update to mailing list
  1220. # [20:41] * trackbot is creating a new ACTION.
  1221. # [20:41] <trackbot> Created ACTION-612 - Send update to mailing list [on Simon Fraser - due 2014-02-04].
  1222. # [20:41] <sgalineau> smfr: based on feedback I'll update the ED
  1223. # [20:41] * Quits: Rossen__ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
  1224. # [20:41] <sgalineau> smfr, dirk: no other issues to discuss
  1225. # [20:41] <krit> http://dev.w3.org/csswg/css-transforms/#issues-index
  1226. # [20:43] <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2012Jul/0450.html
  1227. # [20:43] <fantasai> ScribeNick: fantasai
  1228. # [20:43] <fantasai> Topic: Display Module Revisited
  1229. # [20:44] <fantasai> TabAtkins: Wanted to discuss fantasai's run-in model, and whether to integrate it into Display module
  1230. # [20:44] <fantasai> TabAtkins summarizes the model
  1231. # [20:44] <fantasai> (see mail above)
  1232. # [20:44] <fantasai> foo <runin>bar</runin>
  1233. # [20:44] <fantasai> creates a block boundary between foo and bar
  1234. # [20:45] <fantasai> TabAtkins: It's a remarkably simple model, and solves every problem we've had with run-ins, I believe.
  1235. # [20:45] * liam thinks the mail looks sane and helpful
  1236. # [20:45] <fantasai> fantasai: bz did raise some issues, but solveable by defining things more precisely
  1237. # [20:46] <fantasai> dbaron: Any interesting things wrt placeholders inside run-in?
  1238. # [20:46] <fantasai> dbaron: The whether things run in is purely computable at box-tree generation time? No layout effect at all?
  1239. # [20:46] <fantasai> TabAtkins: Yes
  1240. # [20:46] <fantasai> TabAtkins: Some box-tree mangling, but no layout
  1241. # [20:46] <fantasai> SteveZ: So inline, but create a new block if needed
  1242. # [20:47] <fantasai> TabAtkins: or merge into next block if needed
  1243. # [20:47] <fantasai> RESOLVED: Add fantasai's run-in model to Display Model, with clarifications / fixes needed to solve bzbarsky's issues
  1244. # [20:47] <fantasai> TabAtkins: Also, I would like to publish FPWD
  1245. # [20:47] <fantasai> http://dev.w3.org/csswg/css-display-3/
  1246. # [20:48] <fantasai> SimonSapin: Where does run-in fit into this module?
  1247. # [20:48] <fantasai> TabAtkins: It's a display-outside value, like inline-level
  1248. # [20:48] <fantasai> SimonSapin: Doesn't affect display-inside?
  1249. # [20:48] <fantasai> TabAtkins: Not at all
  1250. # [20:49] <fantasai> dbaron asks for clarification on how the shorthand handles omitted values
  1251. # [20:50] <fantasai> ACTION TabAtkins clarify how omitted values are handled for display shorthand (and other shorthands he might've forgotten to handle)
  1252. # [20:50] * trackbot is creating a new ACTION.
  1253. # [20:50] <trackbot> Created ACTION-613 - Clarify how omitted values are handled for display shorthand (and other shorthands he might've forgotten to handle) [on Tab Atkins Jr. - due 2014-02-04].
  1254. # [20:50] <fantasai> SimonSapin: What are longhands for 'display'?
  1255. # [20:51] <fantasai> fantasai: display-inside, display-outside, display-decoration
  1256. # [20:51] <fantasai> TabAtkins: Yes, need to specify that they get reset
  1257. # [20:51] <fantasai> dbaron: display shorthand should be more clear about what happens with values listed twice
  1258. # [20:51] <fantasai> dbaron: e.g. flex is both a value for 'display' and also 'display-inside', how is it interpreted
  1259. # [20:52] <fantasai> TabAtkins: Yes, I can be much clearer about that
  1260. # [20:52] <fantasai> florian: Does this model make sense for authors and others who don't have a deep mental model of how this all works?
  1261. # [20:52] <fantasai> TabAtkins: The main motivation is to separate out display: none, the rest is just making things easier
  1262. # [20:54] <fantasai> dbaron: I'm ok with publishing
  1263. # [20:54] <fantasai> RESOLVED: FPWD Display Module
  1264. # [20:54] <fantasai> SimonSapin: display-inside: auto;, says some cases element acts as normal. Should also specify what is the computed value
  1265. # [20:55] <TabAtkins> (the computed value is still "auto")
  1266. # [20:55] <fantasai> <br type=lunch>
  1267. # [20:58] * Quits: koji (~koji@public.cloak) (Client closed connection)
  1268. # [20:59] * Joins: koji (~koji@public.cloak)
  1269. # [20:59] * Quits: florian (~Adium@public.cloak) ("Leaving.")
  1270. # [21:01] * Joins: koji_ (~koji@public.cloak)
  1271. # [21:01] * Quits: koji (~koji@public.cloak) (Client closed connection)
  1272. # [21:13] * Quits: koji_ (~koji@public.cloak) (Client closed connection)
  1273. # [21:13] * Joins: koji (~koji@public.cloak)
  1274. # [21:20] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
  1275. # [21:23] * Joins: florian (~Adium@public.cloak)
  1276. # [21:28] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
  1277. # [21:28] * leaverou_away is now known as leaverou
  1278. # [21:29] * Joins: stakagi (~stakagi@public.cloak)
  1279. # [21:35] * Joins: glenn (~gadams@public.cloak)
  1280. # [21:38] * leaverou is now known as leaverou_away
  1281. # [21:42] * leaverou_away is now known as leaverou
  1282. # [21:46] * Joins: koji (~koji@public.cloak)
  1283. # [21:57] * Quits: florian (~Adium@public.cloak) ("Leaving.")
  1284. # [22:05] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
  1285. # [22:06] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
  1286. # [22:06] * Joins: emalasky (~Adium@public.cloak)
  1287. # [22:10] * Joins: emalasky1 (~Adium@public.cloak)
  1288. # [22:10] * Quits: emalasky (~Adium@public.cloak) (Client closed connection)
  1289. # [22:10] * leaverou is now known as leaverou_away
  1290. # [22:10] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
  1291. # [22:11] * leaverou_away is now known as leaverou
  1292. # [22:14] <smfr> hi leaverou!
  1293. # [22:15] <leaverou> hi smfr !!
  1294. # [22:15] <ChrisL> hi lea, how was sunny africa?
  1295. # [22:15] <leaverou> I'm still in Africa :)
  1296. # [22:15] <ChrisL> s/was/is
  1297. # [22:15] <leaverou> going back on Sunday
  1298. # [22:15] <leaverou> it's great!! Different than anywhere else I've ever been to
  1299. # [22:16] <smfr> leaverou: we were talking about a 9-piece image function yday
  1300. # [22:16] <ChrisL> life's a beach and then you code
  1301. # [22:16] <smfr> leaverou: not much support, and a call for use cases
  1302. # [22:16] <smfr> leaverou: so if you have use cases, could you share them somehow?
  1303. # [22:16] <leaverou> smfr: you mean for 9 slice scaling?
  1304. # [22:16] <ChrisL> call for use cases that aren't borders
  1305. # [22:16] <smfr> leaverou: right
  1306. # [22:16] <leaverou> hmm I think I've come across some, but can't remember them off the top of my head right now :/
  1307. # [22:17] <smfr> main comment on things like button backgrounds was "why can't you use user border image?"
  1308. # [22:18] <leaverou> what about masking?
  1309. # [22:18] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
  1310. # [22:18] <leaverou> like, if you were able to 9-slice-scale any image, you could use it for masking too
  1311. # [22:19] <leaverou> which you can't flexibly do with border-image
  1312. # [22:19] <smfr> this came up in the context of masking
  1313. # [22:19] <smfr> do we remove mask-box in favor of some mythical future image slicing function
  1314. # [22:20] * Joins: Rossen__ (~Rossen@public.cloak)
  1315. # [22:21] * Rossen__ is now known as Rossen_f2f
  1316. # [22:21] <leaverou> that doesn't seem very wise when we already have implementations of mask-box
  1317. # [22:21] <leaverou> we can always have the image slicing function in addition
  1318. # [22:22] <TabAtkins> leaverou: Main issue with usign it for masking is that you need the "outset" ability that border-image has, but that's nonsense for normal images.
  1319. # [22:22] <TabAtkins> Because normal images dont' extend outside of their bounds.
  1320. # [22:22] <TabAtkins> ScribeNick: TabAtkins
  1321. # [22:22] * Joins: florian (~Adium@public.cloak)
  1322. # [22:23] <TabAtkins> Topic: Fragmentation
  1323. # [22:23] <TabAtkins> fantasai: Main issue is element vs box vs fragment.
  1324. # [22:23] <smfr> http://dev.w3.org/csswg/css-break/
  1325. # [22:23] <TabAtkins> fantasai: Dirk posted some issues about hwo the spec is confusing.
  1326. # [22:23] <TabAtkins> fantasai: We have three things that need names right now.
  1327. # [22:24] <TabAtkins> fantasai: 1) thing in source document that has a tagname/etc
  1328. # [22:24] <TabAtkins> fantasai: 2) abstract layout object that is maybe associated with (1). Often 1 per (1), sometimes 2+ or 0 per.
  1329. # [22:24] <TabAtkins> fantasai: So far in CSS, never more than 2 per.
  1330. # [22:25] <TabAtkins> fantasai: And it has properties, like 'width'.
  1331. # [22:25] <TabAtkins> fantasai: 3) pieces of (2) that are rectangular after fragmentation.
  1332. # [22:26] <TabAtkins> dbaron: If you're display:none, you have (1) but no (2).
  1333. # [22:26] <TabAtkins> dbaron: If you're display:table, you have a single (1) but two (2)s - table box and table container box.
  1334. # [22:27] * Joins: stakagi (~stakagi@public.cloak)
  1335. # [22:27] <TabAtkins> dbaron: Depending on how you interpret block-in-inline-splitting-the-inlines, there might be more than 2 (2)s per (1).
  1336. # [22:28] <TabAtkins> fantasai: Currently we call (1) an element, (2) a box, and (3) a fragment, or box fragment.
  1337. # [22:28] <TabAtkins> fantasai: If anyone wants something else, propose it.
  1338. # [22:28] <TabAtkins> SimonSapin: I don't think we have an issue for (1). It's called an "element" in DOM and Selectors too.
  1339. # [22:28] <TabAtkins> SimonSapin: The issue is with "box" - we sometimes use it when we mean (3).
  1340. # [22:31] <TabAtkins> fantasai: [goes through another element/box/fragment example]
  1341. # [22:34] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
  1342. # [22:34] <TabAtkins> fantasai: CSS 2.1 uses "element" and "box" interchangeably to refer to all of these.
  1343. # [22:34] <TabAtkins> fantasai: Or at least, "element" for (1) and (2), and "box" for (2) and (3) (and sometimes (1)).
  1344. # [22:34] * Joins: sgalineau (~sgalineau@public.cloak)
  1345. # [22:35] * Quits: sgalineau (~sgalineau@public.cloak) (sgalineau)
  1346. # [22:35] * Joins: sgalinea_ (~sgalineau@public.cloak)
  1347. # [22:35] <TabAtkins> fantasai: We're trying to replace all of this by writing CSS3 specs.
  1348. # [22:36] * glazou we need "fragmented pseudo-elemental boxes" I think...
  1349. # [22:37] * Ms2ger except tables, and stuff
  1350. # [22:38] * astearns fragmepseudelemtainers
  1351. # [22:38] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
  1352. # [22:39] <TabAtkins> dbaron: One thing that confused people is that "box" may not be rectangular.
  1353. # [22:40] <dbaron> (SteveZ proposes "unresolved formatting object"; ChrisL proposes "universal formatting object")
  1354. # [22:41] <dbaron> Bert: Can "box has property" be a shorthand for "element has property"?
  1355. # [22:41] <TabAtkins> Bert: In 2.1, we want to say that boxes have properties. Is this true?
  1356. # [22:41] <dbaron> Tab, fantasai: yes! Also anonymous boxes need that.
  1357. # [22:41] <TabAtkins> fantasai: Yes, we agreed on that a while ago. Anonymous boxes definitely have properties.
  1358. # [22:41] <TabAtkins> Bert: Is the box structure always a tree?
  1359. # [22:41] <TabAtkins> fantasai: Yes.
  1360. # [22:41] <dbaron> 林
  1361. # [22:42] <ChrisL> grove
  1362. # [22:42] <TabAtkins> Bert: What about margin boxes? They're not in the same tree as the elements.
  1363. # [22:42] <smfr> box -> package
  1364. # [22:42] <TabAtkins> fantasai: They're in a separate tree.
  1365. # [22:42] <TabAtkins> SimonSapin: Paged Media also has a terminology problem with "page box".
  1366. # [22:42] <TabAtkins> SimonSapin: For each page, there's a root box, which contains the root boxes, and the box for the page content.
  1367. # [22:43] <TabAtkins> SimonSapin: Someone we say "page box" for the root box, sometimes for the content box.
  1368. # [22:43] <TabAtkins> fantasai: So, I thought we had an agreement several years ago regarding terminology, which is what's in the Fragmentation spec.
  1369. # [22:43] <TabAtkins> fantasai: But Dirk said he's confused.
  1370. # [22:43] * Joins: rhauck (~Adium@public.cloak)
  1371. # [22:44] <TabAtkins> Rossen_: And hopefully we make this the last time we talk about this.
  1372. # [22:44] <TabAtkins> shepazu: I think it would be valuable for everyone involved to have a very clear explanation fo this written in a spec.
  1373. # [22:45] <TabAtkins> fantasai: I think we could handle this between Display and Fragmentation.
  1374. # [22:45] <TabAtkins> TabAtkins: Yeah, I can take fantasai's explanation/diagram and put it in Display.
  1375. # [22:46] <TabAtkins> krit: So can we resolve to keep these terms?
  1376. # [22:47] <TabAtkins> shepazu: And resolve to put a good explanation of these terms somewhere?
  1377. # [22:48] * sgalinea_ is happy with almost any word except 'fragmentainer'
  1378. # [22:49] <glazou> let's absolutize the fragmentainers
  1379. # [22:49] <TabAtkins> Bert: I'd rather have "box" mean "rectangular".
  1380. # [22:50] <ChrisL> http://www.flickr.com/photos/50612995@N02/6418083471/
  1381. # [22:50] <TabAtkins> florian: I'm confused by "region box". If it's none of those, we shouldn't use the existing words.
  1382. # [22:51] <TabAtkins> krit: Why not use "box" for "fragmentainer"?
  1383. # [22:51] <TabAtkins> fantasai: Because not all boxes are fragmentainers.
  1384. # [22:51] <TabAtkins> plinss: Why not call it "fragmenter"?
  1385. # [22:51] * dauwhe there has to be a joke about breaker boxes here somewhere, but I can't find it.
  1386. # [22:53] <TabAtkins> RESOLVED: use the terminology "element", "box", and "fragment"
  1387. # [22:53] * liam was just reviewing page boxes and viewports this morning, as it happens, comparing XSL-FO to css page
  1388. # [22:55] <TabAtkins> RESOLVED: put Elika's explanation of element/box/fragment distinction in Display and Fragmentation.
  1389. # [22:55] * dauwhe liam: could FO help with how to define pages and margin boxes in relation to elements, boxes, and fragments?
  1390. # [22:57] * dauwhe padding bochs, margin bochs...
  1391. # [22:57] <dbaron> dbaron: 4 wrenches: content box, padding box, border box, margin box
  1392. # [22:57] <dbaron> dbaron: could use * edge, * rectangle
  1393. # [22:57] * liam suspects page-viewport-area wouldn't go down too well
  1394. # [22:58] * dauwhe liam: true.
  1395. # [22:58] <dbaron> SimonSapin: * area
  1396. # [22:58] * tantek recommends a field trip to nearest The Container Store
  1397. # [22:58] * liam link - http://www.w3.org/TR/xsl11/#fo_simple-page-master - there's a diagram a little way down.
  1398. # [22:59] * sgalinea_ wants to see tantek fragmenting boxes at The Container Store
  1399. # [22:59] * tantek sgalineau we can practice box-sizing
  1400. # [22:59] <ChrisL> page-viewport-area? why not generator-of-sets-of-page-viewport-areas?
  1401. # [22:59] <TabAtkins> RESOLVED: Don't use "element", "box", or "fragment" in new terms that aren't elements, boxes, or fragments. Where possible, convert old terminology accordingly as well.
  1402. # [23:00] <liam> because it isn't that.
  1403. # [23:00] * tantek wonders what is a box
  1404. # [23:00] * tantek … compared to a block
  1405. # [23:01] * sgalinea_ thought a block was the thing that says where the boxes of the next element lay out by default
  1406. # [23:01] <TabAtkins> fantasai: So, let's say we have a large border-radius on a box, and it's fragmented partway through the curve.
  1407. # [23:02] <TabAtkins> fantasai: Do we keep the curve sliced across the fragment edge, or do we "correct" the edges in one fragment to connect to the box edge.
  1408. # [23:02] <TabAtkins> smfr: I think graphical slice is right - it'll keep the relationship with background.
  1409. # [23:02] <TabAtkins> fantasai: Yeah, probably.
  1410. # [23:03] <TabAtkins> krit: WK does that. FF "corrects" the border-radius.
  1411. # [23:03] <TabAtkins> dbaron: Mats Palmgren wrote some patches to do the slicing behavior, it hasn't landed yet.
  1412. # [23:04] <TabAtkins> RESOLVED: border-radius should get sliced across fragments, maintaining unfragmented geometry.
  1413. # [23:05] <fantasai> Clarify that for variable-widthf ragments, this is handled like for bg images
  1414. # [23:06] <TabAtkins> fantasai: If box fragments have different widths/heights, each piece draws its portion fo the bg, assuming the whole element has the same width as the fragment's piece.
  1415. # [23:06] <TabAtkins> fantasai: [is just quoting from the spec]
  1416. # [23:07] <fantasai> http://dev.w3.org/csswg/css-break/#joining-boxes
  1417. # [23:07] <florian> "piece" should be "fragment"
  1418. # [23:07] <TabAtkins> krit: What about the height?
  1419. # [23:07] <TabAtkins> fantasai: You lay out the box and fragment.
  1420. # [23:08] <TabAtkins> krit: Oh, so you sum the height of the fragments, and use that?
  1421. # [23:08] <TabAtkins> fantasai: Yeah. Backgrounds and borders are drawn after layout, so that's fine.
  1422. # [23:08] <TabAtkins> fantasai: But Shapes are done before/during layout, which might be a problem.
  1423. # [23:09] <TabAtkins> krit: If you take a fragment with the largest width, this'll be your "reference box" for general layout...
  1424. # [23:09] <TabAtkins> fantasai: No.
  1425. # [23:09] <TabAtkins> fantasai: This only doesn't work if you have an image with an aspect-ratio, where the height of the image depends on the width of the box.
  1426. # [23:09] <TabAtkins> fantasai: So in each fragment the image's progress changes, it's not monotonic.
  1427. # [23:10] <TabAtkins> fantasai: So you have to figure out the image's height, and use that through the entire tiling process.
  1428. # [23:10] <TabAtkins> fantasai: We use the width of the widest fragment for this, to disambiguate.
  1429. # [23:10] <TabAtkins> fantasai: So if you want an SVG image to stretch across the entire box, that'll work even if you fragment into different sizes.
  1430. # [23:10] <TabAtkins> fantasai: It'll be stretched/squished in some fragments, but it'll work.
  1431. # [23:10] <TabAtkins> krit: The spec seems to be unclear on this, it seems to say two different things about height.
  1432. # [23:11] <TabAtkins> krit: So I'd like more detail.
  1433. # [23:11] <TabAtkins> krit: Just make sure that it's really explicit.
  1434. # [23:12] * leaverou is now known as leaverou_away
  1435. # [23:13] <TabAtkins> krit: Another issue.
  1436. # [23:13] <TabAtkins> krit: Transform-origin is relative to border-box.
  1437. # [23:13] <TabAtkins> krit: So it's changed in each fragment.
  1438. # [23:15] <TabAtkins> krit: But if something overflows, and the *overflowing content* gets fragmented, what's the transform-origin in that stuff?
  1439. # [23:16] <TabAtkins> dbaron: The spec isn't clear, but I thought we'd agreed to do a single origin, based on the union of the fragments.
  1440. # [23:16] <TabAtkins> [confusion over whether the union is the unfragmented box, or the bounding box of the fragments]
  1441. # [23:16] <TabAtkins> krit: In Tucson, we resolved to do transform origin per fragment.
  1442. # [23:17] <TabAtkins> fantasai: The question was whether you transform first and then fragment, or fragment first and then transform.
  1443. # [23:17] * sgalinea_ thought we punted on transforms of inlines due to their fragmentation. This seems complicated for similar reasons...
  1444. # [23:18] <TabAtkins> fantasai: But I dont' think we specifically talked about transform origin.
  1445. # [23:18] <TabAtkins> Rossen_: I think it's more natural to do origin per fragment.
  1446. # [23:18] <TabAtkins> dbaron: I've seen people want to transform inlines, and if it gets split across lines, to rotate as a whole, rather than per-line.
  1447. # [23:19] <TabAtkins> krit: WK just does visual slicing right now.
  1448. # [23:21] <TabAtkins> [I think dbaron said that he wants to do a single transform-origin in the unfragmented coordinate space of the box]
  1449. # [23:21] <dbaron> yes..
  1450. # [23:22] <TabAtkins> fantasai: (1) take the bounding box of all fragments and use transform origin in that.
  1451. # [23:22] <TabAtkins> TabAtkins: (Which is nonsensical.)
  1452. # [23:22] <dbaron> I believe the spec did at one point say to do (1), though.
  1453. # [23:22] <TabAtkins> fantasai: (2) Each fragment computed origin per its fragment rectangle.
  1454. # [23:22] <smfr> q+
  1455. # [23:22] <TabAtkins> fantasai: (3) Take the composite (unfragmented) box (same as we do for background positioning), find the transform origin in that, then have each fragment use that origin.
  1456. # [23:23] <dbaron> I think (3) produces substantially better results from (2).
  1457. # [23:23] <TabAtkins> szilles: The Tucson minutes are clear that we resolved on per-fragment transforms (and implicitly origins)
  1458. # [23:24] <TabAtkins> dbaron: I don't recall that was what we were discussing, and I may have misunderstood at th etime. I'd object tothat now.
  1459. # [23:25] <TabAtkins> krit: [shows WK doing visual slicing, but FF doing per-fragment transforms]
  1460. # [23:25] <TabAtkins> florian: WK doing option 3, FF doing option 2.
  1461. # [23:25] <TabAtkins> smfr: [something about hyatt]
  1462. # [23:25] <TabAtkins> krit: hyatt agreed that it should be per border-box, and each column fragment gets its own border box
  1463. # [23:26] <TabAtkins> smfr: I think authors transforming fragmented content are crazy anyway.
  1464. # [23:26] <TabAtkins> smfr: The whole reason we punted on inlines was to avoid this issue.
  1465. # [23:27] <dbaron> dbaron: I take back what I said earlier; I'm ok with doing option (2).
  1466. # [23:27] <smfr> smfr: should box-decoration-break affect this behavior?
  1467. # [23:27] <TabAtkins> TabAtkins: So with option (2), what happens with the overflowing content in the original example?
  1468. # [23:27] <smfr> [people say no]
  1469. # [23:28] <dbaron> (Which, looking at http://lists.w3.org/Archives/Public/www-style/2013Feb/0472.html , Is what we resolved in Tucson.)
  1470. # [23:28] <TabAtkins> krit: Mailing list explanation is that the overflowing fragment effectively has a 0-height box at the start of its fragmenting.
  1471. # [23:29] <krit> http://jsfiddle.net/WLByL/
  1472. # [23:29] <TabAtkins> florian: And we have agreement that the overflowing content fragments?
  1473. # [23:29] <TabAtkins> TabAtkins: Yeah, we have browsers doing that.
  1474. # [23:30] <TabAtkins> plinss: I'm not sure about the fragmented overflow.
  1475. # [23:30] <TabAtkins> plinss: If an element creates two fragments, then when it overflows, that overflow should just extend from that second fragment.
  1476. # [23:30] <TabAtkins> plinss: It can't go to the third column, because there's no third fragment.
  1477. # [23:31] <TabAtkins> plinss: Thus, if we want overflow to go in the third column, then by definition we've created a third fragment.
  1478. # [23:31] <TabAtkins> florian: I don't find that multicol defines block-direction overflow
  1479. # [23:31] <TabAtkins> plinss: Doesn't surprise me at all.
  1480. # [23:31] <TabAtkins> plinss: So something needs to define this.
  1481. # [23:33] * Quits: koji (~koji@public.cloak) (Client closed connection)
  1482. # [23:33] * Joins: koji (~koji@public.cloak)
  1483. # [23:33] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
  1484. # [23:33] <TabAtkins> astearns: Note that column balancing uses the height of the overflowing stuff too.
  1485. # [23:34] <TabAtkins> TabAtkins: That's fine; the third fragment can still be zero height. The balancing algo would just refer to the height of the overflow of each fragment, rather than to the height of each fragment.
  1486. # [23:34] <TabAtkins> florian: Why does column balancing use the height of the overflow?
  1487. # [23:34] <TabAtkins> astearns: I can't explain it. It makes no sense to me. I just observe that behavior.
  1488. # [23:35] * Quits: koji (~koji@public.cloak) (Client closed connection)
  1489. # [23:36] * Joins: koji (~koji@public.cloak)
  1490. # [23:36] * Joins: stakagi (~stakagi@public.cloak)
  1491. # [23:36] <fantasai> The reason is that many pages are created just from abspos elements, which means the entire page overflows the zero-height root.
  1492. # [23:37] <fantasai> We still want to print all of that, so the overflow creates pages.
  1493. # [23:37] <fantasai> If it creates pages, it should also create columns.
  1494. # [23:37] <fantasai> We want columns and pages to behave the same way.
  1495. # [23:37] <fantasai> "overflowing overflow is still overflow"
  1496. # [23:38] <fantasai> ?^: Fragmentation is a way of handling overflow.
  1497. # [23:40] <TabAtkins> RESOLVED: Overflow that breaks into a new fragment container does so by forcing its container to generate an additional fragment.
  1498. # [23:40] <fantasai> s/fragment/fragmentainer/
  1499. # [23:40] <smfr> q-
  1500. # [23:40] <dbaron> peterl: zero height or width depending on overflow direction
  1501. # [23:40] <TabAtkins> fantasai, no, that's not an accurate regex.
  1502. # [23:41] * fantasai doesn't understand the resolution then
  1503. # [23:41] <astearns> I want to loop back on shape serialization at some point
  1504. # [23:41] <fantasai> Topic: Flexbox
  1505. # [23:41] <fantasai> TabAtkins: There's an issue in Flexbox where it doesn't interact well with animation in certain cases
  1506. # [23:42] <fantasai> TabAtkins: e.g. start with inflexible items, then try to animate an item to flex: 1
  1507. # [23:42] <fantasai> TabAtkins: the item snaps from inflexible to taking all the free-space immediately
  1508. # [23:42] <fantasai> TabAtkins: Same thing for shrinking; it's discontinuous between 0 and non-0
  1509. # [23:43] <fantasai> TabAtkins: To change it I made a small tweak to flex algorithm, which afaict makes zero difference to all existing cases where sum of flexes is either zero or is 1 or greater
  1510. # [23:43] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
  1511. # [23:43] <fantasai> TabAtkins: but is continuous between 0 and 1
  1512. # [23:43] <fantasai> TabAtkins: dholbert agrees with the problem and the rough solution to the algorithm
  1513. # [23:44] <fantasai> TabAtkins: If anyone has opinions on that, or have an implementation, please review
  1514. # [23:44] <fantasai> TabAtkins: There's another issue, but we don't understand it well yet
  1515. # [23:44] <fantasai> file:///home/fantasai/w3c/csswg/css-flexbox/issues-cr-2012.html#issue-23
  1516. # [23:45] <fantasai> er
  1517. # [23:45] <fantasai> TabAtkins: dholbert thinks Chrome's behavior is more sensible than Firefox's in this case. We haven't quite figured this out yet
  1518. # [23:45] <fantasai> TabAtkins: So won't bring it up now
  1519. # [23:47] <fantasai> TabAtkins: Also have issue of min-size of flex items
  1520. # [23:47] <fantasai> fantasai: Rossen and I did some interesting testing
  1521. # [23:47] <fantasai> fantasai: IE does what Alex proposed -- min-size of min-content, except when overflow is scrolling
  1522. # [23:47] <fantasai> TabAtkins: Ok... I will talk to our implementers
  1523. # [23:47] <fantasai> TabAtkins: I *think* we can make the change, because doesn't affect [...]
  1524. # [23:48] <fantasai> fantasai: <br> element issue
  1525. # [23:48] <fantasai> file:///home/fantasai/w3c/csswg/css-flexbox/issues-cr-2012.html#issue-28
  1526. # [23:48] * fantasai needs to stop loading her local copy
  1527. # [23:49] <fantasai> TabAtkins: Issue comes up when creating anonymous flex items
  1528. # [23:49] * dbaron waits to start using whiteboard markers on tab's fancy computer-glasses
  1529. # [23:49] <fantasai> TabAtkins: Flex item creation splits things on element boundaries: each child element becomes a flex item, and runs of text between get wrapped in anonymous flex item
  1530. # [23:50] <fantasai> TabAtkins: e.g. <flexbox>foo <em></em> bar</flexbox> creates 3 flex items
  1531. # [23:50] <fantasai> TabAtkins: However, if you replace <em> with <br>, then it's all one flex item
  1532. # [23:50] <fantasai> TabAtkins: In chrome it's because <br> is treated kindof like text
  1533. # [23:51] <fantasai> dbaron: We do this for <br>, but also for some MathML stuff
  1534. # [23:51] <fantasai> dbaron: There is a rule for Flexbox that conversions that happen for computed value of display
  1535. # [23:51] <fantasai> dbaron: Inlines that are children of a flexbox have their computed display changed to block
  1536. # [23:51] <fantasai> dbaron: So that span there is display: block
  1537. # [23:51] <fantasai> dbaron: Then code comes over that does this
  1538. # [23:51] <fantasai> dbaron: It runs over what should go into an anonymous frame
  1539. # [23:52] <fantasai> dbaron: by using a test of "does this participate in inline layout?"
  1540. # [23:52] <fantasai> dbaron: span with display : block doesn't
  1541. # [23:52] <fantasai> dbaron: but <br> does
  1542. # [23:52] <fantasai> dbaron: I believe the same is true for some MathML elements
  1543. # [23:52] <fantasai> SteveZ: Doesn't <br> start a new block?
  1544. # [23:53] <fantasai> TabAtkins: <br> is weird goo
  1545. # [23:53] <fantasai> plinss: Logically behaves same as page break, line break, whatever
  1546. # [23:53] <fantasai> plinss: Like having a line-break-after property on it
  1547. # [23:54] <fantasai> plinss: <br> is an element. Should get a box. Should be an element with a line-break-before element
  1548. # [23:54] <fantasai> SimonSapin: Can we remove the magic from <br> and spec it?
  1549. # [23:54] <fantasai> florian: Is it an element?
  1550. # [23:54] <fantasai> plinss, Tab: yes, it's an element in the DOM
  1551. # [23:54] <fantasai> dbaron: It gets its own box, it's just an interesting sort of box. :)
  1552. # [23:54] <fantasai> TabAtkins: Firefox, for example, will honor 'display: none'. Chrome doesn't
  1553. # [23:54] <SimonSapin> HTML says br { content: '\A'; white-space: pre; }
  1554. # [23:55] * Joins: stakagi (~stakagi@public.cloak)
  1555. # [23:55] <fantasai> dauwhe: We use display: none on <br> a lot
  1556. # [23:55] <fantasai> TabAtkins: Ok, we somehow need to figure out that <br> works in this way...
  1557. # [23:56] <fantasai> dbaron: I'm not saying our behavior is desireable
  1558. # [23:56] <fantasai> fantasai: What else do we use inline slurping for?
  1559. # [23:56] <fantasai> dbaron: block-in-inline splitting, maybe?
  1560. # [23:56] <fantasai> TabAtkins: I guess, would you want to change so that <br> becomes a flex item?
  1561. # [23:56] <fantasai> dbaron: I'd be fine with that if it makes more sense
  1562. # [23:56] <fantasai> ...
  1563. # [23:56] * dauwhe <br class="large-print-edition"/>to force a line break in one format, set to display: none in other formats.
  1564. # [23:57] * sgalinea_ http://img2.imagesbn.com/p/9780425264607_p0_v1_s260x420.JPG
  1565. # [23:57] <fantasai> dbaron: If in between foo and bar you have a span that is floating or absolutely positioned, it's out-of-flow and doesn't count
  1566. # [23:57] <fantasai> TabAtkins: So right now flexbox and reality don't agree
  1567. # [23:57] <fantasai> TabAtkins: Also, we need to define what <br> does
  1568. # [23:58] <fantasai> ...
  1569. # [23:58] <fantasai> fantasai: what are reasons why HTML's definition doesn't work?
  1570. # [23:59] <fantasai> plinss: If we make it CSS-defined, then changing display or other properties has to be respected
  1571. # [23:59] <fantasai> fantasai: Spec for <br> will require lots of testing. <br> has lots of weirdness. I don't remember what they all are, just remember it had a lot of weirdness
  1572. # Session Close: Wed Jan 29 00:00:00 2014

The end :)