/irc-logs / w3c / #css / 2011-11-01 / end

Options:

  1. # Session Start: Tue Nov 01 00:00:00 2011
  2. # Session Ident: #css
  3. # [00:00] <TabAtkins_> fantasai: For pages, there are use-cases where you want to feed the blank pages, there are larger use-cases where you *absolutely don't* want that.
  4. # [00:00] * Joins: Mike5 (Mike5@mcclure.w3.org)
  5. # [00:00] * Joins: kojiishi (kojiishi@63.145.238.4)
  6. # [00:01] <TabAtkins_> fantasai: So we should use that as the default, and possibly address the "force blank pages" later.
  7. # [00:01] <TabAtkins_> RESOLVED: Pages work the same as columns - an element at the to pof the page with break-before won't force a blank page.
  8. # [00:01] * Quits: tpod (tpod@63.145.238.4) (Ping timeout)
  9. # [00:01] <TabAtkins_> howcome: Now, <div><div></div></div><style>div { break-after: all; }</style>
  10. # [00:02] <TabAtkins_> howcome: Two breaks? Or do they collaps?
  11. # [00:02] <TabAtkins_> fantasai: I think they do collapse. The spec seems to imply that as well.
  12. # [00:02] <TabAtkins_> TabAtkins_: And it's consistent with the decision we just made.
  13. # [00:04] * Joins: howard (howard_wan@63.145.238.4)
  14. # [00:04] <TabAtkins_> alexmog: I don't think any browser currently has that behavior.
  15. # [00:04] * Joins: tpod (tpod@63.145.238.4)
  16. # [00:04] <TabAtkins_> fantasai: I intend to fix that in Mozilla.
  17. # [00:04] <TabAtkins_> alexmog: I think all browsers collapse -after breaks, but not -before breaks.
  18. # [00:05] * Joins: JohnJansen (JohnJansen@63.145.238.4)
  19. # [00:05] * Joins: r12a (rishida@128.30.52.169)
  20. # [00:05] <TabAtkins_> alexmog: Things like the <html> element shouldn't count as "content" before the element, forcing a break. Same with display:none elements.
  21. # [00:06] * Joins: tantek (tantek@63.145.238.4)
  22. # [00:06] <TabAtkins_> fantasai: For <div></div><div></div>, we shouldn't collapse - breaks shouldn't collapse through.
  23. # [00:06] * Joins: plinss (plinss@63.145.238.4)
  24. # [00:06] * Joins: MoZ (MoZ@63.145.238.4)
  25. # [00:06] <fantasai> corrected example: <div>...</div><div/></div>...</div>
  26. # [00:06] <TabAtkins_> szilles: I'm surprised at this. I would think it would be simpler to always honor the breaks, not collapse.
  27. # [00:06] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
  28. # [00:06] <TabAtkins_> alexmog: Say you have an <h1>, the first thing in the document, and you set break-before on it.
  29. # [00:07] <TabAtkins_> alexmog: But it's *not* actually the first element. <html> and <body> precede it.
  30. # [00:07] <TabAtkins_> szilles: Isn't that consistent with our previous case? If the <h1> is at the top of the page...
  31. # [00:07] * Joins: r12a (rishida@128.30.52.169)
  32. # [00:07] <fantasai> TabAtkins: This is a different case
  33. # [00:08] <fantasai> TabAtkins: In this multicol case, the <div> is literally the first thing on the page
  34. # [00:08] <fantasai> TabAtkins: In the other case, the <h1> is not the first thing on the page, it's wrapped by a <body> and an <html>
  35. # [00:08] <fantasai> szilles: Define that as being at the top of the page
  36. # [00:09] <fantasai> Alex: Orphan control shouldn't .. if you have a region with only room for one line, and we have an element with orphan that has 3 lines
  37. # [00:09] <fantasai> alex: we're currently going to move that to the next region because we're not at the top of the page
  38. # [00:09] * fantasai doesn' tthink the minuted version makes any sense here
  39. # [00:10] <fantasai> alex: You have a long enough paragraph, multiple lines
  40. # [00:10] <fantasai> alex: starts in a region which can fit just one line
  41. # [00:10] <fantasai> alex: which is ok for titles
  42. # [00:10] <fantasai> alex: You want that one line to still be in that region, even though with orphan control will want to keep it with the rest of the parent
  43. # [00:11] <fantasai> alex: The resason these cases are related, is if break-before and break-after are intepreted as I think in the spec
  44. # [00:11] <fantasai> alex: they're not "make sure there's a break here", it's "make sure this is the first thing on the page"
  45. # [00:11] * Joins: shepazu (shepazu@128.30.52.169)
  46. # [00:11] <fantasai> alex: For both widow/orphan and breaks, you're still looking at whether you're the first thing on the page
  47. # [00:11] <fantasai> alex: opening tags don't count as making you not at the top of the page
  48. # [00:12] <fantasai> szilles: That would just fall out of the deifnition, which is make sure this is the first thing on the page
  49. # [00:12] <fantasai> howcome: ...
  50. # [00:13] <fantasai> howcome: <chapter><section></section.</chapter>
  51. # [00:13] <TabAtkins_> howcome: You'd like to break before/after both the sections and chapters.
  52. # [00:13] <fantasai> howcome: You want each chapter to start on the first page, and each section to start on the first. You want to set break-before
  53. # [00:13] <TabAtkins_> fantasai: 2.1 says that when determining breaks, you look at the break properties of all the elements that meet at the given margin.
  54. # [00:13] <TabAtkins_> fantasai: It's pretty vague, unfortunately.
  55. # [00:14] <TabAtkins_> alexmog: page breaks don't prevent margin collapsing, though...
  56. # [00:15] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
  57. # [00:15] <alexmog> http://www.w3.org/TR/CSS21/page.html#forced
  58. # [00:15] <TabAtkins_> TabAtkins_: Specifically, the definition of "top of a page" is underdefined. Does a marging or border on a parent make you no longer at the to pof a page? (The correct answer is no.)
  59. # [00:15] <fantasai> dbaron: It needs to be defined in a whole bnch of cases. Frex Mozilla has mTopOfPage, which deals solely with the possibility of somethng not fitting -- it lets us know
  60. # [00:16] <fantasai> dbaron: if we have made any progress in putting things on the page, so that we don't keep breaking and placing no content
  61. # [00:16] <fantasai> dbaron: For that border does count
  62. # [00:16] * Joins: homata (homata@58.158.182.50)
  63. # [00:16] <TabAtkins_> alexmog: Having <body> as your parent, even with ??? is honored.
  64. # [00:17] <TabAtkins_> alexmog: If you look at break-after, which is supposed to be consistent with break-before, all browsers collapse break-after.
  65. # [00:17] <TabAtkins_> szilles: Isn't that the same rule/difficulty in determining if something is at the end of the page?
  66. # [00:17] <TabAtkins_> alexmog: Yes.
  67. # [00:17] <TabAtkins_> alexmog: [some sectoin] has a very simply rule that just says a forced break occurs when any elements contributing to the current margin have a forced break.
  68. # [00:17] <TabAtkins_> alexmog: So you go and do normal margin collapsing, then look at the result.
  69. # [00:18] <fantasai> ...
  70. # [00:18] <fantasai> alexmog reads from CSS2.1 spec
  71. # [00:18] <TabAtkins_> fantasai: It wouldn't have been written with more than one element if collapsing wasn't meant to happen.
  72. # [00:18] <fantasai> s/one/two/
  73. # [00:19] <TabAtkins_> howcome: So we can just clarify 2.1 if it' snot fully clear.
  74. # [00:19] * Joins: tobie (tobie@63.145.238.4)
  75. # [00:19] * Quits: dbaron (dbaron@63.145.238.4) (Ping timeout)
  76. # [00:20] <TabAtkins_> szilles: Doesn't the margin definition break if you put a border on <chapter>?
  77. # [00:20] <TabAtkins_> TabAtkins_: Yes, and that's bad.
  78. # [00:20] <TabAtkins_> dbaron: What happens if one says 'left' and the other says 'right'?
  79. # [00:20] <TabAtkins_> howcome: I say you choose whichever one grants you the most pagebreaks.
  80. # [00:21] <TabAtkins_> fantasai: When collapsing breaks there's nothing "between" your breaks. I think you should choose the last one, because it's the one closest to the next content.
  81. # [00:22] <TabAtkins_> howcome: I'd like to have a resolution because we're in CR, and we need testcases written.
  82. # [00:22] * Joins: szilles (chatzilla@63.145.238.4)
  83. # [00:22] <TabAtkins_> howcome: I can live with the last one winning if there are conflicts.
  84. # [00:22] * Quits: tobie (tobie@63.145.238.4) (Ping timeout)
  85. # [00:23] <TabAtkins_> fantasai: The spec is pretty clear that a series of page breaks should never generate more than one page break in series.
  86. # [00:23] <TabAtkins_> howcome: Okay, so collapsing works. Do borders stop break collapsing?
  87. # [00:23] <TabAtkins_> alexmog: They block margin collapsing, so.
  88. # [00:23] * Joins: dbaron (dbaron@63.145.238.4)
  89. # [00:24] <TabAtkins_> howcome: Can't we just lean on margin collapsing's rule?
  90. # [00:24] <TabAtkins_> fantasai: I don't think there's *ever* a use-case for having a border around a blank page with this.
  91. # [00:24] * Quits: tpod (tpod@63.145.238.4) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
  92. # [00:24] <TabAtkins_> alexmog: the 2.1 definition is based on margin-collapsing.
  93. # [00:25] <fantasai> Florian: We should prioritize authors over implementations, and authors don't want a blank page with just a border.
  94. # [00:25] <TabAtkins_> alexmog: And if we can avoid changing the very complicated margin-collapsing, that's good.
  95. # [00:25] <fantasai> szilles advocates for just coming up with a good definition for top-of-page
  96. # [00:26] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
  97. # [00:26] <fantasai> szilles: Definition is if you haven't put any content on the page, then you're at the top. And borders aren't content.
  98. # [00:26] <fantasai> TabAtkins: This is still wayyy simpler than margin collapsing. There's no negatives, no zer-height elements that collapse through, none of that.
  99. # [00:27] <fantasai> howcome: I think there's some kind of consensus here.
  100. # [00:27] * Joins: Mike5 (Mike5@mcclure.w3.org)
  101. # [00:27] <fantasai> RESOLVED: page-break-before doesn't create a break if you're at the top of the page, where at the top of the page means no content has been placed. Borders do not count as content.
  102. # [00:28] <fantasai> Zero-height content counts.
  103. # [00:28] <fantasai> as content
  104. # [00:28] <fantasai> dbaron: So placing an empty block counts, but placing start of a block does not count.
  105. # [00:29] <fantasai> dbaron: Alternative def is placed either a non-phantom line box or a non-replaced block with non-zero height, or anything other than something that goes in a line box, or ...
  106. # [00:29] <fantasai> TabAtkins: Can we just say line boxes is all we care about?
  107. # [00:29] <fantasai> dbaron: tables? replaced blocks?
  108. # [00:29] <fantasai> s/, or .../and isn't a non-replaced block/
  109. # [00:30] <fantasai> TabAtkins: Why are we allowing ... collapsed through?
  110. # [00:30] <fantasai> dbaron: Because alex waned it
  111. # [00:30] <fantasai> Alex: I really like CSS2.1 definition because it covers lots of cases in just 2 lines
  112. # [00:30] <fantasai> howcome: So we have one proposal which is 2.1, based on margin collapsing
  113. # [00:31] <dbaron> I'm fine with the 2.1 definition
  114. # [00:31] <dbaron> s/waned/wanted/
  115. # [00:31] <fantasai> howcome: And then another, perhaps simpler, definition
  116. # [00:31] <dbaron> s/and isn't a non-replaced block/, or something that doesn't go in a line box and isn't a non-replaced block/
  117. # [00:32] <fantasai> howcome writes out the definitions
  118. # [00:32] <fantasai> dbaron: One thing that seems weird is that you have start of a block, that's ok, and end of a block, that's ok, but start *and* end of block, that's not ok
  119. # [00:33] <fantasai> ...
  120. # [00:33] <fantasai> TabAtkins: The break-afters generate a break
  121. # [00:33] <fantasai> TabAtkins: The break-befores don't generate a break: they're already on a new page
  122. # [00:34] <fantasai> fantasai: The thing that's weird is collapsing anything through the content area of an element. We do that for margin collapsing, and its weird. We should not do that here.
  123. # [00:34] <fantasai> alex: I have a problem with not counting the border as content
  124. # [00:34] <fantasai> alex: My margin will be after that border, and while I'm asking to be the first thing on the page, I'm not really
  125. # [00:35] <fantasai> TabAtkins: I think the potential downside of where that might be confusing is less bad than having an entirely blank page with nothing but a border on it.
  126. # [00:35] <fantasai> fantasai: You're actually not required to print pages that have only backgrounds and borders on them
  127. # [00:35] <fantasai> howcome: It seems you feel quite strongly about this, Alex.
  128. # [00:36] <fantasai> howcome: Let's take a quick straw poll.
  129. # [00:36] <fantasai> A: alex
  130. # [00:36] <fantasai> B: steve/fantasai/tab
  131. # [00:36] <fantasai> jj: A
  132. # [00:37] <fantasai> alex: A
  133. # [00:37] <fantasai> koji: abstain
  134. # [00:37] <fantasai> Markus: abstain
  135. # [00:37] <fantasai> Tantek: abstain
  136. # [00:37] <fantasai> Steve: B
  137. # [00:37] <fantasai> Alan: abstain
  138. # [00:37] <fantasai> abstain
  139. # [00:37] <fantasai> Florian: B
  140. # [00:37] <fantasai> ert; abstain
  141. # [00:37] <fantasai> ....
  142. # [00:37] <fantasai> lots of abstain
  143. # [00:37] <fantasai> howcome: we can collapse all the abstain
  144. # [00:37] <fantasai> Rossen: A
  145. # [00:38] <fantasai> dbaron: A
  146. # [00:38] <fantasai> sylvaing: abstain
  147. # [00:38] <fantasai> arronei: A
  148. # [00:38] <fantasai> Tab: B
  149. # [00:38] <fantasai> fantasai: B
  150. # [00:38] <Bert> s/ert;/Bert:/
  151. # [00:38] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
  152. # [00:39] * Joins: Mike5 (Mike5@mcclure.w3.org)
  153. # [00:40] <fantasai> smfr: B
  154. # [00:40] <fantasai> molly: B
  155. # [00:40] <hober> hober: b
  156. # [00:40] * Joins: gilles (gilles@63.145.238.4)
  157. # [00:41] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
  158. # [00:43] <fantasai> molly: The empty <div> is there. If we're dynamically generating things, it should have an effect
  159. # [00:43] <fantasai> fantasai^ explains the two options
  160. # [00:44] <fantasai> now howcome is explaining why we're collapsing at all
  161. # [00:44] <fantasai> Alex: If you look at continuous media, where instead of page-break you have a large margin
  162. # [00:44] <fantasai> alex: e.g. 3em margin
  163. # [00:45] * Quits: BradK (bradk@63.145.238.4) (Quit: Buh bye)
  164. # [00:45] <fantasai> alex: whatever comes after margin is held together by the results of margin-collapse
  165. # [00:45] * Parts: howard (howard_wan@63.145.238.4)
  166. # [00:45] <TabAtkins_> fantasai: If you're collapsing through this element, where is this break happening?
  167. # [00:46] <TabAtkins_> fantasai: If you have a bunch of break-afters, and you collapse them, and you break the page, the margins that were there get truncated.
  168. # [00:46] <TabAtkins_> fantasai: But after a forced page break, you keep margins at the top.
  169. # [00:47] <TabAtkins_> fantasai: If you have an empty div, and you have set break-before and after on it, and the preceding and following div also have breaks, which page is the middle <div> contributing to?
  170. # [00:47] <TabAtkins_> dbaron: And more importantly, which page is the empty div on?
  171. # [00:48] <TabAtkins_> alexmog: Where does it say that margins are truncated after the break?
  172. # [00:48] * Joins: Mike5 (Mike5@mcclure.w3.org)
  173. # [00:48] <TabAtkins_> howcome: We resolved on that.
  174. # [00:49] <TabAtkins_> dbaron: [explains the 2.1 spec for it]
  175. # [00:50] * Quits: Kai (chatzilla@63.145.238.4) (Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928134238])
  176. # [00:50] <TabAtkins_> dbaron: And this assumes that breaks exist *between* block-level margins, rather than being stuck somewhere *inside* of collapsed margins.
  177. # [00:50] * Joins: mollydotcom (mollyh@63.145.238.4)
  178. # [00:50] <dbaron> quoting 13.3.3 point 1 and the note following
  179. # [00:50] * Quits: dsinger (dsinger@63.145.238.4) (Quit: dsinger)
  180. # [00:50] <fantasai> jj: A
  181. # [00:50] <TabAtkins_> new straw poll!
  182. # [00:50] <fantasai> alex: A
  183. # [00:50] <fantasai> steve:B
  184. # [00:50] <fantasai> Florian: B
  185. # [00:50] <fantasai> Bert: A
  186. # [00:50] <fantasai> Brad: B
  187. # [00:51] <fantasai> hober: B
  188. # [00:51] <fantasai> smfr: B
  189. # [00:51] <fantasai> Kim: B
  190. # [00:51] <fantasai> Molly: B
  191. # [00:51] <fantasai> Rossen: B
  192. # [00:51] <fantasai> dbaron: B
  193. # [00:51] <fantasai> arronei: A
  194. # [00:51] <fantasai> TabAtkins_: B
  195. # [00:51] <fantasai> TabAtkins_: B
  196. # [00:51] <fantasai> glazou: B
  197. # [00:51] <dbaron> s/TabAtkins_/fantasai/
  198. # [00:51] <TabAtkins_> s/TabAtkins_:/fantasai:/
  199. # [00:51] <dbaron> s/fantasai/TabAtkins/
  200. # [00:51] <fantasai> 4 A, 12 B
  201. # [00:52] <fantasai> ChrisL: B
  202. # [00:52] <fantasai> -> 13 B
  203. # [00:52] <fantasai> RESOLVED: B
  204. # [00:52] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
  205. # [00:53] <fantasai> ACTION fantasai: put proposal B for page-break collapsing into specs
  206. # [00:53] * trackbot noticed an ACTION. Trying to create it.
  207. # [00:53] * RRSAgent records action 14
  208. # [00:53] <trackbot> Created ACTION-393 - Put proposal B for page-break collapsing into specs [on Elika Etemad - due 2011-11-07].
  209. # [00:53] * Joins: Ruinan (Ruinan@63.145.238.4)
  210. # [00:53] <fantasai> dbaron: We should errata 2.1
  211. # [00:53] <dbaron> alex: can we get it written up first?
  212. # [00:54] <fantasai> sylvaing: Column boxes define a containing block, right?
  213. # [00:54] <fantasai> sylvaing: What if my columns are balanced and I have a percentage height?
  214. # [00:54] <fantasai> dbaron: If it's auto height, it's auto-height
  215. # [00:54] <fantasai> dbaron: The column boxes all occupy the full height of the multicol box
  216. # [00:54] <fantasai> dbaron: They should have the same implicit height
  217. # [00:55] <fantasai> sylvaing: Don't they adjust when you balance
  218. # [00:55] <Bert> ACTION bert: create issue against CSS 2.1 corresponding to ACTION-393.
  219. # [00:55] * trackbot noticed an ACTION. Trying to create it.
  220. # [00:55] * RRSAgent records action 15
  221. # [00:55] <trackbot> Created ACTION-394 - Create issue against CSS 2.1 corresponding to ACTION-393. [on Bert Bos - due 2011-11-07].
  222. # [00:56] <fantasai> RESOLVED: percentage in block dimension is computed relative to multi-col element
  223. # [00:57] <fantasai> Topic: GCPM
  224. # [00:57] <fantasai> howocme: This is what I showed last night.
  225. # [00:57] <fantasai> howcome: A few other changes we need to go through.
  226. # [00:57] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
  227. # [00:57] <fantasai> howcome: WD is a year old.
  228. # [00:57] <fantasai> howcome: One thing that left GCPM since then is hyphenation
  229. # [00:57] <fantasai> howcome: We should do an updated WD
  230. # [00:57] <fantasai> howcome: A couple other things
  231. # [00:58] <fantasai> glazou: Markus has shown me horizontal navigation in a document that is a little bit in conflict with your proposal
  232. # [00:58] <fantasai> howcome: I don't think it's in conflict, they're going in the same way
  233. # [00:58] <fantasai> Markus and howcome seem to be ok with the situation
  234. # [00:58] * Quits: MoZ (MoZ@63.145.238.4) (Quit: Quitte)
  235. # [00:58] * Joins: Mike5 (Mike5@mcclure.w3.org)
  236. # [00:58] <fantasai> howcome: I'm not tied to the syntax, but I think it shoudl be declarative as you say
  237. # [00:58] <fantasai> markus: Declarative is good, but you also need JS access
  238. # [00:58] <fantasai> howcome: First issue is with leaders
  239. # [00:58] <fantasai> howcome: Bert brought up this point
  240. # [00:59] <fantasai> howcome: The issue being that he wanted to have control over alignment of leaders
  241. # [00:59] * glazou loves to see love between browser vendors ; we say "bisounours" in french :-)
  242. # [00:59] <fantasai> howcome: If I understood correctly, Bert, you wanted to create a leader that's an arrow
  243. # [00:59] <fantasai> howcome draws: ABC ------------> 1
  244. # [00:59] * mollydotcom can someone post the URL for this WD please?
  245. # [00:59] <Bert> -> http://www.w3.org/Style/Examples/007/leaders examples of leaders (hacked, of course, but showing the way I want them)
  246. # [00:59] <fantasai> howcome: In order for this arrow, which is in the generated content,
  247. # [00:59] <fantasai> howcome: to make this visually make sense, Bert wants the point of the arrow to connect with the line
  248. # [01:00] <fantasai> howcome: So that you don't get that effect *draws an arrow where the head is broken from the body*
  249. # [01:00] <fantasai> ChrisL: That assumes the horizontal lines match up with the arrows
  250. # [01:00] * Joins: curmet (5ad8fb39@207.192.75.252)
  251. # [01:00] <fantasai> Bert: In the Symbol fonts they do
  252. # [01:00] <fantasai> howcome: the idea is to add a second argument to the leader function,
  253. # [01:01] * Parts: curmet (5ad8fb39@207.192.75.252)
  254. # [01:01] <fantasai> howcome: I think these are the values you need: 'start', 'end', 'center', 'space', 'pattern'
  255. # [01:02] <fantasai> howcome: pattern is to make the dots align across lines
  256. # [01:02] * Joins: karl (karlcow@128.30.54.58)
  257. # [01:02] <fantasai> glazou: 'space' should be 'stretch'
  258. # [01:02] <fantasai> fantasai: Stretching implies stretching the glyph. background-repeat uses 'space'
  259. # [01:02] <fantasai> howcome: You want these leaders to align. I think this is the most common use case.
  260. # [01:03] <fantasai> szilles: Don't understand where the space is added.
  261. # [01:03] <fantasai> dbaron: You put as many characters as will fit. In normal case you right-align them
  262. # [01:03] <fantasai> dbaron: In space case, you insert spaces between the leaders
  263. # [01:04] <fantasai> szilles: Need to be clear about whether its between all the characters or between each string
  264. # [01:04] <fantasai> Bert: Not the way it works in TeX, but it's another option
  265. # [01:04] <fantasai> Bert: The leader unit is a fixed size, doesn't chnage size
  266. # [01:04] <fantasai> Bert: Can put space before/after, both, etc. but not inside it
  267. # [01:04] <fantasai> Tantek: Aren't leaders like border-images?
  268. # [01:05] <glazou> s/'space' should be 'stretch'/'space' will mean whitespace in web author's mind, please use something else like stretch (just an example)
  269. # [01:05] <fantasai> Tantek: why not use images
  270. # [01:05] <fantasai> szilles: Because the common case is to use glyphs
  271. # [01:05] <ChrisL> typographers also see decorations as glyphs
  272. # [01:06] <fantasai> fantasai: might want both characters and images
  273. # [01:06] <fantasai> fantasai talks about matchng the dots to the dots in the font, in size, postion, and shape
  274. # [01:07] <fantasai> szilles: We've talked about a need for characters, there might also be a need for images
  275. # [01:07] <fantasai> molly: I think space, which goes characters out to available space, and justification which fits inside the containing block
  276. # [01:07] <fantasai> ????
  277. # [01:07] <fantasai> molly: What I interpret that as meaning space out the chraacters to take up the width
  278. # [01:07] <fantasai> howcome: That's right
  279. # [01:08] <fantasai> howcome: The quesiton is between all characters or only where the repetition is
  280. # [01:08] <fantasai> szilles: Why not have two values
  281. # [01:08] <fantasai> fantasai: space and justify
  282. # [01:08] <fantasai> fantasai: space like border-image and background-repeat
  283. # [01:08] <fantasai> ?: letter-space and pattern-space
  284. # [01:09] <fantasai> molly: justify makes sense
  285. # [01:09] <fantasai> molly: This addresses both issues
  286. # [01:09] <fantasai> howcome: Does anyone need center?
  287. # [01:09] <fantasai> Bert: Sometimes you want as much space before the leader as well as after
  288. # [01:10] <fantasai> dbaron: Centered absolutely or centered individually?
  289. # [01:11] <fantasai> Florian: We're resolving to split the space into two, and not remove any other value
  290. # [01:11] * Joins: wangsi-wei (wang@63.145.238.4)
  291. # [01:12] <fantasai> some confusion around everything
  292. # [01:12] * tantek provides a dot-leader example from >10 years ago: http://tantek.com/CSS/Examples/dotleaders.html
  293. # [01:12] <tantek> (try resizing)
  294. # [01:12] * Quits: dbaron (dbaron@63.145.238.4) (Ping timeout)
  295. # [01:12] <tantek> #tablesabuse
  296. # [01:13] <fantasai> howcome puts in string-space and letter-space
  297. # [01:14] * Joins: cslye (cslye@192.150.10.200)
  298. # [01:15] <fantasai> bikeshed pattern -> align
  299. # [01:15] <fantasai> fantasai: I'd also drop the comma and use ||
  300. # [01:15] <fantasai> fantasai: just like in properties
  301. # [01:15] <fantasai> Bert: One more about leaders, but maybe not so easy to solve.
  302. # [01:15] <fantasai> Bert: How to make double-ended arrows
  303. # [01:16] * Quits: mihara (mihara@63.145.238.4) (Ping timeout)
  304. # [01:16] <fantasai> fantasai: Just put three strings: "start" "middle" "end"
  305. # [01:17] <fantasai> TabAtkins: image-resolution is in css3-images, so should remove from here
  306. # [01:17] <fantasai> howcome: ok, done
  307. # [01:18] <fantasai> szilles: One other catch with alignment
  308. # [01:18] <fantasai> szilles: In Indic languages, the leader aligns with the hanging basline
  309. # [01:18] <fantasai> szilles: In Japanese it would be centered
  310. # [01:18] <fantasai> fantasai: That should be handled in the fonts
  311. # [01:19] <fantasai> szilles: The leader needs to be aligned to the relevant baseline.
  312. # [01:19] <fantasai> szilles: That may fall out
  313. # [01:19] <fantasai> szilles: Just want it noted
  314. # [01:19] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
  315. # [01:20] * Joins: dbaron (dbaron@63.145.238.4)
  316. # [01:20] <fantasai> howcome: Nothing changed in ... various sections ....
  317. # [01:20] <fantasai> howcome: Paged Presentations
  318. # [01:20] <fantasai> howcome: This is basically what I demoed yesterday, where we use the overflow property to set the axis onto which we put out these pages
  319. # [01:21] <fantasai> howcome: They could be analyzed and split into two, and we could have multiple properties for them
  320. # [01:21] * Joins: szilles (chatzilla@63.145.238.4)
  321. # [01:21] <fantasai> howcome: We did that at some point in our implementation, but it creates many possibilities
  322. # [01:21] <fantasai> howcome: that we aren't really going to use
  323. # [01:21] <fantasai> howcome: So instead we have four values that cover the needs we have found
  324. # [01:21] <fantasai> howcome: there might be others
  325. # [01:21] * Quits: Ruinan (Ruinan@63.145.238.4) (Quit: Ruinan)
  326. # [01:21] <fantasai> howcome: not tied to syntax, but we like the functionlity
  327. # [01:21] <fantasai> howcome: the -controls bit adds the UI
  328. # [01:22] <fantasai> howcome: native UI for paging
  329. # [01:22] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
  330. # [01:22] <fantasai> szilles: I'm concerned that it's not as standardized as scrollbars are
  331. # [01:22] <fantasai> howcome: It's like HTML5 controls for video
  332. # [01:22] <fantasai> glazou: that's in the markup
  333. # [01:23] <fantasai> alex: ... overflow paginator, could be x and y
  334. # [01:23] <fantasai> howcome: Could split these into 2 properties. Paged thing could be on 2 oveflow, and the others on a diferent property
  335. # [01:23] <fantasai> howcome clarifies that x in paged-x is about how the pages connect, not which direction of overflow is affected
  336. # [01:24] <fantasai> glazou: I'm very concerned about the controls bit
  337. # [01:24] <fantasai> Florian: Does the first bit forbid the UA to have controls?
  338. # [01:24] <fantasai> howcome: Alex asked, does touch work both places?
  339. # [01:24] <fantasai> howcome: This just adds visual controls
  340. # [01:24] <fantasai> dbaron: In the simplest case it could even be a scrollbar, though probably not the best idea, but it could be
  341. # [01:24] <ChrisL> so the distnction is that the controls take up space
  342. # [01:25] * ChrisL felt that was actually worth minuting
  343. # [01:25] <fantasai> howcome: We have overflow: scroll;, so we are referring to controls already
  344. # [01:25] <Bert> q+ to compare to marquee and overflow-style
  345. # [01:25] <fantasai> fantasai: In scroll vs auto, we're distinguisshing whether the controls are visible when there's no need to scroll, not whether the UA should put controls at all when there is overflow to scroll to
  346. # [01:26] <fantasai> dbaron: More similar to hidden
  347. # [01:26] <glazou> q-
  348. # [01:26] <fantasai> molly: Point out that if the controls are UA-dependent, could be a problem -- authors will want to style it
  349. # [01:26] <glazou> ack Bert
  350. # [01:26] <fantasai> Bert: When we introduced marquee, we added overflow-style and had it as a value of overflow-style
  351. # [01:27] <fantasai> Bert: This seems more like additional values for overflow-style
  352. # [01:27] * Joins: kermit (5e080aef@207.192.75.252)
  353. # [01:27] * Parts: kermit (5e080aef@207.192.75.252)
  354. # [01:27] <fantasai> Tantek: overflow-style: marquee-paged
  355. # [01:27] <fantasai> Markus: In the first case (paged-x) you still want some indication of where you are
  356. # [01:28] <fantasai> Markus: The default shouldn't be nothing.
  357. # [01:28] <tantek> where's Tapas when you need him
  358. # [01:28] <fantasai> dbaron: There are 2 options, in some sense there's no default. You can choose with or without controls
  359. # [01:28] <fantasai> howcome: This is where we've built a UI through the dom. These controls have been made by the page (shows demo) whereas these are made by the UA
  360. # [01:29] <fantasai> szilles: I'm still confused about what "this" is that you say should be in CSS
  361. # [01:29] <fantasai> Adobe: In Acrobat the controls appear on hover
  362. # [01:30] <fantasai> howcome: you can choose whether UA gives controls or whether author provides controls
  363. # [01:31] <fantasai> fantasai: What if the author assumes you have a swipe interface for paging, and doesn't provide controls, but I don't have that interface? Then I'm stuck.
  364. # [01:31] <fantasai> glazou: When you use the overflow property, you just say that the overflow should be visible in some way. You don't make any provision about the means.
  365. # [01:31] <tantek> q+
  366. # [01:31] <dbaron> I disagree with Daniel.
  367. # [01:31] <fantasai> Markus: Here I'm showing you a similar solution using regions and exlucions
  368. # [01:31] <dbaron> I don't think saying there are "controls" is too constraining.
  369. # [01:32] <fantasai> Markus: You have a template mechanism that handles overflow.
  370. # [01:32] <fantasai> Markus: At the bottom there is a little indicator of where you are and how many pages you have
  371. # [01:32] <fantasai> Markus: If I use the mouse, I get a scrollbar
  372. # [01:32] * tantek notes that Opera claims to support overflow-x and overflow-y: http://dev.opera.com/articles/view/opera-9-5-the-next-generation-of-web-s/
  373. # [01:32] <fantasai> glazou: Here you are stopping the scrolling between two pages
  374. # [01:32] * Joins: Ruinan (sunruinan@63.145.238.4)
  375. # [01:32] <fantasai> (markus is demoing)
  376. # [01:33] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  377. # [01:33] <fantasai> markus puts some experimental -ms- snap properties
  378. # [01:33] <fantasai> markus: Now it snaps between pages
  379. # [01:33] <fantasai> markus: But you still get a progress indicator, so you know where you are
  380. # [01:33] <fantasai> markus: Beauty of this approach, based on regions, it's a simple JS templating model.
  381. # [01:33] <fantasai> markus: You can inject animations, etc. etc.
  382. # [01:34] <fantasai> markus: Not saying howcome's idea is a bad idea, but this brings more powerful
  383. # [01:34] <fantasai> Tantek: Can we go back to howcome's demo
  384. # [01:34] <fantasai> Tantek: You mentioned that simple values etc.
  385. # [01:34] <fantasai> Tantek: I'm wondeirng how does that interact with overflow-x and overflow-y
  386. # [01:34] <fantasai> Tantek: I know Opera supports those.
  387. # [01:34] <fantasai> Tantek: If you've figured that out, I'd love to understand that interaction
  388. # [01:35] <fantasai> howcome: These properties only belong on overflow shorthand
  389. # [01:35] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
  390. # [01:35] <fantasai> Tantek: That's why I think they should go on overflow-style
  391. # [01:35] <fantasai> howcome ...
  392. # [01:35] <fantasai> fantasai: I agree it should go in overflow-style
  393. # [01:36] <fantasai> dbaron: This changes the layout model
  394. # [01:36] <fantasai> dbaron: It's not just changing how we get to the overflow
  395. # [01:36] <fantasai> fantasai: I have a question for Markus: what happens when you print?
  396. # [01:37] <fantasai> Markus projects:
  397. # [01:37] <fantasai> body {
  398. # [01:37] <fantasai> overflow-x: auto;
  399. # [01:37] <fantasai> overflow-y: hidden;
  400. # [01:37] <fantasai> -ms-scroll-snap-type: mandatory;
  401. # [01:37] <fantasai> -ms-scroll-snap-points-x: snapInterval(...)
  402. # [01:37] <fantasai> }
  403. # [01:37] * Joins: plinss (plinss@63.145.238.4)
  404. # [01:37] <fantasai> Markus: In general the basics of how this app runs, it's just a simple page that brings in other html pages as templates
  405. # [01:38] * Quits: arno (arno@192.150.10.200) (Ping timeout)
  406. # [01:38] <fantasai> markus: We also have a default overflow template
  407. # [01:38] * Quits: anne (annevk@63.145.238.4) (Quit: anne)
  408. # [01:38] <fantasai> markus: Just a little bit of JS to make this stuff work
  409. # [01:38] <fantasai> glazou: little bit?
  410. # [01:38] <fantasai> markus shows template pages
  411. # [01:38] <fantasai> markus: Place my items, grid
  412. # [01:38] <fantasai> Markus: What I showed you at the end is playing with this snap thing
  413. # [01:39] <fantasai> Markus: You can snap after one page, multiple pages, define ranges etc.
  414. # [01:39] <fantasai> Markus: We presented at the build conference, sdk out there, want to bring th WG as a propsoal
  415. # [01:39] <fantasai> glazou: So this only works with JS?
  416. # [01:39] <tantek> LOL - Håkon's pagination proposal is already in the media: www.macworld.com/article/163317/2011/10/opera_cto_kill_the_browser_scroll_bar.html
  417. # [01:40] <fantasai> fantasai: I don't mind having JS interact with CSS, but I don't want us to build layout models here that require JavaScript in order to work.
  418. # [01:40] <tantek> (and http://dvice.com/archives/2011/10/creator-of-css.php )
  419. # [01:40] <fantasai> Markus: You can do interesting animations
  420. # [01:41] <fantasai> Markus: When we started thinking about pagination, we started with something ismilar to howcome's model, but thought it would be better to have .... to create a better magazine-type experience.
  421. # [01:41] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
  422. # [01:41] <fantasai> hober: ...
  423. # [01:41] <fantasai> howcome: I encourage you to add pagination to regions
  424. # [01:41] <fantasai> alex: Pagination should be part of regions
  425. # [01:41] <fantasai> howcome: Regions should know how to work with pages
  426. # [01:41] * Quits: Ruinan (sunruinan@63.145.238.4) (Quit: Ruinan)
  427. # [01:42] <fantasai> szilles: I agree with fantasai's statement that layout models shouldn't require JavaScript, but also good to define events and things to add more
  428. # [01:42] <fantasai> glazou: Agreed, but the basic thing howcome demoed shouldn't require JavaScript
  429. # [01:42] * tantek agrees with szilles
  430. # [01:42] <fantasai> sylvaing: Right, it should be optional
  431. # [01:42] <tantek> pagination events would be useful
  432. # [01:43] <fantasai> howcome shows his api
  433. # [01:43] <fantasai> szilles: I might want to ask questions about pages, like what links are on this page
  434. # [01:43] <fantasai> howcome: I think that's reasonable
  435. # [01:43] <fantasai> howcome: I object to you calling this a low-end feature, markus.
  436. # [01:43] <fantasai> howcome: I can recreate the Economist's layout almost pixel perfect with this
  437. # [01:43] * Joins: dcosta (dcosta@187.31.77.7)
  438. # [01:43] <stearns> Alex's comment was that pagination should *not* be part of regions
  439. # [01:44] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
  440. # [01:44] <fantasai> BradK: Howcome's solution, the UA cna provid ethe UI for how the pagees get turned
  441. # [01:44] <fantasai> bradk_: So you can even hav an ibook like experience, where it's curling and everything. Could be a high-end kind of experience
  442. # [01:44] <fantasai> florian: high-end from control of the user, not the author (?)
  443. # [01:44] <fantasai> bradk_: I consider an advantage, don't have to relearn how to turn pages on every website
  444. # [01:45] <fantasai> Alan: I think whatever we build for pagination should work with multicol, work with regions, shoudl wirk without either
  445. # [01:45] <fantasai> Alan: Could see this for slides
  446. # [01:46] <fantasai> Markus: As soon as you want more flexibility on what thigns look like, you need regions
  447. # [01:46] * Quits: Linuz (linuz.lee@63.145.238.4) (Quit: Linuz)
  448. # [01:46] <fantasai> bradk_: Scrollbars are the same every page you're at, unless the author does somethng special
  449. # [01:46] <fantasai> bradk_: I think that's good, so you don't have to figure out how to turn pages.
  450. # [01:46] * Joins: karl (karlcow@128.30.54.58)
  451. # [01:46] <fantasai> Szilles: If we're going to do what Brad just said, we should agree on what the compones are
  452. # [01:46] * Quits: drublic (drublic@95.115.8.221) (Client exited)
  453. # [01:46] <fantasai> szilles: My Kindle can do more than go back and forth between pages
  454. # [01:47] <fantasai> szilles: A bunch of things ppl expect when paging things
  455. # [01:47] <fantasai> szilles: Come up with some expectation of what the controls should be
  456. # [01:47] <fantasai> szilles: controls is too open ended
  457. # [01:47] <fantasai> [szilles says stuff about bookmarks etc]
  458. # [01:47] <fantasai> molly: I agree.
  459. # [01:47] <fantasai> molly: Need consistency, and say explicit about how it needss to be done
  460. # [01:47] <fantasai> hober: HTML5 doesn't say much about what the video controls should be
  461. # [01:48] <fantasai> howcome: Depending on what the device is, might have different controls
  462. # [01:48] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
  463. # [01:48] <fantasai> Florian: Say what capabilities it has
  464. # [01:48] <fantasai> molly: I want to step back a moment,I understood that if you use these features and allow the UA specific ontrols, that you wil be able to style those ocntrols
  465. # [01:49] <fantasai> Florian: If you want to style it, you build it yourself.
  466. # [01:49] <fantasai> molly: ok
  467. # [01:49] <fantasai> hober: Ua could provide some hook into its controls, but that's up to the UA
  468. # [01:49] <fantasai> molly: As long as ppl can create their own controls
  469. # [01:49] * Quits: lgombos (Laszlo@63.145.238.4) (Ping timeout)
  470. # [01:49] <fantasai> Bert: As longas I as the user can override what the author does
  471. # [01:49] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
  472. # [01:49] <fantasai> Bert: I want consistency across pages. I choose my browser.
  473. # [01:50] <fantasai> fantasai: If the author says, don't put controls, and builds his own out of JS, and the user is lke "I can't deal with these weird controls, I want my own controls", how do you deal with that?
  474. # [01:51] <fantasai> Florian: Turning on the UA controls is easy. Killing the author controls is not so much.
  475. # [01:51] <fantasai> szilles: Also need ot make sure ther eare screenreader APIs for this.
  476. # [01:51] <fantasai> discussion of accessibility apis and what they're capable of
  477. # [01:51] <mmielke> Links to the Regions based demo (runs on win8 developer preview): http://code.msdn.microsoft.com/windowsapps/Dynamic-Region-Templates-94bc9c95
  478. # [01:51] <fantasai> molly: When you're looking at this content anyway, the ocntent is linearized in your core document
  479. # [01:51] <fantasai> szilles: With regions you can mix streams
  480. # [01:52] <fantasai> alex: I think this should be a display property
  481. # [01:52] <fantasai> alex: If it's overflow property, it applies to everything. But paging a flexbox doesn't make sense.
  482. # [01:53] <fantasai> alex: All other kinds of layout that support overflow don't need to support paged overflow
  483. # [01:53] <fantasai> plinss: Don't see why you can't paginate flexbox
  484. # [01:53] <fantasai> howcome: I'd really like to publish another WD of GCPM.
  485. # [01:54] <fantasai> howcome: We haven't gone through everything, so we can have big disclaimers about syntax and everything
  486. # [01:54] <fantasai> howcome: But I'd like to get out another WD. First for updates to other things. But second there seems to be consensus that we want to work on this.
  487. # [01:54] <fantasai> glazou: Don't have consensus, have interest
  488. # [01:54] <fantasai> glazou: So provided you document all the issues and comments.
  489. # [01:54] <fantasai> glazou: It's only a WD and we have interest in the feature
  490. # [01:55] <fantasai> szilles: I'm def interested in the feature, but not sure where it belongs
  491. # [01:55] <fantasai> fantasai: It can start here, and then we'll see where it goes. Just like everything else.
  492. # [01:55] <fantasai> TabAtkins: Move counter styles to css3-lists? most is already in css3-lists. Willing to take on the next thing
  493. # [01:56] <fantasai> dbaron: I think there's a bunch of things in this spec, and not a whole lot of interest in other things in the spec
  494. # [01:56] <fantasai> fantasai: we're doing that already
  495. # [01:56] <fantasai> dbaron: So we're going with the model that everything we want will go out of it?
  496. # [01:56] * Quits: YUMA (yuma@63.145.238.4) (Quit: TakIRC)
  497. # [01:56] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
  498. # [01:56] <fantasai> howcome: Like John said, I don't think this will ever go to REC
  499. # [01:57] <fantasai> s/this/this module/
  500. # [01:57] <fantasai> glazou: Any objection to publishing?
  501. # [01:57] <fantasai> RESOLVED: Publish CSS3 GCPM as soon as all edits are made
  502. # [01:57] * Quits: smfr (smfr@63.145.238.4) (Quit: smfr)
  503. # [01:57] * Quits: JohnJansen (JohnJansen@63.145.238.4) (Quit: JohnJansen)
  504. # [01:57] * Joins: cslye_ (cslye@63.145.238.4)
  505. # [01:57] * Quits: cslye_ (cslye@63.145.238.4) (Quit: cslye_)
  506. # [01:57] <fantasai> glazou: Reminder, lot of joint meetings tomorrow, not necessarily in this room
  507. # [01:57] <fantasai> glazou: Also FXTF on Thursday
  508. # [01:57] <fantasai> glazou: Start here tomorrow.
  509. # [01:58] * Quits: stearns (anonymous@63.145.238.4) (Quit: stearns)
  510. # [01:58] <fantasai> glazou: We will discuss CSSOM with Anne at 9am
  511. # [01:58] * Joins: szilles (chatzilla@63.145.238.4)
  512. # [01:58] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
  513. # [01:58] * Quits: jdaggett_ (jdaggett@63.145.238.4) (Quit: jdaggett_)
  514. # [01:58] * Quits: shan (soonbo.han@63.145.238.4) (Quit: Leaving)
  515. # [01:58] * Quits: glazou (glazou@63.145.238.4) (Quit: glazou)
  516. # [01:58] * ed agenda for the FXTF meeting: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_TPAC
  517. # [01:58] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
  518. # [01:58] <fantasai> fantasai: jdagget, kojiishii and I will be having a joint meeting with the UTC on Thursday
  519. # [01:59] * Quits: bradk_ (bradk@63.145.238.4) (Quit: Computer has gone to sleep)
  520. # [01:59] * Quits: cslye (cslye@192.150.10.200) (Ping timeout)
  521. # [01:59] * Quits: dbaron (dbaron@63.145.238.4) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  522. # [01:59] * Quits: dino (dino@63.145.238.4) (Quit: dino)
  523. # [02:00] * Quits: florian (florianr@63.145.238.4) (Ping timeout)
  524. # [02:00] * Quits: kimberlyblessing (Kimberly@63.145.238.4) (Ping timeout)
  525. # [02:00] * Quits: mollydotcom (mollyh@63.145.238.4) (Client exited)
  526. # [02:01] * Quits: sylvaing (sylvaing@63.145.238.4) (Ping timeout)
  527. # [02:01] * Quits: jun (fujisawa@63.145.238.4) (Quit: jun)
  528. # [02:01] * Quits: wangsi-wei (wang@63.145.238.4) (Quit: wangsi-wei)
  529. # [02:01] * Joins: wangsi-wei (wang@63.145.238.4)
  530. # [02:01] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
  531. # [02:01] * Quits: arronei (arronei@63.145.238.4) (Ping timeout)
  532. # [02:02] * Quits: alexmog (alexmog@63.145.238.4) (Ping timeout)
  533. # [02:03] * Joins: tpod (tpod@63.145.238.4)
  534. # [02:04] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
  535. # [02:04] * Quits: wangsi-wei (wang@63.145.238.4) (Ping timeout)
  536. # [02:05] * Joins: glazou (glazou@63.145.238.4)
  537. # [02:06] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
  538. # [02:06] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
  539. # [02:07] * Quits: TabAtkins_ (tabatkins@63.145.238.4) (Ping timeout)
  540. # [02:07] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
  541. # [02:07] * Quits: tcelik (tantek_@63.145.238.4) (Quit: tcelik)
  542. # [02:09] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
  543. # [02:09] * Quits: kojiishi (kojiishi@63.145.238.4) (Ping timeout)
  544. # [02:12] * Joins: paul_irish (paul_irish@76.14.88.222)
  545. # [02:13] * Quits: paul_irish (paul_irish@76.14.88.222) (Client exited)
  546. # [02:15] * Quits: mmielke (mmielke@63.145.238.4) (Ping timeout)
  547. # [02:15] * Joins: paul_irish (paul_irish@76.14.88.222)
  548. # [02:17] * Quits: chsiao (chatzilla@63.145.238.4) (Ping timeout)
  549. # [02:17] * Quits: howcome (howcome@63.145.238.4) (Ping timeout)
  550. # [02:18] * Quits: tpod (tpod@63.145.238.4) (Ping timeout)
  551. # [02:24] * Quits: glazou (glazou@63.145.238.4) (Quit: glazou)
  552. # [02:30] * Joins: arronei (arronei@131.107.0.84)
  553. # [02:30] * Quits: arronei_ (arronei@131.107.0.119) (Ping timeout)
  554. # [02:32] * Joins: tpod (tpod@63.145.238.4)
  555. # [02:37] * Joins: sylvaing (sylvaing@63.145.238.4)
  556. # [02:38] * Joins: tpod_ (tpod@63.145.238.4)
  557. # [02:39] * Quits: tpod (tpod@63.145.238.4) (Ping timeout)
  558. # [02:39] * tpod_ is now known as tpod
  559. # [02:42] * Quits: tpod (tpod@63.145.238.4) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
  560. # [02:43] * Quits: vhardy (vhardy@192.150.10.200) (Ping timeout)
  561. # [02:48] * Joins: myakura (myakura@209.119.68.98)
  562. # [02:51] * Joins: nimbupani (Adium@27.7.20.144)
  563. # [02:52] * Joins: myakura_ (myakura@209.119.68.98)
  564. # [02:52] * Quits: myakura (myakura@209.119.68.98) (Connection reset by peer)
  565. # [02:59] * Quits: paul_irish (paul_irish@76.14.88.222) (Client exited)
  566. # [03:00] * Quits: nimbupani (Adium@27.7.20.144) (Client exited)
  567. # [03:00] * Joins: nimbupani (Adium@27.7.20.144)
  568. # [03:08] * Quits: sylvaing (sylvaing@63.145.238.4) (Ping timeout)
  569. # [03:16] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
  570. # [03:16] * Joins: nimbupani (Adium@27.7.20.144)
  571. # [03:17] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
  572. # [03:25] * Joins: nimbupani (Adium@27.7.20.144)
  573. # [03:28] * Joins: myakura (myakura@209.119.68.98)
  574. # [03:28] * Quits: myakura_ (myakura@209.119.68.98) (Connection reset by peer)
  575. # [03:28] * Joins: paul_irish (paul_irish@69.181.215.45)
  576. # [03:28] * Quits: homata (homata@58.158.182.50) (Quit: Leaving...)
  577. # [03:30] * Quits: paul_irish (paul_irish@69.181.215.45) (Client exited)
  578. # [03:32] * Joins: myakura_ (myakura@209.119.68.98)
  579. # [03:32] * Quits: myakura (myakura@209.119.68.98) (Connection reset by peer)
  580. # [03:35] * Joins: homata (homata@58.158.182.50)
  581. # [03:37] * Joins: myakura (myakura@209.119.68.98)
  582. # [03:37] * Quits: myakura_ (myakura@209.119.68.98) (Connection reset by peer)
  583. # [03:42] * Joins: sylvaing (sylvaing@209.119.68.98)
  584. # [03:42] * Quits: sylvaing (sylvaing@209.119.68.98) (Quit: sylvaing)
  585. # [03:48] * Joins: myakura_ (myakura@209.119.68.98)
  586. # [03:48] * Quits: myakura (myakura@209.119.68.98) (Connection reset by peer)
  587. # [03:50] * Joins: myakura (myakura@209.119.68.98)
  588. # [03:50] * Quits: myakura_ (myakura@209.119.68.98) (Connection reset by peer)
  589. # [04:01] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
  590. # [04:26] * Joins: lgombos (Laszlo@209.119.68.98)
  591. # [04:27] * Joins: nimbupani (Adium@27.7.20.144)
  592. # [04:45] * Joins: myakura_ (myakura@209.119.68.98)
  593. # [04:45] * Quits: myakura (myakura@209.119.68.98) (Connection reset by peer)
  594. # [04:46] * Joins: dsinger (dsinger@68.126.183.95)
  595. # [04:58] * Quits: lgombos (Laszlo@209.119.68.98) (Quit: Leaving)
  596. # [05:11] * Quits: jwir3 (qw3birc@128.30.52.28) (Ping timeout)
  597. # [05:20] * Joins: szilles (chatzilla@24.6.120.172)
  598. # [05:23] * Quits: dcosta (dcosta@187.31.77.7) (Connection reset by peer)
  599. # [05:24] * Quits: szilles (chatzilla@24.6.120.172) (Ping timeout)
  600. # [05:24] * Joins: szilles (chatzilla@24.6.120.172)
  601. # [05:27] * Joins: chsiao (chatzilla@24.6.101.192)
  602. # [05:31] * Quits: szilles (chatzilla@24.6.120.172) (Ping timeout)
  603. # [05:32] * Quits: chsiao (chatzilla@24.6.101.192) (Quit: ChatZilla 0.9.87 [Firefox 6.0.2/20110902133214])
  604. # [05:34] * Joins: kojiishi (kojiishi@209.119.68.98)
  605. # [06:07] * Joins: stearns (anonymous@209.119.68.98)
  606. # [06:08] * Joins: dino (dino@75.16.26.133)
  607. # [06:08] * Quits: kojiishi (kojiishi@209.119.68.98) (Ping timeout)
  608. # [06:14] * Quits: homata (homata@58.158.182.50) (Ping timeout)
  609. # [06:14] * Joins: homata (homata@58.158.182.50)
  610. # [06:16] * Joins: kojiishi (kojiishi@209.119.68.98)
  611. # [06:22] * Joins: gilles (gilles@204.14.156.63)
  612. # [06:29] * Joins: tpod (tpod@98.210.10.195)
  613. # [06:34] * Quits: kojiishi (kojiishi@209.119.68.98) (Ping timeout)
  614. # [06:38] * Quits: gilles (gilles@204.14.156.63) (Client exited)
  615. # [06:39] * Joins: gilles (gilles@204.14.156.63)
  616. # [06:43] * Joins: arno (arno@208.87.61.130)
  617. # [06:46] * Joins: homata_ (homata@58.158.182.50)
  618. # [06:47] * Quits: homata (homata@58.158.182.50) (Ping timeout)
  619. # [06:48] * Quits: homata_ (homata@58.158.182.50) (Quit: Leaving...)
  620. # [07:05] * Quits: tpod (tpod@98.210.10.195) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
  621. # [07:07] * Quits: arno (arno@208.87.61.130) (Quit: Leaving.)
  622. # [07:10] * Quits: gilles (gilles@204.14.156.63) (Quit: gilles)
  623. # [07:36] * Joins: gilles (gilles@204.14.156.63)
  624. # [07:37] * Quits: gilles (gilles@204.14.156.63) (Quit: gilles)
  625. # [07:40] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
  626. # [07:40] * Quits: stearns (anonymous@209.119.68.98) (Quit: stearns)
  627. # [08:17] * Joins: tantek (tantek@70.36.139.219)
  628. # [08:50] * Quits: dino (dino@75.16.26.133) (Quit: dino)
  629. # [09:10] * Quits: myakura_ (myakura@209.119.68.98) (Client exited)
  630. # [09:35] * Joins: Ms2ger (Ms2ger@91.181.84.233)
  631. # [09:45] * Quits: plinss_ (plinss@68.107.116.103) (Ping timeout)
  632. # [09:56] * Joins: drublic (drublic@77.2.149.184)
  633. # [10:10] * Joins: nimbupani (Adium@27.7.20.144)
  634. # [10:23] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
  635. # [10:32] * Joins: nimbupani (Adium@27.7.20.144)
  636. # [10:41] * Quits: drublic (drublic@77.2.149.184) (Client exited)
  637. # [10:55] * Joins: drublic (drublic@93.132.231.203)
  638. # [10:55] * Quits: drublic (drublic@93.132.231.203) (Client exited)
  639. # [10:56] * Joins: drublic (drublic@93.132.231.203)
  640. # [11:48] * Zakim excuses himself; his presence no longer seems to be needed
  641. # [11:48] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  642. # [13:21] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
  643. # [13:23] * Joins: nimbupani (Adium@27.7.20.144)
  644. # [13:23] * Joins: gilles (gilles@204.14.156.63)
  645. # [13:29] * Quits: gilles (gilles@204.14.156.63) (Quit: gilles)
  646. # [13:34] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
  647. # [13:34] * Joins: drublic_ (drublic@77.2.128.229)
  648. # [13:36] * Quits: drublic (drublic@93.132.231.203) (Ping timeout)
  649. # [13:36] * Quits: drublic_ (drublic@77.2.128.229) (Client exited)
  650. # [13:36] * Joins: drublic (drublic@77.2.128.229)
  651. # [13:42] * Quits: drublic (drublic@77.2.128.229) (Ping timeout)
  652. # [13:47] * Joins: drublic (drublic@77.2.147.143)
  653. # [14:12] * Joins: miketaylr (miketaylr@206.217.92.186)
  654. # [14:24] * Joins: karl (karlcow@128.30.54.58)
  655. # [14:29] * Quits: Ms2ger (Ms2ger@91.181.84.233) (Quit: bbl)
  656. # [15:09] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
  657. # [15:19] * Joins: miketayl_r (miketaylr@206.217.92.186)
  658. # [15:21] * Quits: miketaylr (miketaylr@206.217.92.186) (Ping timeout)
  659. # [15:21] * Joins: stearns (anonymous@209.119.68.98)
  660. # [15:26] * Quits: dsinger (dsinger@68.126.183.95) (Quit: dsinger)
  661. # [15:27] * Quits: miketayl_r (miketaylr@206.217.92.186) (Connection reset by peer)
  662. # [15:27] * Joins: miketaylr (miketaylr@206.217.92.186)
  663. # [15:37] * Joins: tcelik (tantek_@70.36.139.219)
  664. # [15:40] * Quits: tcelik (tantek_@70.36.139.219) (Quit: tcelik)
  665. # [15:41] * Joins: plinss (plinss@63.145.238.4)
  666. # [15:42] * Joins: arno (arno@208.87.61.130)
  667. # [15:44] * Joins: tcelik (tantek_@70.36.139.219)
  668. # [15:46] * Quits: tcelik (tantek_@70.36.139.219) (Quit: tcelik)
  669. # [15:46] * Quits: tantek (tantek@70.36.139.219) (Quit: tantek)
  670. # [15:46] * Quits: stearns (anonymous@209.119.68.98) (Quit: stearns)
  671. # [15:52] * Quits: miketaylr (miketaylr@206.217.92.186) (Connection reset by peer)
  672. # [15:52] * Joins: miketayl_r (miketaylr@206.217.92.186)
  673. # [15:52] * Joins: florian (florianr@209.119.68.98)
  674. # [15:57] * Quits: florian (florianr@209.119.68.98) (Ping timeout)
  675. # [15:57] * Joins: gilles (gilles@63.145.238.4)
  676. # [15:57] * Joins: stearns (anonymous@63.145.238.4)
  677. # [15:59] * Quits: arno (arno@208.87.61.130) (Quit: Leaving.)
  678. # [16:04] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
  679. # [16:08] * Joins: r12a (rishida@128.30.52.169)
  680. # [16:14] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
  681. # [16:18] * Joins: mmielke (mmielke@63.145.238.4)
  682. # [16:24] * Joins: myakura (myakura@209.119.68.98)
  683. # [16:25] * Quits: stearns (anonymous@63.145.238.4) (Quit: stearns)
  684. # [16:26] * Joins: arno (arno@192.150.10.200)
  685. # [16:31] * Joins: stearns (anonymous@63.145.238.4)
  686. # [16:33] * Joins: karl (karlcow@128.30.54.58)
  687. # [16:35] * Quits: myakura (myakura@209.119.68.98) (Client exited)
  688. # [16:39] * Joins: kojiishi (kojiishi@209.119.68.98)
  689. # [16:43] * Joins: shan (soonbo.han@63.145.238.4)
  690. # [16:45] * Joins: arronei_ (arronei@63.145.238.4)
  691. # [16:49] * Joins: bradk (bradk@63.145.238.4)
  692. # [16:52] * Joins: duga (duga@63.145.238.4)
  693. # [16:53] * Joins: dsinger (dsinger@63.145.238.4)
  694. # [16:53] * Joins: Ruinan (sunruinan@63.145.238.4)
  695. # [16:54] * Joins: gilles (gilles@63.145.238.4)
  696. # [16:55] * Joins: dbaron (dbaron@63.145.238.4)
  697. # [16:56] * Quits: kojiishi (kojiishi@209.119.68.98) (Ping timeout)
  698. # [16:57] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
  699. # [17:02] * Joins: myakura (myakura@63.145.238.4)
  700. # [17:02] * Joins: sylvaing (sylvaing@63.145.238.4)
  701. # [17:02] * Joins: gilles (gilles@63.145.238.4)
  702. # [17:03] * Joins: anne (annevk@63.145.238.4)
  703. # [17:03] * Joins: lgombos (Laszlo@63.145.238.4)
  704. # [17:04] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
  705. # [17:04] * Joins: mihara (mihara@63.145.238.4)
  706. # [17:05] * Joins: glazou (glazou@63.145.238.4)
  707. # [17:06] * Joins: plinss (plinss@63.145.238.4)
  708. # [17:06] <sylvaing> scribenick: sylvaing
  709. # [17:06] <dbaron> Topic: CSSOM
  710. # [17:07] * Joins: YUMA (yuma@63.145.238.4)
  711. # [17:07] <sylvaing> annevk: the CSSOM is a collection of various CSS features exposed through script
  712. # [17:07] <sylvaing> annevk: such as alternate stylesheets, stylesheets themselves
  713. # [17:08] <sylvaing> annevk: and a new part is CSS values which is very new
  714. # [17:08] <sylvaing> annevk: we are now waiting for implementation experience for CSS values
  715. # [17:09] <sylvaing> florian: we had talked about defining serialization
  716. # [17:09] <sylvaing> annevk: nothing new at this point
  717. # [17:10] <sylvaing> fantasai,annevk: we had talked about defining the serialization of basic types in a Serialization module
  718. # [17:10] * Joins: shans (qw3birc@128.30.52.28)
  719. # [17:11] * Quits: arno (arno@192.150.10.200) (Ping timeout)
  720. # [17:11] * Joins: Kai (chatzilla@63.145.238.4)
  721. # [17:11] * Joins: arno (arno@192.150.10.200)
  722. # [17:12] <sylvaing> fantasai: most of them were in CSS2.1 or should be new units in css3-values and Color
  723. # [17:12] * Joins: jdaggett_ (jdaggett@63.145.238.4)
  724. # [17:12] * Joins: si-wei (si-wei@63.145.238.4)
  725. # [17:13] * Joins: kimberlyblessing (Kimberly@63.145.238.4)
  726. # [17:13] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
  727. # [17:13] <sylvaing> jdaggett: there may a problem with the way we've modularized; some modules need to rev often than others. CSSOM is one of those
  728. # [17:13] * Joins: vhardy (vhardy@192.150.10.201)
  729. # [17:13] <sylvaing> Tab: some specs need to be 'living' ?
  730. # [17:14] <sylvaing> fantasai: that was the case for many modules. hence the modularization
  731. # [17:14] <sylvaing> jdaggett: if I add an at-rule I need a DOM interface so I'm adding things that should be in the OM
  732. # [17:14] <sylvaing> annevk: if you add an at-rule you should define all the related OM pieces in the same place
  733. # [17:15] <sylvaing> florian: the problem we have right now is bootstrapping. we don't have a 2.1 for serialization
  734. # [17:15] * Joins: kojiishi (kojiishi@63.145.238.4)
  735. # [17:15] <sylvaing> s/florian/fantasai
  736. # [17:15] <sylvaing> fantasai: until we have that we will be discussing process
  737. # [17:16] * Joins: miketaylr (miketaylr@206.217.92.186)
  738. # [17:16] <sylvaing> glazou: we're also going to talk about the OM forever until we fix its issues and implement the fixes
  739. # [17:16] * Quits: miketaylr (miketaylr@206.217.92.186) (Client exited)
  740. # [17:16] * Quits: miketayl_r (miketaylr@206.217.92.186) (Connection reset by peer)
  741. # [17:16] * Joins: miketaylr (miketaylr@206.217.92.186)
  742. # [17:16] <sylvaing> glazou: we need a better OM
  743. # [17:17] <sylvaing> tantek: I agree we need a foundational OM spec.
  744. # [17:17] * Joins: shepazu (shepazu@128.30.52.169)
  745. # [17:18] <fantasai> +1
  746. # [17:18] <sylvaing> tantek: just like HTML went through a painful process of defining an OM in sync with content out there. Starting with a known feature set would be easier and establish a baseline
  747. # [17:18] <fantasai> tantek: Instead of redrawing module lines, we should start by creating an OM for CSS 2.1
  748. # [17:19] <sylvaing> jdaggett: we do not have a consistently defined DOM interface. some modules define new at-rules but implementations may be using different rule constants which should be coordinated across specs
  749. # [17:19] * Joins: howard (howard_wan@63.145.238.4)
  750. # [17:20] <sylvaing> jdaggett: there is no one looking at these features from an OM perspective. It's up to each editor and each editor's level of OM experience e.g. some modules will not define exceptions correctly
  751. # [17:20] <sylvaing> jdaggett: so specs are inconsistent
  752. # [17:20] <sylvaing> tantek: I suggest the common reference baseline would be a 2.1 OM
  753. # [17:20] <sylvaing> jdaggett: how does that help with new features
  754. # [17:21] * Joins: alexmog (alexmog@63.145.238.4)
  755. # [17:21] <sylvaing> fantasai: like non OM features, most new OM features derive from existing features in 2.1 and you would have patterns to base new interfaces on
  756. # [17:22] <sylvaing> jdaggett: the pattern for what you have to do to specify a new at-rule is not defined; I'm not sure a 2.1 OM defines it. how is that different from what we have now ?
  757. # [17:22] * Joins: florian (florianr@63.145.238.4)
  758. # [17:22] <sylvaing> jdaggett: I think we need more: at least a set of how-to guidelines e.g. if you define a new at-rule, these are the things you need to specify
  759. # [17:23] <sylvaing> tantek: we agree on goals, we're only discussing how to get there
  760. # [17:23] <sylvaing> jdaggett: I don't think we even have consensus on issues such as prefixed at-rules and how this relates to at-rule constants
  761. # [17:24] <sylvaing> glazou: this should definitely be specified
  762. # [17:24] <sylvaing> tantek: we should reach a bar where each module should define its DOM
  763. # [17:24] <fantasai> Proposal: Modularize CSSOM. Break it up into a a Serialization module, a Values module, an At-Rules module, a Media Queries module, etc.
  764. # [17:25] <sylvaing> tantek: keeping things separately did not help HTML
  765. # [17:26] <sylvaing> dbaron: there are modules how define their own OM e.g. Transitions (events), Animations (OM), Fonts, Conditional....
  766. # [17:26] <sylvaing> dbaron,annevk: Transforms has a value type but we agreed to deprecate the CSSValue type it uses
  767. # [17:27] <sylvaing> tantek: I think we need something that is up to date with 2.1
  768. # [17:27] <sylvaing> dbaron: part of the base problem is that DOM L2 Style has a number of features that are wrong, and a number of things we agreed to change but never fixed
  769. # [17:27] * Joins: tcelik (tantek_@63.145.238.4)
  770. # [17:27] <sylvaing> dbaron: we need to define this core baseline so we can build on top of it
  771. # [17:28] <sylvaing> annevk: as far as values, we deprecated the 2003 model but never replaced it
  772. # [17:28] <sylvaing> annevk: I didn't want to spec out the new model fully until we at least had some implementation experience with it
  773. # [17:29] <sylvaing> tankek: is there interop among browsers for 2.1 CSSOM ?
  774. # [17:29] <sylvaing> dbaron: what do you mean by 2.1 ?
  775. # [17:29] <sylvaing> tantek: what is in Gecko, Webkit, Trident today ?
  776. # [17:29] <sylvaing> dbaron: I don't know if it's that that interoperable?
  777. # [17:30] <sylvaing> annevk: I don't see how reorganizing is going to help us vs. implementors working on it.
  778. # [17:30] <sylvaing> annevk: there isn't even much discussion
  779. # [17:31] <sylvaing> dbaron: also, authors don't use the OM that much
  780. # [17:31] <sylvaing> tantek: isn't it a chicken-and-egg problem; they don't because they can't
  781. # [17:32] <sylvaing> tantek: Tab was complaining about how many obsolete drafts we have. we have this problem here too e.g. DOM L2 Style.
  782. # [17:33] <sylvaing> tantek: I'd like to see something that reflects the interoperable state of the world
  783. # [17:33] <dbaron> dbaron: I think authors don't use the OM much, even what is interoperable. Authors tend to use the model that styles are static and they dynamically change the content-- and I tend to think that's a good thing.
  784. # [17:33] * Joins: matt (matt@128.30.52.169)
  785. # [17:33] * Joins: smfr (smfr@63.145.238.4)
  786. # [17:33] * Parts: matt (matt@128.30.52.169)
  787. # [17:33] <sylvaing> dbaron: if there isn't a lot of demand for it, should we spend time on it ?
  788. # [17:33] <fantasai> http://dev.w3.org/csswg/cssom/
  789. # [17:34] <sylvaing> tab: I know that there is demand for a new value based om that wouldn't be string-based. It's a popular author request that is currently done through libs like jQuery
  790. # [17:34] <sylvaing> tab: we know that there is a use-case in that area
  791. # [17:34] <sylvaing> dbaron: yes, i've seen author demand for this, as well as for variants of computed style as well as some author demand for the set of matched rules for an element
  792. # [17:35] <sylvaing> dbaron: I can't recall authors asking for poking through rules inside a stylesheet
  793. # [17:35] <sylvaing> tab: that is useful for CSS polyfills
  794. # [17:35] <sylvaing> annevk,dbaron: except the features you want to polyfill are dropped
  795. # [17:36] * Joins: cyril (chatzilla@63.145.238.4)
  796. # [17:36] * Quits: arronei_ (arronei@63.145.238.4) (Connection reset by peer)
  797. # [17:36] * Joins: arronei_ (arronei@63.145.238.4)
  798. # [17:37] <sylvaing> fantasai: I'd like to document what we have right now
  799. # [17:37] * Joins: JohnJansen (JohnJansen@63.145.238.4)
  800. # [17:37] <sylvaing> fantasai: and the new interfaces would be in a separate document
  801. # [17:38] <sylvaing> fantasai: and we can move the bit that's implemented in CR and beyond
  802. # [17:39] <sylvaing> kimberly: we as implementors are looking for guidance; we need a document that reflects what browsers do in order to build compatible devices/platforms
  803. # [17:40] * Joins: Mike5 (Mike5@mcclure.w3.org)
  804. # [17:40] <sylvaing> howcome: are we interested in investing this kind of effort ?
  805. # [17:40] <fantasai> [insert^ discussion about the fact that DOM Level 2 Style is on /TR and has not been obsoleted by anything]
  806. # [17:41] <fantasai> sylvaing: It does keep coming back.
  807. # [17:41] <fantasai> glazou: But it keeps coming back. We've been discussing this since 10 years ago.
  808. # [17:41] * Quits: vhardy (vhardy@192.150.10.201) (Connection reset by peer)
  809. # [17:41] <fantasai> glazou: Anne invested a lot of time in this spec cleaning it up
  810. # [17:41] <fantasai> glazou: Form an implementation POV, we're almost exactly at the same point
  811. # [17:41] <fantasai> dbaron: There's a bunch of things in anne's spec that have been implemented. It's just not the core stuff
  812. # [17:42] <sylvaing> dbaron: I think there are things in the spec that have been implemented. but a number of things have not been
  813. # [17:42] * Joins: chsiao (chatzilla@63.145.238.4)
  814. # [17:42] <fantasai> discussion of poking around the style sheet
  815. # [17:42] <sylvaing> discussion of how many people need editing functionality
  816. # [17:43] <sylvaing> alan: do we need a testsuite to get implementors interested ?
  817. # [17:44] * Joins: arno (arno@192.150.10.200)
  818. # [17:44] <fantasai> sylvaing: There's enough pain that this topic keeps coming back, but not enough that implementers are investing in it
  819. # [17:44] <sylvaing> tantek: since we agree to have obsoletion noticed in old modules that aren't maintained, I think we should do that for DOM L2 Style and link from the latter to CSSOM
  820. # [17:45] <sylvaing> bert: but then there is nothing stable anymore
  821. # [17:45] * Joins: dino (dino@17.202.47.159)
  822. # [17:45] <sylvaing> tantek: but that is reality and would be honest
  823. # [17:45] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
  824. # [17:45] * Joins: cyril_ (chatzilla@63.145.238.4)
  825. # [17:45] * cyril_ is now known as cyril
  826. # [17:45] * Joins: ChrisWilson (ChrisWilso@63.145.238.4)
  827. # [17:45] <sylvaing> annevk: that would be a service to the community, I think. They would at least know what we're working on now
  828. # [17:45] <sylvaing> bert: it's better but not enough
  829. # [17:46] <fantasai> annevk: we should at least have a link to the obsoletion email you sent in 2003; adding a link to the CSSOM would be helpful, but not critical imo
  830. # [17:47] <sylvaing> glazou, jdaggett: the specs are not understandable or usable hence the attraction of jQuery as a way to use the OM
  831. # [17:47] <sylvaing> jdaggett: is it OK to mark specific sections as obsolete at least ?
  832. # [17:48] <sylvaing> glazou: yes
  833. # [17:48] <sylvaing> jdaggett: so CSS values in DOM L2 Style in marked invalid, not the entire spec
  834. # [17:48] <sylvaing> hober: that can also be marked at the top
  835. # [17:48] <sylvaing> glazou: I don't want the entire document to be obsoleted
  836. # [17:49] <sylvaing> plinss: is the problem unaware of the Editor's Draft ? is that the problem ?
  837. # [17:50] * Joins: MoZ (MoZ@63.145.238.4)
  838. # [17:50] <fantasai> various people giving examples of this actually being a problem
  839. # [17:50] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
  840. # [17:50] <sylvaing> dbaron: there are 2 threads here; the value API and the representation of style sheets e.g. at-rules
  841. # [17:51] <sylvaing> glazou: I don't understand why we don't have a requirements document for this
  842. # [17:51] <fantasai> RESOLVED: Add obsoletion notice stating which sections of DOM Level 2 style are obsolete, links to Bert's obsoletion notice, and links to the CSSOM editor's draft
  843. # [17:51] <sylvaing> RESOLVED: add a notice to the top DOM L2 Style indicating portions of the spec are obsolete linking to Bert's email and linking to CSSOM. Also, the specific obsolete section of DOM L2 Style must be marked as such
  844. # [17:51] * Joins: r12a (rishida@128.30.52.169)
  845. # [17:52] <fantasai> ACTION Tab: Draft note on DOM Level 2 Style
  846. # [17:52] * trackbot noticed an ACTION. Trying to create it.
  847. # [17:52] * RRSAgent records action 16
  848. # [17:52] <trackbot> Created ACTION-395 - Draft note on DOM Level 2 Style [on Tab Atkins Jr. - due 2011-11-08].
  849. # [17:53] <sylvaing> fantasai: once we agree on the draft notice, we can resolve a PER
  850. # [17:54] <sylvaing> dbaron: the things people do with jQuery relates to the value API; editing tools need both the value API as well as the stylesheet traversal interface. The latter is not that hard but the current specs are inconsistent and poorly written, but 80% right
  851. # [17:55] <sylvaing> dbaron: we decided to throw out the value API and rewrite it but the new API is a draft that no one has implemented
  852. # [17:55] <fantasai> annevk: Only part of the values API is there
  853. # [17:55] <fantasai> dbaron: If someone tried to implement it, what would happen?
  854. # [17:55] <sylvaing> sylvaing: does one need to implement it in the engine or could it be experimented with in JS ?
  855. # [17:56] <fantasai> jdaggett: If it's not a big API...
  856. # [17:56] <sylvaing> annevk: it could be done in JS
  857. # [17:56] <fantasai> dbaron: It's a pretty big API
  858. # [17:57] <fantasai> jdaggett: It seems we have two modules here. I keep hearing that we need something in a firmer state, and the Values API is not in that state
  859. # [17:57] <fantasai> annevk: I don't think we need to split the draft.
  860. # [17:58] <sylvaing> jdaggett: I think the stylesheet traversal API has more impact on new features
  861. # [17:58] <sylvaing> dbaron: it depends on the feature. if we implement the new values API, this would impact CSS3 Fonts features e.g. font-feature-settings would need a whole object model
  862. # [17:59] * Joins: AnanKan (AnanKan@63.145.238.4)
  863. # [17:59] <sylvaing> jadaggett, dbaron: there is no consistency of design among the at-rule definitions across modules
  864. # [17:59] <sylvaing> annevk: shouldn't that be solved by review ?
  865. # [17:59] <sylvaing> tab: we should have guidelines before review
  866. # [18:00] * Joins: Rossen (Rossen@63.145.238.4)
  867. # [18:00] <sylvaing> dbaron: the OM for keyframes rule looks different from what's in 2.1 but it was already implemented so I followed the same model.
  868. # [18:01] * Joins: arno (arno@192.150.10.200)
  869. # [18:01] <anne> I have to go in four minutes
  870. # [18:01] <sylvaing> dbaron: as far as we can tell, it's unclear that the people who use these interfaces care about these inconsistencies
  871. # [18:02] <fantasai> Florian: The people who care do not give sufficient feedback
  872. # [18:02] <sylvaing> dbaron: one of the ways we judge interest in things is based on feedback on obvious problems
  873. # [18:03] <sylvaing> glazou: and maybe they don't have to comment because there are shims like jQuery which deal with the problem
  874. # [18:03] <fantasai> plinss: If something is bad enough, people look at it and decide it's way to unstable, way too much of a mess, to comment on
  875. # [18:03] <sylvaing> dbaron: that is the values API, not the stylesheet interface. they're not the same thing.
  876. # [18:04] <sylvaing> fantasai: I edit a lot of specs. I don't know what I need to put in my spec about serialization, OM, values API. I don't know what to do in CSS3 because there is nothing stable for me to build on top of
  877. # [18:05] <sylvaing> fantasai: once I have something stable then I can reference it and update my modules.
  878. # [18:05] * Quits: anne (annevk@63.145.238.4) (Quit: anne)
  879. # [18:05] <sylvaing> fantasai: maybe serialization is stable enough so I could reference it but if stable and unstable things are in the same module I don't know what to do
  880. # [18:05] <tcelik> I've updated http://wiki.csswg.org/spec/cssom with notes about what people have claimed are author demands. More evidence / statements welcome.
  881. # [18:06] <sylvaing> jdaggett: I think we need to have someone else co-edit to ensure we document implementation reality
  882. # [18:07] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
  883. # [18:07] <fantasai> glazou: John is proposing to have a document reflecting current implementations
  884. # [18:07] <fantasai> glazou: I'm not sure that the current implementations are so inconsistent that this is undoable
  885. # [18:07] <fantasai> glazou: Getting a stable spec, that only consists of the stable specs, I don't know that that's useful
  886. # [18:08] <fantasai> Florian: If you ask me what the stable parts are, I have no idea.
  887. # [18:08] <fantasai> jdaggett: I think there is value here. If you have a spec that focuses the set of features that have impelemtnations, even if they are inconsistent,
  888. # [18:08] <fantasai> jdaggett: Trying to iron out those variations, that's value. Even if it's not sexy, it's still value.
  889. # [18:08] <fantasai> jdaggett: I don't know that it has to be another spec, but we need to get the existing CSSOM spec ...
  890. # [18:09] <fantasai> glazou: I think what you want is a better use of our time to add warning notes to the current DOM Level 2 spec than what you're proposing
  891. # [18:09] <fantasai> arronei: This is what our test suites do
  892. # [18:09] <fantasai> Tantek: I'm going to object John's assertion that we need another oc-editor, the editor's draft was lately updated
  893. # [18:09] <fantasai> jdaggett: Editing the draft doesn't ensure it's moving towards something stable
  894. # [18:10] * Joins: lgombos_ (Laszlo@63.145.238.4)
  895. # [18:10] <fantasai> Tantek: Let's work cooperatively within existing mechanism
  896. # [18:10] * Joins: dcosta (dcosta@187.31.77.7)
  897. # [18:10] * Quits: lgombos (Laszlo@63.145.238.4) (Ping timeout)
  898. # [18:10] <fantasai> Tantek: Oftentimes when another editor is needed for something, it's not due..
  899. # [18:10] <fantasai> Florian: Anne is not interested in documenting the existing bits,, he 
  900. # [18:11] <glazou> test
  901. # [18:11] <sylvaing> tantek: writing down what works today, I just want to establish how. can we write it down on the wiki page ?
  902. # [18:11] <sylvaing> tantek: i just want to capture the request that we want to know what implementations do
  903. # [18:12] * Joins: arno (arno@192.150.10.200)
  904. # [18:12] <fantasai> sylvaing: Anne is definitely the right guy for the values API, but he's not interested in doing the documenting existing stuff
  905. # [18:12] <fantasai> sylvaing: Putting things on a wiki page doesn't make them happen
  906. # [18:13] <fantasai> szilles: you can't tell whether they'll happen until you put them there
  907. # [18:13] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
  908. # [18:13] <fantasai> <br duration=5m>
  909. # [18:14] * Quits: ChrisWilson (ChrisWilso@63.145.238.4) (Quit: Leaving.)
  910. # [18:16] * Quits: bradk (bradk@63.145.238.4) (Quit: Computer has gone to sleep)
  911. # [18:17] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
  912. # [18:20] <fantasai> </br>
  913. # [18:20] <fantasai> Topic: IDPF Joint WG meeting
  914. # [18:20] <fantasai> +Brady Duga
  915. # [18:20] <fantasai> +Bill McCoy
  916. # [18:20] <fantasai> +Peter Sorotkin
  917. # [18:21] <fantasai> duga: The Advanced Layout group of IPDF is going to begin work shortly
  918. # [18:21] <fantasai> duga: our members have been clamoring for more powerful design, adaptive design, for page layout
  919. # [18:21] <fantasai> duga: Right now when people want to do high design, they go back to JPEG, abspos, things that don't work well for multiple-size devices
  920. # [18:21] <fantasai> duga: A proposal was made by adobe in PEU3 for more adaptive layout
  921. # [18:21] * Joins: bradk (bradk@63.145.238.4)
  922. # [18:22] <fantasai> duga: Didn't make it into 3, but portions of it turned into CSS Regions and Exclusions
  923. # [18:22] * Quits: dino (dino@17.202.47.159) (Client exited)
  924. # [18:22] <fantasai> duga: There's still a whole bunch of things not in those specs
  925. # [18:22] * Joins: ChrisWilson (ChrisWilso@63.145.238.4)
  926. # [18:22] * Quits: MoZ (MoZ@63.145.238.4) (Quit: This computer has gone to sleep)
  927. # [18:22] * Joins: dino (dino@17.202.47.159)
  928. # [18:22] <fantasai> duga: There's still a lot of clamoring for advanced adaptive layout features in a very short timeframe
  929. # [18:22] * Joins: fukuno (fukuno@63.145.238.4)
  930. # [18:22] <fantasai> jdaggett: There's a bi disconnect that I see between the way EPUB makes their specifications and the work that actually needs to get done.
  931. # [18:23] <fantasai> jdaggett: If you define a schedule and then try to match features to that schedule, anyone in software will tell you that that doesn't work
  932. # [18:23] <fantasai> jdaggett: Especially where complexity is involved
  933. # [18:23] * Joins: Rossen (Rossen@63.145.238.4)
  934. # [18:23] * Joins: arno (arno@192.150.10.200)
  935. # [18:23] * Joins: MoZ (MoZ@63.145.238.4)
  936. # [18:23] <fantasai> jdaggett: And when you talk about compelx layouts in CSS, that's by def complex
  937. # [18:23] <fantasai> bill: The reason we're here is to make sure whe ahve a connection
  938. # [18:23] <fantasai> jdaggett: A schedule-driven process will not get you something that will be interoperable.
  939. # [18:23] <fantasai> jdaggett: The way EPUB has operated i nthe past is on-schedule. Whatever you're delivering is built on quicksand
  940. # [18:23] <Bert> -> http://code.google.com/p/epub-revision/wiki/AdvancedAdaptiveLayoutCharter IDPF Advanced Adaptive Layout working group charter
  941. # [18:24] <fantasai> jdaggett: You're referencing working drafts of this WG, and those chang.e
  942. # [18:24] <fantasai> jdaggett: Rather than talk about scheduling, it's much more important to look at for the work of this group, where are the problems that are holding up things. And contribute from that angle. Rather than ctalking about scheduling
  943. # [18:24] <fantasai> jdaggett: I think basically proposals are here. Would be more helpful if members at EPUB were focusing on what is needed to work out the problems associated with the various feature sthat re being proposed.
  944. # [18:25] <fantasai> jdaggett: I see this a lot in vertical text layou. EPUB comes with a eature list, but when you have to figure out how these thigns actually work, participation is lacking.
  945. # [18:25] <fantasai> bill: We ant to make sure participation is there and we contribute to broad open web andd assume open web wants to evolve to handle needs of publishing
  946. # [18:25] * Joins: tantek (tantek@63.145.238.4)
  947. # [18:25] <fantasai> bill: Over time we're getting closer and closer.
  948. # [18:25] <fantasai> bill: EPUB2 referenced subset of CSS
  949. # [18:26] <fantasai> bill: EPUB3 took a different approach. We followed the recommendation from the liaison to prefix things, etc.
  950. # [18:26] <fantasai> jdaggett: We also had ppl form this group of not referencing WDs
  951. # [18:26] <fantasai> jdaggett: Do what you want, but this will not get you interop
  952. # [18:26] <fantasai> bill: The market demands were movin on anyway
  953. # [18:27] <fantasai> dbaron: One thing you mentioned was seeking eventual alignment with web technology.
  954. # [18:27] <fantasai> dbaron: One of the dangers there if you take a snapshot of a WD is that either one of two things will happen
  955. # [18:27] <fantasai> dbaron: one is that the set of implementations doing EPUB will be different from Web technology, or same implementations plus flags
  956. # [18:28] <fantasai> dbaron: And you'll end up with converging implementations within EPUB and converging implementations within the Web, and those two groups diverging
  957. # [18:28] <fantasai> dbaron: The other possibility is that you'll have common implementations, and one or the other set of specs will end up bein ignored in reality
  958. # [18:28] <fantasai> szilles: I completely agree with points by john and david, but we are sort of faced with 2 orgs trying to find an effective mechanism for cooperating. They have different constraints.
  959. # [18:29] <fantasai> szilles: The warnings you express are valid
  960. # [18:29] <fantasai> szilles: But more productive than trying to change how they're operating, is trying to minimize these kinds of issues or find ways for efffective coperation.
  961. # [18:29] <fantasai> szilles: In particular one of these seems to be for EPUB to prioritize the feature list, so if we can only tackle some of it we know what to tackle fro myour side
  962. # [18:30] <fantasai> glazou: Since I'm myself writing an EPUB2/3 editor, taken a look at all the editors , tools, renderers.
  963. # [18:30] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  964. # [18:30] <fantasai> glazou: Most of them are based on web engines
  965. # [18:30] <fantasai> glazou: The Web industry and EBOOK industry share the app layer
  966. # [18:30] <fantasai> glazou: I don't think they are ogoing to be two different layers of runtimes
  967. # [18:31] <fantasai> glazou: one for web and one for ebook
  968. # [18:31] <fantasai> bill: We took decision in EPUB3 on buying that assumption
  969. # [18:31] <fantasai> bill: Could have moved towards more DocBOok like vocab. Instead reference HTML5/CSS all-in
  970. # [18:31] <fantasai> bill: Taking hoewver the reality that some of those won't be fully baked
  971. # [18:31] <fantasai> bill: Decision was popular with vendors, lead to thinks like Apple iBooks based on WebKit
  972. # [18:31] <fantasai> bill: Downside is that widely adopted modules that are WD
  973. # [18:32] <fantasai> bill: CSS2.1 is baseline, but 9 modules referenced by EPUB3
  974. # [18:32] <fantasai> bill: But all of those have some implementation
  975. # [18:32] <fantasai> bill: We would like guidance from CSSWG.
  976. # [18:32] <fantasai> bill: We are not W3C.
  977. # [18:33] <fantasai> bill: As soon as there's cross-browser implementation, we're using those features
  978. # [18:33] <fantasai> bill: We're here today because we ant to develop an optional add-on module to EPUB.
  979. # [18:34] <fantasai> jdaggett: I'm telling you that within this group we've had ppl say "we have to do this this way because impl for EPUB already do this this way"
  980. # [18:34] <fantasai> jdaggett: That's not the right way.
  981. # [18:34] <fantasai> jdaggett: If it's something that's funamentally wrong, I don't buy that argument.
  982. # [18:34] <fantasai> bill: We took the decision, knowing that our maintenance strategy for unfinished specs, would be to rev EPUB .1 .2
  983. # [18:35] <fantasai> jdaggett: Go back to what brady said, Adaptive layout is a minefield.
  984. # [18:35] <fantasai> jdaggett: It's very complex, it's hard to get right. if you start snapshotting, you will run into trouble.
  985. # [18:35] <fantasai> glazou: You said cross-browser implementations, you'll add to EPUB
  986. # [18:35] <fantasai> glazou: It's not beacuse we have cross-browser implementation of something at some point that the spec is stable
  987. # [18:36] <fantasai> glazou: for us the only moment we can say something is stable enough is when we move from CR to PR.
  988. # [18:36] <fantasai> glazou: The good example is gradients.
  989. # [18:36] <fantasai> glazou: We have four incompatible specs for gradients.
  990. # [18:36] <fantasai> glazou: At some point we may have 2 or 3 compatible implementation
  991. # [18:36] <fantasai> glazou: If you rely on temporary stuff, if it's not a recommendation
  992. # [18:37] <fantasai> Florian: I think Steve is a valid point. If we have a scehdule, a feature set, and a quality requirement
  993. # [18:37] <fantasai> Florain: i.e. spec is advanced enough
  994. # [18:37] <fantasai> Florian: We can't have these things all at the same time
  995. # [18:37] <fantasai> Florian: Prioritizing your features is important.
  996. # [18:37] <fantasai> Florian: We can try to push ahead faster with higher priority things.
  997. # [18:38] <fantasai> Florian: We have a lot of things, some of which you care, some not so much.
  998. # [18:38] <fantasai> Florian: We won't exclusively work on your things, but we can give it more wieght
  999. # [18:38] <fantasai> Florian: We are quality-driven, you are schedule driven. The only way to work together is prioritizing
  1000. # [18:38] * Joins: mgylling (mgylling@83.251.132.182)
  1001. # [18:39] <fantasai> smfr: the othe rissue of snapshotting WDs is that it puts a burden on implementers
  1002. # [18:39] <fantasai> smfr: We have to maintain old behavior for compatibility, that we really don't want to have to maintain
  1003. # [18:39] <fantasai> smfr: In Ebkit we try to avoid flags, "we are rendering epub"
  1004. # [18:40] <fantasai> smfr: We might not even be aware that EPUB snapshotted some draft spec
  1005. # [18:40] <myakura> s/Ebkit/WebKit/
  1006. # [18:40] <fantasai> Markus: I totally understand where you guys are coming from. Because if you don't push the needle, you wind up with ... Amazon
  1007. # [18:40] <fantasai> Markus: I think he solution to this problem is prioritization Florian brought up. So if you keep separation of content and style
  1008. # [18:41] <fantasai> Markus: We of course don't work on content
  1009. # [18:41] <fantasai> Markus: That is best model to work forward
  1010. # [18:41] <fantasai> szilles: In category of requirements, might be useful to look at what Peter proposed to IDPF as kinds of things publishers are looking for
  1011. # [18:41] <fantasai> duga: Charter does list some priorities, and I epxect next few days we'll see more concrete proposal
  1012. # [18:42] <fantasai> duga: We're defining these as a vendor extesion, but will show what we might depend on.
  1013. # [18:42] <fantasai> duga: You might not do adpative layout on our schedule, but o we depend on calc(), or CSS regions,
  1014. # [18:42] <fantasai> s/duga/bill/
  1015. # [18:42] * Parts: howard (howard_wan@63.145.238.4)
  1016. # [18:42] <fantasai> bill: We need to work together with those.
  1017. # [18:43] <fantasai> szilles: We've had demos from MS and Opera of paginated documents, so they're very much on the structure.
  1018. # [18:43] <fantasai> (using CSS)
  1019. # [18:43] <fantasai> szilles: They are going in that particular direction, so showing the PGT sort of things is relevant. It's written on top of HTML and CSS
  1020. # [18:43] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
  1021. # [18:43] <fantasai> hober: I tihkn echoing florian and john...
  1022. # [18:43] <mmielke> Correction: Amazon is having a model that is based on REC specs (CSS2.1 capabilites) and do not rely on specs in working drafts
  1023. # [18:44] <fantasai> hober: I think there's a diff between source of dependence of WDs in EPUB3 and this new high-design module whatever
  1024. # [18:44] * Quits: dcosta (dcosta@187.31.77.7) (Quit: bbl)
  1025. # [18:44] <fantasai> hober: It's one thing to epub-prefix writing modes
  1026. # [18:44] <fantasai> hober: But this last couple days, I've seen some very interesting and very different proposals for doing these kinds fo layouts
  1027. # [18:44] <fantasai> hober: so different that even if we make an amazing amount of progres sin the next 6months, I have no idea what it's going to look like
  1028. # [18:45] * Quits: lgombos_ (Laszlo@63.145.238.4) (Ping timeout)
  1029. # [18:45] <fantasai> hober: Baking in something like regions is petrifying.
  1030. # [18:45] <jdaggett_> fantasai: our specs have different phases
  1031. # [18:46] <jdaggett_> fantasai: you really don't want to depend on something that's not in the stabilizing phase
  1032. # [18:46] <jdaggett_> fantasai: all the layout proposals are in the completely unstable phase
  1033. # [18:46] <fantasai> bill: If you say we shouldn't reference something, then we won't.
  1034. # [18:47] <fantasai> bill: We want to have publishers avoid creating proprietary features
  1035. # [18:47] <alexmog> q+
  1036. # [18:47] <fantasai> howcome: I agree with steve there is strong interested in moving to on-screen pages, so we have common interests
  1037. # [18:47] * Zakim sees alexmog on the speaker queue
  1038. # [18:47] <fantasai> howcome: My concern with some of these e.g. regions is that they are quite complex and they will take a long time to stabilize
  1039. # [18:48] <fantasai> howcome: My demo shows that we can do 90% without adding a single property in CSS
  1040. # [18:48] <fantasai> bill: The pages things in Opera is awesome. I was showing it at a conference just recently.
  1041. # [18:48] <fantasai> bill: However, that's not what makes EPUB tick. The EPUB content isn't content that paginates.
  1042. # [18:48] <Bert> q+ to ask about ways to do liaisons
  1043. # [18:48] * Zakim sees alexmog, Bert on the speaker queue
  1044. # [18:48] <fantasai> bill: It's ... orchestrated
  1045. # [18:48] <fantasai> manifest
  1046. # [18:48] <fantasai> bill: I welcome paged views, but it's not what EPUB has
  1047. # [18:49] <fantasai> bill: That's EPUB2 level. We have picturebooks, magazines, etc.
  1048. # [18:49] <dbaron> q+ jdaggett
  1049. # [18:49] * Zakim sees alexmog, Bert, jdaggett on the speaker queue
  1050. # [18:49] <fantasai> bill: template-based stuff
  1051. # [18:49] <duga> AAL charter: http://code.google.com/p/epub-revision/wiki/AdvancedAdaptiveLayoutCharter
  1052. # [18:49] * Joins: lgombos (Laszlo@63.145.238.4)
  1053. # [18:49] <fantasai> alex: I might be a little confused with teh background, what you're saying "us", is this EPUB or is this advanced adaptive layout charter group
  1054. # [18:50] <fantasai> bill: My immediate agenda item is coordination around advanced layout, but first issues raised are about genera principles of IDPF
  1055. # [18:50] <fantasai> standardization practice
  1056. # [18:50] <JohnJansen> zakim, who is on the q?
  1057. # [18:50] <Zakim> I see alexmog, Bert, jdaggett on the speaker queue
  1058. # [18:50] <dbaron> ack alexmog
  1059. # [18:50] * Zakim sees Bert, jdaggett on the speaker queue
  1060. # [18:50] <fantasai> bill: IDPF is a trade associate of publishers and ppl working in publishing. Very focused on publications, with a range from trade books to more compelx pbulications
  1061. # [18:50] <plinss> ack alexmog
  1062. # [18:50] * Zakim sees Bert, jdaggett on the speaker queue
  1063. # [18:50] <fantasai> alex: ... how much youre' going there.
  1064. # [18:51] <fantasai> alex Around 10 years ago, MS had an epub format which was subset of HTML+CSS
  1065. # [18:51] <fantasai> alex: It seems that in advanced layout is that you're willing to very divergent standizing of something
  1066. # [18:51] <fantasai> alex: is this something we should do in tihs group?
  1067. # [18:51] <fantasai> bill; that would be fantastic
  1068. # [18:51] <fantasai> bill: We asked W3C staff for review of our charter
  1069. # [18:52] <fantasai> bill: We're trying to meet the timeline of our members
  1070. # [18:52] <fantasai> bill: We are a date-driven organization, not so much quality
  1071. # [18:52] <dbaron> bill: we didn't receive comments on the charter from CSSWG members
  1072. # [18:52] <fantasai> bill: ... We're trying to get things out the door, and will accept the risks of some things fail.
  1073. # [18:52] <fantasai> bill: more like a startup
  1074. # [18:52] * Joins: szilles (chatzilla@63.145.238.4)
  1075. # [18:52] <szilles> q?
  1076. # [18:52] * Zakim sees Bert, jdaggett on the speaker queue
  1077. # [18:53] <fantasai> alex: You can have 8-month completely standard for a paginated document book and magazine layout and it will be ready for publication and have implementations? *skeptical*
  1078. # [18:53] <dbaron> q+ hober
  1079. # [18:53] * Zakim sees Bert, jdaggett, hober on the speaker queue
  1080. # [18:53] <fantasai> bill: yes. were' generalizing work that a member has already done
  1081. # [18:53] <szilles> q+ to show example document
  1082. # [18:53] * Zakim sees Bert, jdaggett, hober, szilles on the speaker queue
  1083. # [18:53] <hober> q+
  1084. # [18:53] * Zakim sees Bert, jdaggett, hober, szilles on the speaker queue
  1085. # [18:53] <fantasai> peter: I'm from adobe, I'm member of IDPF WG.
  1086. # [18:53] <dbaron> peter == Peter Sorotokin
  1087. # [18:53] <fantasai> peters: We have a lot of idfferences, not only how the standards is driven, but also how these documeents actually live
  1088. # [18:53] * hober thanks dbaron :)
  1089. # [18:53] <fantasai> peters: Complex websites get updated daily. Books don't
  1090. # [18:54] <fantasai> peters: The JS on the Web, you can't afford for books on the web.
  1091. # [18:54] <fantasai> peters: You want to publish it and forget about it, not maintain it.
  1092. # [18:54] <fantasai> peters: Puts a lot of pressure for having declartive ways of doing things.
  1093. # [18:54] <fantasai> peters: pressure is very differernt
  1094. # [18:54] <fantasai> peters: I was voicing a lot of similar concerns about referencing CSS WDs in IDPF
  1095. # [18:54] <fantasai> peters: A lot of these references come from East Asian market
  1096. # [18:55] <fantasai> peters: There are competing standards there. If we give up and not do it for 2 years, it's saying we won't do EBooks with CSS.
  1097. # [18:55] <fantasai> peters: You're lucky, there is no CSSX, nobody is trying to fork it or do someting completely different.
  1098. # [18:55] <fantasai> peters: We have this problem in ebooks, we cannot ignore
  1099. # [18:55] <fantasai> peters: One of our considerations for advanced layout proposal is to make sure it can be implemented today on top of existing browsers
  1100. # [18:56] <fantasai> peters: As long as we can do it today, we can be sure we can do it in future borwsers.
  1101. # [18:56] <fantasai> peters: That simpliefies the javascript.
  1102. # [18:56] * Quits: glazou (glazou@63.145.238.4) (Ping timeout)
  1103. # [18:56] <fantasai> peters: You'd need to augment your presentation with JS
  1104. # [18:56] <fantasai> peters: There is no requirement for JS in the publishing world as in browser
  1105. # [18:56] <fantasai> peters: iT's possible to move forward with moving creating more properties and eatures without touching the browser at all
  1106. # [18:56] <plinss> ack Bert
  1107. # [18:56] <Zakim> Bert, you wanted to ask about ways to do liaisons
  1108. # [18:56] * Zakim sees jdaggett, hober, szilles on the speaker queue
  1109. # [18:56] * Quits: arronei_ (arronei@63.145.238.4) (Ping timeout)
  1110. # [18:57] <jdaggett_> ack Bert
  1111. # [18:57] * Zakim sees jdaggett, hober, szilles on the speaker queue
  1112. # [18:57] <fantasai> Bert: My conclusion so far is that we can only influence each others time scales so much, so how do we limit the damange?
  1113. # [18:57] <fantasai> Bert: two wasy to do that
  1114. # [18:57] <fantasai> Bert: One is to have timely info from EPUB of what they mean, so we can within the littel flexiblity we have, to work on their things faster
  1115. # [18:58] <fantasai> Bert: Also would be a good thing if we can give advice regularly to EPUB to avoid that they make too many mistakes
  1116. # [18:58] <dbaron> q+ to ask about future epub versions
  1117. # [18:58] * Zakim sees jdaggett, hober, szilles, dbaron on the speaker queue
  1118. # [18:58] <fantasai> Bert: Steer you into somehting that's a littel bit safe. How do we make sure that happen?
  1119. # [18:58] <fantasai> Bert: Way to do that is liaisons, need people on both sides to communicate
  1120. # [18:58] <fantasai> Bert: maybe I should take some responsibility for that, it's in scope for my work anyway.
  1121. # [18:58] <fantasai> Bert: Maybe bring other people along to join meetings/telecons
  1122. # [18:59] <fantasai> Bert: Talking to each other is best way
  1123. # [18:59] <fantasai> Bert: Peter siad books cannot be changed. That means you need even more stable standards than the web browsers.
  1124. # [18:59] <fantasai> Bert: So you really need things that are extremely stable
  1125. # [18:59] <fantasai> Bert: You want to buy a book and 10 years still read it
  1126. # [18:59] <alexmog> q+
  1127. # [18:59] * Zakim sees jdaggett, hober, szilles, dbaron, alexmog on the speaker queue
  1128. # [19:00] <fantasai> bill: We had a lot of help from fantasai for EPUB3, but she was clear that she couldn't represent full bandwith of CSSWG
  1129. # [19:00] * Joins: glazou (glazou@63.145.238.4)
  1130. # [19:00] <fantasai> bill: I thin future of publishing in digital world is up for grab, some overlap with widgets and webapps
  1131. # [19:00] <fantasai> bill: various points of synergy
  1132. # [19:00] <fantasai> peterl: I in process of joining the EPUB group. I think you'll have interst in CSSWG to work with you guys. There would be good to have ppl from EPUB to join us on a regular basis
  1133. # [19:01] <plinss> ack jdaggett
  1134. # [19:01] * Zakim sees hober, szilles, dbaron, alexmog on the speaker queue
  1135. # [19:01] <fantasai> jdaggett: To your point about schedule and having things that you need to ship immediately.
  1136. # [19:01] <fantasai> jdaggett: that's ifne.
  1137. # [19:01] <plinss> ack hober
  1138. # [19:01] * Zakim sees szilles, dbaron, alexmog on the speaker queue
  1139. # [19:01] * Quits: Kai (chatzilla@63.145.238.4) (Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928134238])
  1140. # [19:01] * Joins: arronei_ (arronei@63.145.238.4)
  1141. # [19:01] <fantasai> jdaggett: In the case of adaptive layout, you need to communicate to ppl in your organization, that by standardizing on your time scale, you pretty much guarantee incompat with future web standards
  1142. # [19:02] <fantasai> peters: The point we're trying to achieve, you can develop an EPUB UA on to p of the browser using JavaScript
  1143. # [19:02] <fantasai> jdaggett: Whether that's possible, I cannot tell you
  1144. # [19:02] <fantasai> jdaggett: It's not standardized
  1145. # [19:02] <fantasai> Florian: Sometimes specs are more stable and not marked at such. In this case we're alking about stuff that's really really unstable
  1146. # [19:03] <fantasai> hober: What bill said earlier, that EPUB is trying to be very agile organization. THink it's a very great term, want to hit on the vialbe part
  1147. # [19:03] <fantasai> hober: Like Florian said, if you have [3 things], there's inherent ension there.
  1148. # [19:03] <JohnJansen> s/ension/tension
  1149. # [19:03] <fantasai> hober: To resolve you're best off dropping features
  1150. # [19:03] <fantasai> ...
  1151. # [19:04] <fantasai> bill: We're clear on that, but our main focus of where compat is
  1152. # [19:04] <fantasai> bill: We want that markup produced by tool like InDesign will work in the future
  1153. # [19:04] <fantasai> bill: More important than compat with Web
  1154. # [19:04] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
  1155. # [19:04] <fantasai> s/future/future epub readers/
  1156. # [19:04] <plinss> ack szilles
  1157. # [19:04] <Zakim> szilles, you wanted to show example document
  1158. # [19:04] * Zakim sees dbaron, alexmog on the speaker queue
  1159. # [19:04] <fantasai> szilles: Let me try to say what peters was saying in slightly different words.
  1160. # [19:05] <fantasai> szilles: there is a presumption in a number of the comments that the features that go into EPUB3+ are features that need to go into CSS
  1161. # [19:05] * Joins: howard (howard_wan@63.145.238.4)
  1162. # [19:05] <fantasai> szilles: What peter is saying is slightly different. Pter is saying that CSS today provides enough capbility with JS to take a declarative language and present what you see on the screen
  1163. # [19:05] <tcelik> I'm a little confused about the confusion around communicating stability of CSS specs, isn't that what Beijing did/does (2007, 2010) ?
  1164. # [19:06] <fantasai> szilles: Adobe has been trying to pieces of that mechanism that are hard to replicate in JS and migrate them into CSS
  1165. # [19:06] <fantasai> szilles: on a timescale that fits with CSS. Because there are solutions that work in the interim
  1166. # [19:06] <fantasai> szilles: Regions would make these demos easier to do.
  1167. # [19:06] <fantasai> alan: But these demos don't depend on any of the new stuff
  1168. # [19:07] <fantasai> szilles: There are other things like line grid that can't be done in JS, and we'd need to move within CSSWG
  1169. # [19:07] <fantasai> szilles: So agreeing on those pieces is the most important thing we can do
  1170. # [19:08] <fantasai> Florian: What you said is imporant to me. Your highest priority is not necessary what should be our priority, since you can do much of this without us.
  1171. # [19:08] * Quits: lgombos (Laszlo@63.145.238.4) (Ping timeout)
  1172. # [19:08] <fantasai> bill: ...
  1173. # [19:09] <fantasai> bill: From my pov, even if something's implementable in JS, if we nevertheless use a similar markup... or create our own, it could be a problem later
  1174. # [19:09] <dbaron> ack dbaron
  1175. # [19:09] <Zakim> dbaron, you wanted to ask about future epub versions
  1176. # [19:09] * Zakim sees alexmog on the speaker queue
  1177. # [19:09] <fantasai> bill: Don't want to sweep that under the table and say we're not worrying about it.
  1178. # [19:09] <fantasai> dbaron: You've mentioned that when you did EPUB3 it was essentially a different format from EPUB2. Is it backwards compatible?
  1179. # [19:10] <fantasai> bill: You could write EPUB3 that works on EPUB2 reader. Also EPUB2 books must work in EPUB3 reader
  1180. # [19:10] <fantasai> dbaron: What if EPUB3 depends on a technology that goes in a different way than this CSSWG goes?
  1181. # [19:10] <fantasai> dbaron: Would future versions of EPUB require the divergent technology? What CSSWG creates? Both?
  1182. # [19:11] <fantasai> duga: In EPUB3 we tried to point out pieces where things are likely to change incompatibly.
  1183. # [19:11] <fantasai> duga: We've committed to advancing with CSS, and pointing out to authors to beware of these potential changes
  1184. # [19:11] <glazou> q+
  1185. # [19:11] * Zakim sees alexmog, glazou on the speaker queue
  1186. # [19:11] <fantasai> bill: EPUB4 might say a ruby property is deprecated and nonconformant in content, but UAs must still implement it
  1187. # [19:11] <plinss> ack alexmog
  1188. # [19:11] * Zakim sees glazou on the speaker queue
  1189. # [19:11] <fantasai> Alex: Some questions
  1190. # [19:12] * Joins: ChrisL (ChrisL@128.30.52.169)
  1191. # [19:12] <fantasai> Alex: I'm really surprised we're talking about liaisons and you doing some significant amount of work, but also we're doing here
  1192. # [19:12] <fantasai> Alex: I'm surprised that *I'm* not involved, as someone making major progress on Regions
  1193. # [19:12] <fantasai> Alex: why not talk to us?
  1194. # [19:12] <fantasai> jdaggett: alex editors regions
  1195. # [19:12] <fantasai> alex: Whatever.. finish regions sooner, there are opportunities for us to make parallel progress
  1196. # [19:13] <fantasai> alex: We here need help as well. kindof depressing that I discuss stuff with Vincent and nobody else contributes
  1197. # [19:13] <fantasai> bill: regions is 25% of advanced adaptive layout
  1198. # [19:13] * Joins: Kai (chatzilla@63.145.238.4)
  1199. # [19:13] <ChrisL> rrsagent, here
  1200. # [19:13] <RRSAgent> See http://www.w3.org/2011/10/31-css-irc#T18-07-55
  1201. # [19:13] <fantasai> Florian: Reigons is a good example. Because it's one of the difficult pieces here, only a few people understand it rest are waiting until they're done
  1202. # [19:14] <tcelik> what's the other 75%?
  1203. # [19:14] <fantasai> Florian: I fppl in your group are working on the same thing, participating here will make these ppl feel a lot less lonely
  1204. # [19:14] * Quits: MoZ (MoZ@63.145.238.4) (Quit: Quitte)
  1205. # [19:14] <fantasai> alex: My second point is, it seems that something that will get produced in a very short time and targetted at a very specific applications, seems very similar to a company shipping product with publicly document format, designed by one company
  1206. # [19:14] <fantasai> alex: we've done this with MS office format. develpped by one company for its purposes
  1207. # [19:15] <fantasai> alex: Seems similar to me.
  1208. # [19:15] <fantasai> alex: I fyou don't have any requirements for that format to be tied to CSS WG, does it belong to W3C?
  1209. # [19:15] <stearns> tcelik: see the charter that was linked above
  1210. # [19:15] <fantasai> alex: Would it be your format that is documented and supported by reader applications, and whatever CSS or HTML requires has ...
  1211. # [19:15] <tcelik> stearns thanks
  1212. # [19:15] <plinss> ack glazou
  1213. # [19:15] * Zakim sees no one on the speaker queue
  1214. # [19:15] <fantasai> alex: ... support forever
  1215. # [19:15] <fantasai> glazou: I have quesiton of prefixed properties you're going to use
  1216. # [19:16] <fantasai> glazou: Say you'll sync with us and drop things not used anymore
  1217. # [19:16] <fantasai> glazou: What if you adopt, e.g. gradients now.
  1218. # [19:16] <fantasai> glazou: Gradients are going to drasticaly change in next 12 months, at which point your gradients are entirely incompatible
  1219. # [19:16] <fantasai> glazou: It's not about dropping version, but changing the value of that property
  1220. # [19:16] <fantasai> glazou: The books in the old eversion would be incompat with new one
  1221. # [19:16] <fantasai> bill: Alias would be maintianed
  1222. # [19:17] <fantasai> bill: One option, reader detects 3.0 vs 3.1 and ...
  1223. # [19:17] <fantasai> peters: We would wait until you reached CR, even if we have our epub gradient
  1224. # [19:17] <fantasai> peters: Once you reach CR, we would import your stuff and be done iwth it
  1225. # [19:17] <fantasai> glazou: It's unlikely between editing tools for EPUB would be different than Web
  1226. # [19:17] <fantasai> glazou: You chose HTML+CSS
  1227. # [19:17] <fantasai> glazou: Again the rendering engines are going to be the same
  1228. # [19:18] <fantasai> glazou: so having -epub-prefixed properties does not make sense
  1229. # [19:18] <fantasai> glazou: Editing tools won't deal with that
  1230. # [19:18] <fantasai> glazou: You are not doing editing tool, you're doing a converter
  1231. # [19:18] <fantasai> bill: we agree with premise of minimizing prefixed properties
  1232. # [19:18] <tcelik> stearns, captured on the CSSWG wiki: http://wiki.csswg.org/spec#idpf-epub
  1233. # [19:18] <fantasai> bill: Only 3: text, speech, and ruby are used prefixed
  1234. # [19:18] <fantasai> bill: And those are generally for east asian typography
  1235. # [19:19] <fantasai> bill: we would prefer not to have prefixed properties, no question
  1236. # [19:19] <fantasai> bill: We want EPUB ot be portable documents base don open web
  1237. # [19:19] <fantasai> szilles: Actionable items I heard were to increase liaison participation in both groups
  1238. # [19:20] <fantasai> szilles: Bert volunteered to get involved in IDPF. Can we ask IDPF group to expand liaison with our organization?
  1239. # [19:20] <fantasai> glazou: We have a lot of things to discuss together.
  1240. # [19:20] <fantasai> bill: A mechanistic point, several of the key IPDF members have presence in CSSWG
  1241. # [19:20] <fantasai> bill: Adobe, Google, Apple
  1242. # [19:20] <tcelik> Can we ask IDPF to directly participate in CSS spec discussions on www-style?
  1243. # [19:20] <tcelik> s/ask/invite
  1244. # [19:21] <fantasai> bill: Might ask for redundant representation, but not up to us
  1245. # [19:21] <fantasai> glazou: We need coordination between two groups. Not the same thing as coordination between members.
  1246. # [19:21] <fantasai> szilles: Getting more participation from ppl not reprsented at the table today, more likely to have informative opinions and users
  1247. # [19:22] <fantasai> szilles: We have a lot of technologists at the table, far less users.
  1248. # [19:22] <fantasai> szilles: Unerstanding what's being asked for is a difficulty
  1249. # [19:22] <fantasai> <br>
  1250. # [19:22] * Quits: duga (duga@63.145.238.4) (Quit: duga)
  1251. # [19:23] * Joins: howcome (howcome@63.145.238.4)
  1252. # [19:26] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
  1253. # [19:27] * Quits: bradk (bradk@63.145.238.4) (Quit: Computer has gone to sleep)
  1254. # [19:27] * Joins: mollydotcom (mollyh@63.145.238.4)
  1255. # [19:27] * Quits: mihara (mihara@63.145.238.4) (Connection reset by peer)
  1256. # [19:32] * Joins: TabAtkins_ (tabatkins@63.145.238.4)
  1257. # [19:33] * Quits: mmielke (mmielke@63.145.238.4) (Ping timeout)
  1258. # [19:34] * Quits: arno (arno@192.150.10.200) (Ping timeout)
  1259. # [19:34] * Joins: mmielke (mmielke@63.145.238.4)
  1260. # [19:34] * Joins: Cathy (qw3birc@128.30.52.28)
  1261. # [19:40] * Quits: mmielke (mmielke@63.145.238.4) (Ping timeout)
  1262. # [19:41] * Joins: Rossen (Rossen@63.145.238.4)
  1263. # [19:42] * Quits: AnanKan (AnanKan@63.145.238.4) (Ping timeout)
  1264. # [19:46] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
  1265. # [19:48] * Joins: anne (annevk@63.145.238.4)
  1266. # [19:48] * Joins: mihara (mihara@63.145.238.4)
  1267. # [19:49] <TabAtkins_> scribenick: TabAtkins_
  1268. # [19:49] <TabAtkins_> florian: Extra agenda item - CSS3 Text, talking about text-transform
  1269. # [19:49] * Joins: bradk (bradk@63.145.238.4)
  1270. # [19:49] <TabAtkins_> sylvaing: Extra agenda item - discuss how to move some of the current specs with lots of impl xp.
  1271. # [19:51] * Joins: mmielke (mmielke@63.145.238.4)
  1272. # [19:51] <bradk> xp = experience points?
  1273. # [19:51] * Joins: cyril (chatzilla@63.145.238.4)
  1274. # [19:53] <TabAtkins_> JohnJansen: I'm thinking there are N new tests, and I'm wondering when they're going to be moved into a snapshot.
  1275. # [19:53] <TabAtkins_> JohnJansen: And what it means if we don't have two impls passing those new tests.
  1276. # [19:54] <TabAtkins_> fantasai: To the 2nd q, it doesn't mean anything - we're just moving to better interop. It doesn't revoke our Rec status.
  1277. # [19:54] <TabAtkins_> fantasai: To the 1st q, I think somebody needs to make sure everything's in order and nothing's been lost (general vetting), and then we can just create a new snapshot any time.
  1278. # [19:55] <TabAtkins_> JohnJansen: Should we have a regular schedule for that, so I can predictably work on it? Otherwise things tend to sit.
  1279. # [19:55] <TabAtkins_> fantasai: Sounds good. What schedule do you want?
  1280. # [19:55] <TabAtkins_> JohnJansen: I think it should be in conjunction with publishing errata, so tests over the new errata show up at the same time.
  1281. # [19:55] <TabAtkins_> plinss: I think that makes a lot of sense, it's a no-brainer.
  1282. # [19:56] <TabAtkins_> plinss: Gerard's been reviewing a bunch of tests, and have a bunch flagged now with problems, but no one's working on them.
  1283. # [19:56] <TabAtkins_> JohnJansen: I think one of the challenges is prioritization.
  1284. # [19:56] <TabAtkins_> JohnJansen: Gerard is making a lot of comments (others too) - some are corrections, some are improvements.
  1285. # [19:56] <TabAtkins_> JohnJansen: But they get the same prioritization. I'd like to prioritize a correction versus an optional improvement.
  1286. # [19:56] <TabAtkins_> JohnJansen: We should jump on errors.
  1287. # [19:57] <TabAtkins_> JohnJansen: When I come into work in the morning, though, I dunno if I should work on 2.1 tests or css3 new tests.
  1288. # [19:57] <TabAtkins_> JohnJansen: We've got a lot of specs approaching CR or even Rec that need tests.
  1289. # [19:57] <TabAtkins_> JohnJansen: But I've got a finite amount of time in my day.
  1290. # [19:57] <TabAtkins_> JohnJansen: So some help in prioritizing would be helpful.
  1291. # [19:57] <TabAtkins_> fantasai: You also wanted a snapshot at the time of errata pub.
  1292. # [19:58] <TabAtkins_> fantasai: I'm not sure how long it takes to go from PER to Rec, but we are *way* behind on tracking 2.1 issues.
  1293. # [19:58] <TabAtkins_> JohnJansen: Right. It's never on the agenda.
  1294. # [19:58] <TabAtkins_> fantasai: And simple, I stopped tracking them - I switched to other specs. I was never even an editor, but I was doing most of the tracking.
  1295. # [19:59] <TabAtkins_> fantasai: So we need somebody to track the issues for 2.1. They need to start now, track into the future, and move backwards to the LC deadline, which is a lot of stuff.
  1296. # [19:59] <TabAtkins_> fantasai: And once we have a list, we can do a few issues each telcon and make progress.
  1297. # [19:59] <TabAtkins_> fantasai: And make sure that resolutions end up in the errata and the draft.
  1298. # [19:59] <TabAtkins_> fantasai: And I am *not* volunteering to do that.
  1299. # [19:59] * Joins: tpod (tpod@63.145.238.4)
  1300. # [19:59] <TabAtkins_> fantasai: We can't have a new errata until someone takes it up.
  1301. # [20:00] <fantasai> http://www.w3.org/Style/css2-updates/REC-CSS2-20110607-errata.html
  1302. # [20:00] <TabAtkins_> JohnJansen: yesterday we made a decision on margin-collapsing that needs to go in, for example, and it should be tracked.
  1303. # [20:00] <TabAtkins_> fantasai: Theoretically it should be in bugzilla.
  1304. # [20:00] <TabAtkins_> Bert: I've been lax about this, but I'm going to go through and extract things to Bugzilla.
  1305. # [20:00] <TabAtkins_> Bert: I'll start when I get back to my office.
  1306. # [20:01] <dbaron> http://wiki.csswg.org/spec/css2.1 says "Last mailing list sweep 2011-01-07 – arronei "
  1307. # [20:01] <TabAtkins_> fantasai: If you can maintain a date range that you have definitely covered, that would be very useful.
  1308. # [20:01] * Quits: mmielke (mmielke@63.145.238.4) (Ping timeout)
  1309. # [20:01] <TabAtkins_> fantasai: So if somebody decides to help you, they can just start at the last date you've touched and work backwards.
  1310. # [20:02] <TabAtkins_> dbaron: I'll edit the 2.1 issues wiki to say that new issues go to Bugzilla.
  1311. # [20:02] <TabAtkins_> dbaron: But we can still keep the mailing list sweep dates here in the wiki.
  1312. # [20:02] <TabAtkins_> dbaron: And there's a bunch of open issues here in the wiki that need to migrate.
  1313. # [20:02] * Joins: szilles (chatzilla@63.145.238.4)
  1314. # [20:03] <TabAtkins_> JohnJansen: Last idea - encourage the focus to fall on CSS3 modules, from a testing perspective, rather than continuing to focus exclusively on 2.1.
  1315. # [20:03] <TabAtkins_> fantasai: One thing to keep in mind is that all tests in 2.1 are a subset of the tests we'll need in css3.
  1316. # [20:03] <TabAtkins_> fantasai: So for B&B3, we'll just take all the relevant tests from 2.1, convert to reftest if possible, and then augment with new tests.
  1317. # [20:04] <TabAtkins_> fantasai: Because that's easier than just writing entirely new tests.
  1318. # [20:05] <TabAtkins_> plinss: In most cases, that's nothing more than adding a new spec link to the existing test. No moving, no copying, just add a new link and Shepherd will pick it up and track.
  1319. # [20:05] <gsnedders> How does Shepherd cope with tests becoming reftests?
  1320. # [20:06] <TabAtkins_> JohnJansen: Even if we moved all the 2.1 tests for B&B to B&B tests, we're still not complete.
  1321. # [20:06] <plinss> not an issue, it just adds the reference
  1322. # [20:06] <TabAtkins_> JohnJansen: So should we prioritize writing more css3 tests, or continue prioritizing 2.1.
  1323. # [20:06] <TabAtkins_> fantasai: We need both, but we should prioritize writing new tests for 3.
  1324. # [20:06] * Joins: gilles (gilles@63.145.238.4)
  1325. # [20:06] <TabAtkins_> fantasai: If people outside the WG want to work on 2.1, we should support them, though.
  1326. # [20:06] <TabAtkins_> JohnJansen: Agreed, but I'm not sure that we should *encourage* them to work on 2.1.
  1327. # [20:07] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
  1328. # [20:07] <TabAtkins_> JohnJansen: As a WG, we should give guidance to people who want to participate, and we should guide them to work on 3.
  1329. # [20:07] <TabAtkins_> dbaron: Two types of tests - one is to validate the spec, and one is to improve interop.
  1330. # [20:07] <TabAtkins_> dbaron: For the former, the priority should be writing for css3. For the latter...
  1331. # [20:07] <TabAtkins_> dbaron: I don't want to discourage 2.1 tests. We're still undertesting parts of the spec.
  1332. # [20:08] <TabAtkins_> TabAtkins_: So if someone comes up and says "I want to work on tests", we should encourage specific css3 tests.
  1333. # [20:08] <TabAtkins_> TabAtkins_: But if they want to work on 2.1 tests specifically, that's cool.
  1334. # [20:09] <TabAtkins_> fantasai: We should have a list of specs that need testing help, but Gerard, for example, really wants to work on 2.1 interop, and that's fine.
  1335. # [20:09] * Quits: Kai (chatzilla@63.145.238.4) (Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928134238])
  1336. # [20:09] <TabAtkins_> fantasai: We can put a list on the wiki of specs that are in maintenance and could use tests.
  1337. # [20:10] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
  1338. # [20:10] <TabAtkins_> JohnJansen: And additionally, we don't know and can't really track what parts of 2.1 need tests, we just have sort of a gut feeling.
  1339. # [20:10] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
  1340. # [20:10] * Parts: howard (howard_wan@63.145.238.4)
  1341. # [20:10] <TabAtkins_> JohnJansen: We can provide rough guidance there too, though.
  1342. # [20:10] <TabAtkins_> JohnJansen: My preferred idea is that we're just done with 2.1, it's Rec, and we have a regular maintenance schedule, but it's not a living spec that needs active attention.
  1343. # [20:11] <TabAtkins_> arronei: We need a per-spec maintenance schedule.
  1344. # [20:11] <TabAtkins_> plinss: Probably in conjunction with the snapshot.
  1345. # [20:11] <TabAtkins_> fantasai: We don't have anything new to snapshot yet, but we have a lot of things to errata.
  1346. # [20:12] <TabAtkins_> fantasai: I don't see anything being added to the 2010 snapshot that's not already in the 2011 snapshot.
  1347. # [20:12] <TabAtkins_> arronei: Why not put errata in there?
  1348. # [20:12] * Quits: anne (annevk@63.145.238.4) (Quit: anne)
  1349. # [20:12] <TabAtkins_> plinss: We can have a list of "these specs are in Rec, here's their errata", etc.
  1350. # [20:13] * Quits: myakura (myakura@63.145.238.4) (Client exited)
  1351. # [20:13] <TabAtkins_> fantasai: Right now we just list the stable things and link to the spec. So that's no change.
  1352. # [20:13] * Joins: duga (duga@63.145.238.4)
  1353. # [20:14] <TabAtkins_> arronei: I think it's good to publish an annual snapshot anyway. I want to see the 2011 snapshot, not the 2010 snapshot.
  1354. # [20:14] <TabAtkins_> TabAtkins_: It's difficult to tell the difference between "there was no change, so no updates" and "the spec is dead, and it's out-of-date".
  1355. # [20:14] <TabAtkins_> JohnJansen: And without a deadline to the issue tracking, work will grow to fill the alloted time.
  1356. # [20:14] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
  1357. # [20:15] <TabAtkins_> JohnJansen: With a specific once-per-year date or something, we know when things are expected and have a push to get the necessary things done.
  1358. # [20:15] <TabAtkins_> arronei: I'm hearing that we want a maintenance schedule. Should we set one up for 2.1 right now?
  1359. # [20:15] <TabAtkins_> arronei: And beyond that, each spec can have its own schedule (or hook into the existing one, we can evaluate per module).
  1360. # [20:15] <TabAtkins_> arronei: But we should at least nail down 2.1's schedule.
  1361. # [20:15] <TabAtkins_> fantasai: PLH suggested republishing every year.
  1362. # [20:16] <TabAtkins_> fantasai: Should we set a goal to have all issues in the tracker by the Feb meeting? Bert, is that workable?
  1363. # [20:16] <TabAtkins_> Bert: Yes.
  1364. # [20:16] <TabAtkins_> RESOLVED: Have all 2.1 issues filed in bugzilla by the february meeting.
  1365. # [20:16] <TabAtkins_> dbaron: I think 2.1 issues are best addressed on the mailing list, not in a f2f.
  1366. # [20:17] <TabAtkins_> fantasai: Right, this is just a deadline for getting them in a tracker, not resolving them.
  1367. # [20:17] <dbaron> dbaron: We should at least attempt to deal with them on the mailing list before bringing them to a f2f meeting.
  1368. # [20:17] <TabAtkins_> RESOLVED: Publish an updated version of 2.1 and its testsuite annually.
  1369. # [20:17] * Parts: Ruinan (sunruinan@63.145.238.4)
  1370. # [20:18] * dbaron thought tab was going to say "the ideal future where we've carved it all onto stone tablets"
  1371. # [20:18] <TabAtkins_> RESOLVED: Update the site/wiki/etc to publicly prioritize testing css3 modules rather than 2.1.
  1372. # [20:19] <TabAtkins_> Bert: Once a year seems quite fast. More like every 5 years seems more reasonable.
  1373. # [20:19] <TabAtkins_> plinss: We should keep the once-a-year as a review cycle. If it turns out that the issues are tiny, okay, we'll skip publishing this year.
  1374. # [20:19] <TabAtkins_> PROPOSED EDITED RESOLUTION: Ensure that 2.1 is up-to-date yearly.
  1375. # [20:20] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
  1376. # [20:20] <gsnedders> IMO publishing once a year makes sense if there are non-editorial issues. Even if the issues are tiny it's probably still worth publishing if they have normative consequences.
  1377. # [20:20] <TabAtkins_> plinss: Should we commit to publishing an annual snapshot?
  1378. # [20:21] <TabAtkins_> RESOLVED: Publish a snapshot annually.
  1379. # [20:21] <TabAtkins_> fantasai: I think we should try to address 2.1 issues on the telcon each week.
  1380. # [20:21] <TabAtkins_> plinss: Once we get some together, yeah.
  1381. # [20:22] <TabAtkins_> dbaron: I think we should try to resolve them on the mailing list first.
  1382. # [20:22] <TabAtkins_> plinss: Yes. But once a proposal appears on the mailling list, quickly discuss it for telcons.
  1383. # [20:22] <TabAtkins_> JohnJansen: Another thing - I don't yet know how to prioritize the comments to the list for the current 2.1 testsuite.
  1384. # [20:23] <TabAtkins_> fantasai: If it's invalid, fix it immediately.
  1385. # [20:23] <TabAtkins_> fantasai: Tests that are imprecise (impls can pass when they actually fail the spec) should be fixed next.
  1386. # [20:23] <TabAtkins_> fantasai: And then issues with metadata or reusability are nice-to-fix, but not strictly necessary.
  1387. # [20:24] <TabAtkins_> fantasai: Every time we snapshot, the first two types should have all been fixed.
  1388. # [20:24] <TabAtkins_> fantasai: The last should be fixed as time allows.
  1389. # [20:24] <TabAtkins_> JohnJansen: I agree with that.
  1390. # [20:25] <TabAtkins_> JohnJansen: I don't yet know when I should make sure that's done by.
  1391. # [20:25] <TabAtkins_> fantasai: The last pub was June 2011, so the next will be June 2012, since we're doing yearly.
  1392. # [20:25] <fantasai> http://test.csswg.org/shepherd/
  1393. # [20:25] <TabAtkins_> RESOLUTION: All issues with the tests (not the testsuite) go to Shepherd.
  1394. # [20:25] <fantasai> s/testsuite/infrastructure/
  1395. # [20:26] <dbaron> http://test.csswg.org/shepherd/
  1396. # [20:26] <TabAtkins_> Topic: B&B issue
  1397. # [20:26] <TabAtkins_> fantasai: Issue 189.
  1398. # [20:27] <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Nov/0006.html
  1399. # [20:27] <fantasai> ISSUE-89
  1400. # [20:27] <fantasai> er ISSUE-189
  1401. # [20:27] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/189
  1402. # [20:27] <fantasai> http://lists.w3.org/Archives/Public/www-archive/2011Jul/0005.html
  1403. # [20:28] * Joins: Ms2ger (Ms2ger@91.181.84.233)
  1404. # [20:28] * Quits: mgylling (mgylling@83.251.132.182) (Quit: mgylling)
  1405. # [20:29] <TabAtkins_> fantasai: Look at the pictures!
  1406. # [20:30] <TabAtkins_> fantasai: Which of these 4 looks correct?
  1407. # [20:30] <TabAtkins_> plinss: #4
  1408. # [20:30] * Joins: cyril (chatzilla@63.145.238.4)
  1409. # [20:31] <TabAtkins_> fantasai: #1 is what IE implements.
  1410. # [20:31] <TabAtkins_> fantasai: #2 seems to be hooking up the half-way points of the arc lengths.
  1411. # [20:31] <TabAtkins_> fantasai: #3 is the current spec which is totally crazy.
  1412. # [20:31] <TabAtkins_> fantasai: #4 is what I think is correct.
  1413. # [20:31] <TabAtkins_> smfr: I think we should look at different border widths.
  1414. # [20:32] <TabAtkins_> fantasai: I picked this for a specific reason.
  1415. # [20:32] * Quits: ChrisWilson (ChrisWilso@63.145.238.4) (Quit: Leaving.)
  1416. # [20:32] <TabAtkins_> fantasai: ...
  1417. # [20:33] <TabAtkins_> smfr: Should border-radius influence what this corner-join should look like?
  1418. # [20:33] <TabAtkins_> smfr: In the absence, it's pretty obvious - you just go corner-to-corner.
  1419. # [20:33] <smfr> https://bug-9197-attachments.webkit.org/attachment.cgi?id=30423
  1420. # [20:33] <TabAtkins_> smfr: This diagram shows our logical interpretation which is independent of border-radius.
  1421. # [20:33] <TabAtkins_> dbaron: That doesn't work when one of the sides is very narrow or 0.
  1422. # [20:34] <TabAtkins_> dbaron: You get a thick border that curves down, and then suddenly changes color at these two triangles, and that looks really bad.
  1423. # [20:34] <smfr> http://jsfiddle.net/jMb8k/
  1424. # [20:34] <fantasai> fantasai^: The reason I chose equal widths is that we know the angle must vary to zero when the width of either side is zero, and there are multiple ways to map the ratio of widths onto angles, but 1:1 is definitely 45deg.
  1425. # [20:34] * Joins: AndroUser (androirc@63.145.238.4)
  1426. # [20:34] <fantasai> fantasai^: The quesiton here is how do you interpret "45deg"
  1427. # [20:35] <TabAtkins_> dbaron: Did you consider that the spec is mostly correct, but it should be looking at the curvature of the padding edge instead of border-edge?
  1428. # [20:35] <TabAtkins_> fantasai: What if there's no curvature?
  1429. # [20:36] * Quits: tpod (tpod@63.145.238.4) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
  1430. # [20:36] <TabAtkins_> fantasai: The underlying algorithm is to find the point on the border curve where the tangent's angle equals the ratio of the border widths.
  1431. # [20:37] <TabAtkins_> plinss: So find the angle that you would have without curvature, take the normal of that, then find the point on the outer curve with a matching tangent.
  1432. # [20:37] <TabAtkins_> fantasai: That *sounds* right, but I'm not certain off the top of my head.
  1433. # [20:39] <TabAtkins_> dbaron: Based on the fiddle, if we run the algorithm we're thinking of, it would produce the funny backwards-facing transition line that we don't want.
  1434. # [20:39] <tcelik> Frankly, I don't want to resolve this without a designer in the room.
  1435. # [20:40] <TabAtkins_> fantasai: I *think* you take the ratio of the two widths and apply that to 90deg.
  1436. # [20:40] <TabAtkins_> dbaron: Right, that's not our interpretation, and our intepretation is wrong.
  1437. # [20:40] <tcelik> If the goal is some sort of aesthetic ideal, we should base it on input from visual designer(s). Basing it on convenience of math or some approximate visual ideal is probably not a good way to resolve this.
  1438. # [20:40] <fantasai> tcelik: there's one on your left
  1439. # [20:41] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
  1440. # [20:41] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
  1441. # [20:41] <TabAtkins_> plinss: I think it's take the line from the inner to outer corner, invert it over the 45deg line, then take the normal and match the tangent.
  1442. # [20:41] * Quits: dsinger (dsinger@63.145.238.4) (Quit: dsinger)
  1443. # [20:42] <tcelik> fantasai - and I observe that he's scratching his head.
  1444. # [20:42] <TabAtkins_> dbaron: I think I agree with you on the outside point. I'm not certain that "closest point on the inside edge" is correct.
  1445. # [20:43] <TabAtkins_> [some unminuted discussion about inner point]
  1446. # [20:44] <tcelik> ok I think we should issue a public call for proposals for how to resolve this issue (with the visual samples above as an initial set of possibilities, open to others), and then invite visual designers to provide input (on www-style)
  1447. # [20:44] <tcelik> I don't think we should spend further time trying to resolve this among this group in the f2f - I don't think is either a good use of our f2f time, nor will it result in a visually good solution.
  1448. # [20:45] <TabAtkins_> I disagree, tcelik. This is productive so far.
  1449. # [20:45] * Quits: si-wei (si-wei@63.145.238.4) (Quit: si-wei)
  1450. # [20:47] <fantasai> plinss: You take the angle you'd have without a curve. Mirror it over 45deg (so a r45deg line won't change), then take the normal and find the tangent on the outer curve
  1451. # [20:47] <fantasai> plinss says to take the tangent on the inner curve
  1452. # [20:47] <fantasai> fantasai says she remembers trying that, and it gives bad results -- you want the shortest distance from the chosen outer point
  1453. # [20:48] <TabAtkins_> dbaron: I believe a case something like "border-width: thick thin; border-radius: thin thick;" can produce bad transitions with this rule.
  1454. # [20:48] * Quits: mollydotcom (mollyh@63.145.238.4) (Quit: mollydotcom)
  1455. # [20:49] <TabAtkins_> plinss: I think that has the right behavior. It's at least the limit behavior.
  1456. # [20:49] <TabAtkins_> dbaron: Actually, this may not be a big deal either. [mutters over details]
  1457. # [20:50] * Quits: AndroUser (androirc@63.145.238.4) (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com ))
  1458. # [20:50] <TabAtkins_> ACTION fantasai to detail the algorithm, and produce mockups for lots of corner cases.
  1459. # [20:51] * trackbot noticed an ACTION. Trying to create it.
  1460. # [20:51] <trackbot> Created ACTION-396 - Detail the algorithm, and produce mockups for lots of corner cases. [on Elika Etemad - due 2011-11-08].
  1461. # [20:51] * Quits: chsiao (chatzilla@63.145.238.4) (Ping timeout)
  1462. # [20:51] <dbaron> http://www.w3.org/Style/CSS/Tracker/actions/396
  1463. # [20:51] * Joins: szilles (chatzilla@63.145.238.4)
  1464. # [20:51] <florian> http://lists.w3.org/Archives/Public/www-style/2011Sep/0191.html
  1465. # [20:52] <TabAtkins_> Topic: text-transform issue
  1466. # [20:52] <TabAtkins_> florian: Look at point 4.
  1467. # [20:53] <dbaron> or, better, https://www.w3.org/Style/CSS/Tracker/actions/396 which is now "ACTION-396: Detail the algorithm options for position of color transitions on rounded borders, and produce mockups for lots of corner cases."
  1468. # [20:54] <TabAtkins_> jdaggett_: The use-case for text-transform:full-size-kana is that in ruby, small kana is mapped to full kana, because otherwise they're too small to be readable.
  1469. # [20:54] <TabAtkins_> jdaggett_: That's really the only use-case for this transform.
  1470. # [20:54] <TabAtkins_> jdaggett_: And it's relatively small.
  1471. # [20:54] <TabAtkins_> jdaggett_: I propose that instead of doing these small use-cases, we have an at-rule that lets you do arbitrary transformations.
  1472. # [20:54] <TabAtkins_> jdaggett_: So authors can handle these themselves rather than having to come to us and get it included in a spec.
  1473. # [20:55] <TabAtkins_> jdaggett_: I don't think this kana transform is unworthy, but it's a relatively small use-case.
  1474. # [20:55] <TabAtkins_> florian: I think there are two main cases for a mechanism like this.
  1475. # [20:55] <TabAtkins_> florian: First is the full-size-kana case. Well-defined and small.
  1476. # [20:55] <TabAtkins_> florian: Another place where it's useful is removing accents from letters. We can't have a generic algo for this, because it depends on language and context.
  1477. # [20:56] <tcelik> to remove accents?
  1478. # [20:56] <TabAtkins_> florian: But a specific author and specific document can do this.
  1479. # [20:56] <TabAtkins_> fantasai: Dropping accents tends to be done *per word*. It can't even be done per documnet.
  1480. # [20:56] * tcelik had a proposal to *add* accents: http://lists.w3.org/Archives/Public/www-style/2003Apr/0012.html
  1481. # [20:56] <TabAtkins_> fantasai: In Farsi, diacritics usually arn't written, but some are preserved for readability.
  1482. # [20:56] <TabAtkins_> florian: There are still useful cases where it's solveable.
  1483. # [20:57] <TabAtkins_> florian: For cases that still aren't solveable, well, they're already not solved.
  1484. # [20:57] <TabAtkins_> florian: Another case - old-fashioned long s may want to be transformed into a modern s. That's not something we'll probably ever care about as a group.
  1485. # [20:57] <fantasai> fantasai^: but in some words, they are preserved because otherwise the word would be ambiguous
  1486. # [20:57] <TabAtkins_> jdaggett_: And in Japanese you coul dhave rules that shift from one form of kana to another form. Tiny use-cases.
  1487. # [20:57] <fantasai> fantasai^: you cannot solve this use case without a dictionary
  1488. # [20:58] <TabAtkins_> jdaggett_: For i18n, it's simpler to just give people a rule. If we find people using a particular kind consistently, we can then standardize it.
  1489. # [20:58] <TabAtkins_> howcome: I think this is a good idea, and is similar to @counter-style.
  1490. # [20:58] * tcelik notes a problem report regarding text-transform: https://twitter.com/psd/status/128565170514567168
  1491. # [20:58] <TabAtkins_> jdaggett_: I propose then that we drop this property value and move towards defining this transform rule and its syntax.
  1492. # [20:58] <tcelik> specifically: text-transform: uppercase turns "0.1µF" into "0.1MF"
  1493. # [20:58] <TabAtkins_> szilles: One concern I always raise is, is this opening a security hole?
  1494. # [20:59] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
  1495. # [20:59] <TabAtkins_> dbaron: It seems like anything you can do here, you can do with a font.
  1496. # [20:59] <TabAtkins_> TabAtkins_: or in many cases, just ordinary javascript.
  1497. # [21:00] <TabAtkins_> dbaron: As an aside, I'm not crazy about the specific syntax being proposed, but I won't get into that now.
  1498. # [21:00] <TabAtkins_> stearns: I like this idea, but should the full-size-kana rule still be added, since it seems useful?
  1499. # [21:01] <TabAtkins_> jdaggett_: Given that the use-case is only for Ruby in japanese, and only for people who want to keep their original content that comes with small kana, I don't think we need to.
  1500. # [21:01] <TabAtkins_> szilles: A solution would be to use *this* transform as an example in the spec.
  1501. # [21:02] <TabAtkins_> fantasai: The table is non-trivial.
  1502. # [21:02] <TabAtkins_> fantasai: And the *idea* that you can ask the UA for this sort of thing is new and strange.
  1503. # [21:02] <TabAtkins_> fantasai: If it's tricky and unintuitive, nobody will do it though.
  1504. # [21:03] * Quits: fukuno (fukuno@63.145.238.4) (Ping timeout)
  1505. # [21:03] * Joins: arno (arno@63.145.238.4)
  1506. # [21:03] <TabAtkins_> jdaggett_: If there's an example, or a wiki article or something, it's a simple cut-and-paste to put it in your page.
  1507. # [21:04] * Quits: glazou (glazou@63.145.238.4) (Quit: glazou)
  1508. # [21:04] <TabAtkins_> howcome: Or an @import. That works for fonts already.
  1509. # [21:04] * Joins: dsinger (dsinger@63.145.238.4)
  1510. # [21:04] <TabAtkins_> fantasai: They'll do that because it's shiny and new and cool.
  1511. # [21:04] * Joins: szilles (chatzilla@63.145.238.4)
  1512. # [21:05] <TabAtkins_> howcome: We're not fighting the functionality, just the syntax. And making it available to other languages.
  1513. # [21:05] <TabAtkins_> howcome: For example, in typesetting my Ibsen book, he used a peculiar form of punctuation. I had to edit a font to do that.
  1514. # [21:05] * tcelik notes it is now 13:00
  1515. # [21:06] <TabAtkins_> plinss: I hear many in favor, and one strong objection.
  1516. # [21:06] <TabAtkins_> [three strong objections]
  1517. # [21:07] * Quits: dsinger (dsinger@63.145.238.4) (Quit: dsinger)
  1518. # [21:07] <TabAtkins_> Bert: I think this is creeping transformations to CSS.
  1519. # [21:07] * Quits: kimberlyblessing (Kimberly@63.145.238.4) (Quit: ChatZilla 0.9.87 [Firefox 8.0/20111026191032])
  1520. # [21:07] <TabAtkins_> jdaggett_: Do you support the keyword itself?
  1521. # [21:07] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
  1522. # [21:07] * Quits: smfr (smfr@63.145.238.4) (Quit: smfr)
  1523. # [21:07] * Quits: stearns (anonymous@63.145.238.4) (Quit: stearns)
  1524. # [21:07] * Quits: duga (duga@63.145.238.4) (Quit: duga)
  1525. # [21:07] * Quits: bradk (bradk@63.145.238.4) (Quit: Computer has gone to sleep)
  1526. # [21:07] <TabAtkins_> Bert: You said it was necessary, so yes.
  1527. # [21:07] * Quits: jdaggett_ (jdaggett@63.145.238.4) (Quit: jdaggett_)
  1528. # [21:07] * Quits: shan (soonbo.han@63.145.238.4) (Quit: Leaving)
  1529. # [21:07] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
  1530. # [21:07] <TabAtkins_> <br type=lunch duration=1h>
  1531. # [21:07] * Quits: dbaron (dbaron@63.145.238.4) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  1532. # [21:07] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
  1533. # [21:08] * Quits: Cathy (qw3birc@128.30.52.28) (Ping timeout)
  1534. # [21:08] * Joins: myakura (myakura@63.145.238.4)
  1535. # [21:08] * Quits: JohnJansen (JohnJansen@63.145.238.4) (Ping timeout)
  1536. # [21:09] * Quits: arronei_ (arronei@63.145.238.4) (Ping timeout)
  1537. # [21:09] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
  1538. # [21:09] * Quits: arno (arno@63.145.238.4) (Quit: Leaving.)
  1539. # [21:09] * Quits: YUMA (yuma@63.145.238.4) (Ping timeout)
  1540. # [21:09] * Quits: kojiishi (kojiishi@63.145.238.4) (Ping timeout)
  1541. # [21:10] * Quits: florian (florianr@63.145.238.4) (Ping timeout)
  1542. # [21:10] * Quits: TabAtkins_ (tabatkins@63.145.238.4) (Ping timeout)
  1543. # [21:16] * Quits: sylvaing (sylvaing@63.145.238.4) (Ping timeout)
  1544. # [21:17] * Quits: mihara (mihara@63.145.238.4) (Client exited)
  1545. # [21:21] * Joins: anne (annevk@63.145.238.4)
  1546. # [21:23] * Quits: alexmog (alexmog@63.145.238.4) (Ping timeout)
  1547. # [21:24] * Quits: howcome (howcome@63.145.238.4) (Ping timeout)
  1548. # [21:27] * Zakim excuses himself; his presence no longer seems to be needed
  1549. # [21:27] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  1550. # [21:28] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
  1551. # [21:31] * Joins: tantek (tantek@63.145.238.4)
  1552. # [21:34] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
  1553. # [21:37] * Joins: karl (karlcow@128.30.54.58)
  1554. # [21:37] * Quits: karl (karlcow@128.30.54.58) (Client exited)
  1555. # [21:38] * Joins: karl (karlcow@128.30.54.58)
  1556. # [21:40] * Joins: Mike5 (Mike5@mcclure.w3.org)
  1557. # [21:41] * Joins: jdaggett_ (jdaggett@63.145.238.4)
  1558. # [21:43] * Joins: duga (duga@63.145.238.4)
  1559. # [21:44] * Joins: chsiao (chatzilla@63.145.238.4)
  1560. # [21:44] * Joins: ChrisL (ChrisL@128.30.52.169)
  1561. # [21:45] * Quits: duga (duga@63.145.238.4) (Quit: duga)
  1562. # [21:47] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
  1563. # [21:51] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
  1564. # [21:51] * Joins: smfr (smfr@63.145.238.4)
  1565. # [21:53] * Joins: stearns (anonymous@63.145.238.4)
  1566. # [21:57] * Joins: TabAtkins_ (tabatkins@63.145.238.4)
  1567. # [21:58] * Joins: dsinger (dsinger@63.145.238.4)
  1568. # [21:59] * Joins: duga (duga@63.145.238.4)
  1569. # [21:59] * Joins: howard (howard_wan@63.145.238.4)
  1570. # [21:59] * Joins: bradk (bradk@63.145.238.4)
  1571. # [22:00] * Quits: dsinger (dsinger@63.145.238.4) (Quit: dsinger)
  1572. # [22:01] * Joins: szilles (chatzilla@63.145.238.4)
  1573. # [22:02] * Joins: sylvaing (sylvaing@63.145.238.4)
  1574. # [22:04] * Joins: plinss (plinss@63.145.238.4)
  1575. # [22:04] * Joins: glazou (glazou@63.145.238.4)
  1576. # [22:05] * Joins: arno (arno@63.145.238.4)
  1577. # [22:05] * Quits: chsiao (chatzilla@63.145.238.4) (Ping timeout)
  1578. # [22:07] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
  1579. # [22:07] * Joins: alexmog (alexmog@63.145.238.4)
  1580. # [22:07] * Joins: ChrisWilson (ChrisWilso@63.145.238.4)
  1581. # [22:07] * Quits: anne (annevk@63.145.238.4) (Quit: anne)
  1582. # [22:07] * Joins: arronei_ (arronei@63.145.238.4)
  1583. # [22:07] * Joins: JohnJansen (JohnJansen@63.145.238.4)
  1584. # [22:08] * Joins: mihara (mihara@63.145.238.4)
  1585. # [22:08] * Joins: dbaron (dbaron@63.145.238.4)
  1586. # [22:09] * Joins: mmielke (mmielke@63.145.238.4)
  1587. # [22:09] * Joins: mollydotcom (mollyh@63.145.238.4)
  1588. # [22:09] * Quits: JohnJansen (JohnJansen@63.145.238.4) (Quit: JohnJansen)
  1589. # [22:10] * Joins: AnanKan (AnanKan@63.145.238.4)
  1590. # [22:10] <Bert> Scribe: Bert
  1591. # [22:10] * Joins: anne (annevk@63.145.238.4)
  1592. # [22:10] * glazou is here and as promised earlier, reads IRC and will comment here
  1593. # [22:10] * dbaron hmmm, the wireless from the AC meeting room is barely working
  1594. # [22:10] <Bert> Topic: Image Values
  1595. # [22:11] * Quits: mihara (mihara@63.145.238.4) (Client exited)
  1596. # [22:11] <Bert> [fantasai draws on whiteboard]
  1597. # [22:11] * Joins: dsinger (dsinger@63.145.238.4)
  1598. # [22:11] * Joins: szilles (chatzilla@63.145.238.4)
  1599. # [22:11] * Joins: shan (soonbo.han@63.145.238.4)
  1600. # [22:11] * Quits: arno (arno@63.145.238.4) (Ping timeout)
  1601. # [22:11] * Joins: Cathy (qw3birc@128.30.52.28)
  1602. # [22:11] * Joins: Rossen (Rossen@63.145.238.4)
  1603. # [22:11] <Bert> fantasai: Can somebody project the gradient syntax definition?
  1604. # [22:11] * Joins: cyril (chatzilla@63.145.238.4)
  1605. # [22:11] * Joins: mihara (mihara@63.145.238.4)
  1606. # [22:11] <szilles> join #ac
  1607. # [22:12] * Joins: kimberlyblessing (Kimberly@63.145.238.4)
  1608. # [22:12] * Joins: Kai (chatzilla@63.145.238.4)
  1609. # [22:12] * Quits: howard (howard_wan@63.145.238.4) (Quit: howard)
  1610. # [22:12] <fantasai> http://wiki.csswg.org/ideas/radial-gradients
  1611. # [22:12] <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Oct/0859.html
  1612. # [22:13] * Rossen is now known as rossen
  1613. # [22:13] * Quits: ChrisWilson (ChrisWilso@63.145.238.4) (Quit: Leaving.)
  1614. # [22:13] <Bert> fantasai: Look at bottom of wiki page.
  1615. # [22:13] <Bert> ... Not clear what is going on in these examples.
  1616. # [22:13] <Bert> ... Some colors, som epercentages...
  1617. # [22:13] <Bert> ... So want all notations to be more obvious.
  1618. # [22:14] <Bert> ... Please look at the e-mail for some ideas.
  1619. # [22:14] * Joins: YUMA (yuma@63.145.238.4)
  1620. # [22:14] <Bert> ... Not ncecessary to have positional arguments in CSS.
  1621. # [22:15] <Bert> JohnD: Functional notation is usually interpreted as a function w/ params.
  1622. # [22:15] <Bert> ... This keyword notation is going away from that.
  1623. # [22:15] <Bert> Tab: Bu you can see it as going back more to how CSS properties work.
  1624. # [22:16] <Bert> JohnD: When I read a parentheseis, I expect a function.
  1625. # [22:16] <Bert> [Some people offering opiions]
  1626. # [22:17] * Joins: shepazu (shepazu@128.30.52.169)
  1627. # [22:17] <Bert> fantasai: Inside the func. notation it is pretty much like a value ntation.
  1628. # [22:17] <Bert> ... Not a function call, but a subset of the value.
  1629. # [22:17] <Bert> PeterL: We have other things without commas.
  1630. # [22:17] <Bert> Simon: But always commas in functions.
  1631. # [22:18] <Bert> Molly: Most people are not computer scientists.
  1632. # [22:18] <Bert> ... What is intuitive.
  1633. # [22:18] * Joins: fukuno (fukuno@63.145.238.4)
  1634. # [22:18] <Bert> ... The original proposals were completely unitutive.
  1635. # [22:18] <Bert> ... I have no context from CS. Peopel like me just need words.
  1636. # [22:19] <Bert> ... Gradient "from" here "to" there.
  1637. # [22:19] * Joins: dowan (forty4@63.145.238.4)
  1638. # [22:19] <Bert> JohnD: But look at AppleScript. It is frustrating.
  1639. # [22:19] * Joins: gilles (gilles@63.145.238.4)
  1640. # [22:19] <Bert> Tab: But isn't this the case for every proeprty?
  1641. # [22:19] <Bert> JohnD: It's different inside functional notaitons.
  1642. # [22:20] <Bert> Markus: Should avoid functional notation in general.
  1643. # [22:20] <Bert> Simon: How do you know [something]?
  1644. # [22:20] <Bert> Molly: It's the words, as long as it is logical.
  1645. # [22:20] <Bert> JohnD: Any kind of formal language needs to be consistent.
  1646. # [22:21] <Bert> ... In similar cases, you use similar notations.
  1647. # [22:21] <Bert> ... But this is mixing things together.
  1648. # [22:21] <Bert> ... Will lead to confusion.
  1649. # [22:21] <Bert> Brad: I think it rather clarifies.
  1650. # [22:21] <Bert> ... This is not AppleScript.
  1651. # [22:22] <Bert> fantasai: Looking at the exampels, I cankind of see what is going on.
  1652. # [22:22] <Bert> ... With the other ones, I have no idea.
  1653. # [22:22] <Bert> ... That's why I want to go here.
  1654. # [22:23] <Bert> ... Most functional notations we have so far, have commas in thesame way as in values without functional notations.
  1655. # [22:23] <Bert> JohnD: Do we have func. notations with keywords anywhere?
  1656. # [22:23] <Bert> Tab: We're adding that right now.
  1657. # [22:23] * Joins: arno (arno@63.145.238.4)
  1658. # [22:23] <Bert> ... Most functions sofar are pretty trivial.
  1659. # [22:24] <Bert> JohnD: So this is the first time for keywords in functional notations.
  1660. # [22:24] * Joins: brianman (brianman@131.107.0.110)
  1661. # [22:24] * Quits: gilles (gilles@63.145.238.4) (Client exited)
  1662. # [22:24] <brianman> helps to have the right port - 6665
  1663. # [22:24] <dbaron> I think keywords inside functional notation are reasonable.
  1664. # [22:24] <Bert> Simon: Slippery slope. But other way to think about it is name-value pairs.
  1665. # [22:25] * Joins: kojiishi (kojiishi@63.145.238.4)
  1666. # [22:25] <Bert> Howcome: OK with changing. We can also drop the just the parentheses here.
  1667. # [22:25] <brianman> There was a lot in e-mail. What's the current proposal?
  1668. # [22:25] <Bert> ... Programmers have traditions.
  1669. # [22:25] * Joins: JohnJansen (JohnJansen@63.145.238.4)
  1670. # [22:25] <Bert> ... We can do differently, as a string or something.
  1671. # [22:26] <Bert> PeterL: Cf Python and others.
  1672. # [22:26] <TabAtkins_> Like radial-gradient(center: 20% 20%, shape: cover ellipse, colors: blue, red, black)?
  1673. # [22:26] <Bert> JohnD: But they are specific syntaxes.
  1674. # [22:26] <Bert> PeterL: So is CSS.
  1675. # [22:26] <brianman> There's at least one problem with that syntax, Tab.
  1676. # [22:26] * glazou sees JSON percolate into CSS syntax ? :-)
  1677. # [22:26] <Bert> PeterL: The point is they are *not* parameters, because it is not a *function*.
  1678. # [22:27] <brianman> You probably want .... radial-gradient(center: 20% 20%, shape: cover ellipse, colors: |blue, red, black|) ... but something other than the pipe character.
  1679. # [22:27] * Joins: chsiao (chatzilla@63.145.238.4)
  1680. # [22:27] <dbaron> this is starting to look more like Apple's original proposal
  1681. # [22:27] * glazou waits for the curly braces proposal inside parenthesis
  1682. # [22:27] <Bert> fantasai: I hear objections to commas, because that makes it different from C. I dont' hear that my eample is unreadable.
  1683. # [22:27] <brianman> Your syntax above isn't clear on what the commas separate. Are they separating colors or the next param pair?
  1684. # [22:27] <Bert> JohnD: It's not C. It's consistency with other parts of CSS.
  1685. # [22:28] <brianman> Can you repeat your specific example, fantasai?
  1686. # [22:28] <Bert> fantasai: We dont' use commas between values in CSS.
  1687. # [22:28] <Bert> [For fantasai's idea, see e-mail linked earlier]
  1688. # [22:28] <brianman> [There are like 20 emails.]
  1689. # [22:28] <plinss> http://wiki.csswg.org/ideas/radial-gradients
  1690. # [22:29] <plinss> http://lists.w3.org/Archives/Public/www-style/2011Oct/0859.html
  1691. # [22:29] <Bert> Rossen: fantasai's is not necessarily easier.
  1692. # [22:29] * sylvaing glazou, Python functions also do that. It's a syntactical orgy over here!
  1693. # [22:29] <Bert> ... Functional syntax is hiding three gradient properties. Why do need to be in the notation, not in proeprties?
  1694. # [22:30] <brianman> Are you referring to this flavor: radial-gradient(<shape> keyword <position> keyword <stops) ?
  1695. # [22:30] <Bert> Tab: They are values, gradietns aren't properties.
  1696. # [22:30] <Bert> ... We don't add twenty-something properties for images.
  1697. # [22:30] <Bert> ... Can add @rule or point to SVG.
  1698. # [22:30] <Bert> ... But gradients are right at the edge, can still be in CSS, n a funtion.
  1699. # [22:30] * glazou sylvaing let's use reverse polish notation
  1700. # [22:31] <Bert> sylvaing: At some poijt we switch to SVG, you say. Then we need to inline SVG.
  1701. # [22:31] <Bert> ErikD: [missed]
  1702. # [22:31] * sylvaing glazou omg reverse-polish-calc() !
  1703. # [22:31] <Bert> ... Doesn't seem natural to me.
  1704. # [22:32] <Bert> Simon: Trabsforms has functional notations. But all numeric.
  1705. # [22:32] <bradk> rect() does not require commas: http://www.w3.org/TR/CSS2/visufx.html#value-def-shape
  1706. # [22:32] <dbaron> rect() is an accident from the examples and the normative prose in CSS 2.0 mismatching
  1707. # [22:32] <smfr> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html#FilterFunction
  1708. # [22:32] <brianman> Why is "radial-gradient(circle from center as red, blue)" better than "radial-gradient(circle from center, red, blue)"? In my opinion it's worse.
  1709. # [22:33] <Bert> Tab: Filter functions shorthand in CSS looks like comma-separted now, but will change them to look more like CSS proeprty. Don't need th ecommas. Space is enough.
  1710. # [22:33] <Bert> Simon: Then we need to do that for trnasforms too, Consistency.
  1711. # [22:33] <ed> s/Doesn't seem natural to me./the "from ... as" syntax doesn't seem natural to me./
  1712. # [22:34] <Bert> Luke: Need More general syntax system than the English word thrown here and there.
  1713. # [22:34] <Bert> fantasai: Shorthand and indivisual propeties if needed.
  1714. # [22:34] <glazou> q+
  1715. # [22:34] * sylvaing image-values: spec(from almost-lc back-to endless, syntax, debate)
  1716. # [22:34] <Bert> Simon: @-rule, like keyframe [...]
  1717. # [22:34] * glazou has a comment
  1718. # [22:35] <Bert> ... Use JSON :-)
  1719. # [22:35] <plinss> ack glazou
  1720. # [22:35] <glazou> I would like to avoid "silent" tokens
  1721. # [22:35] <glazou> i.e. like in genetics, genes that express nothing
  1722. # [22:35] <glazou> if we could keep meaningful stuff only
  1723. # [22:35] * ed thinks JSON would make it easier to understand the syntax at first glance anyway
  1724. # [22:35] <glazou> please let's do that
  1725. # [22:36] <brianman> Clarify, glazou?
  1726. # [22:36] <glazou> in that light, from and as are meaningless
  1727. # [22:36] <brianman> Ah.
  1728. # [22:36] <glazou> they help readability by humans
  1729. # [22:36] <glazou> don't help the syntax
  1730. # [22:36] <brianman> I would agree on 'as' but 'from' has some value.
  1731. # [22:36] <Bert> Shane: Pretty strong relation to JSON idea. name:value idea.
  1732. # [22:36] <glazou> and also complexity parsing
  1733. # [22:36] <brianman> It solves the size version position problem with lengths.
  1734. # [22:36] <Bert> Florian: That's not what was proposed here.
  1735. # [22:37] <smfr> gradient(shape circle, from left, as red, green)
  1736. # [22:37] * Joins: Vlad (Vlad@63.145.238.4)
  1737. # [22:37] <brianman> Useless as in that version, smfr.
  1738. # [22:37] <smfr> gradient(shape circle from left as red, green)
  1739. # [22:37] <Bert> Shane: Those "silent" tokens exist in JSON, too.
  1740. # [22:37] <Bert> ... Slight difference in tokens.
  1741. # [22:38] <Bert> fantasai: Can vary order, although it looks weird with shape at the end.
  1742. # [22:38] <brianman> Sidenote: I think from is the wrong word. At is a better word.
  1743. # [22:38] <Bert> JohnD: Maye be readable, but allows syntaxes that are gibberish.
  1744. # [22:38] <brianman> In light of offset focal point in the future.
  1745. # [22:38] <Bert> PeterL: Gibberisgh is loaded term.
  1746. # [22:39] <fantasai> peterl: comma-separated numbers are gibberish to me if I'm not intimately familiar with the order of arguments
  1747. # [22:39] <Bert> Shane: Is it better if it were order-independent and we say we can use it in other situations, too?
  1748. # [22:39] <brianman> It can't be completely order independent. The color stops.
  1749. # [22:39] <Bert> JohnD: It's what an author expects.
  1750. # [22:40] <glazou> +1
  1751. # [22:40] <Bert> Molly: Solve deoendence on order with education.
  1752. # [22:40] <glazou> won't work
  1753. # [22:40] <Bert> ... And a question:
  1754. # [22:40] <Bert> ... What Simon just wrote is beutifule. What is the problem with it?
  1755. # [22:40] <Bert> Simon: Complex grouping, precendence issues...
  1756. # [22:41] <Bert> fantasai: Property values have this already.
  1757. # [22:41] <dbaron> The "shape" in what Simon wrote doesn't seem to me to add anything useful.
  1758. # [22:41] <Bert> howcome: Need to start with "from" right?
  1759. # [22:41] <brianman> @dbaron it has value here: radial-gradient(size 25px 25px, from 25px 25px, red, green)
  1760. # [22:42] <brianman> s/value/usefulness/
  1761. # [22:42] <Bert> Simon; CSS grammar doesn't restict what goes insoide (), does it?
  1762. # [22:42] <Bert> Bert: Correct.
  1763. # [22:42] <rossen> bert: didn't have time to look at the proposed syntax, would like to come back and comment in a week
  1764. # [22:42] <Bert> Florian: Should we allow ourselves the same flexibility inside () as for other values.
  1765. # [22:43] <dbaron> brianman, I was specifically referring to the "shape" rather than the other keywords
  1766. # [22:43] <Bert> howcome: Not more restrictive, just using more keywords, with may be more or less intuitive.
  1767. # [22:43] <Bert> fantasai: [missed]
  1768. # [22:43] <brianman> @dbaron - so you want "radial-gradient(circle...) and "radial-gradient(size 25px 25px, ...)" ... Meaning only a keyword in the size case?
  1769. # [22:44] <Bert> Tab: CSS is designed for English speakers.
  1770. # [22:44] <Bert> PeterL: No consensus?
  1771. # [22:44] <brianman> ... or are you saying that the from is clear enough that the other param doesn't need it?
  1772. # [22:44] <fantasai> fantasai^: gradients is a particularly tricky case because there are many arguments of the same type that need to be disambiguated
  1773. # [22:44] <TabAtkins_> A current example of using keywords in functional notation:
  1774. # [22:45] <TabAtkins_> file:///home/tabatkins/csswg/css3-lists/Overview.html#symbols-function
  1775. # [22:45] <Bert> Molly: Seems less to do with keywords, more to do with notation, i.e., the brackets.
  1776. # [22:45] * Joins: Frankie (Frankie@63.145.238.4)
  1777. # [22:45] <Bert> ... That means something for computer scientists.
  1778. # [22:45] <TabAtkins_> http://dev.w3.org/csswg/css3-lists/#symbols-function
  1779. # [22:45] <Bert> ... Simon's examples in IRC make sense to me.
  1780. # [22:45] <Bert> ... What is the pb with those?
  1781. # [22:45] <brianman> @Bert - Color stops problem.
  1782. # [22:46] <Bert> ... Is it the notation? The limitations?
  1783. # [22:46] <Bert> Simon: No consensus about needed the shape.
  1784. # [22:46] <Bert> ... We need to think about all the things that use func. notation.
  1785. # [22:46] <brianman> 1. The color stops are different from the shape/size/location params. 2. the color steps are a list.
  1786. # [22:46] <brianman> 2 - If you're trying to get order-variability support, you need to group the color stops
  1787. # [22:47] * Joins: lgombos (Laszlo@63.145.238.4)
  1788. # [22:47] <Bert> Florian: Values in general; some have just numbers, some have extra things to make it clearer. So far we didn't consider that inconstsient.
  1789. # [22:47] <brianman> 1 - I think of the color stops as a different thing than the params...just like for linear.
  1790. # [22:47] <Bert> ... Why do we think it is incosistent here?
  1791. # [22:47] * ed agrees with brianman
  1792. # [22:47] <Bert> PeterL: Transforms use a matric, that is a tradition, makes sense to people, no need to label it.
  1793. # [22:47] <Bert> ... What now?
  1794. # [22:47] <Bert> s/matic/matrix/
  1795. # [22:48] <Bert> Tab: Want to add a focal point later to gradients.
  1796. # [22:48] <Bert> ... More general discussion about notations later.
  1797. # [22:48] <brianman> For those that didn't read the e-mail, with one slight adjustment I could accept Elika's radial syntax.
  1798. # [22:48] <Bert> ... Let's settle on radial gradients now.
  1799. # [22:49] <Bert> Brad: linear gradiesnt have spaces.
  1800. # [22:49] <Bert> ... Spaces separate items in a list.
  1801. # [22:49] <fantasai> Brad: Linear gradients already has "to", already uses spaces to separate certain items, and uses commas in a way that's consistent with how we use them in other property values
  1802. # [22:49] <Bert> ... We are only putting () around them here.
  1803. # [22:49] <Bert> Tab: Poll on gradients, and general notation discussion later.
  1804. # [22:50] <brianman> Isn't tha the same as yesterday, Tab?
  1805. # [22:50] <Bert> Florian: Difficult to it in that order.
  1806. # [22:50] <brianman> (What's new in your poll.)
  1807. # [22:50] * Joins: jeff (Jeff@mcclure.w3.org)
  1808. # [22:50] <Bert> Tab: It slows down gradients. We know the features, we just discssu synatx forever.
  1809. # [22:50] * mollydotcom from Eric Meyer "I like gradient(shape circle, from left to bottom left, colors red, green)-makes sense, is very clear.
  1810. # [22:50] <Bert> .. Tjis is a minor issue.
  1811. # [22:50] <Bert> Shane: Let's get gradients out first.
  1812. # [22:51] <Bert> ... Schedule alternative syntaxes discussion.
  1813. # [22:51] <Bert> fantasai: That's terrible. Have to learn two syntaxes.
  1814. # [22:51] <brianman> @molly - sorry, your syntax confuses me terribly
  1815. # [22:51] <Bert> PeterL: Serialization issues too.
  1816. # [22:51] * Joins: howcome (howcome@63.145.238.4)
  1817. # [22:52] <brianman> ...the middle param
  1818. # [22:52] <Bert> sylvaing: Who would formally object to [???]
  1819. # [22:52] <fantasai> s/[???]/the current comma-separated syntax/
  1820. # [22:52] <brianman> the 09/08 WD you mean?
  1821. # [22:52] * Quits: dowan (forty4@63.145.238.4) (Quit: dowan)
  1822. # [22:52] <brianman> 2011/09/08
  1823. # [22:52] <Bert> PeterL: Value in readability and extensibility.
  1824. # [22:52] <fantasai> plinss: A fair question would be to ask would anyone formally object to publishing with this syntax?
  1825. # [22:53] * Quits: anne (annevk@63.145.238.4) (Quit: anne)
  1826. # [22:53] <fantasai> sylvaing: why should we change it?
  1827. # [22:53] <Bert> [two many talking at the same time]
  1828. # [22:53] <fantasai> plinss: I think it's a win for readability and understandability, and a big win for extensibility
  1829. # [22:53] <Bert> peterL: valuable to look at this and see if it blocks something later.
  1830. # [22:53] * Joins: tantek (tantek@63.145.238.4)
  1831. # [22:54] <Bert> howcome: What is the example?
  1832. # [22:54] <Bert> fantasai: Radial with offset center.
  1833. # [22:54] <dbaron> To be clear: I really don't like "shape circle", since "circle" is obviously a shape so "shape" is redundant -- unless we do something more explicitly property:value-like.
  1834. # [22:54] <Bert> Tab: circle at offset X X
  1835. # [22:54] <Bert> JohnD: At some point it gets easier to have an @-rule, as simon said.
  1836. # [22:55] <Bert> howcome: I think gradietns is already beyond readabilty.
  1837. # [22:55] <Bert> Tab; Why didn't you say that earlier?
  1838. # [22:55] <Bert> s/;/:/
  1839. # [22:55] <Bert> Tab: We settled on all this months ago.
  1840. # [22:55] <Bert> JohnD: But you also say you want to extend this.
  1841. # [22:55] <Bert> Tab: Yes, and at some point we say let's not extend any further.
  1842. # [22:56] <Bert> ... We can have that discussion in the future.
  1843. # [22:56] <Bert> ... But keep open possibility to extend in current syntax.
  1844. # [22:56] <Bert> PeterL: I want gradients done. Don't publish and change again.
  1845. # [22:56] <Bert> ... Let;s strawpoll.
  1846. # [22:56] <fantasai> Tab^: That was in the WebKit syntax, and I dropped it partly because I couldn't get a syntax that was reasonable with it.
  1847. # [22:57] <Bert> [preparing strawpoll, finding exampels to show on screen]
  1848. # [22:57] <JohnJansen> brianman, can you post what slight adjustment you need in order to accept Elika's syntax?
  1849. # [22:58] <brianman> sure
  1850. # [22:58] <TabAtkins_> Option A: radial-gradient(1em 2em, 3em 5em, red, orange, yellow)
  1851. # [22:58] <brianman> (i'll wait for tab)
  1852. # [22:58] <TabAtkins_> Option B: radial-gradient(3em 5em at 1em 2em as red, orange, yellow)
  1853. # [22:58] <TabAtkins_> Option c: radial-gradient(3em 5em at 1em 2em, red, orange, yellow)
  1854. # [22:58] <brianman> Yah, that about captures it
  1855. # [22:59] <bradk> B.2 radial-gradient(3em 5em at 1em 2em with red, orange, yellow)
  1856. # [22:59] <brianman> A=WD, I prefer A but I'm fine with C. I dislike B for at least two reasons.
  1857. # [22:59] <Bert> Tab: Second is Elika's
  1858. # [22:59] <Bert> ... 3rd is a variant, with "," instead of as
  1859. # [23:00] <Bert> Luke: Option missing is to name the first params.
  1860. # [23:00] <Bert> Florian: Not sure this is the right set of options for the poll.
  1861. # [23:00] <Bert> ... Need to eliminate.
  1862. # [23:00] <Bert> Tab: Can give multiple votes, to all the ones you like.
  1863. # [23:01] <shans> D. radial-gradient(shape 3em 5em at 1em 2em as red, orange, yellow)
  1864. # [23:01] * ed prefers option A)
  1865. # [23:02] * Quits: fukuno (fukuno@63.145.238.4) (Ping timeout)
  1866. # [23:02] * cyril prefers option A) too, and notes that compared to SVG it's missing the focal point position and compared to canvas it's missing the inner circle size
  1867. # [23:02] <brianman> @cyril - correct on SVG, canvas
  1868. # [23:02] <Bert> Bert: [question about ems in the notation]
  1869. # [23:03] <Bert> JohnJ: A
  1870. # [23:03] <Bert> howcome: Where is the "from" keyword that elika propsoed?
  1871. # [23:03] <brianman> good point
  1872. # [23:03] <fantasai> plinss: The word is unimportant, the concept is what we're voting on
  1873. # [23:03] <Bert> PeterL: The exact word is not inmportant.
  1874. # [23:03] <dbaron> how does the ellipse/circle closest-side/closest-corner/farthest-side/farthest-corner fit into this?
  1875. # [23:04] <fantasai> part of <shape>
  1876. # [23:04] <TabAtkins_> dbaron: First argument is <shape>, which includes that.
  1877. # [23:04] <Bert> PeterL B, then c then A
  1878. # [23:04] <brianman> replace "3em 5em" with the shape keyword
  1879. # [23:04] <brianman> in all the options
  1880. # [23:04] <brianman> the <shape> keywords rather
  1881. # [23:04] <Bert> s/peterL/PeterL:/
  1882. # [23:04] <Bert> howcom: a
  1883. # [23:04] <Bert> koji: A
  1884. # [23:04] <Bert> markus: a
  1885. # [23:05] <Bert> Alan: b, c
  1886. # [23:05] <Bert> soonbo: a
  1887. # [23:05] <Bert> florian: b, c, a
  1888. # [23:05] <dbaron> (I saw that as both a shape and a size, but oh well...)
  1889. # [23:05] <Bert> bert: abstain
  1890. # [23:05] <Bert> masa: abstain
  1891. # [23:05] <Bert> EricM: b
  1892. # [23:05] <bradk> Brad: C, then B
  1893. # [23:05] <Bert> brad: c, b
  1894. # [23:05] <brianman> [After the poll I'd like to address dbaron's question.]
  1895. # [23:06] <Bert> simon: a, d
  1896. # [23:06] <Bert> alex: abstain
  1897. # [23:06] <Bert> kimberley: abstain
  1898. # [23:06] <Bert> rossen: a, c
  1899. # [23:06] <TabAtkins_> (Yes, "radial-gradient(ellipse at top left, red, blue)" is fine.)
  1900. # [23:06] <Bert> sylvaing: a
  1901. # [23:06] <Bert> johnD: a c
  1902. # [23:06] <Bert> arron: b, a
  1903. # [23:06] <Bert> tab: b, c
  1904. # [23:07] <Bert> shane: b, c
  1905. # [23:07] * ed AC/DC anyone?
  1906. # [23:07] <Bert> kimberlyblessing: a
  1907. # [23:07] <glazou> abstain
  1908. # [23:07] <Bert> fantasai: b, c
  1909. # [23:07] <Bert> luke: a, d
  1910. # [23:07] * Joins: anne (annevk@63.145.238.4)
  1911. # [23:08] <fantasai> plinss: If you group b+c as one camp and a as a second, it's a dead tie
  1912. # [23:08] <Bert> PeterL: This isn't showing us anything.
  1913. # [23:08] <dbaron> my prefs are d with the b->c substitution, c, a, if I'm understanding correctly
  1914. # [23:08] <Bert> fantasai: Open up to designers on wiki.
  1915. # [23:09] <Bert> Tab: resolve in two weeks?
  1916. # [23:09] <brianman> Resolve how?
  1917. # [23:09] <fantasai> on csswg blog
  1918. # [23:09] <brianman> ah.
  1919. # [23:09] <Bert> ACTION fantasai: make post with the options, just two options.
  1920. # [23:09] * trackbot noticed an ACTION. Trying to create it.
  1921. # [23:09] * RRSAgent records action 17
  1922. # [23:09] <trackbot> Created ACTION-397 - Make post with the options, just two options. [on Elika Etemad - due 2011-11-08].
  1923. # [23:10] <brianman> The "2" in that action is troubling.
  1924. # [23:10] <brianman> Either you choose to screw B or C.
  1925. # [23:10] <Bert> [discussion about @-rule]
  1926. # [23:10] * sylvaing next: whether to use tabs or spaces
  1927. # [23:10] <Bert> RESOLVED: decide in two weeks.
  1928. # [23:10] * glazou I want to use only one Tab, thanks
  1929. # [23:11] * Ms2ger one Tab, and spaces for indentation?
  1930. # [23:11] <glazou> :)
  1931. # [23:11] <Bert> [agenda discussion]
  1932. # [23:12] * dbaron wonders when CSSWG is doing its break
  1933. # [23:12] * dbaron could come back now or in a little bti
  1934. # [23:12] <plinss> 10 mins
  1935. # [23:12] <plinss> pf joint meeting at 3:30
  1936. # [23:12] <Bert> Topic: Variables
  1937. # [23:12] <glazou> plinss: and variables ?
  1938. # [23:12] <glazou> ah ok
  1939. # [23:12] <Bert> Tab: We talked about it in Seattle. I revised things since.
  1940. # [23:12] <JohnJansen> dbaron, we're going to power through a bit of variables first, then do the joint meeting. short break before joint meeting
  1941. # [23:13] <Bert> ... Let's go over it.
  1942. # [23:13] <Bert> ... Variables were @-rules before.
  1943. # [23:13] <Bert> ... That has scoping problems, etc.
  1944. # [23:13] <Bert> ... So new idea is to define data-* properties.
  1945. # [23:14] <Bert> ... Can be any name after data-. Need to define the syntax exactly.
  1946. # [23:14] <Bert> ... Later.
  1947. # [23:14] <Bert> ... They have arbitrary name and arbitrary value.
  1948. # [23:14] <Bert> .. Attaches these proeprties to an element.
  1949. # [23:14] <Bert> ... Follows cascade, inheritance, exactly like every othe rproperty.
  1950. # [23:14] <Bert> Markus: So always inherited?
  1951. # [23:15] <Bert> Tab: Yes, always inherited.
  1952. # [23:15] <Bert> ... A data- property doens't do anything by itelf.
  1953. # [23:15] <Bert> ... But you can use them by referring to them.
  1954. # [23:15] <Bert> ... Example 1:
  1955. # [23:16] <Bert> ... Sets data-border-color on :root.
  1956. # [23:16] <Bert> ... Inherits to everything.
  1957. # [23:16] <Bert> ... An H1 later on has this property.
  1958. # [23:16] <Bert> ... Can refer to is: background: data(border-color)
  1959. # [23:16] <Bert> .. Example 2:
  1960. # [23:16] <Bert> s/.. /.../
  1961. # [23:17] * Quits: arno (arno@63.145.238.4) (Quit: Leaving.)
  1962. # [23:17] <Bert> ... Easier to understand, at least when you understand cascade and inheritance. :-)
  1963. # [23:17] <Bert> ... Libraries can declare their own variables.
  1964. # [23:18] <glazou> q+
  1965. # [23:18] <Bert> ... With this system you just set it on the root, and won't interfere.
  1966. # [23:18] * Joins: arno (arno@63.145.238.4)
  1967. # [23:19] <Bert> JohnD: name collision?
  1968. # [23:19] <Bert> Tab: Still possible , but addresses the majority of them.
  1969. # [23:19] <Bert> JohnD: So each of these data-* are in the cascade and visible to any element.
  1970. # [23:19] * glazou is on the queue
  1971. # [23:19] <Bert> dbaron: Yes, all inherited.
  1972. # [23:19] * Joins: gilles (gilles@63.145.238.4)
  1973. # [23:20] <Bert> JohnD: So if you set then inside a class...
  1974. # [23:20] * Joins: howard (howard_wan@63.145.238.4)
  1975. # [23:20] <Bert> Tab: Then nothing outside that class they are not there, that's inheritance.
  1976. # [23:20] * Quits: Frankie (Frankie@63.145.238.4) (Quit: Frankie)
  1977. # [23:20] <Bert> dbaron: Some library that deals with a subtree.
  1978. # [23:20] <Bert> Tab: Such as widgets.
  1979. # [23:20] <Bert> dbaron: Tehre are other kinds of libraries.
  1980. # [23:21] <Bert> johnd: You say it resolves na,me collisions, but it simplifes, eliminates global scopes.
  1981. # [23:21] <Bert> PeterL: Not eliminated problem, bur reduced.
  1982. # [23:21] <Bert> howcome: when do you know a value is invalid?
  1983. # [23:21] <glazou> so I think this is clearly the cleanest and best CSS-integrated variables proposal since 1998 ; it's easy to understand, easy to edit, fast and easy to deploy from a web site point of view ; love it
  1984. # [23:21] <Bert> Tab: At computed value time.
  1985. # [23:22] <Bert> ... Say it recolves to color: foo
  1986. # [23:22] <Bert> ... At that point it is not a valid value, and the initial value will be used. Not the previous rule.
  1987. # [23:22] <glazou> q-
  1988. # [23:22] <Bert> fantasai: memeroy usage?
  1989. # [23:23] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
  1990. # [23:23] <Bert> Tab: Shane tried and said it was no so bad.
  1991. # [23:23] <Bert> [break]
  1992. # [23:23] * Quits: duga (duga@63.145.238.4) (Quit: duga)
  1993. # [23:23] <Bert> s/memeroy/memory/
  1994. # [23:23] * Quits: bradk (bradk@63.145.238.4) (Quit: Computer has gone to sleep)
  1995. # [23:23] <glazou> so no resolution here ?
  1996. # [23:23] * Quits: dbaron (dbaron@63.145.238.4) (Ping timeout)
  1997. # [23:23] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
  1998. # [23:24] <Bert> rrsagent, make minutes
  1999. # [23:24] <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-css-minutes.html Bert
  2000. # [23:24] <glazou> Bert: no resolution to publish variables ?
  2001. # [23:25] * Bert : we continue later.
  2002. # [23:25] <glazou> ok
  2003. # [23:25] * Bert first the joint meeting with PF
  2004. # [23:26] <glazou> thks Bert
  2005. # [23:32] * Joins: dbaron (dbaron@63.145.238.4)
  2006. # [23:33] * Joins: Mike5 (Mike5@mcclure.w3.org)
  2007. # [23:34] * myakura wonders why the minutes is dated as 31st.
  2008. # [23:34] * Quits: mihara (mihara@63.145.238.4) (Client exited)
  2009. # [23:36] * Quits: glazou (glazou@63.145.238.4) (Quit: glazou)
  2010. # [23:37] <Ms2ger> Meeting: CSSWG f2f meeting at TPAC
  2011. # [23:37] * Joins: mihara (mihara@63.145.238.4)
  2012. # [23:37] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
  2013. # [23:38] * Joins: florian (florianr@63.145.238.4)
  2014. # [23:38] * mollydotcom stepping outside it's too hot, if you need me I'll follow on IRC
  2015. # [23:38] <Bert> Topic: PF - CSS joint meeting
  2016. # [23:38] * Quits: mollydotcom (mollyh@63.145.238.4) (Client exited)
  2017. # [23:38] <Bert> Janina: We appreciate your time.
  2018. # [23:38] * Joins: vhardy (vhardy@192.150.10.200)
  2019. # [23:39] * Joins: duga (duga@63.145.238.4)
  2020. # [23:39] <Bert> ... We haven't talked to you as often as we should. Been busy with HTML5 and other things.
  2021. # [23:39] * Quits: Kai (chatzilla@63.145.238.4) (Ping timeout)
  2022. # [23:39] * Joins: jamesn (jamesn@63.145.238.4)
  2023. # [23:39] <Bert> ... We have a task to look at other groups' work.
  2024. # [23:39] <Bert> ... We have been trying to make up for lost time in CSS.
  2025. # [23:39] <Bert> ... Created a wiki with CSS modukes.
  2026. # [23:40] <Bert> ... Checked 50-60% so far
  2027. # [23:40] <Bert> ... Several issues, of diff. types.
  2028. # [23:40] * Joins: MichaelC (Michael@128.30.52.169)
  2029. # [23:40] <Bert> ... Soem can be done in e-mail.
  2030. # [23:40] <Bert> ... Shoild get started on the overarching issues.
  2031. # [23:40] <Bert> ... Some might involve others than just CSS and PF.
  2032. # [23:41] <Bert> ... CSS is importan to accessibility.
  2033. # [23:41] * Quits: dbaron (dbaron@63.145.238.4) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  2034. # [23:41] <Bert> ... CSS should be an accessibility success story.
  2035. # [23:41] * Joins: dbaron (dbaron@63.145.238.4)
  2036. # [23:41] <Bert> ... Haveong looked at the modules,
  2037. # [23:41] <Bert> ... (can we project them?)
  2038. # [23:42] <Bert> ... We should start to understand CSS 3.
  2039. # [23:42] <Bert> ... An overview would be useful.
  2040. # [23:42] <Bert> ... Michael will have a list in a second.
  2041. # [23:42] <dbaron> should we mention the snapshot?
  2042. # [23:42] <Bert> ... We're concerned about reflowing content.
  2043. # [23:43] <MichaelC> -> http://www.w3.org/WAI/PF/wiki/CSS/Spec_Review/Discussion PFWG Discussion notes on CSS accessibility
  2044. # [23:43] <Bert> ... Not a bad idea, but may negatively impact the reading order, with braille and screen readers, may affect tab order.
  2045. # [23:43] <Bert> ... May need a solution.
  2046. # [23:43] <Bert> ... We should be able to influence the reading order.
  2047. # [23:43] <Bert> PeterL: Maybe not thinking about the same terms with the same meaning.
  2048. # [23:44] <Bert> dbaron: Can you give what you think it means?
  2049. # [23:44] <Bert> SandyShelly: Concern is , let';take an example:
  2050. # [23:44] <Bert> ... flexbox
  2051. # [23:44] <Bert> ... taborder still follows source order, but screen order is different.
  2052. # [23:44] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
  2053. # [23:44] * Joins: fukuno (fukuno@63.145.238.4)
  2054. # [23:45] <Bert> ... Several places in CSS do that.
  2055. # [23:45] <Bert> ... ARIA and script can help.
  2056. # [23:45] <Bert> ... But is at differnet lvel, in HTML.
  2057. # [23:45] <Bert> dbaron: Authors who want to use different orders for some reasons,
  2058. # [23:45] <myakura> s/SandyShelly/Cynthia Shelly/
  2059. # [23:45] <Bert> ... do that intentionally.
  2060. # [23:46] <Bert> Cynthia: that breaks it for sighted users.
  2061. # [23:46] <Bert> Tab: reflow is very useful for repairing source order.
  2062. # [23:46] * Quits: jeff (Jeff@mcclure.w3.org) (Ping timeout)
  2063. # [23:46] <Bert> cynthia: Yes, good use cases, but
  2064. # [23:47] <Bert> ... some use cases not thought through, especially sighted keyboard users.
  2065. # [23:47] * Quits: howard (howard_wan@63.145.238.4) (Quit: howard)
  2066. # [23:47] <Bert> ... (who can't use a mouse)
  2067. # [23:47] <Bert> Alex: Semantic order and visual order.
  2068. # [23:47] <Bert> ... If we believe the semantic order is the right order, then follow that, otherwise follow th visual order.
  2069. # [23:48] <Bert> cynthia: Focussable elements inside that, eand keeping keyboard and scren in sync. is problematic.
  2070. # [23:48] * Joins: bradk (bradk@63.145.238.4)
  2071. # [23:48] <Bert> ... May need some things in CSS to change the tab order or flow. Rather in CSS than HTML.
  2072. # [23:48] <Bert> JamesCraig: Related properties that we wanted an explanation of: nac-index, nav-right...
  2073. # [23:48] <fantasai> http://www.w3.org/TR/css3-ui/#nav-index
  2074. # [23:49] <fantasai> http://www.w3.org/TR/css3-ui/#nav-dir
  2075. # [23:49] <Bert> Tab: Editor is Tantek, but nor here now.
  2076. # [23:49] <Bert> Florian: Semantic order and visual order both are meaningful. One is not right or wrong.
  2077. # [23:49] <Bert> ... May need to tab throught source order *and* through visual order.
  2078. # [23:50] <Bert> Cynthis: Application dependent. let user choose.
  2079. # [23:50] <Bert> Tab: Rearranging focussable things...
  2080. # [23:50] * Joins: jun_ (qw3birc@128.30.52.28)
  2081. # [23:50] <Bert> ... At leats blocks of things rearranged with media queries.
  2082. # [23:50] <Bert> Janina: Author must indeed be able to rearrnge layout.
  2083. # [23:51] <Bert> ... But some users may need to consume it differently.
  2084. # [23:51] <Bert> markus: A media-query-driven tab-order.
  2085. # [23:51] <Bert> Janina: Perjhaps. We don't have a slution.
  2086. # [23:51] * Joins: hiroki (h_yamada@128.30.52.28)
  2087. # [23:51] <Bert> cynthia: main req. is that it is in CSS layer, not HTML.
  2088. # [23:51] <Bert> s/req./requirement/
  2089. # [23:52] <Bert> fnatasi: Isn't that the nav-index property.
  2090. # [23:52] <Bert> Tab: The existing property is not quite right. We have been working on similar things. This is less useful as it can be.
  2091. # [23:53] <Bert> ... So we can do some work on it.
  2092. # [23:53] <Bert> s/fnatasi/fantasai/
  2093. # [23:54] <Bert> michael: a question on priorities of CSS specs.
  2094. # [23:54] <Bert> JohnD: yes we like to know that too :-)
  2095. # [23:54] <Bert> tab: They can easily end up reordered.
  2096. # [23:54] <dbaron> should also note that http://www.w3.org/TR/CSS/ gives an overview of the stable stuff
  2097. # [23:54] <Bert> fantasai: there is no good answer to that.
  2098. # [23:54] <Bert> MichaelC: So we prioritize our own time on the reviews.
  2099. # [23:55] <Bert> fantasai: specs that head to LC vs other specs.
  2100. # [23:55] * Ms2ger notes obsolescence notices
  2101. # [23:55] <Bert> ... We can break doewn in to 3 categories od stability.
  2102. # [23:55] <Bert> ... I have been writing that up in a blog
  2103. # [23:56] <Bert> ACTION fantasai update current work page with more granularity by stability rather than priority.
  2104. # [23:56] * trackbot noticed an ACTION. Trying to create it.
  2105. # [23:56] <trackbot> Created ACTION-398 - Update current work page with more granularity by stability rather than priority. [on Elika Etemad - due 2011-11-08].
  2106. # [23:56] * Quits: arno (arno@63.145.238.4) (Quit: Leaving.)
  2107. # [23:56] <Bert> MichaelC: User style sheets:
  2108. # [23:56] <Bert> ... User can override author, but
  2109. # [23:57] <Bert> ... if author uses an inaccessible design,
  2110. # [23:57] <Bert> ... it is not so feasible to override it.
  2111. # [23:57] <Bert> janina: is there some way to make those overrides more accessible.
  2112. # [23:57] <Bert> ... be more pro-active.
  2113. # [23:57] <Bert> Tab: I expect W3C cannot do much.
  2114. # [23:57] <Bert> ... isa UA issue.
  2115. # [23:58] <Bert> ... Browsers should do it better. Not standardization issue.
  2116. # [23:58] <Bert> MichaelC: style sheets keyed off of class etc. So difficult to override.
  2117. # [23:58] <Bert> fantasai: We are working on consitional rules.
  2118. # [23:58] <Bert> .. Designate a block for a particular URL or domain.
  2119. # [23:58] <Bert> s/../.../
  2120. # [23:59] <Bert> howcome: can even put all those in a single file.
  2121. # [23:59] <Bert> ... the file may be huge, though.
  2122. # [23:59] <Bert> Tab: Accessibility related issues for user style sheets, sites that share those.
  2123. # [23:59] <Bert> howcome: we can disable floats, go black&whiet, in Opera, e.g.
  2124. # Session Close: Wed Nov 02 00:00:00 2011

The end :)