/irc-logs / w3c / #css / 2011-06-04 / end

Options:

  1. # Session Start: Sat Jun 04 00:00:00 2011
  2. # Session Ident: #css
  3. # [00:00] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
  4. # [00:07] * Joins: arno (arno@192.150.10.200)
  5. # [00:09] * Quits: karl (karlcow@128.30.54.58) (Client exited)
  6. # [00:14] * Joins: karl (karlcow@128.30.54.58)
  7. # [00:28] * Quits: plinss (plinss@61.214.117.102) (Ping timeout)
  8. # [01:03] * Joins: szilles (chatzilla@219.127.245.113)
  9. # [01:17] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
  10. # [01:31] * Quits: nmccully (nmccully@124.144.75.245) (Quit: Colloquy for iPad - http://colloquy.mobi)
  11. # [01:32] * Joins: nmccully (nmccully@124.144.75.245)
  12. # [01:36] * Quits: konaya (konaya@83.250.39.172) (Quit: Leaving)
  13. # [01:46] * Joins: plinss (plinss@125.207.177.35)
  14. # [01:54] * Joins: dbaron (dbaron@125.207.177.35)
  15. # [01:55] * Joins: hober (ted@125.207.177.35)
  16. # [02:07] * Joins: jdaggett (jdaggett@125.207.177.35)
  17. # [02:11] * Joins: danield (danield@125.207.177.35)
  18. # [02:11] * Joins: smfr (smfr@17.203.14.12)
  19. # [02:13] * Joins: shans (qw3birc@128.30.52.28)
  20. # [02:14] <hober> ScribeNick: hober
  21. # [02:14] <hober> Topic: CSS3 Fonts
  22. # [02:15] * Joins: vhardy (vhardy@125.207.177.35)
  23. # [02:15] <hober> jdaggett: Two issues: same-origin restriction & super/sub-script handling
  24. # [02:15] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#same-origin-restriction
  25. # [02:15] <hober> jdaggett: starting with the same-origin restriction
  26. # [02:15] * Joins: sylvaing (sylvaing@125.207.177.35)
  27. # [02:17] <hober> jdaggett: came out of discussion in fonts/woff group
  28. # [02:17] <hober> jdaggett: description of SOR used to be in an appendix of the css3 fonts spec
  29. # [02:18] <hober> jdaggett: fonts group's charter calls for making SOR a requirement
  30. # [02:18] <hober> jdaggett: now we have a split between woff spec & css3 fonts spec
  31. # [02:18] <hober> jdaggett: objection from apple that it doesn't make sense for SOR to be tied to the format
  32. # [02:18] <hober> jdaggett: we came to conclusion that it makes sense for this to live in the css3 fonts spec
  33. # [02:19] <hober> jdaggett: the text has been moved into the body from the appendix
  34. # [02:19] * Joins: TabAtkins (tabatkins@125.207.177.35)
  35. # [02:19] <hober> jdaggett: open issues: what should the default behavior be
  36. # [02:19] <hober> ff & ie? restrict by default, allow CORS for relaxing
  37. # [02:19] <hober> jdaggett: annevk thinks this is weird
  38. # [02:20] <hober> jdaggett: inconsistent with other parts of web platform
  39. # [02:20] <hober> jdaggett: problems with data leakage
  40. # [02:20] <hober> jdaggett: e.g. canvas' dirty flag
  41. # [02:20] <hober> jdaggett: [describes example of embedding security problem on whiteboard]
  42. # [02:22] * Joins: murakami (murakami@118.154.209.3)
  43. # [02:22] <hober> jdaggett: these issues are beyond fonts & images
  44. # [02:23] <hober> jdaggett: there are even issues if script can see the response code from certain cross-origin images
  45. # [02:23] <hober> jdaggett: we have normative prose (section 4.8.1)
  46. # [02:23] <hober> jdaggett: annevk doesn't like the default restriction
  47. # [02:24] <hober> jdaggett: he'd prefer no restriction by default & users would need to explicitly set an exception
  48. # [02:24] <hober> sylvaing: annevk's first objection is that CORS isn't the right tech for this
  49. # [02:24] * Joins: florian (florianr@125.207.177.35)
  50. # [02:24] <hober> jdaggett: [as annevk] the web has evolved because people can link willy-nilly
  51. # [02:24] <hober> florian: why solve this for fonts only?
  52. # [02:25] <hober> Bert: fonts are different
  53. # [02:25] <jdaggett> siteA --> siteB gimme xxx
  54. # [02:25] <jdaggett> siteA <-- here you go (no CORS header)
  55. # [02:25] <jdaggett> UA sees no CORS header, doesn't download resource
  56. # [02:25] <hober> jdaggett: how does the existing text in 4.8.1 work?
  57. # [02:25] * Parts: florian (florianr@125.207.177.35)
  58. # [02:25] <jdaggett> siteA --> siteB gimme xxx
  59. # [02:25] <jdaggett> siteA <-- here you go (CORS header: siteB use ok -or- all sites ok)
  60. # [02:25] <jdaggett> UA sees CORS header, check for a match, downloads resource
  61. # [02:26] * Joins: florian (florianr@125.207.177.35)
  62. # [02:26] <hober> jdaggett: instead, annevk's proposal:
  63. # [02:27] <jdaggett> siteA --> siteB gimme xxx
  64. # [02:27] <florian> link to where annevk discusses this: http://annevankesteren.nl/2011/02/from-origin
  65. # [02:27] <jdaggett> siteA <-- siteB here you go (no From-Origin header)
  66. # [02:27] <jdaggett> UA sees no From-Origin restriction, <uses default behavior>
  67. # [02:27] <hober> jdaggett: explicit restriction instead of explicit relaxation
  68. # [02:27] <jdaggett> siteA --> siteB gimme xxx
  69. # [02:27] <jdaggett> siteA <-- siteB here you go (From-Origin: no cross-linking please)
  70. # [02:27] <jdaggett> UA sees From-Origin restriction, doesn't download resource
  71. # [02:28] * Joins: szilles (chatzilla@125.207.177.35)
  72. # [02:28] <hober> jdaggett: this could be used for images, scripts, wider set of resource types
  73. # [02:28] <hober> jdaggett: both ff & ie have implemented the cors approach
  74. # [02:28] <hober> jdaggett: others haven't impled eithet
  75. # [02:28] <hober> s/eithet/either/
  76. # [02:28] <hober> jdaggett: consensus that some kind of mechanism is a good thing
  77. # [02:29] <hober> jdaggett: don't want to allow cross-origin font linking by default
  78. # [02:29] <hober> jdaggett: the cors approach hits the 80/20 point for fonts
  79. # [02:29] <hober> jdaggett: vs. the from-origin proposal, which requires you to raise a flag to get the typical behavior
  80. # [02:29] <hober> florian: yes for fonts, but for all resources, from-origin hits the default correctly
  81. # [02:30] <hober> jdaggett: should the default for fonts be different?
  82. # [02:30] <hober> jdaggett: our (ff) security guys think all new resource types should default to SOR
  83. # [02:31] <hober> TabAtkins: [describes attack that extracts font data out of a tainted <canvas>]
  84. # [02:31] <hober> Bert: the problem is the javascript, not the resources
  85. # [02:31] <hober> TabAtkins: then you wouldn't be able to do anything with fonts in javascript
  86. # [02:31] <hober> TabAtkins: e.g. canvas
  87. # [02:31] <hober> dbaron: or figure out the width of text
  88. # [02:31] <hober> Bert: there should be 2 kinds of things on the web: programs and documents
  89. # [02:31] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
  90. # [02:32] <hober> Bert: text/html is document, maybe application/html could have these restrictions
  91. # [02:32] <hober> jdaggett: existing content
  92. # [02:32] <hober> Bert: the power of the web is transclusion
  93. # [02:33] <hober> jdaggett: we can't get there from here
  94. # [02:34] <hober> TabAtkins: [describes <iframe> v. <img> differences]
  95. # [02:34] <hober> Bert: fonts are different
  96. # [02:34] <hober> Bert: you can't right click on a font
  97. # [02:34] <hober> Bert: this is why we have woff
  98. # [02:34] <hober> Bert: need to say "this font is for this document"
  99. # [02:34] <hober> jdaggett sylvaing: that's not what woff does
  100. # [02:35] <hober> [eot v. woff, root string disagreement]
  101. # [02:35] <hober> plinss: </tangent>
  102. # [02:35] <hober> jdaggett: still contention about mechanism & default
  103. # [02:35] <hober> jdaggett: this is not a css-only discussion
  104. # [02:35] <hober> jdaggett: is a web-wide discussion
  105. # [02:36] <hober> jdaggett doesn't want to have things in css3 fonts that will block it moving forward
  106. # [02:36] <hober> jdaggett: has labelled what impls are doing & put wording that captures where this will change if consensus changes
  107. # [02:36] <hober> jdaggett: what the consensus will be isn't quite clear
  108. # [02:36] <hober> jdaggett: marked this as risk
  109. # [02:37] <hober> jdaggett: does that suffice to move this forward? i don't know
  110. # [02:37] <hober> sylvaing: from-origin is broader, will be more controversial
  111. # [02:37] <hober> jdaggett: so it'll take longer
  112. # [02:37] <hober> florian: opera prefers annevk's position, but isn't locked into it
  113. # [02:37] <hober> jdaggett: annevk prefers a mechanism to work across resource types and the default should be no restriction
  114. # [02:38] <hober> jdaggett: howcome is ambivalent here
  115. # [02:38] <hober> sylvaing: any resources loaded by src: in @font-face, not about fonts v. other resources
  116. # [02:39] <hober> fantasai: so fonts loaded in <img src> would behave differently
  117. # [02:39] <hober> sylvaing: yes
  118. # [02:39] <hober> jdaggett: we can't go back and change the default
  119. # [02:40] <hober> jdaggett: wanted to make people aware of the wording here that this is at risk etc.
  120. # [02:40] <hober> plinss: bottom line is we're not making the restriction decision here in csswg
  121. # [02:40] <hober> plinss: you want to decouple so we can advance
  122. # [02:40] <hober> jdaggett: yes
  123. # [02:41] <hober> jdaggett: delicate negotiations with the web fonts group
  124. # [02:42] <hober> Bert: not for csswg, because fonts can be embedded via xsl, etc.
  125. # [02:42] <hober> hober: we define @font-face, so we define restriction for that embedding point
  126. # [02:42] <hober> everyone: [we didn't develop woff for origin restriction reasons]
  127. # [02:43] <hober> Bert: sounds like annevk's proposal is better
  128. # [02:43] <hober> Bert: what is the reason for woff if all fonts are restricted?
  129. # [02:44] <hober> jdaggett: existing font formats weren't for the web, etc., needed to be a web font format
  130. # [02:44] <hober> szilles: woff had 2 requirements: transmission prevent dropping into client os, 2. can post on web without anyone willy-nilly being able to use it
  131. # [02:45] <hober> jdaggett: @font-face is here, so restriction has to be here
  132. # [02:45] <hober> jdaggett: web fonts group has the format
  133. # [02:45] <hober> web fonts charter isn't woff-specific
  134. # [02:46] <hober> plinss: bert's point is that we & svg etc should use same mechanism
  135. # [02:47] <hober> plinss: we shouldn't be deciding the restriction
  136. # [02:48] <hober> plinss: is there an actionable item here?
  137. # [02:48] <hober> jdaggett: proposals have to be detailed and go to web fonts group & css group
  138. # [02:48] <hober> florian: opera is satisfied with this wording
  139. # [02:48] <hober> florian: we'd welcome clearly-defined alternatives
  140. # [02:49] <hober> florian: this is good enough, allows for alternative proposals
  141. # [02:49] <hober> fantasai: we can't go to cr with this
  142. # [02:49] <hober> jdaggett: we can mark it at risk
  143. # [02:50] <hober> Bert: what about non-http urls, we need to still work
  144. # [02:50] <hober> plinss: yes, this is very http-specific
  145. # [02:50] * Joins: szilles (chatzilla@125.207.177.35)
  146. # [02:51] <hober> szilles: it's not woff pushing it back on us, they were conviniced this is acceptable solution to one of their problems
  147. # [02:51] <hober> szilles: if we push back, woff group would have to start over
  148. # [02:52] <hober> jdaggett: [doesn't want to create other thing that we can't reference normatively]
  149. # [02:52] <hober> jdaggett: put it here, mark it at risk, and go on
  150. # [02:53] <fantasai> s/fantasai: so fonts loaded in <img src> would behave differently/fantasai: so images loaded via @font-face would be restricted by default/
  151. # [02:53] <hober> jdaggett: by the time we have impls, test suite, etc. this will be worked out one way or another
  152. # [02:53] * hober fantasai: ahh, sorry
  153. # [02:54] <hober> jdaggett: font EULAs say you need to do referrer checking when ua doesn't support [sor mechanism]
  154. # [02:54] <hober> fantasai: if user turns off Referer header, can't get fonts
  155. # [02:55] <hober> jdaggett: post detailed proposals, not just "i want this"
  156. # [02:55] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#vertical-position-prop
  157. # [02:55] <hober> jdaggett: Next issue: dealing with superscripts and subscripts
  158. # [02:55] <hober> 'vertical-position' property
  159. # [02:56] <hober> jdaggett: lets you turn on super/sub-script variants in fonts
  160. # [02:56] <hober> jdaggett: within the font, variants of the number 2, say, that fit in normal em box
  161. # [02:56] <hober> jdaggett: by using this, line box doesn't change, etc.
  162. # [02:56] <hober> jdaggett: currently, baseline shifts and font size changes
  163. # [02:56] <hober> jdaggett: so you see changes in the line box
  164. # [02:57] <hober> jdaggett: doesn't look good
  165. # [02:57] <hober> jdaggett: when you shrink down the normal-size glyph, strokes shrink too, so super/sub scripts don't have same typographic color as surrounding text
  166. # [02:58] <hober> jdaggett: 'vertical-position' addresses lots of cases [footnotes, etc.]
  167. # [02:58] <hober> jdaggett: doesn't address putting images in <sup> or nesting other sorts of things in <sup>/<sub>
  168. # [02:59] <hober> jdaggett: superscripts&subscripts are semantic, so can't be treated like other font variants
  169. # [02:59] <hober> szilles: we've already discussed this; what's the new information?
  170. # [03:00] <hober> jdaggett: if I use 'vertical-position: superscript' for s^2 and look at content in an older browser, I see s2
  171. # [03:00] <hober> jdaggett: authors need a way to ensure the right thing happens
  172. # [03:00] <hober> jdaggett: the current spec makes 'vertical-position' a shorthand
  173. # [03:01] <hober> jdaggett: [reads from section 6.4 on how fallback works]]
  174. # [03:01] <hober> jdaggett: allows you to make styles for <sub> and <sup> that work well in older UAs
  175. # [03:01] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Apr/0391.html
  176. # [03:02] <hober> fantasai: describes her proposal
  177. # [03:02] <hober> fantasai: new property 'magic'
  178. # [03:02] <hober> [fantasai & dbaron's replacement for vertical-position]
  179. # [03:02] <hober> magic: none | super | sub
  180. # [03:02] <hober> fantasai: [describes proposal in email jdaggett linked above]
  181. # [03:04] <hober> fantasai: if magic matches vertical-align, then computed font size is set by multiplying size ratio to parent's font size & we ignore specified font size
  182. # [03:04] <hober> szilles: you're setting the font size to the size that's in the font
  183. # [03:04] <hober> fantasai: yes
  184. # [03:04] <hober> dbaron: let's explain the goals of this approach
  185. # [03:05] <hober> fantasai: we're trying to handle basic super/sub scripts with special glyphs if available, & synthesizing if they're not available
  186. # [03:06] <hober> fantasai: second goal: handle atomic inlines & nested super/subscripts, what happens if you have a span with changed font size inside these thigns
  187. # [03:06] <hober> fantasai: we're not handling mixing special glyphs with anything else
  188. # [03:06] <hober> fantasai: if font metrics are off, this will look ugly
  189. # [03:06] <hober> dbaron: that's true of all proposals that use font's special glyphs
  190. # [03:06] <hober> jdaggett: adobe ships same same metrics in all of their fonts
  191. # [03:07] <hober> jdaggett: 99% use case, you'll (probably) be ok
  192. # [03:07] <hober> fantasai: also don't handle using lengths or percentages for vertical align & mixing with this feature
  193. # [03:08] <hober> fantasai: won't get the right glyphs if you try to position the super/sub-script differently than what the font does
  194. # [03:08] <hober> Bert: [expresses scepticism]
  195. # [03:08] <hober> jdaggett: this could be a case for @supports
  196. # [03:09] <hober> jdaggett: if someone's explicitly enabling this, we document that it works this way, so they're aware of the tradeoffs
  197. # [03:10] <hober> dbaron: fantasai & my proposal makes this more complex, but allows ua stylesheet to have this on by default
  198. # [03:10] <hober> fantasai: might not look good when some glyphs have this and others don't
  199. # [03:11] <hober> plinss: anything but the special glyphs will draw in synthesized state
  200. # [03:11] <hober> fantasai: yes
  201. # [03:11] <hober> szilles: is this opentype feature turned on by default?
  202. # [03:11] <hober> jdaggett: we're not talking about unicode code points
  203. # [03:12] <hober> plinss: if you're using those code points, you're not using <sup> or <sub>
  204. # [03:13] <hober> Bert: you have super, sub, and none, but why no 'yes'?
  205. # [03:13] <hober> Bert: turn it on from root element
  206. # [03:13] <hober> jdaggett: vertical-align controls the baseline, if other properties affect this, this makes me uncomfortable
  207. # [03:14] <hober> jdaggett: behavior of this feature dependent on this other value
  208. # [03:14] <hober> szilles: we've got other such cases
  209. # [03:14] <hober> szilles: property-refining properties are common
  210. # [03:15] <hober> plinss: it's a per-glyph undo of what vertical-align does
  211. # [03:15] <hober> fantasai: won't change the line box if you have the right glyphs
  212. # [03:15] <hober> jdaggett: font metrics aren't correct
  213. # [03:16] * Quits: smfr (smfr@17.203.14.12) (Quit: smfr)
  214. # [03:16] <hober> [plinss fantasai: talk re: vertical-align causes baseline change in even empty line boxes]
  215. # [03:17] <hober> plinss: as soon as you start nesting, you want to affect the line height
  216. # [03:17] <hober> jdaggett: divergence between opentype spec and what fonts actually do
  217. # [03:17] <hober> jdaggett: i want to set this up for people who know how to use it, without breaking existing content
  218. # [03:18] <hober> Bert: what happens if font has some of the special glyphs but not others
  219. # [03:18] <hober> jdaggett: you'll synthesize
  220. # [03:18] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
  221. # [03:18] <hober> jdaggett: color won't match, stroke width will be different in synthesized case
  222. # [03:19] <hober> szilles: if you don't have all the glyphs, synthesize everything
  223. # [03:19] <hober> plinss: if you don't have all the glyphs, pretend you have none
  224. # [03:20] <hober> fantasai: allow the UA to be smarter, but don't require complex analysis
  225. # [03:21] <hober> jdaggett: wants to work on impl & experiment
  226. # [03:21] <hober> jdaggett: expects to see things we're not anticipating
  227. # [03:21] <hober> fantasai: that's a reasonable thing to do
  228. # [03:21] <hober> jdaggett: same fallback issue as with vertical text
  229. # [03:22] <hober> szilles: put a note in that points to the font feature with an appropriate warning
  230. # [03:22] <hober> fantasai: we can do that in the line box spec
  231. # [03:23] <hober> szilles: was strongly in favor of fantasai/dbaron's proposal, but sees point of @supports approach
  232. # [03:23] <hober> fantasai: author of stylesheet might not know what's in the content
  233. # [03:24] <hober> szilles: italic or bold isn't a problem
  234. # [03:24] <hober> Bert: magic property seems short; can it be keyword(s) of font-variant property?
  235. # [03:24] <hober> fantasai: might make sense
  236. # [03:25] <hober> jdaggett: tricky because font-variant is shorthand (reset problem)
  237. # [03:25] <hober> szilles: can we put it in @font-face?
  238. # [03:26] <hober> florian: "this font supports being magic; use it if you can"
  239. # [03:26] <hober> fantasai: not tied to the choice of the font
  240. # [03:27] <hober> fantasai: can we link to this email from the spec?
  241. # [03:27] <hober> jdaggett: would prefer note that says there are alternate proposals
  242. # [03:27] <hober> jdaggett: i have to try to impl this before we can do more
  243. # [03:28] <hober> fantasai: what other open issues are in this spec?
  244. # [03:28] <hober> fantasai: maybe we should defer this issue so spec can reach lc
  245. # [03:28] * Joins: szilles (chatzilla@125.207.177.35)
  246. # [03:28] <hober> jdaggett: there are a number of issues
  247. # [03:28] <hober> jdaggett: is tightening the wording based on impl feedback
  248. # [03:29] <hober> jdaggett: wanted to make people aware of the issue & hear other ideas
  249. # [03:29] <hober> fantasai: i want to have this findable from the spec
  250. # [03:30] <hober> Topic: Flexbox update
  251. # [03:30] <hober> alexmog: in ie10 we have fairly complete impl of spec
  252. # [03:31] <hober> alexmog: for ie10 we won't have the new syntax
  253. # [03:31] <hober> alexmog: don't want two prefixed syntaxes
  254. # [03:31] <hober> alexmog: the timing isn't right for ie10
  255. # [03:32] <hober> alexmog: for new spec, we want to see what other browsers are doing
  256. # [03:32] <hober> alexmog: we need to have multiline back in spec
  257. # [03:32] <hober> TabAtkins: will be bringing multiline back
  258. # [03:32] <hober> TabAtkins: webkit is working on impl of the new spec
  259. # [03:32] <hober> TabAtkins: will see that in the near future
  260. # [03:33] <hober> alexmog: if the spec stayed in the old syntax, we could drop prefix; but we don't need to reopen that
  261. # [03:33] <hober> dbaron: we [ff] also have someone working on the new spec
  262. # [03:33] <hober> sylvaing: any issues, dbaron?
  263. # [03:33] <hober> dbaron: haven't heard any, don't know how far along things are
  264. # [03:34] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
  265. # [03:34] <hober> alexmog: we can map most of new syntax to old impl; biggest difference is using the flex function notation
  266. # [03:35] <hober> alexmog: would require parser change
  267. # [03:35] <hober> alexmog: different alignment too
  268. # [03:36] <hober> alexmog hopes feedback from other impls will help next version of spec stabilize
  269. # [03:37] <hober> sylvaing: flex notation, alignment modes, multiline--want to see feedback from other implementors
  270. # [03:37] <hober> plinss: anything else?
  271. # [03:38] <hober> alexmog: whats' the eta?
  272. # [03:39] <hober> TabAtkins: wants to publish a new wd sometime in the next 80 years
  273. # [03:39] <hober> s/in the next 80 years/by the end of june/
  274. # [03:39] <hober> TabAtkins: hoepfully ready for lc soon after that
  275. # [03:40] <hober> <br duration="15min" />
  276. # [03:40] * Joins: arronei (arronei@166.205.143.215)
  277. # [03:49] * Quits: plinss (plinss@125.207.177.35) (Quit: plinss)
  278. # [03:51] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
  279. # [03:52] * Joins: plinss (plinss@125.207.177.35)
  280. # [03:55] * Quits: nmccully (nmccully@124.144.75.245) (Client exited)
  281. # [03:58] * Joins: boblet (Adium@122.27.197.150)
  282. # [04:02] <TabAtkins> ScribeNick: TabAtkins
  283. # [04:03] * Joins: szilles (chatzilla@125.207.177.35)
  284. # [04:04] <TabAtkins> Topic: CSS Regions
  285. # [04:05] <TabAtkins> vhardy: content-order is a float right now, which people say are odd - z-index is an integer, frex.
  286. # [04:05] <TabAtkins> vhardy: We did it that way so that you could, say, insert between two consecutive items.
  287. # [04:05] <TabAtkins> vhardy: But the precedent means we should just switch to <integer>s.
  288. # [04:06] <TabAtkins> Bert: Is there any way to avoid using numbers at all?
  289. # [04:07] * arronei wishes it was easier to drive and read the logs at the same time.
  290. # [04:07] <TabAtkins> szilles: The regions aren't inherently ordered - they just pull whatever's in the stream.
  291. # [04:07] <TabAtkins> Bert: Why not push to a stream?
  292. # [04:08] <TabAtkins> vhardy: We thought of that model, but given that many regions aren't named, it becomes more difficult. It seemed simpler to name the flow and have regions pull.
  293. # [04:09] <TabAtkins> vhardy: We sketched out some ideas for an @region-chain rule where you'd list the sequence of regions.
  294. # [04:09] * Joins: alexmog (alexmog@125.207.177.35)
  295. # [04:09] <TabAtkins> Bert: That's similar to what I did with Template - a property that listed a chain of cells that content flowed across in order.
  296. # [04:09] * Joins: nmccully (nmccully@124.144.75.245)
  297. # [04:09] <TabAtkins> szilles: That fails somewhat in paged media, where you can have multiple copies of cells with the same name.
  298. # [04:11] <TabAtkins> vhardy: I also had an idea to have a region-name property that would name a region, but it didn't seem quite harmonious.
  299. # [04:12] <TabAtkins> vhardy: Can we agree on moving it to <integer> for now?
  300. # [04:12] <TabAtkins> [agreement]
  301. # [04:13] <TabAtkins> vhardy: Another syntactic issue is that the 'flow' property uses <string> for value, and is referred to by a string.
  302. # [04:14] <TabAtkins> vhardy: So the question is should that just be an ident?
  303. # [04:15] <TabAtkins> szilles: Didn't we have a similar discussion in february?
  304. # [04:15] <arronei> Ident +1
  305. # [04:15] <TabAtkins> TabAtkins: That was for fonts, which are a problem because their names come form outside CSS. It's okay to do idents in author-defined syntax.
  306. # [04:16] <TabAtkins> plinss: But you do sometimes shoot yourself in the foot when you use idents, because it makes it hard to add new language-defined idents in the future, as you might collide.
  307. # [04:17] <TabAtkins> plinss: If it's guarded as a functional value, it's a bit better.
  308. # [04:18] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
  309. # [04:19] <TabAtkins> szilles: I'd be afraid of it being a quoted string in 'flow' and unquoted in a function in 'content'.
  310. # [04:19] <TabAtkins> hober: Yeah, not doing that. Consistency.
  311. # [04:20] <arronei> Yeah but I don't want a flow to have a string like this. "{}{]}##<"
  312. # [04:20] <TabAtkins> TabAtkins: I think that we can work our way around the problem later if we just restrict the 'flow' to a single author-defined ident for now.
  313. # [04:20] <TabAtkins> plinss: We'll need to do something like a dummy keyword so we can have a distinguished syntax for CSS-defined values, which is dumb.
  314. # [04:21] <TabAtkins> TabAtkins: Another option is to make 'flow' take a to(<ident>) function for now, which pairs with the from(<ident>) function in 'content'.
  315. # [04:21] <TabAtkins> szilles: That sounds good.
  316. # [04:22] <TabAtkins> Bert: I'm not sure we need from(), and so to() seems unnecessary too.
  317. # [04:22] <TabAtkins> szilles: You definitely need from(), to disintiguish it from other values in 'content'.
  318. # [04:23] <arronei> Functions removes the issues if you want to add keywords later.
  319. # [04:23] <TabAtkins> Bert: I'd need to familiarize myself with the syntax more, but 'content' may not be the right place.
  320. # [04:24] <TabAtkins> alexmog: Given that 'content' sets the contents to something other than the natural contents, it seems appropriate to use it here.
  321. # [04:24] <TabAtkins> plinss: Potentially we could use another property, and still get the ability to add things to the flow's contents by using the 'contents' keyword (defined in CSS3 Content).
  322. # [04:25] <TabAtkins> szilles: But that's another issue.
  323. # [04:25] * Joins: szilles (chatzilla@125.207.177.35)
  324. # [04:26] <TabAtkins> [chatter about 'content' and potential 'flow-from']
  325. # [04:27] <TabAtkins> szilles: Wouldn't that mean I need to set two properties?
  326. # [04:28] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
  327. # [04:28] <TabAtkins> plinss: No, setting 'flow-from' would just change the meaning of "content:auto" to pull from the region. And then potentially, when "content:contents" is defined, that can combine.
  328. # [04:29] <TabAtkins> alexmog: We're afraid of author-defined idents colliding with future CSS-defined keywords, right?
  329. # [04:30] <TabAtkins> alexmog: I think from the OM model pov I'd prefer two properties that take strings than something that takes one-off functions.
  330. # [04:31] <arronei> I still prefer content: from(...) for it's simplicity.
  331. # [04:31] <TabAtkins> TabAtkins: Arronei dislikes strings because it becomes easier to write unreadable region names.
  332. # [04:31] <TabAtkins> szilles: You can write unreadable idents too.
  333. # [04:32] <TabAtkins> Bert: Can we duplicate flow content across multiple regions?
  334. # [04:32] <arronei> But it's not as easy to do
  335. # [04:32] <TabAtkins> vhardy: That's an issue that was brought up on the mailing list.
  336. # [04:33] * fantasai likes flow: to(foo); content: from(foo);
  337. # [04:34] <TabAtkins> Bert: In previous approaches to this idea we named the flow specifically to allow duplication. Newer approaches like Grid didn't need that.
  338. # [04:34] <TabAtkins> [some difficult-to-understand discussion about being able to omit the name of the flow]
  339. # [04:35] <dbaron> Bert: template is naming regions, but not naming flows
  340. # [04:35] <TabAtkins> [moving it to the list so we can throw down syntax, because everyone's confused]
  341. # [04:35] <TabAtkins> vhardy: Currently there's nothing about selecting the content in a region.
  342. # [04:36] <TabAtkins> vhardy: User selections, that is.
  343. # [04:36] <TabAtkins> dbaron: A single selection usually operates in terms of the DOM.
  344. # [04:37] <TabAtkins> dbaron: Which could be confusing if you select across a region, and end up getting some content elsewhere in the page.
  345. # [04:37] <TabAtkins> dbaron: You could do a more visual-based selection, but no impl does that yet.
  346. # [04:38] <TabAtkins> plinss: I built a box-selection extension for Firefox that auto-computed the ranges.
  347. # [04:39] <TabAtkins> fantasai: Selection is out-of-scope for this module. Right now it's UA-dependent and up to them to come up with good ideas.
  348. # [04:39] <TabAtkins> szilles: What do we do with bidi right now?
  349. # [04:39] <TabAtkins> fantasai: We specify absolutely nothing for that right now.
  350. # [04:39] <TabAtkins> vhardy: Okay, so I'll remove the issue about selection from the spec.
  351. # [04:40] <TabAtkins> vhardy: Next is about the event model.
  352. # [04:40] <TabAtkins> vhardy: Right now there's a section that says event propogation is not modified - it runs on the plain DOM.
  353. # [04:40] <TabAtkins> vhardy: But I've had some requests that you can listen for, say, clicks on a region.
  354. # [04:41] <TabAtkins> TabAtkins: I don't want to think about event propagation being sensitive to exactly when we do style recalc.
  355. # [04:42] <TabAtkins> vhardy: Okay, so we'll keep it DOM-based. Should I remove it entirely, or make it an informative note?
  356. # [04:43] <TabAtkins> TabAtkins: If people have asked you about it, so you should probably keep a note around.
  357. # [04:43] <TabAtkins> Bert: If you're writing an editor, you may want to, say, select a region to put a background on it. How would you do that?
  358. # [04:44] <TabAtkins> TabAtkins: From an interactioni point of view, this is roughly similar to making a bunch of divs and then absposing content to make it look like they're inside the divs. If you click the content, the click fires at it and walks up the dom that way. If you click the area around the content, you'll get the div.
  359. # [04:44] <TabAtkins> szilles: Is there a way to ask an element what region it's in?
  360. # [04:44] <TabAtkins> vhardy: That'll be in the CSSOM section.
  361. # [04:44] <TabAtkins> szilles: That seems to satisfy the rquirement.
  362. # [04:45] <TabAtkins> vhardy: Now, the CSSOM View section.
  363. # [04:45] <TabAtkins> vhardy: It has two parts. The first is the "named flow interface".
  364. # [04:46] <TabAtkins> vhardy: [explains the "named flow interface" section]
  365. # [04:46] <TabAtkins> vhardy: It's meant to allow you to see if the flow fits in the regions that exist.
  366. # [04:46] <TabAtkins> alexmog: Why do you have a "named flow" interface and not just a concept of regions?
  367. # [04:49] <TabAtkins> vhardy: If you only have it on regions, you can only access regions that are actually elements.
  368. # [04:49] <TabAtkins> alexmog: If you want that, then just add elements.
  369. # [04:49] <TabAtkins> szilles: That violates that "css zen garden" school of philosophy.
  370. # [04:50] <TabAtkins> TabAtkins: We can already interact with pseudos in at least some ways via the CSSOM.
  371. # [04:51] <TabAtkins> alexmog: I don't think it's necessary to extend the "Element" concept to pseudos.
  372. # [04:52] <TabAtkins> [...minute overflow]
  373. # [04:52] <TabAtkins> alexmog: It's good to still have an event that tells when a region changes.
  374. # [04:53] <TabAtkins> TabAtkins: Like when a region overflows? Or more like a mutation event for contents in the region?
  375. # [04:54] <TabAtkins> alexmog: When the contents of the region changes.
  376. # [04:54] * Joins: arron (Arron@24.17.123.244)
  377. # [04:54] <TabAtkins> dbaron: What sort of changes do you want to know, exactly?
  378. # [04:54] <TabAtkins> alexmog: Whenever the contents change.
  379. # [04:54] * Quits: arronei (arronei@166.205.143.215) (Quit: Colloquy for iPhone)
  380. # [04:55] <dbaron> dbaron: We already have onresize
  381. # [04:55] <dbaron> TabAtkins: I think what's useful is notification when a region goes into overflow state and notification when a region becomes empty.
  382. # [04:56] <TabAtkins> vhardy: So basically you're saying that you can get X information from a region, and you'd like to be notified about changes in that.
  383. # [04:56] <TabAtkins> alexmog: Yeah.
  384. # [04:57] <TabAtkins> TabAtkins: I'd want to separate the ideas of a "regionEmpty" and "regionOverflow" events from a "regionMutation" event. The former are easy to see the utility of, the latter not so much imo.
  385. # [04:57] <TabAtkins> vhardy: So I can put them all down in the spec for now, and we can see what exactly we want later.
  386. # [04:58] <TabAtkins> vhardy: So next topic, how do we access regions? Through an element, or through the flow?
  387. # [04:59] <TabAtkins> vhardy: So we can stick to the element interface in 4.2 right now, or we go from the Document which returns a NamedFlow abstraction, which gives you access to the list of regions.
  388. # [05:00] <TabAtkins> szilles: I tend to like the last one, because it ties into the Flow concept, which is primary.
  389. # [05:01] <TabAtkins> hober: I don't like th eElement version, because it separates regions into first-class and second-class regions - DOM are first-class, pseudos are second-class.
  390. # [05:02] <TabAtkins> TabAtkins: There really *are* first and second-class, though. Pseudos can't have listeners on them, for example. If we fire "regionEmpty" events, frex, you can only listen for that on DOM elements acting as regions.
  391. # [05:02] * Quits: nmccully (nmccully@124.144.75.245) (Quit: Colloquy for iPad - http://colloquy.mobi)
  392. # [05:02] <TabAtkins> vhardy: I could fire events on the NamedFlow interface instead.
  393. # [05:05] * Joins: nmccully (nmccully@124.144.75.245)
  394. # [05:06] * Quits: nmccully (nmccully@124.144.75.245) (Client exited)
  395. # [05:06] <TabAtkins> TabAtkins: My primary problem is that making pseudos nearly-real gets closer to exposing the transformed formatting structure that CSS exposes into a real tree. So far we've been able to hide that for the most part.
  396. # [05:06] * Joins: nmccully (macnmm@124.144.75.245)
  397. # [05:06] <TabAtkins> szilles: We can just focus on Flows as a concept, rather than pseudos.
  398. # [05:07] * Joins: szilles (chatzilla@125.207.177.35)
  399. # [05:07] <TabAtkins> vhardy: (1) Current spec is minimal functionality for all regions (2) minimal funcitonality for pseudos and full for DOM (3) full functionality for DOM elements, none for pseudos
  400. # [05:07] <TabAtkins> (4) full functionality for both pseudos and DOM
  401. # [05:08] <TabAtkins> vhardy: And this is kind of a requirements discussion.
  402. # [05:08] <TabAtkins> vhardy: I'd prefer 4, even though it's painful.
  403. # [05:09] <TabAtkins> alexmog: I think we should start with DOM and see how far we can go.
  404. # [05:11] <TabAtkins> TabAtkins: I think we'd be okay with functionality for DOM elements, plus a simple way to ask a flow if it's overflowing.
  405. # [05:11] <TabAtkins> TabAtkins: Basically, what's in the spec.
  406. # [05:11] <TabAtkins> alexmog: If you duplicate a flow into multiple views, you can't get a single answer to "is the flow overflowing?".
  407. # [05:12] <TabAtkins> vhardy: Right now multiviews don't exist - they're talked about in an issue.
  408. # [05:12] <TabAtkins> vhardy: So I'll keep it as it is right now, and put in an issue regarding accessing the flow directly.
  409. # [05:12] <TabAtkins> vhardy: Next is about content duplication (multiviews).
  410. # [05:13] <TabAtkins> vhardy: Right now, if you put an element into a flow, it gets displayed once - a region consumes it and then it's not available anymore.
  411. # [05:13] <TabAtkins> vhardy: Someone asked if there's a way to duplicate flow contents.
  412. # [05:14] <TabAtkins> vhardy: It would cause a lot of issues, though, so right now I suggest not doing it.
  413. # [05:14] <TabAtkins> fantasai: Wouldn't this let you do pullquotes?
  414. # [05:15] <TabAtkins> vhardy: From talking to authors, it looks like pullquotes are very rarely the literal content from the document. There are rewordings, elidings, etc. They're really separate content.
  415. # [05:15] <TabAtkins> szilles: Another use-case is ToC.
  416. # [05:15] <TabAtkins> vhardy: For now, Regions is complex enough that I think we should skip it for now.
  417. # [05:15] <TabAtkins> plinss: I think it's appropriate to push it to Regions 2.
  418. # [05:18] <TabAtkins> <br type=lunch duration=1h>
  419. # [05:38] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
  420. # [05:54] * Quits: shans (qw3birc@128.30.52.28) (Ping timeout)
  421. # [05:57] * Joins: arno (arno@208.87.61.227)
  422. # [06:08] * Joins: shans (qw3birc@128.30.52.28)
  423. # [06:18] <fantasai> jdaggett: http://dev.w3.org/csswg/css3-writing-modes/#writing-mode
  424. # [06:18] * Quits: arno (arno@208.87.61.227) (Quit: Leaving.)
  425. # [06:19] <fantasai> ScribeNick: fantasai
  426. # [06:19] <fantasai> Discussion of agenda for this afternoon
  427. # [06:20] <fantasai> Florian: Would like device adaptation, should not take long
  428. # [06:20] <fantasai> Tab: I want variables
  429. # [06:20] <jdaggett> hmmm, that's in an example
  430. # [06:20] <fantasai> that was what we agreed
  431. # [06:20] <fantasai> the normative text is above the two examples
  432. # [06:21] <jdaggett> that wording isn't strong enough
  433. # [06:21] <fantasai> what is not strong enough about it?
  434. # [06:21] <jdaggett> form elements are included in this list
  435. # [06:21] <jdaggett> *normative* wording needs to say this includes form elements
  436. # [06:21] <jdaggett> otherwise you give folks too much weasel room
  437. # [06:21] <fantasai> form elements are either replaced, or they're not
  438. # [06:21] <fantasai> if they're replaced, then that word applies
  439. # [06:22] <fantasai> if they're not, then 'writing-mode' applies because it's CSS layout
  440. # [06:22] <fantasai> where's the gap here?
  441. # [06:22] <jdaggett> well, we already have problems because css sorta affects them, sorta doesn't
  442. # [06:22] <jdaggett> just do the right thing... ;)
  443. # [06:22] <fantasai> dbaron: would like to discuss @supports briefly
  444. # [06:22] <jdaggett> you understand and mean the sentence to mean xyz
  445. # [06:23] <fantasai> Topic: Meeting Scheduling
  446. # [06:23] <fantasai> plinss: Proposal is to possibly add another F2F
  447. # [06:23] <fantasai> dbaron: Feels like we have a lot to do, and have a pretty crammed schedule here
  448. # [06:23] <fantasai> dbaron: Our summer meeting is at the early end, and the next meeting is a shortened meeting at TPAC
  449. # [06:23] <fantasai> dbaron: We have only TPAC for the next 9 months
  450. # [06:24] <fantasai> dbaron: So either we need another meeting, or significantly longer at TPAC
  451. # [06:24] <fantasai> Vincent: Personally propose second meeting, gives us time to work on drafts in between f2f days
  452. # [06:25] <fantasai> some concern about people who have to travel
  453. # [06:25] <fantasai> jdaggett: Can't travel in September
  454. # [06:25] <fantasai> suggestion to do combined fx and css meeting in August
  455. # [06:25] <fantasai> plinss: Missing ppl who likely to have date conflicts
  456. # [06:25] <fantasai> Bert: I have some budget problem, unless I host it myself
  457. # [06:26] <fantasai> plinss: A lot of ppl would have trouble paying for another trip this year
  458. # [06:26] <fantasai> plinss: unless we do Europe or Bay Area
  459. # [06:26] <fantasai> Alex: Could do 3 TPAC days plust another meeting
  460. # [06:26] <fantasai> dbaron: For the 2 TPAC days, we should assume one full day of CSSF2F amount of work
  461. # [06:27] <fantasai> fantasai: Who's got budget constraints
  462. # [06:28] <dbaron> fantasai: Likely options are West Coast or Europe to reduce budget constraints.
  463. # [06:28] <dbaron> fantasai: TPAC is in bay area
  464. # [06:28] <fantasai> Bert, Vincent maybe, Daniel probably, anyone else?
  465. # [06:28] <fantasai> Alex: For some ppl end of year is July 1st
  466. # [06:29] <fantasai> dbaron: Would be nice to know where TPAC and AC will be
  467. # [06:29] <fantasai> plinss: I'm hearing another meeting would be good, and adding a day to TPAC would be good
  468. # [06:30] <fantasai> RESOLVED: Add a day to TPAC
  469. # [06:32] <fantasai> RESOLVED: Try to schedule a meeting in August in probably in Seattle or France
  470. # [06:32] <fantasai> Topic: Device Adaptation
  471. # [06:34] <fantasai> DD: On desktop browsers viewport is same size as the window
  472. # [06:34] <fantasai> DD: On mobile devices, that's not true.
  473. # [06:34] <fantasai> DD: You can force page to lay out at device width or arbitrary width
  474. # [06:35] <fantasai> DD: So the veiwport meta tag is obviously a meta tag
  475. # [06:35] <fantasai> DD: One problem with this currently is it's not completely specified
  476. # [06:35] <fantasai> DD: There isn't a full spec available to the public
  477. # [06:35] * Joins: kojiishi (kojiishi@125.207.177.35)
  478. # [06:35] <fantasai> DD: undefined whether commas or semicolons used, e.g.
  479. # [06:36] <fantasai> DD: If I do this, it's viewable without zooming
  480. # [06:36] <fantasai> DD: The details .. Apple currently
  481. # [06:36] <fantasai> DD: THe width can be in pixels or same as device width
  482. # [06:36] <fantasai> DD: Can also set scale, to not allow user to scale, so it behaves more like native app
  483. # [06:36] <fantasai> DD: but has accessibility problem
  484. # [06:37] <fantasai> DD: This W3C CSS spec CSS Device Adaptation effectively lays out what exists as a CSS specification
  485. # [06:37] <fantasai> DD: Benefit is it's an open spec, also it's not content it's presentation
  486. # [06:37] <fantasai> DD: The syntax of it is ....
  487. # [06:37] <fantasai> jdaggett: What have Safari guys said about this?
  488. # [06:37] <fantasai> plinss: They said the meta tag is a hack and they'd like to get rid of it
  489. # [06:38] <fantasai> DD gives demos
  490. # [06:38] <fantasai> DD: We have prefixed demo in Opera
  491. # [06:38] <fantasai> jdaggett: So what would be the meaning of this for desktop browsers?
  492. # [06:38] <fantasai> DD: Probably nothing
  493. # [06:39] <fantasai> fantasai: where do you draw the line between desktop browser and non-desktop browser?
  494. # [06:39] <fantasai> plinss: I would think that any rules like this could be targetted with media queries
  495. # [06:39] <fantasai> jdaggett: It seems weird that you're implying that a desktop browser would blow these off
  496. # [06:40] <fantasai> DD: So maybe you'd show it at 320px and zoom in
  497. # [06:40] <fantasai> plinss: zooming could be a UI choice
  498. # [06:41] <fantasai> plinss: Might have other reasons to use this, e.g. someone might want to display their page as landscape paged
  499. # [06:41] <fantasai> dbaron: A lot of this is really a hack to get around the fact that vast majority of pages on the Web don't work on mobile the way things were originally specified
  500. # [06:41] <fantasai> dbaron: So they had to come up with this zooming thing
  501. # [06:41] <fantasai> dbaron: viewport meta was designed to allow pages to opt out of that
  502. # [06:42] <fantasai> jdaggett: You're saying that it should be shown ...
  503. # [06:42] <fantasai> ?: That depends on the page design
  504. # [06:44] <fantasai> discussion of designing pages for mobile
  505. # [06:45] <fantasai> jdaggett: I don't think all pages that fit into the idea of designing for 320px
  506. # [06:46] <fantasai> fantasai: Right. But if there's a minimum width beyond which the page design doesn't work, that width should be set as min-width on the root element
  507. # [06:46] <fantasai> fantasai: And then the UA knows to display at minimum at that size and zoom out accordingly.
  508. # [06:46] <fantasai> Florian: The iPhone's zoom and pan model is good for the Web as currently designed.
  509. # [06:47] <fantasai> Florian: You can have a media query and design for the small screen
  510. # [06:47] <fantasai> Florian: But if you don't do that, then pan+zoom is better
  511. # [06:48] <fantasai> plinss: Most of the pages that use this meta tag have different content
  512. # [06:48] <fantasai> plinss: my mobile banking has mobile versions of their pages -- stripped down content
  513. # [06:48] <fantasai> plinss: wikipedia does the same thing
  514. # [06:49] <fantasai> Florian: It's valid to use this
  515. # [06:49] <fantasai> Florian: And it's valid to us min-width as fantasai said
  516. # [06:49] <fantasai> Florian: But one method is in use
  517. # [06:50] <fantasai> plinss: right, I agree with fantasai that honoring the width and height of the root element would be better, but there are a lot of pages that don't do this
  518. # [06:51] <fantasai> DD: If I set the width of the root to 320, then I have all this blank space I scroll aroun din
  519. # [06:51] <fantasai> fantasai: That's kindof stupid then
  520. # [06:51] <fantasai> plinss: That's a bug. If there's nothing to scroll to, don't scroll to it
  521. # [06:52] <fantasai> plinss: If you don't have overflow, you shouldn't scroll to it
  522. # [06:54] <fantasai> ?: Another issue is, if you do set the width of the root element, but you have a long string that sticks out
  523. # [06:54] <fantasai> fantasai: then that's overflowing the ICB. You should be able to scroll to it, but it's outside the ICB.
  524. # [06:54] <fantasai> ...
  525. # [06:54] <fantasai> plinss: I'm concerned about having a zoom control in CSS
  526. # [06:54] <fantasai> DD: So author should not be able to turn off zooming?
  527. # [06:55] <fantasai> plinss: Why should I be *not allowed* to zoom in on a page?
  528. # [06:55] <fantasai> plinss: Designer designed page for my iPhone, but I'm old and I want to make it bigger. Why can't I do that?
  529. # [06:55] <fantasai> ?: First reason is you want to disable zooming gestures from zooming the page to use them for something else
  530. # [06:56] <fantasai> ?: Say you have a webapp inbox that's just a vertical column of elements
  531. # [06:56] <fantasai> ?: If the user is allowed to zoom, and therefore change the width so that they can pan
  532. # [06:56] <fantasai> ?: then that changes the interaction with the app
  533. # [06:56] <fantasai> s/pan/zoom and pan/
  534. # [06:56] <fantasai> plinss: That's a usability issue, that's not something web page authors should be able to dictate
  535. # [06:56] <fantasai> ?: I think web page authors should be able to dictate
  536. # [06:57] <fantasai> Bert: But if they create a page that's unusable...
  537. # [06:57] <fantasai> plinss: Firefox zooms in and out on my desktop. Should I not be able to do that?
  538. # [06:57] <fantasai> dbaron: This is a different notion than the zoom in your desktop firefox
  539. # [06:57] <fantasai> dbaron: Someone could add zoom like in desktop browser to a mobile browser, but this is a different thing.
  540. # [06:58] <fantasai> plinss: Zoom is a UA thing. Not something the web author should be able to override and disable
  541. # [06:58] <fantasai> dbaron: WebApps need the ability on a mobile device to use the gestures that in this default huge-page scenario that are used for other things
  542. # [06:58] <fantasai> plinss: That's not a CSS issue, that's an event model issue
  543. # [06:59] <fantasai> ...
  544. # [06:59] <fantasai> sylvaing: They also want to turn of user-selection, e.g. in a menu in their webapp
  545. # [07:00] <fantasai> Florian: We think the spec is good and needs more review, so we want to do a WD
  546. # [07:00] <fantasai> dbaron: I think you should have something in the spec that answers John's question
  547. # [07:01] <fantasai> dbaron: The question is, what does this do on the desktop browser? (And what's a desktop browser)
  548. # [07:01] <fantasai> Florian: So do we do that as an editor's draft or what?
  549. # [07:01] <fantasai> fantasai: You have two options: address it in the draft, or mark it as an issue.
  550. # [07:02] <fantasai> Bert: 2 questions
  551. # [07:02] <fantasai> Bert: What's interactions of @viewport and @page
  552. # [07:02] <fantasai> Bert: If you put @viewport, can you put @viewport in @media? Say what it means?
  553. # [07:03] <fantasai> fantasai: would it make sense to have the media query in the @viewport directly?
  554. # [07:04] <fantasai> Florian: Question of when you match media queries, before or after processing @viewport
  555. # [07:04] <fantasai> fantasai: Similar to @page. Copy text from @page?
  556. # [07:04] <dbaron> dbaron: I'm not convinced this belongs in CSS; it really seems like a different layer.
  557. # [07:04] <fantasai> Bert: I would throw away pixel-sized viewports. Should never use pixel sizes
  558. # [07:05] <fantasai> ? talks about dashboard widgets
  559. # [07:05] <dbaron> fantasai, I don't see text in css3-page that describes how 'size' and media queries interact.
  560. # [07:05] <fantasai> ACTION: Rune add 3 questions above to draft
  561. # [07:05] * trackbot noticed an ACTION. Trying to create it.
  562. # [07:05] * RRSAgent records action 8
  563. # [07:05] <trackbot> Created ACTION-328 - Add 3 questions above to draft [on Rune Lillesveen - due 2011-06-11].
  564. # [07:06] <fantasai> Bert: I'm fine with publishing if there's red text making it's clear that there are issues
  565. # [07:07] <fantasai> plinss: Yeah, just opening it up for discussion. Might decide not to do this, but need to discuss it
  566. # [07:07] <fantasai> dbaron somewhat concerned about things progressing down REC track just because they're on the REC track even if it's not desired to move down REC track
  567. # [07:08] <fantasai> dbaron: Would like document status to discuss status of the document
  568. # [07:09] <fantasai> fantasai: Problem is there's so much W3C boilerplate in the status section that nobody ever reads it
  569. # [07:09] <fantasai> Topic: Variables and Mixins
  570. # [07:09] <dbaron> <h2>Status of this Document</h2> should have a subsection called <h3>Status of <em>this</em> Document</h3>
  571. # [07:10] <fantasai> plinss: I would like to set a time limit on this discussion
  572. # [07:10] <fantasai> Tab: half-hour
  573. # [07:10] <fantasai> plinss: ok
  574. # [07:11] <fantasai> Tab: This is the draft I have right now.
  575. # [07:11] * Quits: alexmog (alexmog@125.207.177.35) (Connection reset by peer)
  576. # [07:11] <fantasai> Tab: Variables is sth we've talked about for a decade
  577. # [07:11] <dbaron> http://www.xanthir.com/blog/b4AD0
  578. # [07:11] <shans> oh :)
  579. # [07:11] <fantasai> Tab: It's never gotten anywhere unfortunately, but it's more and more necessary as years go by
  580. # [07:12] <fantasai> Tab: Applications keep getting more complex
  581. # [07:12] <fantasai> Tab: CSS include more and more duplication
  582. # [07:12] <fantasai> jdaggett: Don't think this is delayed due to desire to solve problem
  583. # [07:12] <fantasai> jdaggett: Just there's hard problems to solve
  584. # [07:13] <fantasai> Tab: Just want to make sure group wants to work on this
  585. # [07:13] <fantasai> Florian: Not sure that's the universal view
  586. # [07:13] <fantasai> Florian: Variables is a hard problem, but we've solved harder problems before
  587. # [07:13] <fantasai> Florian: It makes things a little more difficult for authors to understand.
  588. # [07:14] <fantasai> Florian: For the big guys, this is not necessary, because you have a backend system that can generate that on the fly
  589. # [07:14] <fantasai> Florian: For small ppl learning CSS from a book, this is likely to go way over their head.
  590. # [07:14] <fantasai> Florian: It gives some convenience, but doesn't allow anything new.
  591. # [07:14] <fantasai> Florian: Things that this simplifies can be done on the server side
  592. # [07:14] <fantasai> Tab: I think your concern about small authors being confused is totally wrong.
  593. # [07:15] <fantasai> Tab: If you're doing minor page of few hundred lines, you won't need this
  594. # [07:15] <fantasai> Florian: But you'll see it anyway
  595. # [07:15] <fantasai> ...
  596. # [07:15] <fantasai> Sylvain: If you think CSS is easy, you're crazy. Cascading and inheritance is hard
  597. # [07:15] <fantasai> ?: Variable declarations are easy to understand.
  598. # [07:15] <fantasai> Tab gives example of modifying a color everywhere.
  599. # [07:16] <fantasai> Alex: We have 3 issues
  600. # [07:16] <fantasai> Alex: 1. There are reasons for variables.
  601. # [07:16] <fantasai> Alex: 2. Hard problems for variables
  602. # [07:16] <fantasai> Alex: 3. What Tab is proposing
  603. # [07:16] <sylvaing> (meaning it's 'crazy' to say CSS is easy until this capability is added)
  604. # [07:17] <fantasai> Bert: Different people may want different things from variables.
  605. # [07:18] <fantasai> fantasai: If you look at a real CSS preprocessor, it does a lot of stuff. I'm concerned about going down that path.
  606. # [07:18] <fantasai> Tab summarizes his proposal.
  607. # [07:18] <fantasai> @var #main-color blue;
  608. # [07:18] <fantasai> s/#/$/
  609. # [07:19] <fantasai> p {
  610. # [07:19] <fantasai> color: $main-color;
  611. # [07:19] <fantasai> background: url(foo) $main-color;
  612. # [07:19] <fantasai> list-style-image: radial-gradient($main-color, $secondary-color);
  613. # [07:19] <fantasai> }
  614. # [07:20] <fantasai> Tab: Not allowed to define cycles, but allowed to use variables wtihin variable declarations
  615. # [07:20] <fantasai> Tab: Variables are global
  616. # [07:20] <fantasai> Tab: last declaration wins
  617. # [07:21] <fantasai> Tab: Not expanded as parse time
  618. # [07:21] <fantasai> Florian:
  619. # [07:21] <fantasai> a = foo
  620. # [07:21] <fantasai> b = a
  621. # [07:21] <fantasai> a = bar
  622. # [07:21] <fantasai> Florian: What's b?
  623. # [07:21] <fantasai> Tab: bar
  624. # [07:22] <fantasai> Alex: What about naming conflicts, e.g. if I import a style sheet that uses the same name I'm using
  625. # [07:23] <fantasai> ?: You want your variable names to be conceptual.
  626. # [07:23] <fantasai> ...
  627. # [07:23] <fantasai> dbaron: One thing ppl wanted with variables was ability to change them dynamically later on from JS
  628. # [07:23] <fantasai> dbaron: If you want that, I don't see how to have the later set overrides the earlier set.
  629. # [07:23] <fantasai> Tab: This is consistent with defining identifiers in an at-rule
  630. # [07:24] <fantasai> Tab: e.g. with #font-face
  631. # [07:24] <fantasai> s/#/@/
  632. # [07:24] <fantasai> jdaggett: This is actually wrong. If you look very carefully, we have a unicode-range.
  633. # [07:24] <fantasai> jdaggett: The presence of that means what you just said is not correct
  634. # [07:24] <fantasai> jdaggett: For a single set of @rules, you can have multiple fonts. You can have multiple @font-face rules
  635. # [07:25] <fantasai> dbaron: @font-face rules are mostly additive, rather than replacing
  636. # [07:25] <fantasai> jdaggett: They will have a computed unicode-range, which is the intersection of the actual unicode-range and the cmap
  637. # [07:26] <fantasai> dbaron: And it also depends on whether the font can be loaded
  638. # [07:26] <fantasai> dbaron: @font-face is the worst possible example you could have picked
  639. # [07:26] <fantasai> Florian: Even though you define how collisions are resolved, you still get them and you reduce the shareability of CSS
  640. # [07:27] <fantasai> Tab: Ok, that I can agree with that. If you're creating a library then you have that issue.
  641. # [07:27] <fantasai> Tab: One way to deal with that is if you're creating a library, prefix your names.
  642. # [07:27] <fantasai> Tab: Another option is a namespacing option
  643. # [07:28] <fantasai> fantasai notes that the CSS Namespaces module could be reused if it came to that...
  644. # [07:28] <fantasai> not that I think we should go there
  645. # [07:29] <fantasai> discussion of other author-defined names in CSS: counter-style, keyframes, etc.
  646. # [07:29] <fantasai> Tab: Having functionality of having variables that can refer to other variables is great
  647. # [07:31] <fantasai> fantasai: do you need that for JS-accessible variable,s or just for macros variables (parse-time substitution)
  648. # [07:31] <fantasai> dbaron: If you have a parse-time substitution mechanism, you have a lot more constraints wrt scoping
  649. # [07:32] <fantasai> dbaron: That requirement slows down how you load and parse style sheet
  650. # [07:32] <fantasai> dbaron: depending on the scoping rules
  651. # [07:32] <fantasai> fantasai: scoping rules in my proposal don't have that problem
  652. # [07:33] <fantasai> Tab: undeclared variables are treated as invalid values until resolved
  653. # [07:33] <fantasai> Tab: Another reason to work this way is you wnat htis out-of-orderness
  654. # [07:33] * Joins: alexmog (alexmog@125.207.177.35)
  655. # [07:33] <fantasai> Tab: CSS works so that you can almost reorder style sheet arbitrarily without changing things.
  656. # [07:33] <fantasai> Tab: Usually resolve things based on specificity, not order
  657. # [07:33] <fantasai> Tab: This trained us to import style sheets in any order, append things to document
  658. # [07:34] <fantasai> Tab: Preserving that with variables
  659. # [07:34] <fantasai> Tab: e.g. throw in corporate styles anywhere in include path of doc, won't affect how things are parsed
  660. # [07:34] <fantasai> dbaron: resolved dynamically
  661. # [07:35] <fantasai> Tab: Covered multiple variables with same name, last one wins
  662. # [07:35] <fantasai> Tab: If you import a style sheet after the doc loaded, it gets processed same way as if they were in from the start
  663. # [07:35] <fantasai> Tab: If you use a variable that's not defined, it's treated as always invalid
  664. # [07:35] <fantasai> Tab gives example
  665. # [07:36] <fantasai> fantasai suggests to make the example use green
  666. # [07:36] <fantasai> Tab: bzbarsky suggested it still be valid, but be ???
  667. # [07:37] <fantasai> ??? = set to the inital state
  668. # [07:39] <fantasai> dbaron: ...
  669. # [07:39] <fantasai> fantasai: p { color: red; } p { color: $foo } should always, always be equivalent to p { color: red; color: $foo; }
  670. # [07:39] <dbaron> I think it's important that "p { color: green} p { color: $foo }" does the same whether $foo is undefined or invalid.
  671. # [07:40] * fantasai agrees with that too
  672. # [07:40] <dbaron> fantasai and others think it's important that p { color: green; color: $foo; } and p { color: green } p { color: $foo } do the same thing.
  673. # [07:40] <fantasai> Tab reviews dependency cycle breaking
  674. # [07:40] <fantasai> @var $foo red;
  675. # [07:41] <fantasai> @var $bar $foo;
  676. # [07:41] <fantasai> @var $foo $bar;
  677. # [07:41] <fantasai> Tab: You would get $foo as red
  678. # [07:41] <fantasai> dbaron: I would rather throw out the whole thing.
  679. # [07:41] <dbaron> throw out $foo rather than use red for $foo
  680. # [07:41] <fantasai> Tab: Ok, crash both variables in the cycle
  681. # [07:42] <dbaron> dbaron: The cycle detection should be after you've parsed all the variables and thrown out previous definitions.
  682. # [07:42] <fantasai> Tab: Some concern about grammar
  683. # [07:43] <fantasai> fantasai: I would prefer using glazou's syntax of var()
  684. # [07:43] <fantasai> fantasai: Clearer that this is being preserved into the CSSOM, that it's only valid in property values. And it doesn't have grammar implications.
  685. # [07:44] <fantasai> Tab: Want to know if we can start doing experimental implementations of this.
  686. # [07:44] <fantasai> fantasai: And you can prefix it if you use functional notation
  687. # [07:45] <fantasai> Tab: Management wants to know if we are approved to work on variables.
  688. # [07:45] <fantasai> Tab: Start work on an editor's draft that could move to WD
  689. # [07:45] <fantasai> dbaron: I don't know if I'm answering your question, but my feeling about this is that I think this is the sanest way to do variables that I've seen so far.
  690. # [07:45] <fantasai> dbaron: Authors want this. I think it's a lot of work. And I think it doesn't let authors do anything that they couldn't do before.
  691. # [07:46] <fantasai> dbaron: Given the amount of work it is, and it doesn't give authors anything really new
  692. # [07:46] <fantasai> dbaron: I would not put this near the top of any priority lists.
  693. # [07:46] <fantasai> Tab: I think while it's not new functionality, we think it adds value, and we'd like to work on it and pressure everyone else to implement it too
  694. # [07:47] <dbaron> Florian: It lets fewer people write CSS faster.
  695. # [07:47] <fantasai> ...
  696. # [07:48] <fantasai> fantasai makes a comment about other ppl's preprocessor stuff being really intelligent and us being the wrong people to work on it
  697. # [07:48] <fantasai> Bert: Could make a Community Group
  698. # [07:48] <fantasai> Tab: ... besides the point ...
  699. # [07:48] <fantasai> Alex talks about priorities of different vendors
  700. # [07:49] <fantasai> Bert: SVG is also working on something liek this, the parameter model
  701. # [07:49] <fantasai> Bert: They have variables that you can inherit from outside the style sheet
  702. # [07:49] * Joins: myakura (myakura@118.111.219.27)
  703. # [07:49] <fantasai> Alex: What Doug has is a superset of that
  704. # [07:49] <fantasai> Tab: They could potentially work together
  705. # [07:49] <fantasai> Alex: Initial values of variables ...
  706. # [07:49] <fantasai> Tab: No problem working together with schepers
  707. # [07:50] <fantasai> jdaggett: I sitll think while it's a good thing to work on it, it could still get to the point that ppl say "on balance, this is not what we should do"
  708. # [07:50] <fantasai> Tab: Looking for explicit acceptance that if I work on this and address issues, it /can/ get to WD.
  709. # [07:51] <fantasai> Florian: I'm not convinced that any variable ssystem can bring more than it costs.
  710. # [07:51] <shepazu_vacation> (I am very flexible about how we get parameters working for both SVG and CSS)
  711. # [07:51] <fantasai> Tab: Are you ok with me pursuing this in WD form until we can decide whether it's worth doing?
  712. # [07:51] <fantasai> Florian: Not authorized to say.
  713. # [07:51] <fantasai> Florian: I look at this, it's too much and not enough.
  714. # [07:52] <fantasai> ... JS ...
  715. # [07:52] <fantasai> jdaggett: That's a good point. Maybe modifications to the CSSOM is a better use of time.
  716. # [07:52] <fantasai> talk of other important things
  717. # [07:53] <fantasai> Alex: It's a stake in the ground, when we talk about variables, this is what variables mean.
  718. # [07:53] <fantasai> Alex: If you have more workable proposal, then we'll consider it, but here's what we have so far, this is what we mean by CSS Variables, and that's orthogonal to whether we implement this now.
  719. # [07:53] <fantasai> plinss: Let me try to sum up here.
  720. # [07:54] <fantasai> plinss: So I think it's fair for you to start working on an official editor's draft so we have a place to gather all this information.
  721. # [07:54] <fantasai> plinss: I don't think anybody can guarantee it's ever going to go anywhere.
  722. # [07:54] <fantasai> plinss: Might be where we gather all the data and then kill it.
  723. # [07:54] <fantasai> plinss: As as I write a style sheet, I want this capability.
  724. # [07:55] <fantasai> plinss: As soon as I think about the implications of this capability, I want this to stay away.
  725. # [07:55] <fantasai> ?: From an implementers perspective?
  726. # [07:55] <fantasai> plinss: No. From authors perspective even.
  727. # [07:55] <fantasai> plinss: Your argument that variables would make things harder to read, I think it will make them much easier to read.
  728. # [07:55] <fantasai> plinss gives an example
  729. # [07:56] <fantasai> plinss: But when you start getting into what does this do when I change this, what does this do when I change that.
  730. # [07:56] <fantasai> plinss: For implementers, we can figure this out and solve it.
  731. # [07:56] <fantasai> plinss: But for authors it will be hard to figure out.
  732. # [07:56] <fantasai> plinss: Why did this break everything all of a sudden? i think this will make things harder to understand.
  733. # [07:56] * hober contemplates "@var $foo red !important;"
  734. # [07:56] <fantasai> ...
  735. # [07:57] <fantasai> plinss: You can't do this proposal in a preprocessor, it has to be done at run-time in the client.
  736. # [07:57] <fantasai> plinss: That's a whole different class of problems.
  737. # [07:58] <fantasai> plinss: So I think about this, and I really don't want to do this. Or do this in a very very limited way, e.g. only do colors, which is most of the problem.
  738. # [07:58] <fantasai> plinss: So my conclusion is that you can put this in an editor's draft, but there's no guarantee it will go anywhere.
  739. # [07:59] <fantasai> Bert: I know ppl writing preprocessors are looking at what you're doing and want to incorporate it into their system. So be careful with what you write
  740. # [07:59] <fantasai> plinss: Maybe doing this in CSSOM extensions would be a better idea.
  741. # [08:00] <hober> <br duration="15min">
  742. # [08:19] <fantasai> dbaron quote "If your well-defined rules for handling that take less than 50 pages, you don't have well-defined rules."
  743. # [08:19] <fantasai> s/quote/qotd/
  744. # [08:20] <fantasai> Topic: @supports
  745. # [08:20] <fantasai> jdaggett: I see a number of problems in various specs including the fonts spec, where there's a feature and it's difficult to set up fallback that would work
  746. # [08:20] <fantasai> plinss: because you have interdependent properties
  747. # [08:20] <fantasai> dbaron: I think this is going to become a particularly big issue as we add new layout systems
  748. # [08:21] <fantasai> fantasai: Does anybody not understand the problem we're solving?
  749. # [08:21] <fantasai> <silence>
  750. # [08:21] <dbaron> http://lists.w3.org/Archives/Public/www-archive/2011Jun/att-0002/Overview.html
  751. # [08:21] * hober notes dbaron forgot to include "Grid" in the module name
  752. # [08:22] <fantasai> dbaron: first, want to add support for testing for property-value pairs
  753. # [08:22] <fantasai> dbaron: It's a very simple thing. It gives you ability to test for properties and for values
  754. # [08:22] <fantasai> dbaron: A little extra work if you just want to check a property, but probably a good thing [...]
  755. # [08:22] <fantasai> dbaron: I think there's a strong use case for conjunction, disjunction, and negation
  756. # [08:23] <fantasai> dbaron: i.e. not/and/or
  757. # [08:23] * Bert and xor and nand? :-)
  758. # [08:23] <fantasai> dbaron: You want negation so you can write your "if supported" case separate from your "not supported" case so you don't have to make a set of overrides in the supported case
  759. # [08:23] <fantasai> dbaron: and for combination of features
  760. # [08:24] <fantasai> dbaron: or is needed mainly for prefixed properties
  761. # [08:24] * sylvaing briefly attempted to think of variables inside @support rules and hurt his brain
  762. # [08:24] <fantasai> dbaron: Came up with syntax similar to media queries
  763. # [08:24] <fantasai> dbaron: but has a few differences
  764. # [08:25] <fantasai> dbaron: Media queries don't let you group operators in arbitrary ways
  765. # [08:25] <fantasai> dbaron: So the syntax here allows combining in any nesting level, but requires parentheses
  766. # [08:25] <fantasai> dbaron: can have a and b and c, but not a and b or c
  767. # [08:25] <fantasai> dbaron: So no precedence rules
  768. # [08:26] <fantasai> dbaron: Also, I didn't use commas or spaces, you have to write out the keywords
  769. # [08:26] * Quits: myakura (myakura@118.111.219.27) (Client exited)
  770. # [08:26] <fantasai> dbaron: and then you have (property: value)
  771. # [08:27] <fantasai> jdaggett asks about the 'not' case
  772. # [08:27] <fantasai> ppl give examples
  773. # [08:27] <fantasai> wont' be useful in the near future, b/c we don't have support for @supports
  774. # [08:27] <fantasai> but in the future it will become important
  775. # [08:28] <fantasai> discussion of @import in @supports
  776. # [08:28] <fantasai> dbaron: Would like @import stay at the top
  777. # [08:28] <dbaron> could have supports() function part of @import rule
  778. # [08:29] <fantasai> ...
  779. # [08:29] <fantasai> plinss: Makes sense to have a supports check on @import, can figure out exact syntax later
  780. # [08:30] <fantasai> dbaron: There's a couple other things in this draft
  781. # [08:30] <fantasai> dbaron: Another is something according to plinss has been discussed 12 years ago, which is @media inside @media
  782. # [08:30] <fantasai> dbaron: In 2.1, @media can only contain rulesets, not other @rules
  783. # [08:30] <fantasai> dbaron: So I'm saying that @media can contain any @rule that can be interleaved with rulesets
  784. # [08:31] <fantasai> dbaron: So it redefines @media with that definition
  785. # [08:31] <fantasai> dbaron: then defines @supports
  786. # [08:31] <fantasai> dbaron: and then a third proposal, that's been floating around for not quite a decade
  787. # [08:31] <fantasai> dbaron: primary use case for this is user stylesheets
  788. # [08:31] <fantasai> dbaron: @document
  789. # [08:31] <fantasai> dbaron: Not sure how important to standardize, but I've heard some interest in it
  790. # [08:32] * sylvaing @media ($display) { @supports($flexbox) { bike: shedding; } }
  791. # [08:32] <fantasai> Alex gives a use case for that
  792. # [08:32] <fantasai> Alex: If it could be used to conditionally load a file, could save a lot of downloading because would load styles relevant to the pages being visited
  793. # [08:32] <fantasai> s/that/using that in @import/
  794. # [08:33] <fantasai> Alex: It is an issue with performance, because people right now put all the style rules for their entire site in a single style sheet
  795. # [08:33] <fantasai> Alex: They have 2-3 times more rules than necessary for the page
  796. # [08:33] <fantasai> Alex: Slows down downloading, selector matches, etc.
  797. # [08:33] <fantasai> Bert: Might want it all to be cached
  798. # [08:33] <fantasai> Alex: ...
  799. # [08:34] <fantasai> Alex: We've seen sites that can be improved dramatically by just shrinking their style sheets, among other things.
  800. # [08:34] <fantasai> Alex: If they could write instead of complicated selectors, they coudl write for this area of my site I'm loading this set of style sheets, and for that area use this set
  801. # [08:36] <fantasai> Bert discusses extra HTTP requests as another factor, not convinced this will help on @import
  802. # [08:36] <fantasai> jdaggett: Sounds like you're looking for something to solve a problem that isn't necessarily a problem, just more an organizational problem
  803. # [08:36] <fantasai> Alex: Def my problem, I think when ppl see this functionality it's something they will ask for
  804. # [08:36] <dbaron> s/my problem/not my problem/
  805. # [08:37] <fantasai> Florian: If you have @document but not on @import, you can still get selector-matching benefits
  806. # [08:37] <fantasai> Florian: So there seem to be several valid use cases for this
  807. # [08:37] <fantasai> jdaggett: Wrt @supports, are those conditions relatively complicated.. Are there parser questions? I guess we've already tackled a lot of this with media queries
  808. # [08:38] <fantasai> dbaron: The parsing is not that bad, because I required parens around every prop:value pair, but not more than necessary
  809. # [08:38] <fantasai> DD: I'm concerned about the syntax being different from Media Queries
  810. # [08:38] <fantasai> dbaron: I think Media Queries did it wrong
  811. # [08:39] <fantasai> dbaron: Also I think this is a strict superset of Media Queries, except for the comma
  812. # [08:40] <fantasai> dbaron: I think the comma is confusing, because people don't know whether it's "or" or "and"
  813. # [08:41] <fantasai> jdaggett: Could add "or" to Media Queries
  814. # [08:41] <fantasai> plinss: So a question of when can a UA legally claim it supports something.
  815. # [08:41] <fantasai> fantasai: That's defined in the Snapshot
  816. # [08:42] <fantasai> dbaron: Ok, I could reference that
  817. # [08:42] <fantasai> fantasai: or copy the text
  818. # [08:42] <fantasai> ...
  819. # [08:42] <fantasai> jdaggett: SVG has the idea of capabilities, and it turned out to not be very useful because of the problem you're talking about
  820. # [08:42] <fantasai> plinss: It's a useful feature, but can be abused
  821. # [08:42] <fantasai> dbaron: Part of the problem with SVG is that they tried to define sets of features.
  822. # [08:43] <fantasai> dbaron: With adding support for values, CSS implementations have been pretty good at not parsing new values until they actually support them
  823. # [08:43] <fantasai> dbaron: because of the known fallback where authors want the fallback
  824. # [08:43] <fantasai> dbaron: So I think property:value pairs is the right level to do this
  825. # [08:43] <fantasai> dbaron: It won't work perfectly, but most implementations will do it right most of the time
  826. # [08:44] <fantasai> Florian: I think only time UA will lie about it on a site-specific basis
  827. # [08:44] <fantasai> Florian: there are sites that block us (Opera) because they think we don't support things we do
  828. # [08:44] <fantasai> plinss: I think we should put a stake in the ground that UAs must not lie about this.
  829. # [08:45] <fantasai> jdaggett: We could also put in wording about passing tests in the test suite
  830. # [08:45] <fantasai> fantasai: already in the Snapshot wording
  831. # [08:45] <fantasai> Florian: Can this test for support for @variables
  832. # [08:45] <fantasai> Severa: Stop.
  833. # [08:45] <fantasai> plinss: Can we test for @rules? And is that useful?
  834. # [08:46] <fantasai> dbaron: @font-face is the only case where I see a use for this
  835. # [08:46] <fantasai> jdaggett: All of Tab's animation stuff, I don't want that in this
  836. # [08:46] <fantasai> plinss: Paged Media 3 adds 16 new @rules for margin boxes
  837. # [08:47] <fantasai> dbaron: One of the nices things about property-value pairs is that we already have code for parsing them.
  838. # [08:47] * hober @supports atrule(font-face)
  839. # [08:47] <fantasai> dbaron: @rules are much more context-dependent, so you'd almost have to have a separate @support parsing list
  840. # [08:48] <fantasai> dbaron: So if we want this, we should make sure it's in the new charter
  841. # [08:48] <fantasai> Bert: The scope is wider than just the list of modules, so no problem here.
  842. # [08:49] <fantasai> dbaron: So other issue is what to call it
  843. # [08:49] <fantasai> fantasai: css3-if :)
  844. # [08:49] <hober> "CSS3?"
  845. # [08:49] <fantasai> dbaron: Currently calling it css3-conditional
  846. # [08:49] <fantasai> hober, @media is in 2.1
  847. # [08:49] * hober fantasai: no, i mean call it "CSS3?" :) (wasn't serious)
  848. # [08:50] * Joins: Ms2ger (Ms2ger@91.181.137.121)
  849. # [08:50] * jdaggett current css3 text spec says "CSS Text Level 3" ;)
  850. # [08:50] * Joins: szilles (chatzilla@219.67.44.188)
  851. # [08:50] * jdaggett needs a "Module" in there
  852. # [08:51] <fantasai> plinss: so I'm hearing consensus that we want this
  853. # [08:51] <fantasai> dbaron: So "CSS Conditional Rules" aka css3-conditional
  854. # [08:51] <fantasai> ?
  855. # [08:52] <fantasai> fantasai: And Bert's bibliography can call it [CSS3IF] :)
  856. # [08:53] <fantasai> dbaron: Ok, I'll put this in dev.w3.org, do some editing, and then ask for WD
  857. # [08:53] <fantasai> Bert asks why @document isn't a selector
  858. # [08:53] <fantasai> several don't like this idea
  859. # [08:54] <fantasai> doesn't allow grouping
  860. # [08:54] <fantasai> and doesn't help as much with selector matching performance
  861. # [08:54] <fantasai> dbaron: Also makes it easier to allow user style injection
  862. # [08:55] <fantasai> dbaron: So we can have UI for site-specific styles, and we just stick it in the @document {} rule
  863. # [08:55] <fantasai> RESOLVED: Add css3-conditional
  864. # [08:56] <fantasai> RESOLVED: Allow Tab to work on a css3 variables editor's draft, no guarantee we'll move it to WD
  865. # [08:57] <fantasai> DD: How do we add "or" to Media Queries?
  866. # [08:57] <fantasai> fantasai: Need to start a new draft, since MQ is closed to new features already
  867. # [08:57] <fantasai> dbaron: Might want to start that new draft in the next 2 years, we have some other features to add, too
  868. # [08:58] <fantasai> Topic: mixins
  869. # [08:58] <fantasai> Tab: These are basically the same thing, this is variables 2.0
  870. # [08:59] <fantasai> Tab: Mixins, rather than being single values that you then use in properties, they are declaration blocks you mix into other declaration blocks
  871. # [08:59] <fantasai> Tab: Simple example, declare a mixin like this
  872. # [08:59] <fantasai> Tab gives an example
  873. # [08:59] <hober> http://www.xanthir.com/blog/b4Av0
  874. # [08:59] <fantasai> jdaggett: So this is closer to preprocessing
  875. # [09:00] <fantasai> Tab: What's very useful here is the ability to parametrize them
  876. # [09:00] <fantasai> Florian: Are nonprogrammers going to understand that?
  877. # [09:00] <fantasai> jdaggett: Why do we need to use the variable syntax?
  878. # [09:00] <fantasai> Tab: Similar concept here
  879. # [09:00] <fantasai> jdaggett: But the functionality is distinct, how it works
  880. # [09:01] <fantasai> jdaggett: If you have variables in your mixin, there are two things that you're jumbling together
  881. # [09:01] <fantasai> jdaggett: essentially local variables and global variables
  882. # [09:02] <fantasai> fantasai: How is this different from my proposal, aside from parameters?
  883. # [09:02] <dbaron> fantasai: "So, what question are you actually answering, and what's the answer to it?"
  884. # [09:03] <fantasai> Tab mashes around some words and doesn't answer the question
  885. # [09:03] * Quits: szilles (chatzilla@219.67.44.188) (Ping timeout)
  886. # [09:04] * sylvaing mixins, variables: I think the module is css3-inception
  887. # [09:04] <hober> fantasai's proposal: http://fantasai.inkedblade.net/style/specs/constants/
  888. # [09:04] * Ms2ger css3-$$$?
  889. # [09:05] <fantasai> bunch of discussion
  890. # [09:05] * Bert .oO (will that make us rich?)
  891. # [09:05] <fantasai> simultaneously
  892. # [09:05] <dbaron> Sylvain: "Can we have one discussion at a time?"
  893. # [09:05] <fantasai> Tab: Aside from naming issues, this is something we want to pursue experimentally
  894. # [09:05] <dbaron> (participant in one of the other two discussions): "No."
  895. # [09:05] * sylvaing only if $ is a unit
  896. # [09:05] * Ms2ger Bert, no, but it will turn CSS into JavaScript ;)
  897. # [09:06] <fantasai> fantasai asks for use cases for putting all this in the DOM and allowing JS to manipulateit
  898. # [09:07] <fantasai> ??: debugging
  899. # [09:07] <fantasai> Alex: ...
  900. # [09:07] * Joins: szilles (chatzilla@219.67.44.188)
  901. # [09:07] <fantasai> Alex: If we compare this to programming language, it's a really bad idea
  902. # [09:08] <fantasai> s/.../... multiple inheritance .../
  903. # [09:08] <fantasai> Tab: It's different.
  904. # [09:09] <fantasai> Alex: really bad usage of multiple inheritance, trust me it's possible
  905. # [09:09] <fantasai> ??: You've got a bunch of rules and a very clear set of resolution
  906. # [09:10] <fantasai> fantasai: I'd like to understand why this proposal is better than mine, that we should use this and not that
  907. # [09:10] <fantasai> Tab: parameters
  908. # [09:11] <fantasai> Tab: and global scoping
  909. # [09:11] <fantasai> fantasai: mine has a parameterization mechanism, just different
  910. # [09:11] <fantasai> Tab: I think global scoping is simpler and matches what authors expect from the language
  911. # [09:12] <fantasai> Tab: So do people want to go forward or hate it?
  912. # [09:12] <fantasai> plinss: I hate it
  913. # [09:12] <fantasai> Alex: I hate it
  914. # [09:13] <fantasai> Tab: Useful for authors, using it in their preprocessors
  915. # [09:13] <plinss> s/plinss: I hate it/plinss: I _really_ hate it/
  916. # [09:13] <fantasai> fantasai: So use it in the preprocessors.
  917. # [09:14] <fantasai> discussion of how preprocessors work and debugging tools work
  918. # [09:16] <fantasai> Tab argues that debugging is better when you have mixins in the browser
  919. # [09:16] <fantasai> plinss: I think this is a failure in your debugging toolchain
  920. # [09:18] <fantasai> random unminuted comments
  921. # [09:18] <fantasai> and bad jokes
  922. # [09:18] <fantasai> dbaron: I have a CS professor named Norman Ramsey
  923. # [09:18] <fantasai> dbaron: whose comment was that Knuth attempted to make TeX not a programming language, and failed, and so it is a bad programming language
  924. # [09:19] <fantasai> Florian: You asked if some people hated it, and the answer is yes.
  925. # [09:19] <dbaron> s/ named Norman Ramsey//
  926. # [09:20] <fantasai> ??: Reuse is good for the Web, it's good for the authors, not manually preprocessing things.
  927. # [09:20] <fantasai> Florian: The good thing about manually preprocessing is that you know exactly what's going on
  928. # [09:20] <fantasai> plinss: There have been other proposals that are more CSS-like and not programming-language-like
  929. # [09:21] <fantasai> plinss: That's another thing
  930. # [09:21] <fantasai> plinss: Your fundamental question was is there a strong objection, and the ansewr is yes, there is a strong objection.
  931. # [09:21] <fantasai> plinss: I'm not hearing anybody supporting this except you guys.
  932. # [09:21] <fantasai> Vincent: I'm not objecting. I'm sympathetic to their arguments.
  933. # [09:22] <fantasai> jdaggett: There's a level of complexity that's here. You're adding complexity and also solving problems. You have to balance it.
  934. # [09:22] <fantasai> DD: If it was just a plain text-replace, I'd be more comfortable with that
  935. # [09:23] <fantasai> Tab: But CSS is global scope for everything
  936. # [09:23] * Quits: szilles (chatzilla@219.67.44.188) (Ping timeout)
  937. # [09:23] <fantasai> s/DD:/danield:/g
  938. # [09:23] <fantasai> Topic: Nesting
  939. # [09:24] * Joins: szilles (chatzilla@219.67.44.188)
  940. # [09:25] <fantasai> Tab: Once again drawn from preprocessors
  941. # [09:26] * Quits: jdaggett (jdaggett@125.207.177.35) (Quit: jdaggett)
  942. # [09:27] <fantasai> Tab summarizes his proposal, see www-style posting
  943. # [09:28] * Quits: shans (qw3birc@128.30.52.28) (Quit: Page closed)
  944. # [09:28] * Quits: szilles (chatzilla@219.67.44.188) (Ping timeout)
  945. # [09:29] <fantasai> fantasai: what happens if you forget the & ?
  946. # [09:29] <fantasai> Tab: It's an invalid selector. Selectors inside this scope must start with &
  947. # [09:30] <sylvaing> if you define the nested & selector in an @mixin you'd have to resolve your @mixin at parse time....
  948. # [09:31] <hober> Tab's nesting proposal: http://lists.w3.org/Archives/Public/www-style/2011Jun/0022.html
  949. # [09:32] <fantasai> plinss: What if the original selector has a comma
  950. # [09:32] <fantasai> fantasai: equivalent to replacing the & with :any()/:matches() with that selector as its argument
  951. # [09:32] <fantasai> (using a full implementation of :matches())
  952. # [09:32] <fantasai> fantasai: why ampersand?
  953. # [09:32] <fantasai> Tab: Looking for something terse that's easily recognizable
  954. # [09:33] <fantasai> fantasai: How about using a question mark?
  955. # [09:33] <fantasai> Tab: could work
  956. # [09:34] <fantasai> several ask if it has to be punctuation
  957. # [09:34] <fantasai> plinss: need to distinguish it from a property
  958. # [09:36] <fantasai> Alex: Can you do anything with this that you couldn't before?
  959. # [09:37] <fantasai> Tab: purely syntactic sugar
  960. # [09:37] <fantasai> plinss: better maintainability
  961. # [09:38] <hober> h1, h2, h3, h4, h5, h6 { & a {}}
  962. # [09:38] <fantasai> Tab: So, I would like to pursue this.
  963. # [09:38] <fantasai> Tab: There are some problems that need to be worked on
  964. # [09:38] * fantasai notes that the constants proposal addresses this problem by allowing variables as selectors
  965. # [09:38] * fantasai although this is terser
  966. # [09:39] <fantasai> Tab: There's a combinatorial problem here. The author can easily write a lot of rules that have to kept track of
  967. # [09:40] * Joins: plinss__ (plinss@125.207.177.35)
  968. # [09:40] * Quits: plinss (plinss@125.207.177.35) (No route to host)
  969. # [09:40] <fantasai> Tab: This ability is simple. I just explained everything.
  970. # [09:40] * Quits: vhardy (vhardy@125.207.177.35) (Ping timeout)
  971. # [09:40] <fantasai> Tab: Out of everthing I talked about so far, only one that can be entirely done in preprocessor
  972. # [09:40] * plinss__ is now known as plinss
  973. # [09:40] <fantasai> Tab: But it's a huge win for maintainability
  974. # [09:40] * Joins: hober2 (ted@125.207.177.35)
  975. # [09:41] * Quits: hober2 (ted@125.207.177.35) (Client exited)
  976. # [09:41] <fantasai> Alex: What will the adoption picture be fore this, when there is nothing you can do with this for a long while
  977. # [09:41] * Joins: hober2 (ted@174.143.153.77)
  978. # [09:41] * Quits: hober (ted@125.207.177.35) (Ping timeout)
  979. # [09:41] <fantasai> Tab: Yeah, there's no fallback
  980. # [09:41] <fantasai> Tab: You'd have to do preprocessor for now.
  981. # [09:41] <fantasai> Alex: Something that like this improves readability but also enables something new...
  982. # [09:42] <fantasai> Alex: you have to still do this in separate style sheets. Have new style sheet and old one
  983. # [09:42] <fantasai> ?: we've written a JS that will do the processing in JS, might be good interim solution
  984. # [09:42] <fantasai> plinss: could also do an apache plugin or something
  985. # [09:42] <fantasai> plinss: What does this do to the CSSOM
  986. # [09:42] <fantasai> Tab: Relatively simple change.
  987. # [09:42] <fantasai> Tab: Add ... to ...
  988. # [09:42] * hober2 is now known as hober
  989. # [09:43] <fantasai> discussion of parsing in downlevel UAs
  990. # [09:44] <fantasai> Tab: You have to put them at the bottom of the rule block
  991. # [09:44] <fantasai> sylvaing: or put a semicolon at the end of each block
  992. # [09:45] <fantasai> fantasai: Rather restrict it to one or the other, otherwise it's confusing and people will get it wrong
  993. # [09:46] <fantasai> Tab: Happy to just require putting them at the end of the style block. I think it's more readable that way anyway
  994. # [09:46] <fantasai> Bert raises issue of the Core Grammar
  995. # [09:46] <fantasai> Tab: But plays well with forward-compatible parsing
  996. # [09:46] <fantasai> Bert: But we're not supposed to change the Core Grammar
  997. # [09:46] <fantasai> plinss: Almost anything we add that's new is ...
  998. # [09:47] <fantasai> dbaron: The grammar in syndata.html is very general, and Bert is saying that new stuff has to match that
  999. # [09:48] <fantasai> foo {
  1000. # [09:48] <fantasai> prop: val;
  1001. # [09:48] <fantasai> @nest:hover {
  1002. # [09:48] <fantasai> prop: val;
  1003. # [09:48] <fantasai> }
  1004. # [09:48] <fantasai> }
  1005. # [09:48] * Joins: vhardy (vhardy@125.207.177.35)
  1006. # [09:49] <fantasai> plinss: One of my concerns about the syntax, other than &, it looks reading it a very subtle distinction between having a space after the & or not
  1007. # [09:50] <fantasai> fantasai: One advantage of the @nest is that it looks more like a regular selector, where you make this distinction. With the & it's so short, it's easier to not notice the space distinction.
  1008. # [09:51] <fantasai> Bert: Would be easier to not use ampersand in cases where the space is there, so it's more different
  1009. # [09:51] <fantasai> Tab: But then you start parsing it like a property
  1010. # [09:51] <fantasai> fantasai: I think Bert's suggestion is much better-looking.
  1011. # [09:52] <fantasai> This is agreed, but it still creates a problem.
  1012. # [09:52] <fantasai> Discussion of Tab's priorities
  1013. # [09:52] <fantasai> Tab: List, images, flexbox
  1014. # [09:52] <fantasai> Tab: want to work next on positioning to make it editor's-draft ready
  1015. # [09:52] <fantasai> Alex: Which positioning?
  1016. # [09:53] <fantasai> Tab: Firming up abspos model, and then adding ability to attach edges to edges of other boxes
  1017. # [09:53] <fantasai> Tab: We put together a newsread app that's really slick, 3 cols of stories etc.
  1018. # [09:53] <fantasai> Tab: It was ridiculously hard to do in JS or CSS.
  1019. # [09:53] <fantasai> Tab: We wound up absposing everything and using a constraint solver in JS
  1020. # [09:54] <fantasai> Bert: I think abspos was a huge mistake
  1021. # [09:54] <fantasai> Tab: I agree that what we have in CSS2 is minimally useful
  1022. # [09:54] <fantasai> dbaron: I think it's harmful
  1023. # [09:54] <fantasai> plinss: I really like this feature
  1024. # [09:54] <fantasai> plinss: that's my 2cents
  1025. # [09:55] <fantasai> plinss: I accept it's a problem that it can't be used until universally supported
  1026. # [09:55] <dbaron> betweeen "I think it's harmful" and "I really like this feature" we switched back from discussing abspos to discussing tab's proposal
  1027. # [09:55] <fantasai> oh, heh :)
  1028. # [09:57] <fantasai> Tab: If you want preprocessor, you either need server-side scripting, or JS, and JS has perf issues (and doesn't work for ppl with JS turned off)
  1029. # [09:57] <fantasai> Tab: So should I work on this?
  1030. # [09:58] <fantasai> Nobody seems to be objecting, but only Tab and plinss seem to be enthusiastic
  1031. # [09:58] <fantasai> Florian: I'm tempted to say nay based on the fact that it doesn't fit within the grammar, but not sure I can say this in Opera's name.
  1032. # [09:59] <dbaron> I think it's not crazy; I'm scared of the OM implications. Doesn't seem like an implementation priority.
  1033. # [10:00] <fantasai> Alex: not committing to do this, will be pretty far down in priority list
  1034. # [10:00] <fantasai> Alex: Think there's value in writing up what syntax could look like
  1035. # [10:00] <fantasai> Alex: In right combination with other features, could be useful
  1036. # [10:02] <fantasai> fantasai is concerned about prioritization
  1037. # [10:03] <fantasai> plinss: I'm hearing a conditional yes, that it's low priority, doesn't impact other work, no guarantee of implementation
  1038. # [10:03] <fantasai> Topic: Selectors 4
  1039. # [10:05] <TabAtkins> fantasai: I've omitted the pseudoelems from this draft (they're not relevant for other selector-y thing like querySelector). They should go in a PseudoElements Module.
  1040. # [10:05] <TabAtkins> fantasai: I added a couple of things I felt were fairly uncontroversial.
  1041. # [10:05] <TabAtkins> fantasai: Main things is :matches() (previously called :any()).
  1042. # [10:05] <TabAtkins> fantasai: It means "an element which matches my argument".
  1043. # [10:05] <TabAtkins> fantasai: And :not() is the opposite.
  1044. # [10:06] <TabAtkins> fantasai: The argument is an arbitrary selector without combinators.
  1045. # [10:06] <TabAtkins> fantasai: So :matches(foo,bar,baz) is fine, but :matches(foo > bar) is not, because that gets into branching issues.
  1046. # [10:07] <TabAtkins> fantasai: I've also added a proposal for selecting the "subject" of a selector.
  1047. # [10:07] <sylvaing> Elika is reviewing http://dev.w3.org/csswg/selectors4/
  1048. # [10:07] <TabAtkins> fantasai: So, frex, in "ol > li:only-child", you may want the <ol> itself.
  1049. # [10:07] <TabAtkins> fantasai: You can write "!ol > li:only-child".
  1050. # [10:07] <TabAtkins> florian: That reminds me of "not".
  1051. # [10:08] <TabAtkins> fantasai: I've also tightened up some terminology.
  1052. # [10:09] <TabAtkins> fantasai: "simple selector" is the same as before. "compound selector" is a sequence of simple selector, without combinators.
  1053. # [10:09] <TabAtkins> sylvaing: Do you ahve anything about pseudoelements with pseudoclasses in it?
  1054. # [10:09] <TabAtkins> fantasai: I haven't touched that yet, but i think the pseudoelem should specify what pseudoclasses can apply to it.
  1055. # [10:10] <TabAtkins> fantasai: Another new feature is :dir([rtl | ltr]), which is the same as the older suggestion for :ltr/:rtl, but more consistent with :lang().
  1056. # [10:10] <TabAtkins> fantasai: I also believe we should pull in the various pseudos that HTML5 defines, because they should be defined on our side.
  1057. # [10:11] <TabAtkins> fantasai: And then HTML can just clarify what they apply to for HTML, rather than *defining* them.
  1058. # [10:11] <fantasai> http://wiki.csswg.org/spec/selectors4
  1059. # [10:12] <TabAtkins> fantasai: Here are some other features people have requested for Selectors.
  1060. # [10:12] <TabAtkins> fantasai: A lot of which I think are very cool.
  1061. # [10:15] <TabAtkins> fantasai: I think for now I just want to add the "current url" selector.
  1062. # [10:15] <TabAtkins> fantasai: And then publish as WD?
  1063. # [10:16] <TabAtkins> Bert: I think we're done with Selectors for a while.
  1064. # [10:17] <TabAtkins> florian: One comment from Opera, under the impression that :matches() was the only new thing, we're okay with it.
  1065. # [10:19] <TabAtkins> Bert: Shouldn't the HTML5 pseudoclasses be in the UI module?
  1066. # [10:22] <TabAtkins> fantasai: I'd prefer to have all selectors be defined in the Selectors module, otherwise it's kinda annoying to have to specifically define a conformance class in UI just for selectors-using stuff.
  1067. # [10:23] <TabAtkins> [discussion about naming]
  1068. # [10:23] <dbaron> Bert: We shouldn't do any specs in level 4 until we've done everything in level 3.
  1069. # [10:23] <dbaron> Peter: We've agreed to level modules independently.
  1070. # [10:25] <TabAtkins> vhardy: Why isn't the module's shortname "css4-selectors"?
  1071. # [10:25] <TabAtkins> fantasai: We determined a while ago that Selectors aren't CSS-specific, and the level 3 name was a historical mistake.
  1072. # [10:26] <hober> scribenick: hober
  1073. # [10:26] <hober> Topic: dropping prefixes
  1074. # [10:27] <hober> sylvaing: in recent snapshot we updated the rules for when impls can drop prefixes
  1075. # [10:27] <hober> sylvaing: let's update the spec template to match the snapshot
  1076. # [10:28] <fantasai> http://www.w3.org/TR/css-2010/#experimental
  1077. # [10:28] <fantasai> http://dev.w3.org/csswg/css-module/#conformance
  1078. # [10:28] <TabAtkins> fantasai: A related issue is that most of our modules don't follow the latest template, which has new text and boilerplate.
  1079. # [10:28] <hober> scribenick: tabatkins
  1080. # [10:29] <TabAtkins> sylvaing: When are we going to start doing this?
  1081. # [10:29] <TabAtkins> fantasai: How about right now?
  1082. # [10:29] <TabAtkins> TabAtkins: I can fix my modules to use the new boilerplate soon.
  1083. # [10:29] <TabAtkins> vhardy: Can we get the preprocessor to handle this for us?
  1084. # [10:30] <TabAtkins> fantasai: Some parts, yes. Sounds good - Bert and I will update the template and work on this.
  1085. # [10:31] <TabAtkins> RESOLVED: Update all modules to the latest module template, once Fantasai has checked in the necessary edits.
  1086. # [10:31] <TabAtkins> ACTION fantasai and bert to update the preprocessor template to match boilerplate.
  1087. # [10:31] * trackbot noticed an ACTION. Trying to create it.
  1088. # [10:31] <trackbot> Created ACTION-329 - And bert to update the preprocessor template to match boilerplate. [on Elika Etemad - due 2011-06-11].
  1089. # [10:32] <fantasai> RESOLVED: Move forward with Selectors 4
  1090. # [10:32] <TabAtkins> sylvaing: Given all the specs we're doing, should each spec have a "test owner" that tracks tests and determines coverage and such?
  1091. # [10:32] <TabAtkins> fantasai: That sounds like a wonderful idea.
  1092. # [10:33] <TabAtkins> florian: The only problem I have is that having a test owner will make the editors not care about tests.
  1093. # [10:33] <TabAtkins> sylvaing: That's today's situation. ^_^
  1094. # [10:34] <TabAtkins> fantasai: Also, having it official means that people like sylvain can go to management and say "I need a QA person in the group to be test owner for my spec".
  1095. # [10:34] <TabAtkins> RESOLVED: Establish official "test owner" position parallel to the editor, who keeps track of testing the module.
  1096. # [10:35] <fantasai> s/keeps track of/is responsible for ensuring the/
  1097. # [10:35] <fantasai> s/testing the/test suite of/
  1098. # [10:35] <TabAtkins> Topic: text-overflow
  1099. # [10:36] <TabAtkins> fantasai: There was a string value for text-overflow that let you specify what ellipsis you wanted.
  1100. # [10:36] <TabAtkins> fantasai: Moz has an impl of this.
  1101. # [10:36] <TabAtkins> fantasai: There was also a proposal to have two values.
  1102. # [10:37] <TabAtkins> fantasai: In a scrollable box, when you scroll you end up cutting off text on *both* sides. If you have a direction-sensitive ellipsis character, like an arrow, you want a different one for the other side.
  1103. # [10:37] <TabAtkins> fantasai: So the proposal is to let it take two strings (left and right) in addition to one string (both).
  1104. # [10:38] <TabAtkins> vhardy: We have a similar issue with CSS Regions, where we want something like a "(cont)" at the bottom of each region.
  1105. # [10:39] <TabAtkins> fantasai: We've had a proposal for a 'block-overflow' to handle that case. It doesn't live in any spec yet.
  1106. # [10:39] <TabAtkins> vhardy: I'll put it into Regions for now, just to give it a place to live.
  1107. # [10:39] <TabAtkins> alexmog: The feature gets significantly more complex if you want references and back-references "(cont on page 5)".
  1108. # [10:40] <TabAtkins> fantasai: Yes, but it's okay to deal with that later.
  1109. # [10:40] <TabAtkins> dbaron: Another issue is that we're implementing it unprefixed, because everyone else already has. That's... an issue.
  1110. # [10:40] <TabAtkins> plinss: Not happy about the unprefixed, but I understand the position you're in.
  1111. # [10:45] <TabAtkins> RESOLVED: Add the two-value syntax to text-overflow.
  1112. # [10:45] <fantasai> marked at-risk
  1113. # [10:45] <TabAtkins> Topic: Regions
  1114. # [10:46] <TabAtkins> vhardy: There's a question of integration with other specs.
  1115. # [10:46] <TabAtkins> vhardy: The issue is that, to use something as a region, it needs to be addressible in some way.
  1116. # [10:46] <TabAtkins> vhardy: Like a grid-cell, so you can use 'content' or 'flow-from' on it.
  1117. # [10:46] <TabAtkins> vhardy: This works with Grid Layout, because there's a pseudo for it.
  1118. # [10:46] <TabAtkins> vhardy: But there's none for multicol and flexbox.
  1119. # [10:47] <TabAtkins> vhardy: There's no way to address a column box in multicol.
  1120. # [10:47] <TabAtkins> vhardy: For example, you may want to make a flow of text and a flow of images, and put the images into the second column and flow the text into the first, third, and subsequent columns.
  1121. # [10:48] <TabAtkins> alexmog: Sounds like an exclusion.
  1122. # [10:48] <TabAtkins> vhardy: Or putting alternating content in columns.
  1123. # [10:49] <TabAtkins> alexmog: The way to address this is to make a Grid set up with the same dimensions as the columns that multicol would have given, and then flow into the grid cells.
  1124. # [10:50] <TabAtkins> vhardy: The question is if we want to integrate more closely into the multicol.
  1125. # [10:50] <TabAtkins> alexmog: Multicol is the only exception here. Grid was carefully designed so that it would size the same as grid.
  1126. # [10:50] <fantasai> s/grid/column/
  1127. # [10:51] <TabAtkins> TabAtkins: I think I must agree with alexmog. It makes more sense to flow into grid cells than to flow into multicol column boxes.
  1128. # [10:52] <TabAtkins> alexmog: And you can use, say, region styling to say "this region should have 'columns:3'".
  1129. # [10:52] <TabAtkins> vhardy: Okay, no column boxes as regions.
  1130. # [10:52] <TabAtkins> vhardy: next is, what is a grid cell exactly?
  1131. # [10:53] <TabAtkins> vhardy: There's a grid-cell-stacking property, and an issue that questions whether it should instead be 'display'.
  1132. # [10:54] <TabAtkins> hober: I agree with whatever Hyatt last said.
  1133. # [10:54] <TabAtkins> TabAtkins: I think Hyatt said he liked the 'display' version. I also strongly support it.
  1134. # [10:55] <TabAtkins> alexmog: Note that we don't have immediate plans to implement the ::grid-cell pseudos - our current experimental impl is from the November draft where you could only position boxes.
  1135. # [10:55] <TabAtkins> alexmog: But it makes sense to do so.
  1136. # [10:57] <TabAtkins> fantasai: [separate note] I think it makes sense to limit it to only pseudoelements being regions, not elements.
  1137. # [10:58] <TabAtkins> vhardy: There was some discussion on that on the mailing list.
  1138. # [10:59] <fantasai> Topic: Gradients
  1139. # [10:59] <fantasai> sylvain: When you say bottom left for the corner
  1140. # [11:00] <fantasai> fantasai: Animating keyword sides/corners through 0deg makes the gradient spin through the longest path instead of the shortest path
  1141. # [11:00] <fantasai> Tab: Oh, yes. I will fix that in the spec
  1142. # [11:01] <fantasai> fantasai: Next issue was direction of 0deg and direction of increase
  1143. # [11:02] <fantasai> fantasai: We posted to css3.info to ask for feedback from authors
  1144. # [11:02] <fantasai> fantasai: got 95+ comments, overwhelming majority, as you can see, was for C which is polar angles (zero degrees up)
  1145. # [11:03] <fantasai> fantasai: Arguments given were that it's consistent with the TRBL model that is used everywhere else in CSS, and the angles increment clockwise which is consistent with every other use of angles in CSS.
  1146. # [11:04] <fantasai> plinss: There was a small minority asking for 0deg to the right, increasing counter-clockwise.
  1147. # [11:04] <fantasai> noted that Brad objects to polar angles
  1148. # [11:05] <fantasai> RESOLVED: gradients use polar angles
  1149. # [11:05] <fantasai> s/polar/bearing/
  1150. # [11:05] <fantasai> s/polar/bearing/
  1151. # [11:05] <fantasai> WG: Polar Bears!
  1152. # [11:06] <plinss> s/Brad objects to polar angles/Brad objects to bearing angles/
  1153. # [11:06] <fantasai> s/polar/bearing/
  1154. # [11:08] <sylvaing> a gradient angle value e.g. 30deg is the end point of a gradient line
  1155. # [11:08] <sylvaing> however, an angle keyword e.g. top is the start point of the gradient line
  1156. # [11:09] <alexmog> Tab: ??
  1157. # [11:10] <sylvaing> this is somewhat confusing, especially once one starts transitioning linear gradients
  1158. # [11:13] <Bert> (If it is a direction, why isn't it called 'up' instead of 'top'?)
  1159. # [11:16] <Bert> (Or maybe north, nnw, nw, wnw, west....)
  1160. # [11:20] <fantasai> Bert, it means "attach my gradient to the top edge and then draw from there"
  1161. # [11:20] <dbaron> the allowed keywords should just be 东, 西, 北, 南, 東, 东北, 西北, 東北, 东南, 西南, 東南 :-)
  1162. # [11:21] <danield> So maybe 0 deg should also mean "attach my gradient to the top edge and then draw from there"
  1163. # [11:22] <fantasai> Florian: The cardinal directions map directly to degrees.
  1164. # [11:26] <dbaron> dbaron: associating expected status and priorities in the charter doesn't make sense
  1165. # [11:28] <fantasai> Agreement that the charter should be organized not by "priority" but by what status we expect specs to reach by the end of the charter
  1166. # [11:28] <fantasai> and the sections then need some severe editing
  1167. # [11:28] <fantasai> Specs expected to reach REC:
  1168. # [11:28] <fantasai> - css3-background
  1169. # [11:28] <fantasai> - css3-values, maybe
  1170. # [11:28] <fantasai> - css3-ui
  1171. # [11:28] <fantasai> Specs expected to reach CR:
  1172. # [11:29] <fantasai> - css3-fonts
  1173. # [11:29] <fantasai> - css3-2d-transforms
  1174. # [11:29] <fantasai> - css3-animations
  1175. # [11:29] <fantasai> - css3-writing-modes
  1176. # [11:29] <fantasai> - css3-text
  1177. # [11:29] <fantasai> - css3-images
  1178. # [11:29] <fantasai> - css3-lists
  1179. # [11:29] <fantasai> - css3-flexbox
  1180. # [11:29] <fantasai> - css3-transitions
  1181. # [11:30] <fantasai> plinss: multicol?
  1182. # [11:31] <fantasai> fantasai: If we are planning to test whether things paginate across columns correctly, no, not REC.
  1183. # [11:31] <fantasai> fantasai: If we're only testing whether you calculate columns correctly, then quite possible
  1184. # [11:31] <fantasai> dbaron: Have a "Expected to have test suite" bucket?
  1185. # [11:32] <fantasai> Specs expected to have a test suite:
  1186. # [11:32] <fantasai> - css3-multicol
  1187. # [11:32] <fantasai> s/a test/a complete test/
  1188. # [11:32] <fantasai> (and is in CR)
  1189. # [11:33] <fantasai> Vincent: Regions
  1190. # [11:34] <fantasai> fantasai: I think we can have CR as a goal, but I think not as an expectation
  1191. # [11:34] <fantasai> Testing bucket should be "Specs that are CR that we expect to have a complete test suite for"
  1192. # [11:35] <fantasai> Add css3-speech to CR bucket
  1193. # [11:36] <fantasai> Everything else will be in the WD-and-working-on-it bucket
  1194. # [11:37] <fantasai> plinss: "Expected to *be* CR with a complete test suite"
  1195. # [11:38] <fantasai> Meeting closed.
  1196. # [11:39] <fantasai> plinss thanks Google for dinner, Microsoft for lunch, and Koji and Seko-san for hosting
  1197. # [11:40] * Parts: danield (danield@125.207.177.35)
  1198. # [11:40] * Quits: plinss (plinss@125.207.177.35) (Quit: plinss)
  1199. # [11:40] * Quits: dbaron (dbaron@125.207.177.35) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  1200. # [11:42] * Quits: vhardy (vhardy@125.207.177.35) (Quit: vhardy)
  1201. # [11:42] * Quits: florian (florianr@125.207.177.35) (Ping timeout)
  1202. # [11:42] * Quits: murakami (murakami@118.154.209.3) (Quit: Leaving...)
  1203. # [11:43] <boblet> お疲れさま CSSWG!
  1204. # [11:43] * Quits: sylvaing (sylvaing@125.207.177.35) (Quit: sylvaing)
  1205. # [11:46] * Quits: alexmog (alexmog@125.207.177.35) (Quit: alexmog)
  1206. # [11:49] * Quits: TabAtkins (tabatkins@125.207.177.35) (Ping timeout)
  1207. # [11:51] * Quits: Ms2ger (Ms2ger@91.181.137.121) (Ping timeout)
  1208. # [11:51] * Quits: kojiishi (kojiishi@125.207.177.35) (Ping timeout)
  1209. # [11:52] * Quits: nmccully (macnmm@124.144.75.245) (Quit: byeeeeee!)
  1210. # [12:19] * Joins: Ms2ger (Ms2ger@91.181.137.121)
  1211. # [12:57] * Quits: Ms2ger (Ms2ger@91.181.137.121) (Ping timeout)
  1212. # [12:59] * Joins: Ms2ger (Ms2ger@91.181.230.41)
  1213. # [15:14] * Joins: florian (florianr@218.220.206.223)
  1214. # [15:36] * Quits: florian (florianr@218.220.206.223) (Ping timeout)
  1215. # [15:45] * Joins: plinss (plinss@61.214.117.102)
  1216. # [15:48] * Quits: plinss (plinss@61.214.117.102) (Ping timeout)
  1217. # [15:53] * Joins: florian (florianr@218.220.206.223)
  1218. # [15:54] * Parts: florian (florianr@218.220.206.223)
  1219. # [15:55] * Quits: shepazu_vacation (schepers@128.30.52.169) (Quit: shepazu_vacation)
  1220. # [16:50] * Quits: boblet (Adium@122.27.197.150) (Quit: Leaving.)
  1221. # [17:26] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
  1222. # [17:32] * Joins: arronei (arron.eich@131.107.0.117)
  1223. # [17:33] * Quits: arronei_ (arron.eich@131.107.0.87) (Ping timeout)
  1224. # [18:24] * Quits: Ms2ger (Ms2ger@91.181.230.41) (Quit: nn)
  1225. # [22:28] * Joins: szilles (chatzilla@24.6.120.172)
  1226. # [22:31] * Quits: szilles (chatzilla@24.6.120.172) (Quit: ChatZilla 0.9.86.1 [Firefox 4.0.1/20110413222027])
  1227. # [23:41] * Joins: vhardy (vhardy@219.127.245.113)
  1228. # Session Close: Sun Jun 05 00:00:00 2011

The end :)