/irc-logs / w3c / #css / 2009-11-02 / end

Options:

  1. # Session Start: Mon Nov 02 00:00:00 2009
  2. # Session Ident: #css
  3. # [01:20] * Quits: arronei (arronei@131.107.0.86) (Ping timeout)
  4. # [01:25] * Joins: arronei (arronei@131.107.0.82)
  5. # [01:28] * Joins: plinss (plinss@72.254.91.137)
  6. # [01:35] * Quits: plinss (plinss@72.254.91.137) (Quit: plinss)
  7. # [02:34] <dbaron> mmm, dark at 5:30
  8. # [02:35] * dbaron wonders if the restaurant for dinner has already been chosen
  9. # [02:48] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  10. # [02:48] * Quits: dsinger (dsinger@38.114.142.134) (Quit: dsinger)
  11. # [02:57] * Quits: ChrisL2 (ChrisL@128.30.52.169) (Ping timeout)
  12. # [03:09] * Quits: dbaron (dbaron@98.234.51.190) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  13. # [03:14] * Quits: Curt` (curt@76.241.83.104) (Quit: Sleep)
  14. # [03:26] * Joins: TabAtkins (chatzilla@72.254.98.254)
  15. # [03:27] * Joins: Arron (arronei@72.254.89.128)
  16. # [03:42] * Quits: TabAtkins (chatzilla@72.254.98.254) (Ping timeout)
  17. # [03:44] * Quits: Arron (arronei@72.254.89.128) (Ping timeout)
  18. # [04:21] * Joins: plinss (plinss@72.254.91.137)
  19. # [05:43] * Joins: Arron (arronei@72.254.89.128)
  20. # [05:46] * Quits: Arron (arronei@72.254.89.128) (Ping timeout)
  21. # [06:31] * Joins: shepazu (schepers@128.30.52.169)
  22. # [06:53] * Joins: annevk (opera@12.197.88.10)
  23. # [06:59] * Joins: dsinger (dsinger@68.126.189.44)
  24. # [07:15] * Quits: annevk (opera@12.197.88.10) (Quit: annevk)
  25. # [07:19] * Joins: TabAtkins (chatzilla@72.254.98.254)
  26. # [07:22] * Quits: TabAtkins (chatzilla@72.254.98.254) (Ping timeout)
  27. # [07:32] * Quits: plinss (plinss@72.254.91.137) (Quit: plinss)
  28. # [07:37] * Joins: TabAtkins (chatzilla@72.254.98.254)
  29. # [07:38] * Joins: Arron (arronei@72.254.89.128)
  30. # [07:49] * Quits: Arron (arronei@72.254.89.128) (Ping timeout)
  31. # [07:50] * Quits: TabAtkins (chatzilla@72.254.98.254) (Ping timeout)
  32. # [08:26] * Joins: plinss (plinss@72.254.91.137)
  33. # [09:46] * Joins: Arron (arronei@72.254.89.128)
  34. # [09:50] * Quits: Arron (arronei@72.254.89.128) (Ping timeout)
  35. # [11:29] * Quits: plinss (plinss@72.254.91.137) (Quit: plinss)
  36. # [13:32] * Joins: MoZ (chatzilla@82.230.92.154)
  37. # [14:05] * Joins: myakura (myakura@114.163.221.102)
  38. # [14:07] * Joins: howcome (howcome@80.203.19.119)
  39. # [16:12] * Joins: Arron (arronei@72.254.111.4)
  40. # [16:13] * Joins: plinss (plinss@72.254.111.33)
  41. # [16:36] * Joins: annevk (opera@72.254.112.194)
  42. # [16:44] * Quits: dsinger (dsinger@68.126.189.44) (Quit: dsinger)
  43. # [17:08] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  44. # [17:22] * Quits: plinss (plinss@72.254.111.33) (Quit: plinss)
  45. # [17:23] * Joins: jdaggett (jdaggett@72.254.115.101)
  46. # [17:24] * Joins: smfr (smfr@72.254.115.22)
  47. # [17:28] * Quits: annevk (opera@72.254.112.194) (Quit: annevk)
  48. # [17:40] * Quits: Arron (arronei@72.254.111.4) (Ping timeout)
  49. # [17:42] * Joins: dbaron (dbaron@72.254.82.225)
  50. # [17:44] * Joins: plinss (plinss@72.254.111.33)
  51. # [17:44] * Joins: glazou (glazou@72.254.115.247)
  52. # [17:49] * Joins: sylvaing (sylvaing@72.254.116.25)
  53. # [17:49] * Joins: anne (annevk@72.254.94.228)
  54. # [17:50] * Joins: shepazu (schepers@128.30.52.169)
  55. # [18:03] * Joins: mjs (mjs@72.254.93.235)
  56. # [18:03] * Quits: dbaron (dbaron@72.254.82.225) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  57. # [18:03] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  58. # [18:03] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
  59. # [18:03] <RRSAgent> logging to http://www.w3.org/2009/11/02-CSS-irc
  60. # [18:03] * Joins: dbaron (dbaron@63.245.220.11)
  61. # [18:03] <plinss> rrsagent make logs public
  62. # [18:04] * Joins: Yves (ylafon@128.30.52.169)
  63. # [18:05] <sylvaing> ScribeNick: sgalineau
  64. # [18:05] <plinss> zakim, this is style
  65. # [18:05] <Zakim> plinss, I see Styl_CSS-FP(TPAC)12:00PM in the schedule but not yet started. Perhaps you mean "this will be style".
  66. # [18:05] <sylvaing> Introductions
  67. # [18:06] <sylvaing> Peter Linss, HP.
  68. # [18:06] * Joins: Arron (arronei@72.254.111.4)
  69. # [18:06] <sylvaing> Sylvain Galineau, Microsoft, IE team
  70. # [18:06] <plinss> zakim, this will be style
  71. # [18:06] <Zakim> ok, plinss; I see Styl_CSS-FP(TPAC)12:00PM scheduled to start 6 minutes ago
  72. # [18:06] <sylvaing> Arron Eicholz, Microsoft, IE Team
  73. # [18:06] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  74. # [18:06] <sylvaing> Beth and Simon, Apple, WebKit
  75. # [18:07] <sylvaing> David Baron, Mozilla
  76. # [18:07] <glazou> Pierre Saslawsky
  77. # [18:07] * Joins: Bert_lap (bert@128.30.52.169)
  78. # [18:07] <sylvaing> John Daggett, Mozilla Japan, CSS3 Fonts editor
  79. # [18:07] <sylvaing> Chris Lilley, W3C
  80. # [18:07] <sylvaing> Alex Mogilevsky, Microsoft
  81. # [18:08] <sylvaing> Tab Atkins, Invited Expert
  82. # [18:08] <sylvaing> Brad Kemper, Invited Expert
  83. # [18:08] <sylvaing> Elika Etemad (fantasai), Invited Expert
  84. # [18:08] <sylvaing> Daniel Glazman, csswg co-chair
  85. # [18:08] <sylvaing> Bert Bos, W3C
  86. # [18:08] <sylvaing> (scribe missed a couple of observers)
  87. # [18:09] <sylvaing> Topic: Meeting Agenda
  88. # [18:10] <sylvaing> http://wiki.csswg.org/planning/tpac-2009
  89. # [18:10] * Joins: mielke (48fe53a0@128.30.52.43)
  90. # [18:10] * fantasai waves to markus
  91. # [18:11] <mielke> *waves back :)
  92. # [18:12] <sylvaing> Discussing timing of various items, adding CSS test suite to agenda
  93. # [18:17] * Joins: hamaji (hamaji@72.254.84.191)
  94. # [18:20] <sylvaing> Topic: LC comments for Math-ML for CSS profile
  95. # [18:20] <glazou> mielke: you've got mail
  96. # [18:22] <sylvaing> bert: largely CSS2.1 to render MathML
  97. # [18:22] <sylvaing> bert: I didn't find anything I would comment on
  98. # [18:22] <mielke> sweet. thx for the agenda mail
  99. # [18:22] <sylvaing> http://www.w3.org/TR/2009/WD-mathml-for-css-20091006/
  100. # [18:24] <sylvaing> bert: in section 12 (default stylesheet), a general comment says 'it would be appropriate to extend CSS3 with a few math-specific properties'
  101. # [18:24] <sylvaing> glazou: it would be helpful to know what is intended
  102. # [18:24] * Joins: bradk (bradk@72.254.115.105)
  103. # [18:25] <sylvaing> bert: one approach involves additions to the box model for math layout. then stretchable characters such as a parenthesis stretching to the size of the box next to it
  104. # [18:25] <sylvaing> dbaron: stretchable characters require knowledge of what's being contained
  105. # [18:26] <sylvaing> bert: the stretching character is bound to something; but an additional issue is that stretching the height of a character may also impacts its width
  106. # [18:26] * Joins: TabAtkins (chatzilla@72.254.56.183)
  107. # [18:26] <sylvaing> bert: these are the general issues that were discussed in the past
  108. # [18:27] <sylvaing> jdagget notices variant properties under the math variants section and forecasts comments...
  109. # [18:28] <sylvaing> jdaggett: there are Unicode characters for maths outside the BMP
  110. # [18:30] <sylvaing> jdaggett: when you use math characters, things like italics may have a semantic meaning i.e. they're not presentation
  111. # [18:30] * Joins: szilles (chatzilla@72.254.62.158)
  112. # [18:31] <dbaron> 𝐅𝒖𝓷𝖐𝘆 𝘾𝐡𝒂𝓻𝖘
  113. # [18:31] <sylvaing> jdaggett: section 3.3: stretchar ?
  114. # [18:32] * Joins: alexmog (alexmog@72.254.94.79)
  115. # [18:33] <smfr> http://www.w3.org/TR/MathML2/chapter6.html#chars.BMP-SMP
  116. # [18:33] <bradk> stretchar is spelled consistently throughout at least.
  117. # [18:34] * Joins: ChrisL (ChrisL@128.30.52.169)
  118. # [18:34] <ChrisL> http://www.w3.org/TR/2009/WD-MathML3-20090604/chapter7.html#chars.BMP-SMP
  119. # [18:34] <ChrisL> 7.5 Mathematical Alphanumeric Symbols
  120. # [18:35] <sylvaing> TabAtkins: this section describes both Unicode and alternatives ways to specify math characters
  121. # [18:36] <ChrisL> "Mathematical Alphanumeric Symbol characters should not be used for styled text. For example, Mathematical Fraktur A must not be used to just select a blackletter font for an uppercase A. Doing this sort of thing would create problems for searching, restyling (e.g. for accessibility), and many other kinds of processing. "
  122. # [18:36] <sylvaing> jdaggett will send comments on document tonight
  123. # [18:37] <sylvaing> Bert will share the WG's answer with MathML
  124. # [18:37] <sylvaing> Topic: Transitions/Transformations/Animations
  125. # [18:37] * Joins: plh-webapps (plh@128.30.52.28)
  126. # [18:37] <ChrisL> also http://www.unicode.org/reports/tr25/tr25-8.html Unicode Technical Report #25
  127. # [18:37] <ChrisL> Unicode Support for Mathematics
  128. # [18:38] <sylvaing> glazou: there are large expectations from the web design community around these features
  129. # [18:38] * plh-webapps wonders if Dave Singer woke up this morning
  130. # [18:39] <sylvaing> glazou: we'd like to move these specifications along: edit the specs, test suites...
  131. # [18:40] <sylvaing> smfr: we're committed to moving the specs forward, specifically 2D Transforms and Transitions
  132. # [18:40] <sylvaing> smfr: 3D Transforms and Animations will likely take longer
  133. # [18:40] <fantasai> +David Singer (Apple)
  134. # [18:40] <sylvaing> smfr: we have tests we need to move to the W3C format
  135. # [18:41] <sylvaing> fantasai: we have both stand-alone testcases and reftests
  136. # [18:41] <sylvaing> fantasai: if we need another test format for transitions, that's understandable
  137. # [18:41] <sylvaing> dbaron: some of these tests will have to scripted and we should be ok with that
  138. # [18:42] <sylvaing> smfr: some of the functionality needed to test transitions may need to be specified as well
  139. # [18:43] * Joins: dsinger (dsinger@72.254.95.64)
  140. # [18:44] <sylvaing> dsinger: if we had agreement on a template testcase, it would help get us going
  141. # [18:46] <sylvaing> dbaron: I'd be willing to help edit Transitions
  142. # [18:47] * Parts: anne (annevk@72.254.94.228)
  143. # [18:47] * Joins: anne (annevk@72.254.94.228)
  144. # [18:49] * Quits: myakura (myakura@114.163.221.102) (Quit: Leaving...)
  145. # [18:49] * Joins: dethbakin (dethbakin@72.254.115.244)
  146. # [18:50] <sylvaing> dbaron: for the inheritance processing model issue, I think we decided that if you have 4 elements A, B, C in an ancestor-descendant relationship
  147. # [18:50] * Quits: plh-webapps (plh@128.30.52.28) (Client exited)
  148. # [18:50] <sylvaing> and you specify a transition on color in B and C and a dynamic color property change occurs, what happens to C's transition ?
  149. # [18:51] <sylvaing> we decided that C's transition does not happen but it doesn't inherit B's animated values
  150. # [18:52] <ChrisL> its just a case of being clear when the values are grabbed to compute the transition, and whether they can be changed during a transition.
  151. # [18:52] <sylvaing> dbaron: C's transition would only be triggered when C is updated
  152. # [18:53] <sylvaing> dbaron: if C was already in a transition, that would not be affected
  153. # [18:55] <sylvaing> smfr: Webkit does not currently handle transitions on inherited properties and we haven't seen any issues from it
  154. # [18:56] <sylvaing> glazou: are web designers going to understand this ?
  155. # [18:57] <sylvaing> szilles: this is the most understandable solution yet
  156. # [18:57] <TabAtkins> a { transition: none; color: blue; } a:hover { color: red; } b { transition: color 1s; } <-- If I hover <a>, should <b> transition? Does it currently?
  157. # [18:59] <bradk> A>B
  158. # [19:00] * Joins: plh-css (plh@128.30.52.28)
  159. # [19:01] <TabAtkins> b>c { transition: color 2s } <-- Given the previous rules, now <c> does *not* transition when I hover <a>, but it does inherit <b>'s colors as <b> transitions.
  160. # [19:02] <sylvaing> the answer to Tab's first case was that B does transition as the inherited color value is not animated
  161. # [19:04] <sylvaing> smfr: transitioning visibility is an area we have thought of making changes to create fading effects vs. the current specified behavior where all non-1 values result in visibility:hidden
  162. # [19:06] <sylvaing> pierres: regarding the inheritance discussion, does this mean that the result will be different depending on the sequence in which I trigger my transitions through script ?
  163. # [19:08] * plh-css rrsagent, where am I?
  164. # [19:08] * RRSAgent See http://www.w3.org/2009/11/02-CSS-irc#T18-06-54
  165. # [19:08] <TabAtkins> Example: <script> $foo.css("color","red"); $foo.css("transition","color 1s");</script> <-- Does the color transition? Does it not? Is this impl-dependent currently?
  166. # [19:08] <sylvaing> dbaron: transitions do complicate the model in that dynamic property updates were effectively simultaneous but now we still have residual effects from older values
  167. # [19:10] <fantasai> smfr describes a case where the author turns off transitions, sets an intermediate value, sets transitions back on, and then sets another value
  168. # [19:11] <fantasai> various browser optimizations may cause that intermediate value to not be used, in which case the transition transitions from the wrong start point
  169. # [19:16] * Joins: Lachy (Lachlan@72.254.57.120)
  170. # [19:16] * Quits: Lachy (Lachlan@72.254.57.120) (Connection reset by peer)
  171. # [19:16] * Joins: Lachy (Lachlan@72.254.57.120)
  172. # [19:17] * Joins: tantek (tantek@72.254.62.180)
  173. # [19:18] <sylvaing> TabAtkins: there was talk about grouping transitions together to happen as an atomic unit i.e. setting a number of transitions together without any one starting ahead of the others
  174. # [19:18] <sylvaing> dbaron: we already batch these things
  175. # [19:18] <sylvaing> plinss: the point is that the author can control when the batching start and stops
  176. # [19:19] <glazou> AGENDA, move fitting text-size to monday afternoon to allow SteveZ's presence
  177. # [19:19] <sylvaing> dbaron: the problem with such an API is that we will do more frequent flushing
  178. # [19:21] <fantasai> dbaron: the browser has to flush right before the "don't flush here" call
  179. # [19:21] <fantasai> dbaron: as well as at the "flush here" call
  180. # [19:21] <sylvaing> smfr: I think this issue requires a note in the spec
  181. # [19:21] <fantasai> dbaron: and if someone calls "don't flush here" in a loop to try to optimize, it'll cause lots of flushes and actually degrade perf
  182. # [19:21] * Quits: Lachy (Lachlan@72.254.57.120) (Connection reset by peer)
  183. # [19:21] <sylvaing> ACTION smfr Add implementation note in the spec about style update batches and their effect on transitions
  184. # [19:21] * trackbot noticed an ACTION. Trying to create it.
  185. # [19:21] <trackbot> Sorry, couldn't find user - smfr
  186. # [19:22] * smfr is here
  187. # [19:22] <sylvaing> sgalineau: pseudo-elements and transitions ?
  188. # [19:23] <sylvaing> smfr: Dean Jackson updated the spec so that they can transition
  189. # [19:23] <sylvaing> dbaron: only :before and :after transition.
  190. # [19:23] * Joins: Lachy (Lachlan@72.254.57.120)
  191. # [19:23] * Quits: Lachy (Lachlan@72.254.57.120) (Connection reset by peer)
  192. # [19:23] <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jun/0121.html and http://lists.w3.org/Archives/Public/www-style/2009Jul/0050.html are the messages about the inheritance issue we discussed earlier
  193. # [19:24] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  194. # [19:24] <sylvaing> ChrisL: are we aiming to move this specification to LC ?
  195. # [19:24] <sylvaing> glazou: it depends on the editorial stability of the document
  196. # [19:25] <TabAtkins> a { color: yellow; } <script>a.color="red"; a.transition="color 1s"; a.color="blue";</script> <-- So the proposal is just to say "Hey authors, watch out for this!"?
  197. # [19:25] <sylvaing> smfr: the spec has been edited over the w-e
  198. # [19:27] <sylvaing> fantasai: you will have less to do during LC if you put out another WD first with all your changes
  199. # [19:28] <sylvaing> Bert: I agree this is a likely path for transitions; I disagree that 2D transforms is as close to LC
  200. # [19:29] <TabAtkins> Anyone have a nightly of webkit with transitions?
  201. # [19:29] * Quits: mielke (48fe53a0@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
  202. # [19:29] * Joins: Lachy (Lachlan@72.254.57.120)
  203. # [19:31] <smfr> TabAtkins: yes
  204. # [19:31] <TabAtkins> smfr: Can I have it?
  205. # [19:31] <dbaron> I probably need to send a bunch of comments on the "Animation of property types" section...
  206. # [19:33] * Quits: plh-css (plh@128.30.52.28) (Quit: always accept cookies)
  207. # [19:33] * dbaron thinks that sounds like perl
  208. # [19:34] * dbaron (the language with too many operators)
  209. # [19:35] <sylvaing> tantek suggests an FAQ to answer 'When do we add a property?
  210. # [19:35] <tantek> greetings everyone
  211. # [19:35] <sylvaing> ' following a long discussion of this topic around 2D Transforms and all the other things we are adding to CSS
  212. # [19:35] <sylvaing> glazou agrees
  213. # [19:36] <sylvaing> ACTION Bert Draft an FAQ on when the CSS WG adds a new property
  214. # [19:36] * trackbot noticed an ACTION. Trying to create it.
  215. # [19:36] <trackbot> Created ACTION-189 - Draft an FAQ on when the CSS WG adds a new property [on Bert Bos - due 2009-11-09].
  216. # [19:37] * Quits: bradk (bradk@72.254.115.105) (Quit: Computer has gone to sleep)
  217. # [19:37] * Quits: dethbakin (dethbakin@72.254.115.244) (Quit: dethbakin)
  218. # [19:37] <sylvaing> <br />
  219. # [19:37] * Quits: glazou (glazou@72.254.115.247) (Quit: glazou)
  220. # [19:37] * Quits: plinss (plinss@72.254.111.33) (Quit: plinss)
  221. # [19:38] * Joins: glazou (glazou@72.254.115.247)
  222. # [19:38] <TabAtkins> Got a transition issue. Check out www.xanthir.com/etc/transitions.html. First, the transitions trigger on *pageload*, which is weird. Second, "baz" doesn't start transitioning until after "bar" is done, when it *should* just inherit "bar"'s color as "bar" transitions.
  223. # [19:39] * Quits: glazou (glazou@72.254.115.247) (Quit: glazou)
  224. # [19:40] * Quits: Arron (arronei@72.254.111.4) (Ping timeout)
  225. # [19:40] * Quits: smfr (smfr@72.254.115.22) (Quit: smfr)
  226. # [19:55] * Joins: dethbakin (dethbakin@72.254.115.244)
  227. # [19:56] * Quits: mjs (mjs@72.254.93.235) (Quit: mjs)
  228. # [19:56] * Quits: tantek (tantek@72.254.62.180) (Quit: tantek)
  229. # [19:59] * Quits: Lachy (Lachlan@72.254.57.120) (Quit: This computer has gone to sleep)
  230. # [20:01] * Joins: bradk (bradk@72.254.115.105)
  231. # [20:03] * Joins: smfr (smfr@72.254.115.22)
  232. # [20:03] <fantasai> TabAtkins: http://wiki.csswg.org/test/harness
  233. # [20:04] * Joins: glazou (glazou@72.254.115.247)
  234. # [20:04] <smfr> TabAtkins: your testcase looks like a webkit bug with transitions of inherited properties
  235. # [20:04] <smfr> TabAtkins: what does FF do?
  236. # [20:06] * Joins: mjs (mjs@72.254.93.235)
  237. # [20:07] <TabAtkins> smfr: Notice also that it transitions on page load from black to red. That doesn't seem to make sense.
  238. # [20:07] * Joins: hyatt (hyatt@98.201.21.231)
  239. # [20:07] <smfr> sounds like a bug
  240. # [20:07] * Joins: plinss (plinss@72.254.111.33)
  241. # [20:08] <sylvaing> smfr: transitions: we will publish another WD then aim for LC in early 2010
  242. # [20:08] * Joins: shepazu (schepers@128.30.52.169)
  243. # [20:08] * Joins: tantek (tantek@72.254.62.180)
  244. # [20:09] * Joins: Arron (arronei@72.254.111.4)
  245. # [20:09] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
  246. # [20:09] <sylvaing> glazou: 2D transforms; what about the rotated table header scenario esp. not overlapping preceding content ?
  247. # [20:09] <sylvaing> fantasai: this is difficult as the table header borders also need to be properly rotated ?
  248. # [20:10] <sylvaing> dbaron: there was a long discussion and proposal around this topic in the past (Beijing)
  249. # [20:10] * Quits: Bert_lap (bert@128.30.52.169) (Ping timeout)
  250. # [20:10] <sylvaing> Topic: CSS3 Animations
  251. # [20:10] * Joins: Bert_lap (bert@128.30.52.169)
  252. # [20:11] <sylvaing> smfr: we think animations are useful. There are things you can do with animations you can't with transitions such as moving objects through intermediate points
  253. # [20:12] <sylvaing> smfr: 3D Tranforms needs more work e.g. detailing the 3D hiearchy of elements
  254. # [20:13] <sylvaing> glazou: let's move transitions and 2d transforms forward
  255. # [20:13] * Zakim excuses himself; his presence no longer seems to be needed
  256. # [20:13] * Parts: Zakim (rrs-bridgg@128.30.52.30)
  257. # [20:13] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  258. # [20:14] <sylvaing> dbaron: I think transform-origin is interesting as in 3d the value requires extra input vs. 2d. (the latter is exactly like background-position)
  259. # [20:15] <sylvaing> sylvaing: what about the note at the top of 2d transforms re: transforming fixed positioned descendants ?
  260. # [20:16] <sylvaing> smfr: dave hyatt made this note; we think this is the most desirable behavior
  261. # [20:16] <sylvaing> dbaron: we do this as well
  262. # [20:16] <sylvaing> smfr: for fixed backgrounds, we have already noted that the transformed element will act like a porthole. we don't do this yet but will fix it
  263. # [20:17] <sylvaing> Topic: Modularization and how to write a CSS profile
  264. # [20:17] <smfr> i didn't say we'll fix it :)
  265. # [20:17] * fantasai sylvaing, if you want a break let me know
  266. # [20:17] * sylvaing oops
  267. # [20:17] * fantasai thinks you have been doing a lot of minuting today :)
  268. # [20:18] * sylvaing i like to make up apple claims though
  269. # [20:20] <sylvaing> szilles: ideally profiles should refer to RECs. if not, breaking circularity can be achieved by referring to a snapshot
  270. # [20:21] <sylvaing> fantasai: or a module such as CSS3 Multicolumn can refer to CSS2.1 but if an implementor supports CSS3 Color, the latter's definition of <color> then applies
  271. # [20:22] <sylvaing> szilles: then the profile should state this
  272. # [20:23] * fantasai reads from http://www.w3.org/TR/css-beijing/#css3 and the next section
  273. # [20:26] <sylvaing> quick discussion of when one can be conformant with no vendor prefix; answer: one a module reaches CR
  274. # [20:26] * Joins: mmielke (48fe53a0@128.30.52.43)
  275. # [20:26] <sylvaing> szilles: we hope that conformance would be claimed against the snapshot
  276. # [20:31] <sylvaing> szilles: if I don't know what a snapshot is, I won't find the information I need
  277. # [20:32] <sylvaing> fantasai: the CR reference for CSS3 should point to the snapshot
  278. # [20:33] <sylvaing> fantasai: we can update the snapshot as soon as Selectors moves to CR or PR
  279. # [20:34] * Joins: ChrisL (ChrisL@128.30.52.169)
  280. # [20:34] <fantasai> http://wiki.csswg.org/planning/tpac-2009
  281. # [20:35] <sylvaing> topic: text-overflow
  282. # [20:36] <sylvaing> fantasai: there have been comments re: text overflow in the vertical direction
  283. # [20:36] <sylvaing> fantasai: the feature was originally aimed at single lines; what about multi-line items ?
  284. # [20:36] <szilles> Note, that under current rules, an implementation is still conforming if it implements features, like CSS3 color, that are in CR, using the CSS property names rather than having a vendor prefix
  285. # [20:39] <fantasai> http://krijnhoetmer.nl/irc-logs/css/20090805#l-303
  286. # [20:39] * Quits: mmielke (48fe53a0@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
  287. # [20:42] <sylvaing> TabAtkins: there is no useful distinction between line boxes overflowing vertically vs. blocks overflowing vertically
  288. # [20:43] <sylvaing> smfr: a use case involves wrapped song names in the iTunes store that only need an ellipsis at the end of the last line
  289. # [20:44] <sylvaing> tantek: what we're saying is that this really is an inline overflow
  290. # [20:44] <fantasai> (there are only two lines of space for the song titles)
  291. # [20:46] <sylvaing> smfr: does this property cause overflow though ?
  292. # [20:47] <sylvaing> plinss: it seems orthogonal since its aim is to prevent overflow
  293. # [20:47] <sylvaing> tantek: agree
  294. # [20:47] <sylvaing> fantasai: do implementors agree on what the sensible behavior should be ?
  295. # [20:48] * Quits: ChrisL (ChrisL@128.30.52.169) (Client exited)
  296. # [20:48] <fantasai> smfr: We'd like to drop the requirement for overflow: hidden to trigger text-overflow
  297. # [20:48] <fantasai> peter: Seems like this property prevents overflow
  298. # [20:48] <fantasai> Alex: You can have other content that triggers overflow even in the presence of text-overflow
  299. # [20:49] <fantasai> Alex: e.g. if you have a float that overflows and triggers scrollbars, and then also have text truncated by text-overflow
  300. # [20:49] <fantasai> ...
  301. # [20:49] <dbaron> Tantek: could say that 'text-overflow' always forces 'overflow' to 'hidden'
  302. # [20:49] <dbaron> David Baron: Or you could say that it forces 'overflow' values other than 'visible' to 'hidden'
  303. # [20:50] <hyatt> don't you mean forces only visible to hidden?
  304. # [20:50] <dbaron> hyatt, no... but why do you suggest that?
  305. # [20:50] * tantek agrees with dbaron's proposal.
  306. # [20:50] <hyatt> you wouldn't want to turn overflow:scroll into hidden just because you set text-overflow after overflow
  307. # [20:50] <dbaron> hyatt, I think the issue Alex raised was complications crossing "whether to have scrollbars" and "whether to have ellipses"
  308. # [20:51] <dbaron> hyatt, or was that not the reason for the restriction in the first place?
  309. # [20:51] <dbaron> hyatt, so, in that case, why do we want to change 'overflow' at all?
  310. # [20:51] <dbaron> hyatt, or is it because otherwise nothing else in the spec actually hides the text that overflows?
  311. # [20:51] * fantasai is not capturing this discussion between Tab and Alex...
  312. # [20:51] <fantasai> TabAtkins: Anytime I'm using overflow: hidden for anything other than making the block overflow: hidden, I run into problems
  313. # [20:52] <fantasai> ... block formatting context ... etc
  314. # [20:52] <fantasai> Alex: How about floats?
  315. # [20:52] <fantasai> TabAtkins: If I want my floats to get cut, I want to put overflow: hidden on them. They're not text
  316. # [20:52] <fantasai> Alex: If there is a float in the text beyond the ellipsis cut-off point,
  317. # [20:52] <hyatt> can't text-overflow just be completely independent of overflow
  318. # [20:52] <fantasai> Alex: Where would be the hypothetical position for that float?
  319. # [20:53] <fantasai> (or something with abspos)
  320. # [20:53] <hyatt> like it would truncate even if overflow is visible
  321. # [20:53] <fantasai> Tab: Good question
  322. # [20:53] <hyatt> but doesn't imply overflow:hidden
  323. # [20:53] <fantasai> Tab: I think it would try to position itself at the end of the line
  324. # [20:53] <fantasai> Alex: Or pretend overflow: visible and just refuse to render the text
  325. # [20:53] <hyatt> i don't see why text-overflow has to really care what the value of overflow is...
  326. # [20:54] <fantasai> hyatt, what happens if you have overflow: scroll and a float that overflows and text-overflow won the text and then you scroll down?
  327. # [20:55] <fantasai> ...
  328. # [20:55] <hyatt> i can't tell what you mean exactly
  329. # [20:55] <fantasai> Alex: If there is a paragraph that fits perfectly, but there is a paragraph that does not fit
  330. # [20:55] <hyatt> (sorry i don't want to derail remotely, so just ignore me if it is convenient) :)
  331. # [20:56] <fantasai> Alex: Do we append an ellipsis to the paragraph that fits because of the paragraph that didn't fit?
  332. # [20:56] <fantasai> ...
  333. # [20:56] <sylvaing> plinss: yes, you want to truncate enough of the first paragraph to fit the ellipsis
  334. # [20:56] <fantasai> Alex: In the process of measuring one block of text, you have to consider text that comes later
  335. # [20:56] * hyatt is just looking at the really simple case of text overflow where you have a single line label... it's a bit inconvenient to have to explicitly say overflow:hidden in that case... although it's not the end of the world
  336. # [20:56] <fantasai> Peter: You finish the first paragraph, start the next paragraph, then go back and truncate the earlier paragraph
  337. # [20:56] * Quits: dethbakin (dethbakin@72.254.115.244) (Client exited)
  338. # [20:57] <fantasai> smfr: It's like the first-letter problem
  339. # [20:57] <fantasai> Tantek: Like the first-line problem
  340. # [20:57] * Joins: dethbakin (dethbakin@72.254.115.244)
  341. # [20:57] <tantek> ::first-line
  342. # [20:57] <fantasai> Alex: As you are formatting the line ... later you find that we have to go back and stick an ellipsis up there
  343. # [20:58] <fantasai> ...
  344. # [20:58] <fantasai> Steve: The critical thing is to say that there's content you're not seeing
  345. # [20:58] <fantasai> Tantek: Write up the testcases
  346. # [20:58] <TabAtkins> www.xanthir.com/etc/text-overflow.html
  347. # [20:59] <fantasai> Tab: Pull it up in Safari or IE8
  348. # [20:59] <fantasai> Tab: If you do, you see as expected the ellipsis
  349. # [20:59] <fantasai> Tab: But if you start scrolling, you don't see anymore of the text
  350. # [20:59] * fantasai hyatt, this is what I was talking about :)
  351. # [20:59] * fantasai or something like it
  352. # [21:00] * Joins: mmielke (cdf86653@128.30.52.43)
  353. # [21:00] <hyatt> of course you also said nowrap
  354. # [21:00] <fantasai> Peter: In this case I would argue you shouldn't have a scrollbar
  355. # [21:00] <fantasai> Peter: It should behave as if there is no content to scroll
  356. # [21:00] <hyatt> yup that's a bug in webkit that it showed a scrollbar
  357. # [21:00] <hyatt> an enabled scrollbar rather
  358. # [21:00] <fantasai> dbaron: dsinger made a comment to me which throws another comment in here
  359. # [21:01] <fantasai> dbaron: If it's wrapped and you're doing text-overflow ellipsis, you get the ellipsis on the last line
  360. # [21:01] <hyatt> that is definitely a bug in webkit
  361. # [21:01] <fantasai> dbaron: and it scrolls, and you scroll, you get something idfferent
  362. # [21:01] <fantasai> dbaron: Should these really behave differently?
  363. # [21:02] <fantasai> ...
  364. # [21:02] <fantasai> Peter: I implemented a control with this in 93. When you have a filename and it doesn't fit, it has an ellipsis.
  365. # [21:02] <fantasai> Peter: If I'm editing the field, the ellipsis goes away
  366. # [21:02] <fantasai> Peter: and it scrolls
  367. # [21:02] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
  368. # [21:02] <fantasai> Tantek: Sounds like :focus selector
  369. # [21:04] <fantasai> Peter: For Tab's case, I can see a case for having ellipsis on both sides as we scroll until we get to the end, and then the ellipsis is on the left side.
  370. # [21:04] <fantasai> Peter: In the vertical case, as I'm scrolling down, I'd want an ellipsis at the beginning
  371. # [21:04] <fantasai> Peter: I can imagine wanting that for e.g. a DVR
  372. # [21:05] <fantasai> Peter: And not all UAs have a scrollbar for scrolling
  373. # [21:06] <fantasai> fantasai: roc's interpretation was that the ellipsis is a render-time thing: you lay out everything and then just draw the ellipsis
  374. # [21:06] <fantasai> Peter: I get roc's point that you want it laid out and compute the scroll region as if there's no ellipsis
  375. # [21:06] <fantasai> Peter: but when you render the text on that line you need to actually put the ellipsis in the text flow
  376. # [21:06] * dbaron imagines a font with a ligature for "hello..."
  377. # [21:06] <fantasai> Peter: Otherwise you don't get proper ligatures, etc.
  378. # [21:07] <fantasai> Peter: It should look as if someone typed an ellipsis on the line
  379. # [21:07] * dbaron should have voted for lunch at noon rather than 1pm
  380. # [21:07] <fantasai> Steve: I'm confused in this particular case because I was thinkin the ellipsis would show me there's content that wouldn't fit
  381. # [21:07] <fantasai> Steve: but if I put scorllbars there all the content fits
  382. # [21:07] <fantasai> Steve: So there's no need for an ellipsis there
  383. # [21:07] * Joins: Hixie (ianh@129.241.93.37)
  384. # [21:07] <dbaron> s/scorllbars/scrollbars/
  385. # [21:08] <fantasai> Steve: But I do understand the example that peter mentioned, that the ellipsis is a second hint
  386. # [21:08] <fantasai> ...
  387. # [21:08] <fantasai> Tab: You're seeing the ellipsis as an indication of content you can't reach
  388. # [21:08] <fantasai> Tab: I see it as an indication of content you can't see
  389. # [21:09] <fantasai> Peter: We all agree that the behavior in Tab's example is not wanted (showing scrollbars indicating lots of content, but not beinga ble to scroll to it because it's truncated by the ellipsis)
  390. # [21:09] <fantasai> Alex: What I see here is interoperable behavior that can't be explained easily and doesn't have much use cases
  391. # [21:10] <sylvaing> fantasai: given that there *is* interoperable behavior, are implementors OK with changing it ?
  392. # [21:10] <fantasai> to make more sense :)
  393. # [21:11] <fantasai> Tab: I honestly can't see anyone depending on it working this way and not be happy with it changinge
  394. # [21:12] <fantasai> ...
  395. # [21:12] <fantasai> Alex: There are two questions here. Are we going to change quirks bahvior? No.
  396. # [21:12] <fantasai> Alex: Other question is what do we want to happen here, and this scenario is really questionable to begin with.
  397. # [21:12] <fantasai> Alex: We've created something and we're trying to figure out what we would want to happen
  398. # [21:13] <fantasai> Alex: We have wrapped text, and it may not fit in horiontal direction and it may not fit in vertical direction
  399. # [21:13] <fantasai> Alex: ....
  400. # [21:14] <fantasai> Alex: I like that it does not affect layout
  401. # [21:14] <fantasai> Alex: And just at render time we insert the ellipsis
  402. # [21:14] <fantasai> Alex: I don't think there are cases where we have ellipsis in the middle
  403. # [21:14] <fantasai> Peter: There's a use case for ellipsis in the middle
  404. # [21:15] <fantasai> Peter: URLs
  405. # [21:15] <fantasai> dbaron: We have a middle option for ellipsis in xul, too.
  406. # [21:15] <fantasai> dbaron: Also in bidi you might have cases for ellpisis in the middle
  407. # [21:16] <fantasai> dbaron: I think having a spec for bidi cases was one of the issues we're waiting on for implementing this
  408. # [21:16] <fantasai> smfr: What happens with selection? What happens when the user selects the ellipsis?
  409. # [21:17] <fantasai> dbaron: We don't define selection right now. We probably should at some point
  410. # [21:17] <fantasai> Steve: I have one concern with what you said Alex, which was focusing on text
  411. # [21:17] <tantek> fantasai, feel free to capture the selection question(s) as outstanding questions/issues for CSS3-UI
  412. # [21:17] <fantasai> Steve: What if I'm using images to create lines of symbols, what happens?
  413. # [21:18] * fantasai tantek, put it in Tracker
  414. # [21:18] * fantasai is trying to keep up with minutes
  415. # [21:18] <fantasai> Alex: You wouldn't get an ellipsis with floats, because then you don't have lines
  416. # [21:18] <fantasai> Steve: no, I have lines
  417. # [21:18] <TabAtkins> At the moment, both webkit and ie allow you to highlight the ellipsis, but then put only the visible text on the clipboard. Ellipsis doesn't carry with the content.
  418. # [21:18] <tantek> fantasai, I'm not familiar with Tracker, so I'll action you ;)
  419. # [21:18] <fantasai> ... something about a pseudo-element
  420. # [21:18] <fantasai> http://w3.org/Style/CSS/Tracker/ go for it
  421. # [21:18] <fantasai> it's really straightforward
  422. # [21:19] <fantasai> make product
  423. # [21:19] <fantasai> add an issue
  424. # [21:19] <tantek> ACTION fantasai: capture the (text) selection question(s) related to text-overflow as outstanding questions/issues for CSS3-UI
  425. # [21:19] * trackbot noticed an ACTION. Trying to create it.
  426. # [21:19] * RRSAgent records action 1
  427. # [21:19] <trackbot> Created ACTION-190 - Capture the (text) selection question(s) related to text-overflow as outstanding questions/issues for CSS3-UI [on Elika Etemad - due 2009-11-09].
  428. # [21:19] <fantasai> ACTION Tantek: learn to use Tracker
  429. # [21:19] * trackbot noticed an ACTION. Trying to create it.
  430. # [21:19] <trackbot> Sorry, couldn't find user - Tantek
  431. # [21:19] * RRSAgent records action 2
  432. # [21:19] * fantasai blames IT
  433. # [21:20] <fantasai> Alex: I would like resolution to keep ellipsis a render-time thing. I'm open to extending it
  434. # [21:20] * tantek /hidefrom trackbot
  435. # [21:20] <fantasai> Alex: Let's figure out what we need to do to have vertical overflow create ellipsis. that seems sensible and doable
  436. # [21:21] * Quits: glazou (glazou@72.254.115.247) (Quit: glazou)
  437. # [21:21] <fantasai> Alex: We're not talking about existing ellipsis bheavior proeprty to change behavior to include overflow, right?
  438. # [21:22] <fantasai> fantasai: that is what we're talking about
  439. # [21:22] <fantasai> Alex: We've had this behavior for 10 years
  440. # [21:22] <fantasai> Alex: We usually don't change behavior like that
  441. # [21:22] <fantasai> Alex: I think we should come up with a new value
  442. # [21:23] <fantasai> Alex: .. it's probably not helping that I can't come up with a better term :)
  443. # [21:23] <fantasai> Tab: ellipsis-block
  444. # [21:23] <fantasai> Steve: too long, but content-overflow-indication :)
  445. # [21:24] * Joins: glazou (glazou@72.254.115.247)
  446. # [21:28] <fantasai> ...
  447. # [21:28] <fantasai> Alex doesn't see the point in changing the behavior in Tab's example.
  448. # [21:28] <fantasai> Alex: Maybe if you show me a use case for a different behavior
  449. # [21:28] <fantasai> Brad: I would expect that as you scroll to the right, the ellipsis moves to the right revealing more and more words
  450. # [21:29] <fantasai> Tab: Putting an ellipsis in mind is not about "don't render anything past this point ever"
  451. # [21:29] <fantasai> Tab: I don't want it to be visible all the time, but I still want to be able to scroll to it
  452. # [21:30] <fantasai> Peter gives examples from his DVR
  453. # [21:30] <fantasai> and channel guide
  454. # [21:31] <fantasai> Peter: This is a common UI in places other than web content, and it's something that people want to do with CSS
  455. # [21:31] <fantasai> Peter: More and more people are using XML+CSS
  456. # [21:31] <fantasai> Peter: for UI
  457. # [21:32] <fantasai> Peter: We're using it in our printer UIs. There's no scrollbars, it's flick mechanism
  458. # [21:32] <fantasai> Peter: You can envision your channel guide, but imagine a table
  459. # [21:32] <fantasai> Peter: For the table cells that are incomplete, they show ellipsis
  460. # [21:33] <fantasai> Peter: and as you scroll to the right, the ellipsis shift and the content is revealed
  461. # [21:33] <fantasai> Peter: I want an ellipsis on the right if there's content to the right, or an ellipsis to the left if there's content on the right
  462. # [21:33] <fantasai> s/right/left/
  463. # [21:34] <glazou> You want to apply width to ::ellipsis and a filter
  464. # [21:34] <fantasai> dbaron: Are there cases where the behavior you want for ellipsizing text you can get to is dfferent from the behavior for ellipsizing text you can't get to?
  465. # [21:34] <fantasai> Peter: I don't think so.
  466. # [21:34] <fantasai> dbaron: Maybe crop in the middle case for URLs
  467. # [21:35] <fantasai> dbaron: The other case is the bidi cases, which might be different
  468. # [21:35] <fantasai> Peter: My position is that the ... ellipsizing is ortogonal
  469. # [21:35] * fantasai is getting confused
  470. # [21:36] <fantasai> dsinger: I don't agree with you on the bidi case
  471. # [21:36] * tantek has lost ability to visualize the abstract overflow cases without diagrams.
  472. # [21:36] <fantasai> Peter: .. I want to be able to specify an ellipsis that says "put an ellipsis wherever text is cut off"
  473. # [21:36] <fantasai> Peter: and another one that just cuts off the text
  474. # [21:36] <fantasai> dbaron: Currently it's the doesn't fit case, not the cut off case
  475. # [21:37] <fantasai> dbaron: My position is that I'd like to see a spec based on what everyone else does
  476. # [21:37] <fantasai> dbaron: otherwise we'll be adding a 4th implementation not based on a spec
  477. # [21:37] <fantasai> dbaron: because people want this
  478. # [21:37] <fantasai> Steve: that goes back to fantasai's original question: are we forced to live with the current situation, or can we change things?
  479. # [21:38] <fantasai> Peter: hyatt thinks the existing behaviro in webkit is a bug
  480. # [21:38] <fantasai> ...
  481. # [21:38] * fantasai is losing attention span
  482. # [21:38] <fantasai> Brad: Doesn't seem like it would need a separate property. The way it is now doesn't make any sense
  483. # [21:39] <fantasai> Steve: The question isn't about does it make sense. The question is, is it so cast in stone right now that we can't change it
  484. # [21:39] <fantasai> Tab: I greatly prefer presentation: it jsut shows you stuff you can't see
  485. # [21:41] * Quits: mjs (mjs@72.254.93.235) (Quit: mjs)
  486. # [21:42] <dsinger> OK, if ellipses are visual, and the text is bi-di, then FIRST layout the entire text, then SECOND scroll to that visual position, and then THIRD if there is more text in the text-advance direction, replace the last character(s) in the text-advance direction with an ellipsis (and note that this/these character(s) might be visually in the middle of the visible area)
  487. # [21:43] <fantasai> RESOLUTION: Only horizontal overflow triggers for text-overflow: ellipsis. Add a new keyword for handling ellipsis due to vertical overflow where the ellipsis appears on the last line
  488. # [21:43] <bradk> text-overflow-x (current text-overflow behavior) and text-overflow-y (vertical ellipsis)?
  489. # [21:44] <fantasai> discussion of whether ellipsis is visual or logical in the order of text
  490. # [21:46] <dbaron> http://dbaron.org/css/test/2009/text-overflow-bidi
  491. # [21:49] <fantasai> fantasai: I think it should just behave as clipping. That is the easiest to understand. Maybe in bidi cases you get the end of the sentence and the beginning of the sentence and the middle off-screen
  492. # [21:49] <fantasai> fantasai: But at least you can understand what is happening
  493. # [21:50] <fantasai> (we are looking at actual behavior for bidi cases)
  494. # [21:50] <fantasai> (it seems very weird)
  495. # [21:51] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  496. # [21:53] <fantasai> Steve: If it's a rendering behavior, and affects no layout, then what Daniel is saying makes sense
  497. # [21:53] <fantasai> Daniel: It's extremely simple, and understandable
  498. # [21:53] <dsinger> choice B: layout as a long visual element. scroll to where you want to go. show an ellipsis at the visual left and/or right edges, if there is more to be seen in that direction
  499. # [21:53] <fantasai> dbaron: How does this deal with chopping a character or ligature in half?
  500. # [21:53] <fantasai> Peter: I want to clarify the point about two ellipsis
  501. # [21:53] <fantasai> s/is/es/
  502. # [21:55] <fantasai> ACTION daniel: check for examples in Hebrew books
  503. # [21:55] * RRSAgent records action 3
  504. # [21:55] * trackbot noticed an ACTION. Trying to create it.
  505. # [21:55] <trackbot> Created ACTION-191 - Check for examples in Hebrew books [on Daniel Glazman - due 2009-11-09].
  506. # [21:57] <fantasai> <br type=lunch>
  507. # [21:57] * Quits: bradk (bradk@72.254.115.105) (Quit: Computer has gone to sleep)
  508. # [21:58] * Quits: plinss (plinss@72.254.111.33) (Quit: plinss)
  509. # [21:58] * Quits: dethbakin (dethbakin@72.254.115.244) (Quit: dethbakin)
  510. # [21:58] * Quits: tantek (tantek@72.254.62.180) (Quit: tantek)
  511. # [21:58] * Quits: glazou (glazou@72.254.115.247) (Quit: glazou)
  512. # [21:58] * Quits: smfr (smfr@72.254.115.22) (Quit: smfr)
  513. # [21:59] * Quits: jdaggett (jdaggett@72.254.115.101) (Quit: jdaggett)
  514. # [21:59] * Quits: dbaron (dbaron@63.245.220.11) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  515. # [21:59] * Quits: dsinger (dsinger@72.254.95.64) (Quit: dsinger)
  516. # [22:00] * Quits: TabAtkins (chatzilla@72.254.56.183) (Ping timeout)
  517. # [22:00] * Quits: mmielke (cdf86653@128.30.52.43) (Quit: CGI:IRC (EOF))
  518. # [22:00] * Quits: szilles (chatzilla@72.254.62.158) (Ping timeout)
  519. # [22:00] * Quits: Arron (arronei@72.254.111.4) (Ping timeout)
  520. # [22:00] * Quits: sylvaing (sylvaing@72.254.116.25) (Ping timeout)
  521. # [22:01] * Quits: hamaji (hamaji@72.254.84.191) (Ping timeout)
  522. # [22:02] * Quits: hyatt (hyatt@98.201.21.231) (Quit: hyatt)
  523. # [22:02] * Quits: alexmog (alexmog@72.254.94.79) (Ping timeout)
  524. # [22:10] * Quits: Bert_lap (bert@128.30.52.169) (Ping timeout)
  525. # [22:14] * Zakim excuses himself; his presence no longer seems to be needed
  526. # [22:14] * Parts: Zakim (rrs-bridgg@128.30.52.30)
  527. # [22:21] * Joins: hyatt (hyatt@98.201.21.231)
  528. # [22:21] * Joins: koalie (coralie@128.30.52.169)
  529. # [22:22] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  530. # [22:22] <koalie> Zakim, please dial Salon_9
  531. # [22:22] <Zakim> sorry, koalie, I don't know what conference this is
  532. # [22:22] <koalie> Zakim, this will be css
  533. # [22:22] <Zakim> ok, koalie; I see Styl_CSS-FP(TPAC)12:00PM scheduled to start 262 minutes ago
  534. # [22:23] <koalie> Zakim, dial Salon_9
  535. # [22:23] <Zakim> ok, koalie; the call is being made
  536. # [22:23] <Zakim> Styl_CSS-FP(TPAC)12:00PM has now started
  537. # [22:23] <Zakim> +Salon_9
  538. # [22:23] * Parts: koalie (coralie@128.30.52.169)
  539. # [22:24] <Zakim> -Salon_9
  540. # [22:24] <Zakim> Styl_CSS-FP(TPAC)12:00PM has ended
  541. # [22:24] <Zakim> Attendees were Salon_9
  542. # [22:26] * Joins: jdaggett (jdaggett@72.254.115.101)
  543. # [22:26] <jdaggett> zakim: hello
  544. # [22:26] <jdaggett> invite zakim
  545. # [22:27] <jdaggett> invite Zakim
  546. # [22:28] * Joins: hamaji (hamaji@72.254.84.191)
  547. # [22:28] * Joins: mitzpettel (mitz@17.203.14.116)
  548. # [22:28] * Quits: mitzpettel (mitz@17.203.14.116) (Quit: mitzpettel)
  549. # [22:30] * jdaggett hmmm
  550. # [22:31] <jdaggett> Zakim: please dial Salon_9
  551. # [22:32] * Joins: koalie (coralie@128.30.52.169)
  552. # [22:32] <koalie> RRSAgent, pointer?
  553. # [22:32] <RRSAgent> See http://www.w3.org/2009/11/02-CSS-irc#T21-32-53
  554. # [22:33] * Parts: koalie (coralie@128.30.52.169)
  555. # [22:37] * Quits: jdaggett (jdaggett@72.254.115.101) (Quit: jdaggett)
  556. # [22:38] * Joins: jdaggett (jdaggett@72.254.115.101)
  557. # [22:43] * Joins: glazou (glazou@72.254.115.247)
  558. # [22:44] <Zakim> Styl_CSS-FP(TPAC)12:00PM has now started
  559. # [22:44] <Zakim> +Hakon_Lie
  560. # [22:45] * Joins: Curt` (curt@76.243.219.200)
  561. # [22:46] <jdaggett> Zakim: please dial Salon_9
  562. # [22:47] <jdaggett> http://www.w3.org/2009/11/02-CSS-irc#T21-32-53
  563. # [22:48] * Joins: shepazu (schepers@128.30.52.169)
  564. # [22:49] <jdaggett> Zakim: hello
  565. # [22:49] * Quits: glazou (glazou@72.254.115.247) (Ping timeout)
  566. # [22:49] * Joins: glazou (glazou@72.254.115.247)
  567. # [22:50] <jdaggett> Zakim, how are you?
  568. # [22:50] <Zakim> I don't understand your question, jdaggett.
  569. # [22:50] <jdaggett> Zakim, please dial Salon_9
  570. # [22:50] <Zakim> ok, jdaggett; the call is being made
  571. # [22:50] * Quits: glazou (glazou@72.254.115.247) (Quit: glazou)
  572. # [22:50] <Zakim> +Salon_9
  573. # [22:51] <jdaggett> Zakim, who is here?
  574. # [22:51] <Zakim> On the phone I see Hakon_Lie, Salon_9
  575. # [22:51] <Zakim> On IRC I see shepazu, Curt`, jdaggett, hamaji, Zakim, hyatt, Hixie, anne, MikeSmith, Yves, RRSAgent, howcome, MoZ, arronei, karl, krijnh, fearphage, fantasai, trackbot, Bert
  576. # [22:53] * Joins: mjs (mjs@72.254.93.235)
  577. # [22:55] * Quits: hyatt (hyatt@98.201.21.231) (Quit: hyatt)
  578. # [22:55] * Joins: dethbakin (dethbakin@72.254.115.244)
  579. # [22:55] * Joins: dsinger (dsinger@72.254.95.64)
  580. # [22:57] * Joins: bradk (bradk@72.254.115.105)
  581. # [22:57] * Joins: smfr (smfr@72.254.115.22)
  582. # [22:57] * Joins: jfkthame (jonathan@66.207.206.178)
  583. # [22:58] <Zakim> +[Mozilla]
  584. # [22:58] * Quits: MoZ (chatzilla@82.230.92.154) (Quit: ChatZilla 0.9.85 [Firefox 3.5.4/20091016081620])
  585. # [22:59] * Joins: hyatt (hyatt@98.201.21.231)
  586. # [22:59] * Joins: Arron (arronei@72.254.111.4)
  587. # [23:00] * Joins: tantek (tantek@72.254.62.180)
  588. # [23:00] * Joins: dbaron (dbaron@63.245.220.11)
  589. # [23:00] * Joins: Bert_lap (bert@128.30.52.169)
  590. # [23:00] * Joins: glazou (glazou@72.254.115.247)
  591. # [23:03] <jdaggett> next discussion is font feature support in css
  592. # [23:04] * Joins: szilles (chatzilla@72.254.62.158)
  593. # [23:04] <jdaggett> original proposal: http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html
  594. # [23:04] <jfkthame> so i'm hearing occasional bursts of sound on the phone, but lots of silence..... if you're discussing anything, i can't tell
  595. # [23:04] <jdaggett> demo page: http://people.mozilla.org/~jdaggett/webfonts/features.html
  596. # [23:04] <jdaggett> experimental build: http://people.mozilla.org/~jkew/ot-feature-build
  597. # [23:05] <dbaron> ScribeNick: dbaron
  598. # [23:05] * Joins: alexmog (alexmog@72.254.94.79)
  599. # [23:05] * Joins: ChrisL (ChrisL@128.30.52.169)
  600. # [23:05] * Joins: plinss (plinss@72.254.111.33)
  601. # [23:05] <dbaron> jdaggett: Font feature support in CSS.
  602. # [23:05] <dbaron> jdaggett: Many opentype fonts have additional glyph sets in the font.
  603. # [23:06] <howcome> www.princexml.com also supports font features
  604. # [23:06] <dbaron> jdaggett: They have variations to support various types of ways of rendering text.
  605. # [23:06] <dbaron> jdaggett: I'll show demos using an experimental build of Firefox.
  606. # [23:07] <dbaron> jdaggett: Demo of 'font-variant: small-caps' with shrunk capitals vs. small cap glyphs in the font.
  607. # [23:08] <dbaron> jdaggett: Second demo with "MEgalopolis Extra" font: alternate glyphs, discretionary ligatures, alternates and ligatures.
  608. # [23:09] <dbaron> (Q about whether selection works; demo)
  609. # [23:09] <dbaron> jdaggett: third demo: contextual substitution of opentype fractions
  610. # [23:11] <dbaron> jdaggett: fourth demo, Coluna font, old style figures by default (numbers have descenders), but options for lining (no descenders), tabular (all digits same width), lining+tabular
  611. # [23:12] <dbaron> jdaggett: Some proposed extensions to font-variant; URL above ("original proposal")
  612. # [23:12] * Joins: TabAtkins (chatzilla@72.254.56.183)
  613. # [23:12] <dbaron> jdaggett: font-variant would become a shorthand for font-variant-{ligatures,alternates,caps,numeric,position}
  614. # [23:13] <jdaggett> http://people.mozilla.org/~jkew/ot-feature-build
  615. # [23:13] <dbaron> jdaggett: In WPF, Microsoft has implemented ...
  616. # [23:13] <jdaggett> http://msdn.microsoft.com/en-us/library/ms745109.aspx
  617. # [23:13] * Joins: sylvaing (sylvaing@72.254.116.25)
  618. # [23:14] <dbaron> ligatures: common, additional, historical
  619. # [23:14] <dbaron> alternates: normal, contextual, styleset #, swash #
  620. # [23:14] <dbaron> caps: normal, smal-caps, pettie-caps, titling-caps
  621. # [23:15] <dbaron> numeric: normal, lining, oldstyle, tabular, proportional, fractions, ...
  622. # [23:15] <dbaron> position: normal, subscript, superscript, ruby, ...
  623. # [23:15] <dbaron> s/historical/historical, .../
  624. # [23:15] <fantasai> fantasai: what happens if the font doesn't have a subscript variant?
  625. # [23:15] <fantasai> jdaggett: you get the regular glyph
  626. # [23:15] <dbaron> jdaggett, also ones for CJK alternates, need to do more research about them to figure out what's needed
  627. # [23:15] <fantasai> jdaggett: you could argue that some of these shouldn't be here ...
  628. # [23:16] <dbaron> s/jdaggett,/jdaggett:/
  629. # [23:16] <fantasai> dsinger: If I request subscripts, and get regular figures, that changes the semantics
  630. # [23:16] <dbaron> dsinger: If the font doesn't have subscript, I'll get inline figures which changes the semantics
  631. # [23:16] <dbaron> jdaggett: This is just saying "give me that glyph", not "change the baselien"
  632. # [23:17] <dbaron> dbaron: Is it that the fonts have different glyphs for "when used as a subscript"?
  633. # [23:17] <dbaron> dbaron: And you'll still get subscript size/positing if they don't have that?
  634. # [23:18] <dbaron> ChrisL & dsinger: bad failure modes for getting double-subscript or none at all
  635. # [23:18] <fantasai> s/for/are/
  636. # [23:18] <dbaron> jfkthame: If the semantics are important, people should be using sup/sub elements
  637. # [23:19] <dbaron> jfkthame: The opentype features of superiors or inferiors aren't really a first-class replacement for that.
  638. # [23:19] <dbaron> jfkthame: If you request the feature and the font doesn't support it, you'll get no change.
  639. # [23:20] <dbaron> jfkthame: Intended more for footnote numbers, numeral suffixes
  640. # [23:20] <dbaron> fantasai: But if we have this feature people will use it for semantic subscripts.
  641. # [23:20] <dbaron> fantasai: And then for somebody else who doesn't have the font, the user won't see the superscript/subscript.
  642. # [23:20] <fantasai> because the currently faking it is ugly
  643. # [23:21] <dbaron> jdaggett: I'll note this as an issue and look into it.
  644. # [23:21] <dbaron> jdaggett: small-caps has issue being existing value
  645. # [23:22] * Joins: mmielke (mmielke@72.254.83.160)
  646. # [23:22] <dbaron> alexmog: I want all my subscripts to do the typographically correct thing, but I never want the effects to multiply.
  647. # [23:22] <dbaron> SteveZ: small-caps has two effects ...
  648. # [23:22] <glazou> rrsagent, this meeting spans midnight
  649. # [23:22] <RRSAgent> ok, glazou; I will not start a new log at midnight
  650. # [23:23] <dbaron> SteveZ: some of these are mutually exclusive
  651. # [23:23] * Quits: mmielke (mmielke@72.254.83.160) (Quit: mmielke)
  652. # [23:23] <dbaron> jdaggett: yes, the proposal goes into that in detail
  653. # [23:23] * Joins: mmielke (mmielke@72.254.83.160)
  654. # [23:23] <dbaron> (shows 0506.html)
  655. # [23:24] <dbaron> jdaggett: Shows old-style numerals vs. lining numerals
  656. # [23:24] <dbaron> jdaggett: Demo: swash characters in Garamond Premier Pro
  657. # [23:24] <dbaron> jdaggett: ... and additional ligatures
  658. # [23:25] <dbaron> jdaggett: Opentype has language-sensitive rendering. Demo for Macedonian.
  659. # [23:25] <dbaron> alexmog: yes, that looks more Macedonian.
  660. # [23:26] <dbaron> jdaggett: important not to ligaturize fi in Turkish so that dotted and dotless i can be distinguished
  661. # [23:26] <dbaron> jdaggett: Demo: Also small-caps distinctions for Turkish.
  662. # [23:27] <dbaron> jdaggett: example of lots of features at once
  663. # [23:27] <dbaron> tantek: That also looks like copyfitting.
  664. # [23:27] <dbaron> jdaggett: OpenType has the ability to specify a script and a languag.
  665. # [23:27] <dbaron> jdaggett: But it's not precisely a language, it's a language system.
  666. # [23:28] <tantek> would be great to get a URL to the "lots of features at once" example
  667. # [23:28] <dbaron> jdaggett: But you can display Greek in the French way of displaying Greek.
  668. # [23:28] <dbaron> jdaggett: So one might want a way of choosing the typographic language separately from the language.
  669. # [23:28] <dbaron> fantasai: As long as the default is 'auto' and that uses the markup language.
  670. # [23:29] <dbaron> (Turkish demo was using 'calluna' font.)
  671. # [23:29] <dbaron> jdaggett: Style sets get kind of hairy, having the number.
  672. # [23:29] <TabAtkins> tantek: http://people.mozilla.org/~jdaggett/webfonts/features.html, page to the end
  673. # [23:29] <dbaron> jdaggett: This is the argument we've been having on the list... what happens in the fallback case.
  674. # [23:30] <dbaron> jdaggett: You're not going to get unreadable text, you just won't get what the author hoped for.
  675. # [23:30] <dbaron> jdaggett: Or you could say some of these apply only to the first font in the list.
  676. # [23:30] <tantek> TabAtkins - interesting, in an old nightly of Webkit - the text is *not* copyfit - so this tells me that the OpenType features may be making use of some copyfitting feature somewhere?
  677. # [23:30] <dbaron> ChrisL: That could have issues if you're using a font list to get good Latin from one font plus good Japanese from the second font, you might want properties for the Japanese font.
  678. # [23:31] <dbaron> jdaggett: Doing something fancy... but that has the problem of an author having trouble figuring out what happened.
  679. # [23:31] <tantek> TabAtkins - n.m. just viewed source - each line's font-size is set explicitly.
  680. # [23:31] <dbaron> fantasai: Leave swash in as a keyword, so you can just get the first one.
  681. # [23:31] <tantek> for reference: http://people.mozilla.org/~jdaggett/webfonts/features.html#page%2014
  682. # [23:31] <TabAtkins> tantek: Yah, just wait a bit and we'll hit the copyfitting issue. ^_^
  683. # [23:32] * tantek didn't know that you could put a " " (space) in an id attribute and have it "work"
  684. # [23:32] <dbaron> jdaggett: We could add a font-variant descriptor for @font-face that would only apply the features to that specific face.
  685. # [23:32] <dbaron> jdaggett: I like the idea of allowing that, but I don't like the idea of requiring it.
  686. # [23:33] <dbaron> Håkon: There's pain to dealing with several @font-faces, but it's a neat way of achieving what we want.
  687. # [23:33] <Bert_lap> -> http://people.mozilla.com/~jkew/feature-samples/MEgalopolis.html The multi-feature, justified example with MEgalopolis from the slides
  688. # [23:33] <TabAtkins> In the font-variant-* properties, use a functional notation to target it at specific fonts.
  689. # [23:33] <dbaron> Håkon: I'm tempted to go down the @font-face route, even if it's a little inconvenient sometimes.
  690. # [23:33] <dbaron> jdaggett: I think it's impractical because you'd have so many permutations that it's impractical to use @font-face rules
  691. # [23:34] <TabAtkins> font-variant-ligatures: font-face("foo",lig 1), lig 2
  692. # [23:34] <TabAtkins> ^^^ Would activate lig2 on all fonts, but lig1 only on "foo" font.
  693. # [23:34] <dbaron> fantasai: I'm saying a property is fine for most of these, but require it in @font-face for alternate glyphs, which are very specific (by number) to fonts.
  694. # [23:34] <ChrisL> rrsagent, this meeting spans midnight
  695. # [23:34] <RRSAgent> ok, ChrisL; I will not start a new log at midnight
  696. # [23:35] * ChrisL midnight UTC that is
  697. # [23:35] <dbaron> SteveZ: In that list, there are only 2 things taking numeric values: style sets and alternates. Treating those two differently from all the others makes perfect sense.
  698. # [23:35] <dbaron> SteveZ: And, secondly, those are the two places where things are much more font-specific.
  699. # [23:36] <dbaron> SteveZ: So I would argue that I'd introduce a property: one for style sets and one for alternates, where the property would take...
  700. # [23:36] <dbaron> Steve: ... a font and a style set number that goes with that font.
  701. # [23:36] <dbaron> SteveZ: So you'd match which element in the list corresponded to the font actually chosen.
  702. # [23:37] <dbaron> s/Steve:/SteveZ:/
  703. # [23:37] <dbaron> Håkon: You're proposing two new properties with comma-separated values?
  704. # [23:37] <dbaron> SteveZ: yes
  705. # [23:37] <dbaron> TabAtkins: font-variant-ligatures: font-face("foo",lig 1), lig 2
  706. # [23:38] <dbaron> jdaggett: Originally I had a functional syntax, but people said we don't really have that. I think a functional syntax would work just as well.
  707. # [23:38] <dbaron> dsinger: It seems like you'd only have an explosion of @font-face rules if you have an explosion of styles on the page, which often isn't a good thing.
  708. # [23:39] <dbaron> jdaggett: @font-face is just defining one face of a family: So you'd then have to define all these variations across all faces of the family.
  709. # [23:39] <dbaron> SteveZ: If I want to write a description of 18th century typography in English... historical ligatures, historical letterforms... which I only want to use in examples.
  710. # [23:40] <dbaron> dsinger: You're probably using a different font for the 18th century text.
  711. # [23:40] <dbaron> dsinger: The features would be consistently off in the modern text and on in the 18th c. text.
  712. # [23:40] <dbaron> SteveZ: It's perfectly reasonable that I'm using an 18th c. font for my body text.
  713. # [23:41] <dbaron> fantasai: It doesn't matter how many features you're turning on and off.
  714. # [23:41] <dbaron> SteveZ: Each paragraph would have different features on it.
  715. # [23:41] <dbaron> fantasai: That's a very special edge case.
  716. # [23:41] <fantasai> SteveZ: Because I'm writing about typography
  717. # [23:41] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
  718. # [23:41] <dbaron> dbaron: Writing about typography is an edge case.
  719. # [23:42] <dbaron> dsinger: If you're actually showing lots of faces, that's not a failure of CSS.
  720. # [23:42] <dbaron> jdaggett: That's against the way CSS works, because you're forcing everything into @font-face rules, and people don't have the ability to change specific properties.
  721. # [23:42] <dbaron> jdaggett: You've eliminated inheritance.
  722. # [23:43] <dbaron> dsinger: But then you're asking for a feature in a font that you might not be using.
  723. # [23:43] <dbaron> ...
  724. # [23:44] <dbaron> dsinger: I don't mind changing what it looks like, but I mind changing the meaning.
  725. # [23:44] <dbaron> jdaggett: It's not undermining fallback, it's still an "a".
  726. # [23:45] <dbaron> jdaggett: 3 options, let substitution occur, (2) apply only to first font (3) put feature variants into @font-face, (4) Steve's property that takes family name
  727. # [23:45] <glazou> shepazu: ping
  728. # [23:46] <glazou> $
  729. # [23:46] * Joins: ChrisL (ChrisL@128.30.52.169)
  730. # [23:46] <dbaron> fantasai: Issue of mixing Latin font with Chinese font and choosing alternatives in both.
  731. # [23:46] <dbaron> jdaggett: I like the idea of allowing features to be set in @font-face, but I don't like it being the only mechanism.
  732. # [23:46] <dbaron> Håkon: You could combine (2) and (3).
  733. # [23:47] <dbaron> jdaggett: The complication that these are all shorthands: set all other values to default.
  734. # [23:48] <dbaron> SteveZ: My proposing allows a list that includes fonts that aren't being used... reduces that problem.
  735. # [23:48] <ChrisL> szilles proposal does not suffer from that
  736. # [23:48] <dbaron> Håkon: There's basically a scripting language underlying that... similar to text-replace.
  737. # [23:48] <dbaron> jdaggett: But that's all *inside* the font.
  738. # [23:48] <glazou> text-replace lalala lalala :-)
  739. # [23:48] <dbaron> Håkon: But you can turn those features in the font on and off using this mechanism.
  740. # [23:49] <dbaron> Steve: Fonts gave you that problem, even without variants.
  741. # [23:50] <dbaron> ChrisL: That's how people used to do Greek in Web pages.
  742. # [23:50] <Bert_lap> (People in India are still doing this, using fonts with Indic glyphs in ASCII slots...)
  743. # [23:51] <dbaron> jdaggett: I think that's all I have... I just wanted to present this.
  744. # [23:51] <dbaron> jdaggett: I think there's more that needs to be hashed out.
  745. # [23:51] <dbaron> ChrisL: You were demoing with a special build.
  746. # [23:52] <dbaron> jdaggett: Yes, that build just has a single property demo hack to turn off opentype features by name.
  747. # [23:52] <dbaron> SteveZ: I'd like some action to come out of this discussion. (1) Do people think that John is on the right track?
  748. # [23:52] <dbaron> ChrisL, fantasai: yes
  749. # [23:52] * Quits: tantek (tantek@72.254.62.180) (Connection reset by peer)
  750. # [23:52] * Joins: tantek (tantek@72.254.62.180)
  751. # [23:52] <ChrisL> I'd like to see this put into the spec
  752. # [23:53] <dbaron> Bert: I'm happy to see more attention to typographic features; I've always wanted tabular figures; but I'm wondering why suddenly this attention for putting every opentype feature into CSS when we still don't have hyphenation and leaders.
  753. # [23:53] <dbaron> jdaggett: We're not talking about every opentype feature; a fair number have been omitted. e.g., not exposing multiple ways of doing fractions.
  754. # [23:54] <dbaron> fantasai: hyphenation's also hard because of need for dictionary
  755. # [23:54] <dbaron> jdaggett: Hyphenation is a somewhat tricky problem: language-based, and all sorts of typographic rules for hyphenation.
  756. # [23:54] <dbaron> ChrisL: These are orthogonal features.
  757. # [23:54] <dbaron> Håkon: We have hyphenation specced out.
  758. # [23:55] <fantasai> s/e.g. We're taking some features that are more abstract. Also not, e.g./
  759. # [23:55] <dbaron> Bert: Prince now has the whole-paragraph justification from TeX, but Mozilla will have swash characters but still won't do justification right.
  760. # [23:55] <dbaron> Bert: Things like proper justification and hyphens have a much bigger effect.
  761. # [23:56] <dbaron> dbaron: those are layout features, adding to an area of CSS that's already very complicated.
  762. # [23:56] <dbaron> fantasai: font features are better encapsulated
  763. # [23:56] <dbaron> jdaggett: And having @font-face gives us the opportunity to do more with fonts now.
  764. # [23:57] <dbaron> SteveZ: The other thing I'd want is getting a clear statement of how things like subscripts and small-caps interact with existing facilities: so that (a) we don't get semantic changes and (b) ...
  765. # [23:57] <dbaron> dsinger: yep
  766. # [23:58] <dbaron> jdaggett: font-variant is part of the 'font' shorthand; we don't want any of this new stuff in the 'font' shorthand
  767. # [23:58] * Zakim dbaron, you typed too many words without commas; I suspect you forgot to start with 'to ...'
  768. # [23:58] <jdaggett> Zakim, you silly git...
  769. # [23:58] <Zakim> I don't understand 'you silly git', jdaggett
  770. # [23:59] <ChrisL> zakim, you suspect wrong. Stop doing that. You are thinking outside your pay grade
  771. # [23:59] <Zakim> I don't understand you, ChrisL
  772. # [23:59] <dbaron> Håkon: John, if we have a property that holds the features, do you see that as inherited independent of font-family?
  773. # [23:59] <dbaron> jdaggett: Yes. It makes sense for many things, e.g., tabular figures.
  774. # [23:59] <dbaron> Håkon: Should a randomly-named feature inherit?
  775. # [23:59] * Curt` is now known as Curt`|away
  776. # [23:59] <dbaron> jdaggett: I don't even have a plan for including enabling/disabling arbitrary features.
  777. # Session Close: Tue Nov 03 00:00:00 2009

The end :)