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

Options:

  1. # Session Start: Wed Sep 16 00:00:00 2009
  2. # Session Ident: #webapps
  3. # [00:03] * Joins: Marcos (Marcos@212.214.188.2)
  4. # [00:06] * Quits: taf2 (taf2@38.99.201.242) (Quit: taf2)
  5. # [00:23] <heycam> annevk, i read that as "so firefoxing ugly" :)
  6. # [00:23] <heycam> btw i really think we should go for the "allow the attributes on the interface to be writable before dispatch" route
  7. # [00:24] * Quits: heycam (cam@210.84.56.211) (Quit: bye)
  8. # [00:29] * Quits: Dashiva (noone@129.241.137.223) (Quit: Dashiva)
  9. # [00:31] * Joins: Dashiva (noone@129.241.137.223)
  10. # [00:34] <annevk> that also would be potentially hairy
  11. # [00:42] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
  12. # [00:48] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  13. # [00:48] * Joins: gsnedders (gsnedders@217.44.35.222)
  14. # [01:04] * Joins: heycam (cam@130.194.72.84)
  15. # [01:11] * Quits: Marcos (Marcos@212.214.188.2) (Quit: Marcos)
  16. # [02:17] * Quits: ArtB (c0646811@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
  17. # [02:51] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  18. # [05:32] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  19. # [06:16] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  20. # [06:59] * Joins: zalan (zalan@89.135.144.193)
  21. # [07:02] * Quits: gsnedders (gsnedders@217.44.35.222) (Client exited)
  22. # [07:09] * Quits: arve (arve@212.251.175.125) (Ping timeout)
  23. # [08:23] * Joins: Marcos (Marcos@88.131.66.110)
  24. # [08:39] * Quits: Marcos (Marcos@88.131.66.110) (Connection reset by peer)
  25. # [08:50] * Joins: Marcos (Marcos@88.131.66.110)
  26. # [09:02] <timeless_mbp> how about just offering a property bag template object? :)
  27. # [09:05] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
  28. # [09:07] * Joins: heycam (cam@130.194.69.205)
  29. # [09:09] * Quits: heycam (cam@130.194.69.205) (Quit: bye)
  30. # [09:12] * Joins: heycam (cam@130.194.69.205)
  31. # [09:18] * Joins: arve (arve@213.236.208.247)
  32. # [09:19] * Quits: Marcos (Marcos@88.131.66.110) (Ping timeout)
  33. # [09:29] * Joins: darobin (robin@85.169.117.248)
  34. # [09:38] * Joins: Marcos (Marcos@88.131.66.110)
  35. # [09:53] * Quits: Marcos (Marcos@88.131.66.110) (Connection reset by peer)
  36. # [10:04] * Joins: Marcos (Marcos@88.131.66.110)
  37. # [10:06] * Quits: arve (arve@213.236.208.247) (Ping timeout)
  38. # [10:16] * Quits: heycam (cam@130.194.69.205) (Quit: bye)
  39. # [10:21] * Joins: arve (arve@213.236.208.22)
  40. # [10:45] * Quits: Marcos (Marcos@88.131.66.110) (Ping timeout)
  41. # [10:56] * Joins: heycam (cam@210.84.56.211)
  42. # [11:22] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  43. # [11:27] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  44. # [11:30] * Joins: Marcos (Marcos@88.131.66.80)
  45. # [11:33] * Joins: Lachy (Lachlan@213.236.208.22)
  46. # [11:35] * Joins: tlr (tlr@128.30.52.169)
  47. # [11:42] * Quits: Marcos (Marcos@88.131.66.80) (Quit: Marcos)
  48. # [12:03] * Joins: gsnedders (gsnedders@217.44.35.222)
  49. # [12:09] * Quits: smaug (chatzilla@82.181.150.24) (Ping timeout)
  50. # [12:27] * Joins: smaug (chatzilla@82.181.150.24)
  51. # [12:38] * Joins: ArtB (d0309a43@128.30.52.43)
  52. # [14:21] * Quits: arve (arve@213.236.208.22) (Quit: Ex-Chat)
  53. # [14:27] * Joins: taf2 (taf2@38.99.201.242)
  54. # [14:51] * Quits: taf2 (taf2@38.99.201.242) (Quit: taf2)
  55. # [14:54] * Joins: aroben (aroben@71.58.77.15)
  56. # [14:54] * Joins: taf2 (taf2@38.99.201.242)
  57. # [15:41] * Joins: arve (arve@212.251.175.125)
  58. # [16:10] * Quits: Dashiva (noone@129.241.137.223) (Ping timeout)
  59. # [16:10] * Joins: Dashiva (noone@129.241.137.223)
  60. # [16:18] <arve> is there a way to mute zakim without echoing that to the channel?
  61. # [16:18] <arve> "mute zakim" → "make zakim mute me"
  62. # [16:19] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: Leaving)
  63. # [16:21] <darobin> arve: there are phone commands, I think #61 for mute and #60 for unmute but I'm not sure those are the correct ones
  64. # [16:22] <arve> that'd echo dtmf to the channel, no?
  65. # [16:22] <darobin> you mean to the IRC channel?
  66. # [16:23] <darobin> IIRC the bridge is smart enough not to relay DTMF to the other callers
  67. # [16:24] <arve> s/channel/bridge
  68. # [16:24] * Joins: Lachy (Lachlan@213.236.208.247)
  69. # [16:25] <arve> I heard dtmf on the #dap meeting just now
  70. # [16:25] <darobin> I don't think it relays them
  71. # [16:25] <darobin> http://www.w3.org/2001/12/zakim-irc-bot.html
  72. # [16:26] <darobin> "Conferees can mute themselves by dialing 61#. In that case, unmute is 60#."
  73. # [16:26] <arve> either way, I'd hoped it was possible to do over IRC, since I'd like to quietly mute myself whenever I switch to a different channel
  74. # [16:27] <arve> I do a bit of context switching in parts of a conference
  75. # [16:28] <darobin> well you can use /me, at least it won't show in the minuts
  76. # [16:30] * Quits: taf2 (taf2@38.99.201.242) (Quit: taf2)
  77. # [16:53] * Joins: taf2 (taf2@38.99.201.242)
  78. # [17:40] * Quits: Lachy (Lachlan@213.236.208.247) (Quit: This computer has gone to sleep)
  79. # [17:46] * Quits: arve (arve@212.251.175.125) (Quit: Ex-Chat)
  80. # [17:47] * Joins: arve (arve@212.251.175.125)
  81. # [17:57] * Joins: Lachy (Lachlan@85.196.122.246)
  82. # [17:59] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: Leaving)
  83. # [17:59] * Joins: Lachy (Lachlan@85.196.122.246)
  84. # [18:51] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC)
  85. # [18:51] * Joins: ArtB (d0309a43@128.30.52.43)
  86. # [19:08] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  87. # [20:42] * Quits: darobin (robin@85.169.117.248) (Ping timeout)
  88. # [20:54] * Quits: taf2 (taf2@38.99.201.242) (Quit: taf2)
  89. # [21:38] * Joins: taf2 (taf2@38.99.201.242)
  90. # [21:53] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  91. # [22:10] * Joins: Lachy (Lachlan@85.196.122.246)
  92. # [22:32] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  93. # [22:34] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC)
  94. # [22:43] * Joins: Lachy (Lachlan@85.196.122.246)
  95. # [22:44] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: Leaving)
  96. # [22:44] * Joins: Lachy (Lachlan@85.196.122.246)
  97. # [22:58] <Hixie> arve: you can do it over irc
  98. # [22:58] <Hixie> arve: just /msg zakim directly
  99. # [23:06] <arve> thanks
  100. # [23:10] <shepazu> smaug: you coming to the telcon?
  101. # [23:10] * Joins: CGI469 (836b0047@128.30.52.43)
  102. # [23:10] <smaug> I could, though I have little flu
  103. # [23:10] <CGI469> howdy.
  104. # [23:10] <shepazu> I'm feeling pretty lousy myself
  105. # [23:10] <CGI469> yuck--wrong alias...
  106. # [23:10] * Parts: CGI469 (836b0047@128.30.52.43)
  107. # [23:11] * Joins: Travis (836b0047@128.30.52.43)
  108. # [23:11] <smaug> ah
  109. # [23:11] <shepazu> ah
  110. # [23:11] <smaug> :)
  111. # [23:11] <shepazu> lol
  112. # [23:11] <shepazu> trackbot, start telcon
  113. # [23:11] * trackbot is starting a teleconference
  114. # [23:11] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
  115. # [23:11] <RRSAgent> logging to http://www.w3.org/2009/09/16-webapps-irc
  116. # [23:11] <trackbot> RRSAgent, make logs public
  117. # [23:11] <RRSAgent> I have made the request, trackbot
  118. # [23:11] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  119. # [23:11] <trackbot> Zakim, this will be WAPP
  120. # [23:11] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
  121. # [23:11] <trackbot> Meeting: Web Applications Working Group Teleconference
  122. # [23:11] <trackbot> Date: 16 September 2009
  123. # [23:11] <smaug> ok, so if we could have less than 2 hours long telcon this time ;)
  124. # [23:11] * shepazu zakim, this will be DOM3
  125. # [23:11] * Zakim ok, shepazu, I see IA_WebApps(DOM3)5:00PM already started
  126. # [23:12] * shepazu zakim, call shepazu
  127. # [23:12] * Zakim ok, shepazu; the call is being made
  128. # [23:12] <smaug> I need to get up early
  129. # [23:12] <Zakim> +Shepazu
  130. # [23:12] <shepazu> let's keep this short, then...
  131. # [23:12] <Zakim> +??P1
  132. # [23:13] <Travis> scribenick Travis
  133. # [23:13] <shepazu> Topic: listen/unlisten
  134. # [23:14] <Travis> scribeNick: Travis
  135. # [23:14] <Travis> scribe: Travis
  136. # [23:14] <Travis> topic: listen/unlisten events
  137. # [23:14] <Travis> (methods)
  138. # [23:14] <Travis> shepazu: All major browser venders said 'no' to this proposal.
  139. # [23:15] <shepazu> s/events/methods
  140. # [23:15] <Travis> Resolution: remove listen/unlisten from the spec.
  141. # [23:16] <shepazu> Topic: key identifiers
  142. # [23:16] <Travis> shepazu: Since it's just an alias, it's not really needed. If it added functionality then that would be a different story.
  143. # [23:16] <shepazu> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset
  144. # [23:17] <Travis> shepazu: most recent draft- added explanitory text about key identifiers.
  145. # [23:17] <Travis> ... please review (members of the working group)
  146. # [23:17] <Travis> ... Q: What _is_ a key identifier?
  147. # [23:18] <Travis> ... Finally realized that a key identifier is not a unique id for a key, it's the value of the key at the given moment with contributions from modifiers, etc.
  148. # [23:18] <Travis> ... It's the input key character.
  149. # [23:18] <Travis> ... A key can have multiple key identifiers. Could be unicode name/value or character
  150. # [23:20] <Travis> Travis: Yes, I like the clarity provided in the new draft.
  151. # [23:21] <Travis> shepazu: Yes, need to put a section that says that multiple literal keys may have the same mapping.
  152. # [23:21] <Travis> ... recently added all lowercase key identifiers to the spec. Looking for comments.
  153. # [23:22] <Travis> ... With that, perhaps close to last call?
  154. # [23:22] <Travis> smaug: I need to review the entire spec again. Can you send mail to list to review as well?
  155. # [23:22] <Travis> shepazu: sure.
  156. # [23:23] <Travis> ... might be appropriate to put out a new draft for review. *could* be a last call draft.
  157. # [23:23] <shepazu> topic: namespaced events
  158. # [23:23] <Travis> shepazu: Marked these as "at risk"
  159. # [23:24] <Travis> ... I'm concerned about the dependencies that others may have
  160. # [23:24] <Travis> ... During discussion with SVG group recently... was talking about namespace events.
  161. # [23:25] <Travis> ... Can see the complexity in namespace event implementations
  162. # [23:25] <Travis> ... Also having the init* methods for NS adds complexity.
  163. # [23:26] <Travis> ... Is it really common to init events?
  164. # [23:26] <Travis> travis: Have heard of use cases for this...
  165. # [23:26] <Travis> shepazu: Script libraries may use them more...
  166. # [23:28] <Travis> ... Cameron suggested an event initializer that could allow event properties to be read/write until the event was dispatched.
  167. # [23:28] <Travis> Travis: A little weird to declare (since the read/write changes dynamically).
  168. # [23:29] <Travis> shepazu: One advantage is that namespaceURI becomes much less overhead (don't need an separate init* method).
  169. # [23:30] <Travis> Travis: would we then drop the init*NS methods?
  170. # [23:30] <Travis> shepazu: Don't know... could drop them, could even drop all the custom initializers. Will see. Waiting on Cameron's proposal to the lsit.
  171. # [23:31] <shepazu> topic: focus
  172. # [23:31] <Travis> shepazu: Travis asked why you need the relatedTarget...
  173. # [23:32] <Travis> ... It's a pain to track state (in webpage code). Also use cases don't always use both events
  174. # [23:35] <Travis> Travis: I'm not really opposed to the FocusEvent interface proposal.
  175. # [23:37] <Travis> Travis: I think it's a good idea if we need to have new properties.
  176. # [23:37] <Travis> Resolution: Add a new FocusEvent interface to support the focusin/focusout/focus/blur such that they gain a relatedTarget property.
  177. # [23:38] <Travis> shepazu: There might be an issue with adding new properties...
  178. # [23:38] <Travis> smaug: I don't recall any bugs with our own added properties to MouseEvent
  179. # [23:39] * Quits: zalan (zalan@89.135.144.193) (Ping timeout)
  180. # [23:39] <Travis> shepazu: +DOMFocusIn, +DOMFocusOut (to FocusEvent interface)
  181. # [23:39] <Travis> ... relatedTarget will be the node that the event is going to or coming from. Might also be null.
  182. # [23:40] <Travis> ... for blur/focusout : the relatedTarget is the element that they are going to (opposite of focus/focusin)
  183. # [23:40] <Travis> topic: back to key identifiers (briefly)
  184. # [23:40] <Travis> shepazu: Does anyone implement key identifiers?
  185. # [23:41] <Travis> smaug: Don't think so.
  186. # [23:41] <Travis> shepazu: What if you needed the unicode value? Or the character name (not it's value)...?
  187. # [23:42] <Travis> ... Have some ideas for that: expose it on the event itself with the keyIdentifier (like an array?) or a ConvertTo(keyidentier, newFormat).
  188. # [23:42] <Travis> ... What do you think?
  189. # [23:43] <Travis> Travis: I like the convertTo api. Put it in a new spec (DOM L4 events?).
  190. # [23:43] <Travis> smaug: +1
  191. # [23:44] <Travis> shepazu: Also good to have available when events are not in use.
  192. # [23:45] <shepazu> topic: default actions
  193. # [23:45] <Travis> ... Do implementations have a huge list of character<->codes<->identifiers?
  194. # [23:45] <shepazu> topic: default actions
  195. # [23:46] <Travis> shepazu: Changed the events table to organize around default actions... it raised some questions.
  196. # [23:47] <smaug> btw, scroll event isn't the default action of mouwewheel I believe
  197. # [23:48] <smaug> scroll event certainly isn't the default action of wheel event
  198. # [23:49] <Travis> ... For events without default actions but are cancellable, does that mean that an implemention has a default action anyway?
  199. # [23:50] <Travis> smaug: No direct correlation between wheel event and scroll event.
  200. # [23:50] <shepazu> topic: on-* attributes as event listeners?
  201. # [23:50] <Travis> shepazu: OK, will update the spec.
  202. # [23:50] <Travis> shepazu: Talked about onfoo attributes as an implicit addEventListener.
  203. # [23:51] <Travis> ... hixie wasn't too keen on the idea initially, but has recently asked about it.
  204. # [23:51] <Travis> ... hixie may have wanted more detail than we had in the spec at the time.
  205. # [23:51] <Travis> ... Two benefits (I think):
  206. # [23:51] <Hixie> onfoo isn't quite implicitly addEventListener(), it's a lot more complicated. HTML5 defines it all in detail though.
  207. # [23:52] <Hixie> basically each onfoo registers an event listener when the element is created
  208. # [23:52] <Hixie> and changing the value of onfoo doesn't affect that
  209. # [23:52] * smaug needs to review the body + onfoo handling :)
  210. # [23:52] <Hixie> the listener itself then uses the value of onfoo as part of its processing
  211. # [23:53] <Hixie> html5 also defines some hooks so other specs can make use of these definitions easily
  212. # [23:53] <Hixie> a number of specs make use of this, including at least xhr, eventsource, web sockets, web workers, web storage
  213. # [23:53] <Travis> shepazu: Seems like HTML5 has it covered.
  214. # [23:53] <annevk> I think what HTML5 says might not match implementations. removeAttribute("onfoo", ...) should actually work. Hallvord filed a bug on that.
  215. # [23:54] <Hixie> annevk, that's a separate issue from addEventListener
  216. # [23:54] <annevk> true
  217. # [23:55] <Travis> shepazu: I should say something about this in the spec. (need to define if removeEventListener removes these events, or if they are just special).
  218. # [23:55] <Travis> Travis: (Thinks they are special)
  219. # [23:55] <Travis> ... but what order to the fire in relation to the other eventes?
  220. # [23:55] <Hixie> removeEventListener can't remove them because you can't get a handle to the event handler
  221. # [23:56] <Travis> shepazu: Will probably just reference HTML5 on this issue. (For context within the D3E spec.)
  222. # [23:56] <annevk> order should be registration order
  223. # [23:56] <Travis> True.
  224. # [23:56] <Hixie> order is defined in html5, i believe. at least i intended to define it there. file a bug if it's not defined :-)
  225. # [23:56] <Travis> shepazu: This simplifies the D3E spec. Good.
  226. # [23:56] <Hixie> html5 basically hooks all this into the dom3 events model, so dom3 events shouldn't need to say anything special about it
  227. # [23:57] <Hixie> so long as order is defined in general, i just hook into that
  228. # [23:57] <Travis> ... Also talked awhile ago about providing an enumerator of event listeners. Seems too complicated for D3E. We could pursue in D4E...
  229. # [23:59] <Travis> shepazu: Are folks committed to implementing the features of D3E?
  230. # Session Close: Thu Sep 17 00:00:00 2009

The end :)