/irc-logs / w3c / #webapps / 2009-09-23 / end

Options:

  1. # Session Start: Wed Sep 23 00:00:00 2009
  2. # Session Ident: #webapps
  3. # [00:02] * Quits: heycam (cam@210.84.32.112) (Quit: bye)
  4. # [00:11] * Joins: taf2 (taf2@216.15.54.105)
  5. # [00:39] * Joins: heycam (cam@130.194.72.84)
  6. # [01:22] * Quits: taf2 (taf2@216.15.54.105) (Ping timeout)
  7. # [01:22] * Joins: taf2 (taf2@216.15.54.105)
  8. # [01:29] * Quits: taf2 (taf2@216.15.54.105) (Quit: taf2)
  9. # [02:25] * Quits: ArtB (c0646811@128.30.52.43) (Quit: CGI:IRC (EOF))
  10. # [02:42] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
  11. # [03:31] * Joins: tlr (tlr@128.30.52.169)
  12. # [03:34] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  13. # [04:46] <Hixie> shepazu: i added the events stuff to my pile to reply to, i'll try to get to it asap
  14. # [06:36] <shepazu> Hixie: thanks
  15. # [08:22] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
  16. # [08:27] * Joins: heycam (cam@130.194.69.207)
  17. # [09:12] * Joins: darobin (robin@62.213.144.73)
  18. # [09:23] * Quits: darobin (robin@62.213.144.73) (Ping timeout)
  19. # [09:23] * Joins: darobin (robin@62.213.144.73)
  20. # [10:00] * Quits: heycam (cam@130.194.69.207) (Quit: bye)
  21. # [10:27] * Quits: arve (arve@212.251.175.125) (Client exited)
  22. # [10:43] * Joins: arve (arve@212.251.175.125)
  23. # [10:55] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  24. # [11:12] * Joins: Lachy (Lachlan@213.236.208.22)
  25. # [12:26] * Joins: heycam (cam@210.84.32.112)
  26. # [12:39] * Joins: ArtB (d0309a43@128.30.52.43)
  27. # [13:30] * Quits: gsnedders (gsnedders@217.44.35.222) (Quit: gsnedders)
  28. # [13:39] * Joins: gsnedders (gsnedders@217.44.35.222)
  29. # [14:19] * Joins: tlr (tlr@128.30.52.169)
  30. # [15:31] * Joins: aroben (aroben@71.58.77.15)
  31. # [15:55] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  32. # [15:55] * Quits: darobin (robin@62.213.144.73) (Ping timeout)
  33. # [16:02] * Joins: darobin (robin@62.213.144.73)
  34. # [17:07] <smaug> shepazu: ping
  35. # [17:10] * Quits: darobin (robin@62.213.144.73) (Ping timeout)
  36. # [17:26] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  37. # [17:30] * Joins: Lachy (Lachlan@213.236.208.22)
  38. # [17:39] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  39. # [18:11] * Joins: Marcos (Marcos@41.215.38.99)
  40. # [19:08] * Joins: Lachy (Lachlan@85.196.122.246)
  41. # [19:25] * Quits: Marcos (Marcos@41.215.38.99) (Ping timeout)
  42. # [19:28] * Joins: Marcos (Marcos@41.215.38.99)
  43. # [19:46] <shepazu> smaug: pong
  44. # [19:58] <smaug> shepazu: ping
  45. # [19:59] <shepazu> dangit, I missed... okay, smaug, 0-1
  46. # [19:59] <smaug> shepazu: any chance to get the agenda relatively soon ;)
  47. # [19:59] <shepazu> smaug: oh, my
  48. # [19:59] <shepazu> yeah...
  49. # [20:00] <smaug> shepazu: assuming we do have the call
  50. # [20:01] <shepazu> smaug: would it be better for you (going forward) to have the call earlier in the day?
  51. # [20:01] <shepazu> chaals said he could join us if we did
  52. # [20:01] <shepazu> nobody from Oz is joining the calls now
  53. # [20:02] <shepazu> we could see if that works for Travis
  54. # [20:05] * smaug goes running, will be back before the call
  55. # [20:06] <shepazu> sent
  56. # [20:14] * Quits: Marcos (Marcos@41.215.38.99) (Ping timeout)
  57. # [21:19] * Quits: arve (arve@212.251.175.125) (Client exited)
  58. # [21:48] * Joins: tlr (tlr@128.30.52.169)
  59. # [21:59] * Quits: gsnedders (gsnedders@217.44.35.222) (Client exited)
  60. # [22:01] * Joins: arve (arve@212.251.175.125)
  61. # [22:16] * Joins: gsnedders (gsnedders@217.44.35.222)
  62. # [22:22] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC)
  63. # [22:35] * Quits: Dashiva (noone@129.241.137.223) (Ping timeout)
  64. # [22:41] * Joins: Dashiva (noone@129.241.137.223)
  65. # [22:59] * shepazu will be right back
  66. # [23:02] * Joins: chaals (chaals@212.251.243.170)
  67. # [23:04] * smaug waits shepazu to come back
  68. # [23:04] * chaals wonders what the code is...
  69. # [23:04] <chaals> (where did shepazu go?)
  70. # [23:04] <smaug> [23:59] * shepazu will be right back
  71. # [23:05] * chaals just got in from dinner... and such a nice dinner... ;) (Feeling rather fat and full)
  72. # [23:05] <chaals> and very happy :)
  73. # [23:05] <smaug> too much wine perhaps ;)
  74. # [23:07] <shepazu> trackbot, start telcon
  75. # [23:07] * trackbot is starting a teleconference
  76. # [23:07] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
  77. # [23:07] <RRSAgent> logging to http://www.w3.org/2009/09/23-webapps-irc
  78. # [23:07] <trackbot> RRSAgent, make logs public
  79. # [23:07] <RRSAgent> I have made the request, trackbot
  80. # [23:07] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  81. # [23:07] <trackbot> Zakim, this will be WAPP
  82. # [23:07] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
  83. # [23:07] <trackbot> Meeting: Web Applications Working Group Teleconference
  84. # [23:07] <trackbot> Date: 23 September 2009
  85. # [23:07] <chaals> zakim, code?
  86. # [23:07] <Zakim> sorry, chaals, I don't know what conference this is
  87. # [23:07] <shepazu> zakim, this will be DOM3
  88. # [23:07] <Zakim> ok, shepazu; I see IA_WebApps(DOM3)5:00PM scheduled to start 7 minutes ago
  89. # [23:07] <chaals> zakim, code?
  90. # [23:07] <Zakim> the conference code is 3663 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), chaals
  91. # [23:07] <shepazu> zakim, call shepazu
  92. # [23:07] <Zakim> ok, shepazu; the call is being made
  93. # [23:07] <Zakim> IA_WebApps(DOM3)5:00PM has now started
  94. # [23:07] <Zakim> +Shepazu
  95. # [23:08] <Zakim> +mauro
  96. # [23:08] <Zakim> +mauro.a
  97. # [23:09] <Zakim> -mauro
  98. # [23:09] <Zakim> +??P0
  99. # [23:09] <shepazu> zakim, mauro.a is chaals
  100. # [23:09] <Zakim> +chaals; got it
  101. # [23:09] <smaug> Zakim, ??P0 is me
  102. # [23:09] <Zakim> +smaug; got it
  103. # [23:09] * chaals thinks smaug should try to get his head above water before trying to talk
  104. # [23:10] <chaals> zakim, mute me
  105. # [23:10] <Zakim> chaals should now be muted
  106. # [23:10] <chaals> scribe: chaals
  107. # [23:10] <chaals> chair: shepazu
  108. # [23:11] * chaals slaps chaals for an idiot volunteer ;)
  109. # [23:11] * chaals agenda?
  110. # [23:11] * Zakim sees nothing on the agenda
  111. # [23:11] <shepazu> agenda: http://www.w3.org/mid/4ABA6384.9020108@w3.org
  112. # [23:11] <chaals> Topic: Initialising events
  113. # [23:12] <chaals> DS: Suggestion is to either deprecate (or drop or shove away from the spotlight) event initialisers like initMouseEvent
  114. # [23:12] <chaals> ... One idea: between creating and dispatching an event the properties would be writeable, to save remembering long unwieldy parameter patterns.
  115. # [23:12] <chaals> ... Smaug, you didn't like it. Why?
  116. # [23:13] <chaals> OP: Changing attributes to read/write feels odd.
  117. # [23:13] <chaals> ... but the init methods are awkward, so maybe OK.
  118. # [23:14] <chaals> DS: Right. The init* are already awkward. Making them writeable is more extensible than adding parameters
  119. # [23:14] <chaals> OP: Yes.
  120. # [23:14] <chaals> q+
  121. # [23:14] * Zakim sees chaals on the speaker queue
  122. # [23:14] <chaals> OP: We would then need to define default values for unitialised properties.
  123. # [23:14] <chaals> DS: So we would allow that and define for what? each event?
  124. # [23:14] <chaals> OP: Yes, for each event... or maybe each interface.
  125. # [23:14] <chaals> ack me
  126. # [23:14] * Zakim unmutes chaals
  127. # [23:14] * Zakim sees no one on the speaker queue
  128. # [23:16] <chaals> CMN: We only need to define non-optionals. And we coul just say "if the required attributes aren't met then we just throw away the event"
  129. # [23:16] <chaals> OP: Type is the only property that must be set. everything else should have some reasonable default value.
  130. # [23:17] <chaals> DS: Right now we create an event interface, and then initialise an event and say what you want.
  131. # [23:17] <smaug> var e = new Event("scroll");
  132. # [23:17] <chaals> ... strikes me as really awkward. Why not say 'createEvent("foobar")'
  133. # [23:17] <smaug> var e = new MouseEvent("click");
  134. # [23:18] <chaals> ... each event type knows what its interface is
  135. # [23:18] <chaals> zakim, mute me
  136. # [23:18] <Zakim> chaals should now be muted
  137. # [23:18] <chaals> OP: You can create a click event that implements the normal interface
  138. # [23:18] <chaals> DS: Why is that useful
  139. # [23:18] <chaals> OP: It isn't. It is just there
  140. # [23:18] * chaals asks Doug to repeat that for the minutes
  141. # [23:19] * chaals thinks this is an action...
  142. # [23:20] <chaals> DS: If your chief objetion was that making attributes writeable was odd, but we agree that so is initialisers, I prefer to go with the one that doesn't reqire an nitialiser. Init event would still work where it is defined, but I would not define it for new events.
  143. # [23:20] <chaals> OP: What about creating events?
  144. # [23:20] <chaals> DS: I will propose something about creating events by type rather than by interface.
  145. # [23:20] <chaals> OP: Can you still overwrite type?
  146. # [23:21] <chaals> ... you need a way to create a specific interface, or an object that implements it, then set a type identified in the spec, because people use their own events.
  147. # [23:21] <chaals> ... that is why creating mouseevent by saying new mouseEvent(type) should work.
  148. # [23:21] <chaals> DS: OK, we should look at that further...
  149. # [23:22] <shepazu> Topic: Dropping event namespace init methods
  150. # [23:22] <chaals> ack me
  151. # [23:22] * Zakim unmutes chaals
  152. # [23:22] * Zakim sees no one on the speaker queue
  153. # [23:22] <chaals> DS: Talked to other team members about this
  154. # [23:22] <chaals> zakim, please mute me
  155. # [23:22] <Zakim> chaals should now be muted
  156. # [23:23] <chaals> ... asked them what general tenor in groups is.
  157. # [23:23] <chaals> ... nobody had a problem with dropping them
  158. # [23:23] <chaals> OP: OK.
  159. # [23:23] <chaals> DS: While they have some hope (a namespace can be just another attribute), I am proposing dropping methods devoted to namespaced events
  160. # [23:24] <chaals> OP: You then need to define how event listeners work with namespaces.
  161. # [23:24] <chaals> DS: Uploaded a draft that removes most *NS versions of methods. What about addEventListenerNS ?
  162. # [23:24] <chaals> ... proposing to drop that too.
  163. # [23:24] <chaals> OP: So namespace disappears from the spec?
  164. # [23:25] <chaals> DS: It is all through the spec. In those places, and in mutation events if someone changes the namespace of an attribute you can change that.
  165. # [23:25] <chaals> OP: There is the NS URI still in there?
  166. # [23:25] <Zakim> +[Microsoft]
  167. # [23:25] <chaals> ... if you drop NSlistener the namespace URI in the event doesn't mean anything
  168. # [23:25] <chaals> DS: So how far do we want to go with this?
  169. # [23:25] <chaals> zakim, [Microsoft] is travis
  170. # [23:25] <Zakim> +travis; got it
  171. # [23:26] <chaals> TL: Drop 'em.
  172. # [23:26] <chaals> DS: So checking that you think it makes sense to remove all namespaces...
  173. # [23:26] <chaals> TL: Even if you put them back in, we will not implement them.
  174. # [23:26] <chaals> DS: So it makes sense to drop them
  175. # [23:26] <chaals> TL: Just saying, if you bring them back, it will take *at least* another release to get them in.
  176. # [23:26] <chaals> ... can see Xforms complaining...
  177. # [23:27] * Joins: Travis (836b0052@128.30.52.43)
  178. # [23:27] <chaals> DS: Asked, and the team contacts said nobody would seriously complain. IT is not clear content uses them, ...
  179. # [23:27] <chaals> TL: We shouldn't be tied to the drafts...
  180. # [23:27] <chaals> DS: Sure, although we should respect people who were trying to do the right thing
  181. # [23:27] * chaals waves to Travis - he is muted :)
  182. # [23:27] <chaals> RESOLUTION: Drop namespaced events
  183. # [23:28] * chaals cool. Me too :)
  184. # [23:28] <chaals> agenda+ TPAC
  185. # [23:28] * Zakim notes agendum 1 added
  186. # [23:28] <shepazu> Topic: focusin/focusout, mouseenter/mouseleave, and detectability
  187. # [23:28] <chaals> OP: The change of namespace mutation event is a different beast - please don't kill it
  188. # [23:28] <chaals> DS: Right.
  189. # [23:29] <chaals> DS: Moved focus to its own interface. will probably add from and to to the interface
  190. # [23:29] <chaals> OP: wy?
  191. # [23:29] <chaals> s/wy/why/
  192. # [23:29] <chaals> ... is that what IE has?
  193. # [23:30] <chaals> ack me
  194. # [23:30] * Zakim unmutes chaals
  195. # [23:30] * Zakim sees no one on the speaker queue
  196. # [23:30] <chaals> zakim, mute me
  197. # [23:30] <Zakim> chaals should now be muted
  198. # [23:30] <chaals> DS: It is. Garrett says detectability of that element might be very mportant to content.
  199. # [23:31] <chaals> TL: Nobody will use focusin/out, they will use onfocusin/out. So there is a possibility that a website tries all events from IE, which might break, but it doesn't seem like a big deal.
  200. # [23:31] <chaals> ... if youdon't support all the other properties IE has, it will still break. SO design it the way you want it to be.
  201. # [23:32] <chaals> DS: Garrett suggested we should name the events differently to avoid breaking content
  202. # [23:32] <chaals> q+
  203. # [23:32] * Zakim sees chaals on the speaker queue
  204. # [23:32] <chaals> ... e.g. focusenter/leave to match mouse...
  205. # [23:32] <chaals> TL: there wa another discussion asking focusin/out to bubble. Do they bubble today?
  206. # [23:32] <chaals> DS: yes
  207. # [23:32] <chaals> OP: the problem is with focus/blur not bubbling
  208. # [23:33] <chaals> TL: We need to make a rpincipled decision - are these being added for compatibility or some other purpose?
  209. # [23:33] <chaals> DS: Doesn't seem like they will be compatible, but they are useful for the characteristics they have
  210. # [23:33] <chaals> OP: Agree
  211. # [23:33] <chaals> DS: So changing the name is not such a problem
  212. # [23:33] <chaals> OP: ditto mouseenter/leave
  213. # [23:34] <chaals> DS: Don't think they have the same problem
  214. # [23:34] * Joins: ArtB (c0646811@128.30.52.43)
  215. # [23:34] <chaals> OP: All event listeners use the same properties, (IE) not DOM properties.
  216. # [23:34] <chaals> DS: We are really going for functionality, not just compatibility.
  217. # [23:35] * chaals having trouble keeping up
  218. # [23:35] <chaals> OP: The new functioanlity is useful
  219. # [23:35] <chaals> DS: People are arguing against adding new functionality...
  220. # [23:35] <chaals> TL: like us
  221. # [23:36] <chaals> TL: for the toEleement/from, I don't care
  222. # [23:36] <chaals> DS: If we don't add them, people can detect if they exist and act accordingly.
  223. # [23:36] <chaals> TL: A scenario. I want to support old IE and a new browser ith focusin/out.
  224. # [23:37] <chaals> ... my code has to switch between addeventlistener and attachevent. In both cases I can use focusin. so now I register in both browsers, the event fires and a listener gets it.
  225. # [23:37] <chaals> ... now I have to write code that detects (e.g.) toElement to see if this is an IE browser and use it, otherwise I assume that relatedTarget is there and use it. Otherwise, if we made the names the same, I could just use them.
  226. # [23:38] <chaals> OP: there are other properties in IE in any case
  227. # [23:38] <chaals> ack me
  228. # [23:38] * Zakim unmutes chaals
  229. # [23:38] * Zakim sees no one on the speaker queue
  230. # [23:39] <chaals> CMN: Travis' example still holds...
  231. # [23:39] <chaals> zakim, mute me
  232. # [23:39] <Zakim> chaals should now be muted
  233. # [23:39] <chaals> ... if ou are doing the same thing, wy force people to branch - leave that for where there are different functionalities
  234. # [23:39] <chaals> TL: Garrett has a point...
  235. # [23:40] <chaals> DS: it is a little more code to maintain for browsers. But not much. Maybe we should take this to the list
  236. # [23:40] <chaals> ... think Garrett certainly has a point worth exploring. I won't change the spec now, but willing to entertain the notion that we should.
  237. # [23:40] <chaals> TL: I don't have a strong opinion yet...
  238. # [23:40] * chaals thinks "People are welcome to hate DS"
  239. # [23:41] <chaals> OP: I think the best solution for content authors is to rename the events.
  240. # [23:41] <chaals> DS: I am fine with that. Would it apply to both focus* and mouse*?
  241. # [23:41] <chaals> TL: Maybe both.
  242. # [23:41] <chaals> OP: Please post it to the list so we can think about it more with more input
  243. # [23:42] <chaals> ACTION: Doug to post something to the list on focusin/out and mouseenter/leave on event names
  244. # [23:42] * trackbot noticed an ACTION. Trying to create it.
  245. # [23:42] * RRSAgent records action 1
  246. # [23:42] <trackbot> Created ACTION-407 - Post something to the list on focusin/out and mouseenter/leave on event names [on Doug Schepers - due 2009-09-30].
  247. # [23:42] <shepazu> Topic: key identifiers and convertKeyIdentifier
  248. # [23:42] <chaals> TL: I can see it applying to mouse* - it makes our stories consistent
  249. # [23:42] <chaals> DS: Anne / Maciej asked why we are doing the strings the way they are?
  250. # [23:42] <chaals> zakim, mute me
  251. # [23:42] <Zakim> chaals was already muted, chaals
  252. # [23:43] <chaals> ... I asked PLH why they were like that and he said he doesn't think there was any particular reason. don't know if it means something in Java - is it javascript only or universal?
  253. # [23:43] <chaals> TL: THink it works like that in C# in a string literal
  254. # [23:43] <chaals> DS: Then it is probably like that in Java. Where is this defined - per language, or is there some external spec?
  255. # [23:44] <chaals> TL: Should check Java and see what they have
  256. # [23:44] <chaals> DS: No objection to doing the / - in many cases it makes more sense. I still think there will be times when people want to get teh unicode value (codepoint), although I am having trouble articulating a use case.
  257. # [23:45] <chaals> ... if you have a virtual keyboard and want to say what the unicode codepoint is. I think there will be cases where someone wants the codepoint.
  258. # [23:45] <chaals> TL: Can you turn that into an HTML identity?
  259. # [23:45] <Travis> \u is supported in Java: http://java.sun.com/docs/books/tutorial/i18n/text/string.html
  260. # [23:45] <chaals> DS: Added a convenience constant to turn things into entities
  261. # [23:46] <chaals> ... makes a numeric entity. Wouldn't change something to &amp;, it would change it to &2342; (or whatever)
  262. # [23:46] <chaals> TL: That's useful
  263. # [23:47] <chaals> DS: Not sure if there is a way of doing that now in JS. If you can get the codepoint you can make the entity, because that is a string operation. But if we do make a helper method, we may as well add more of what we thing will be useful functionality.
  264. # [23:47] <chaals> ... converting to an entity, extracting codepoint as string, ...
  265. # [23:48] <chaals> ... If I have the shift key, it doesn't have a Unicode representation. It's named. So if I said charAt for that it will give me the same as S.
  266. # [23:48] <chaals> ... something running around my head says we don't want to use charCodeAt, we want a helper function - either keyname or code point or whatever.
  267. # [23:48] <chaals> TL: looking at a JS/unicode site. /u is supported natively in JS
  268. # [23:49] <Travis> http://javascript.about.com/library/blunicode.htm
  269. # [23:49] <chaals> DS: I couldn't figure out how to get charCodeAt to gve me the unicode codepoint in FF when I tested.
  270. # [23:49] <chaals> ack me
  271. # [23:49] * Zakim unmutes chaals
  272. # [23:49] * Zakim sees no one on the speaker queue
  273. # [23:49] <chaals> zakim, mute me
  274. # [23:49] <Zakim> chaals should now be muted
  275. # [23:50] * chaals unimpressed that shepazu is just reading por^Wemail during the meeting...
  276. # [23:50] <chaals> DS: Looks useful (except it doesn't work for me)
  277. # [23:50] <chaals> OP: Do we want to support things over the 64k limit?
  278. # [23:51] <chaals> DS: Maciej doesn't see the use case for supporting those - they are not on keyboards
  279. # [23:51] <chaals> OP: Are we sure?
  280. # [23:51] <smaug> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#glossary-unicode-code-point
  281. # [23:51] <chaals> DS: I don't know, and don't know it will stay that way. Seems like an artificial limit and not sure why we should limit people that way.
  282. # [23:52] <chaals> OP: In the spec now, the limit is FFFF
  283. # [23:52] <shepazu> s/FFFF/10FFFF
  284. # [23:52] <chaals> TL: The HTML5 parsing spe has a hard limit on codepoint when doing character conversion.
  285. # [23:53] <shepazu> https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Objects/String/charCodeAt
  286. # [23:53] <Travis> https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Unicode
  287. # [23:54] <chaals> DS: I think encapsulating this in a helper function would be useful. It is a unicode helper that also knows about named keys. So you could use things beyond key events to resolve this stuff into entitites, etc.
  288. # [23:55] <chaals> ... this is just about making things more user-friendly. I am going to resist not putting this in...
  289. # [23:55] <chaals> ... let's define helpers that people might find, and then see what happens.
  290. # [23:56] <chaals> DS: One other aspect. We call the attribute KeyIdentifier. I think nobody likes that... and I don't want to say "key". At the same time once it is propogated I think people will understand.
  291. # [23:56] * chaals thinks this is a serious bike shed :S
  292. # [23:56] <chaals> ... waht about having "key" as the attribute?
  293. # [23:57] * gsnedders votes for pink
  294. # [23:57] <chaals> TL: no conflicts?
  295. # [23:57] <chaals> DS: Apparently not...
  296. # [23:57] <chaals> TL: So simple...
  297. # [23:57] <chaals> OP: What about "key" and "location"
  298. # [23:57] * chaals votes against snedders, because I prefer pale salmon
  299. # [23:57] <chaals> DS: Let's try it and see what happens
  300. # [23:58] <chaals> RESOLUTION: We will use the escape sequence for value for keyname
  301. # [23:58] * gsnedders notes that is not a valid css3-color keyword
  302. # [23:58] <chaals> RESOLUTION: We will try to describe a helper function for conversion
  303. # [23:58] <chaals> TL: The one specced out now?
  304. # [23:59] <chaals> DS: Same general idea. Right now we have characer value and unicode string. we are dropping unicode string and making character value an escape sequence
  305. # [23:59] * chaals notes to snedders that it *is* in my new draft specification, CSS 5 colours
  306. # [23:59] * chaals (which has 4 other colours, because the rest get misused too often)
  307. # [23:59] * gsnedders stops distracting the scribe
  308. # Session Close: Thu Sep 24 00:00:00 2009

The end :)