/irc-logs / w3c / #webapps / 2010-02-17 / end

Options:

  1. # Session Start: Wed Feb 17 00:00:00 2010
  2. # Session Ident: #webapps
  3. # [00:29] * Joins: Nikunj (Adium@64.186.167.205)
  4. # [00:42] * Quits: Nikunj (Adium@64.186.167.205) (Ping timeout)
  5. # [00:42] * Joins: Nikunj (Adium@64.186.167.205)
  6. # [01:03] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
  7. # [01:07] * Quits: Nikunj (Adium@64.186.167.205) (Quit: Leaving.)
  8. # [01:11] * Joins: Nikunj (Adium@64.186.167.205)
  9. # [01:20] * Quits: Nikunj (Adium@64.186.167.205) (Quit: Leaving.)
  10. # [01:23] * Joins: Nikunj (Adium@64.186.167.205)
  11. # [01:25] * Quits: Nikunj (Adium@64.186.167.205) (Quit: Leaving.)
  12. # [01:28] * Joins: Nikunj (Adium@64.186.167.205)
  13. # [01:30] * Quits: Nikunj (Adium@64.186.167.205) (Quit: Leaving.)
  14. # [01:31] * Joins: Nikunj (Adium@64.186.167.205)
  15. # [01:33] * Quits: Nikunj (Adium@64.186.167.205) (Quit: Leaving.)
  16. # [02:04] * Joins: MikeSmithXX (MikeSmith@114.48.218.100)
  17. # [02:07] * Quits: MikeSmithX (MikeSmith@114.48.136.110) (Ping timeout)
  18. # [02:11] * Joins: Nikunj (Adium@64.186.167.205)
  19. # [02:14] * Quits: Nikunj (Adium@64.186.167.205) (Ping timeout)
  20. # [03:01] * MikeSmithXX is now known as MikeSmith
  21. # [06:22] * Joins: Nikunj (Adium@98.234.68.6)
  22. # [06:52] * Quits: Lachy (Lachlan@83.170.95.133) (Ping timeout)
  23. # [08:04] * Joins: MikeSmithX (MikeSmith@114.48.73.227)
  24. # [08:06] * Quits: MikeSmith (MikeSmith@114.48.218.100) (Ping timeout)
  25. # [08:15] * Quits: Nikunj (Adium@98.234.68.6) (Quit: Leaving.)
  26. # [08:23] * Joins: Lachy (Lachlan@83.170.95.133)
  27. # [09:03] * Joins: arve (arve@212.251.179.162)
  28. # [09:18] * Joins: viper23 (Lukas_Schm@80.153.21.122)
  29. # [09:26] * Joins: tlr (tlr@128.30.52.169)
  30. # [09:37] * Joins: darobin (robin@78.229.133.72)
  31. # [09:50] * Quits: sicking (chatzilla@63.245.220.240) (Ping timeout)
  32. # [10:07] * Quits: Lachy (Lachlan@83.170.95.133) (Quit: Leaving)
  33. # [10:10] * Joins: Lachy (Lachlan@83.170.95.133)
  34. # [10:17] * Quits: Lachy (Lachlan@83.170.95.133) (Quit: This computer has gone to sleep)
  35. # [10:18] * Quits: MikeSmithX (MikeSmith@114.48.73.227) (Quit: Till kicked and torn and beaten out he lies, and leaves his hold and crackles, groans, and dies.)
  36. # [10:29] * Joins: Lachy (Lachlan@88.131.66.80)
  37. # [10:29] * Quits: Lachy (Lachlan@88.131.66.80) (Client exited)
  38. # [10:29] * Joins: Lachy (Lachlan@88.131.66.80)
  39. # [10:38] * Joins: Marcos (Marcos@84.215.182.38)
  40. # [10:53] * Joins: sicking (chatzilla@69.181.197.163)
  41. # [10:53] * Quits: sicking (chatzilla@69.181.197.163) (Client exited)
  42. # [11:40] * tlr is now known as tlr-bbl
  43. # [11:43] * Quits: arve (arve@212.251.179.162) (Quit: Ex-Chat)
  44. # [11:52] * Joins: arve (arve@212.251.179.162)
  45. # [12:09] * Quits: darobin (robin@78.229.133.72) (Client exited)
  46. # [12:36] * Joins: MikeSmith (MikeSmith@114.48.237.22)
  47. # [12:44] * Quits: timeless_mbp (timeless@88.115.8.36) (Quit: timeless_mbp)
  48. # [13:00] * Joins: ArtB (chatzilla@192.100.124.219)
  49. # [13:34] * Joins: timeless_mbp (timeless@192.100.124.156)
  50. # [13:42] * Quits: timeless_mbp (timeless@192.100.124.156) (Connection reset by peer)
  51. # [13:42] * Joins: timeless_mbp (timeless@192.100.124.156)
  52. # [13:51] * tlr-bbl is now known as tlr
  53. # [13:58] * Joins: timeless_mbp_ (timeless@192.100.124.156)
  54. # [13:58] * Quits: timeless_mbp (timeless@192.100.124.156) (Connection reset by peer)
  55. # [13:58] * timeless_mbp_ is now known as timeless_mbp
  56. # [14:33] * Quits: MikeSmith (MikeSmith@114.48.237.22) (Quit: Till kicked and torn and beaten out he lies, and leaves his hold and crackles, groans, and dies.)
  57. # [14:50] * Joins: Alex_Ivaylov (alex@85.187.214.246)
  58. # [15:06] * Quits: Lachy (Lachlan@88.131.66.80) (Quit: Leaving)
  59. # [15:07] * Joins: Lachy (Lachlan@208.100.23.169)
  60. # [15:09] * Quits: Lachy (Lachlan@208.100.23.169) (Quit: Leaving)
  61. # [15:09] * Joins: Lachy (Lachlan@88.131.66.80)
  62. # [15:16] * Joins: aroben (aroben@71.58.77.15)
  63. # [16:25] * ArtB is now known as ArtB_
  64. # [16:26] <shepazu> smaug: ping
  65. # [16:26] <smaug> shepazu: pong
  66. # [16:26] <smaug> you're up early
  67. # [16:27] <shepazu> yeah, had a lousy meeting to attend, which turns out to be anti-productive
  68. # [16:27] <shepazu> whee
  69. # [16:29] <shepazu> smaug: I will start going through your emails, and ask questions when I hit a roadbump
  70. # [16:29] <smaug> ok
  71. # [16:46] * Joins: Nikunj (Adium@98.234.68.6)
  72. # [16:50] * Quits: Nikunj (Adium@98.234.68.6) (Quit: Leaving.)
  73. # [16:55] * Quits: Alex_Ivaylov (alex@85.187.214.246) (Client exited)
  74. # [17:02] * Joins: Alex_Ivaylov (alex@85.187.214.246)
  75. # [17:05] * Joins: Nikunj (Adium@98.234.68.6)
  76. # [17:05] * Quits: Nikunj (Adium@98.234.68.6) (Quit: Leaving.)
  77. # [17:58] * Quits: Alex_Ivaylov (alex@85.187.214.246) (Quit: Alex_Ivaylov)
  78. # [17:58] * ArtB_ is now known as ArtB
  79. # [18:01] * Joins: Nikunj (Adium@64.186.167.205)
  80. # [18:01] <shepazu> smaug: first question on http://lists.w3.org/Archives/Public/www-dom/2010JanMar/0010.html
  81. # [18:02] <shepazu> what do you mean by [[ "event type" Event type doesn't actually say anything about attributes or interfaces. ]]
  82. # [18:02] * Joins: Lachy_PC (Lachy@213.236.208.22)
  83. # [18:03] <shepazu> since an event type is part of a particular interface, isn't it fair (if not precise) to describe it that way?
  84. # [18:03] * Lachy_PC is now known as anne42
  85. # [18:03] * Parts: anne42 (Lachy@213.236.208.22) (Leaving)
  86. # [18:08] <smaug> shepazu: just a second
  87. # [18:09] <smaug> shepazu: so event type
  88. # [18:09] <smaug> I assume that mean event.type
  89. # [18:09] <smaug> right?
  90. # [18:10] <smaug> or it does, based on the "click" example
  91. # [18:10] <smaug> the fact that event's type is "click" doesn't tell anything about which interface the object implements
  92. # [18:11] <smaug> a script may create event using var e = document.createEvent("MutationEvent"); e.initEvent("click", true, true); target.dispatchEvent(e);
  93. # [18:11] <shepazu> ok
  94. # [18:12] <smaug> I know it is a bit tricky to define this all
  95. # [18:12] <smaug> since by default click is in fact a MouseEvent
  96. # [18:13] <shepazu> yeah, it's a tradeoff between being precise in covering all the cases while being meaningful to authors for the general case
  97. # [18:22] <shepazu> smaug: about your "Feature detection doesn't work in all cases" comment
  98. # [18:22] <shepazu> I have 2 possible solutions
  99. # [18:23] <shepazu> 1) authors can test for something by Interface name, something like "Events.ProgressEvent.load"
  100. # [18:24] <shepazu> 2) give them finer control over testing for specific attributes "Events.mousemove.buttons"
  101. # [18:24] <smaug> and the use case is?
  102. # [18:24] <smaug> even for the 1) ?
  103. # [18:25] <smaug> did you read also G.Smith's emails?
  104. # [18:25] <shepazu> people have expressed a desire to do do feature detection, and I agree with that use case
  105. # [18:25] <shepazu> and hasFeature is already defined and implemented
  106. # [18:26] <smaug> that is there sure
  107. # [18:26] <shepazu> yes, I've read all of G.Smith's emails
  108. # [18:26] <smaug> 1) looks ok, I think
  109. # [18:26] <smaug> I don't quite understand 2)
  110. # [18:26] <smaug> should that be Events.MouseEvent.mousemove.buttons?
  111. # [18:27] <smaug> but if mousemove is a MouseEvent, it has .buttons
  112. # [18:28] <shepazu> his claim that "browsers lie" is not convincing to me... a) my proposal actually provides a better fine-grained mechanism than was previously defined, and b) even if his feature detection method were implemented, it would still not account for implementation bugs
  113. # [18:28] <smaug> that is true
  114. # [18:29] <smaug> though he does have the point that having some method in each eventtarget would allow more fine grained detection
  115. # [18:29] <shepazu> smaug: I'll go with (1) then
  116. # [18:29] <smaug> but yet, that isn't really working
  117. # [18:29] <smaug> if extensions / user scripts / whatever dispatch events
  118. # [18:30] <smaug> 1) doesn't handle extensions either
  119. # [18:31] <smaug> again, tricky case
  120. # [18:35] <shepazu> smaug: that's why I thought of (2)
  121. # [18:35] <shepazu> look at CSSOM Views
  122. # [18:36] <shepazu> it extends the MouseEvent interface with new attributes
  123. # [18:36] <shepazu> so you could test on those attributes
  124. # [18:36] <smaug> ah, you mean that
  125. # [18:37] <smaug> but say that some webapp wants tripleclick
  126. # [18:37] <smaug> and the browser doesn't support it
  127. # [18:37] <shepazu> (I used ".buttons" because that is something new in D3E, which could be used to test for support of that feature specifically
  128. # [18:38] <smaug> yet some extension or greasemonkey script can add the support to browser
  129. # [18:39] <smaug> or would testing Events.MouseEvent.tripleclick just check that if it is possible to create such event
  130. # [18:39] <smaug> or does it check whether the implementation actually does dispatch such events?
  131. # [18:40] <shepazu> well, a good extensibility mechanism in the browser would let an extension "register" the new features added
  132. # [18:40] <shepazu> good question... 2 answers
  133. # [18:40] <smaug> greasemonkey scripts are a bit different
  134. # [18:40] <shepazu> 1) I think that would be implementation-dependent
  135. # [18:40] <smaug> they are closer to javascript: bookmarks
  136. # [18:41] <smaug> which just run something in the page context
  137. # [18:41] <shepazu> 2) even if the system isn't perfect, and doesn't catch every case, it can still be useful for the majority of cases
  138. # [18:42] <smaug> the thing is that I don't want webapps to rely on information which might lack something (the support provided by greasemonkey scripts etc)
  139. # [18:43] <shepazu> fwiw, ProgressEvent.load doesn't seem to be much different than the DOM3 Events load, though it's hard to tell because the events aren't very well defined
  140. # [18:43] <smaug> ProgressEvent.load is pretty well defined
  141. # [18:44] <smaug> at least when dispatched to an XHR object
  142. # [18:44] <shepazu> ah, I was looking at http://dev.w3.org/2006/webapi/progress/Progress.html#Progress
  143. # [18:45] * Parts: viper23 (Lukas_Schm@80.153.21.122)
  144. # [18:48] <shepazu> smaug: about greasemonkey... they can always check the actual event object itself if it comes down to it
  145. # [18:48] <shepazu> feature detection can happen at multiple stages
  146. # [18:49] <smaug> webapps might disable some features if .hasFeature says that something isn't supported
  147. # [18:50] <shepazu> then that's bad programming
  148. # [18:51] <smaug> well, what is the use case for hasFeature then?
  149. # [18:52] <shepazu> it's more likely that they will switch to a different codepath that tries to add the functionality, or finds another way to provide the features
  150. # [19:08] <shepazu> smaug: about "If the feature "+Events" is supported by the Document object, an object that supports the DocumentEvent interface must be returned by invoking the method Node.getFeature("+Events", "3.0") on the Document object."... honestly, I'm not sure what that means... that's from the original draft
  151. # [19:10] <shepazu> could I replace that with "Language-specific type casting may be required, but is implementation-dependent."?
  152. # [19:11] <smaug> why the ",but" ...
  153. # [19:12] <smaug> perhaps just "Language-specific type casting may be required."
  154. # [19:17] <shepazu> ok
  155. # [19:17] <shepazu> I just don't want to define the casting
  156. # [19:48] * Quits: timeless_mbp (timeless@192.100.124.156) (Quit: timeless_mbp)
  157. # [19:50] * Quits: Nikunj (Adium@64.186.167.205) (Quit: Leaving.)
  158. # [19:53] * tlr is now known as tlr-bbl
  159. # [20:02] <shepazu> trackbot, start telcon
  160. # [20:02] * trackbot is preparing a teleconference
  161. # [20:02] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  162. # [20:02] <RRSAgent> logging to http://www.w3.org/2010/02/17-webapps-irc
  163. # [20:02] <trackbot> RRSAgent, make logs public
  164. # [20:02] <RRSAgent> I have made the request, trackbot
  165. # [20:02] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  166. # [20:02] <trackbot> Zakim, this will be DOM3
  167. # [20:02] <Zakim> ok, trackbot; I see IA_WebApps(DOM3)2:00PM scheduled to start now
  168. # [20:02] <trackbot> Meeting: Web Applications Working Group Teleconference
  169. # [20:02] <trackbot> Date: 17 February 2010
  170. # [20:02] * Joins: Nikunj (Adium@64.186.167.205)
  171. # [20:03] <smaug> just a minute
  172. # [20:03] * Joins: timeless_mbp (timeless@62.78.156.226)
  173. # [20:04] * shepazu Zakim, call shepazu
  174. # [20:04] * Zakim ok, shepazu; the call is being made
  175. # [20:04] <Zakim> IA_WebApps(DOM3)2:00PM has now started
  176. # [20:04] <Zakim> +Shepazu
  177. # [20:04] <Zakim> +??P1
  178. # [20:04] <smaug> Zakim, ??P1 is Olli_Pettay
  179. # [20:04] <Zakim> +Olli_Pettay; got it
  180. # [20:22] * Quits: Nikunj (Adium@64.186.167.205) (Quit: Leaving.)
  181. # [20:35] * Joins: Travis (836b0056@128.30.52.43)
  182. # [20:43] <smaug> Travis: are you going to call in?
  183. # [20:45] <Travis> I was waiting to see if there was any activity on the list... Is Doug on the call?
  184. # [20:45] <smaug> yes
  185. # [20:45] <Travis> OK. hang on...
  186. # [20:45] <Zakim> +[Microsoft]
  187. # [20:47] * shepazu http://www.w3.org/2010/webapps/charter/Overview.html
  188. # [20:48] * Joins: Nikunj (Adium@64.186.167.205)
  189. # [20:48] * Quits: timeless_mbp (timeless@62.78.156.226) (Connection reset by peer)
  190. # [20:48] * Joins: timeless_mbp (timeless@62.78.156.226)
  191. # [20:51] <shepazu> Topic: related target
  192. # [20:51] <shepazu> For nested browsing contexts, when tabbing into or out of a nested context, the relevant EventTarget should be the element containing browsing context.
  193. # [20:53] <shepazu> or null?
  194. # [20:56] * Quits: timeless_mbp (timeless@62.78.156.226) (Connection reset by peer)
  195. # [20:57] * Joins: timeless_mbp (timeless@62.78.156.226)
  196. # [21:12] * Quits: Nikunj (Adium@64.186.167.205) (Quit: Leaving.)
  197. # [21:12] * Quits: Lachy (Lachlan@88.131.66.80) (Quit: This computer has gone to sleep)
  198. # [21:13] * Joins: Lachy (Lachlan@88.131.66.80)
  199. # [21:13] * Quits: Lachy (Lachlan@88.131.66.80) (Quit: This computer has gone to sleep)
  200. # [21:19] * Quits: tlr-bbl (tlr@128.30.52.169) (Client exited)
  201. # [21:21] * Quits: chaals (chaals@213.236.208.22) (Quit: chaals)
  202. # [21:27] <shepazu> http://lists.w3.org/Archives/Public/www-dom/2010JanMar/0010.html
  203. # [21:32] <Zakim> -Olli_Pettay
  204. # [21:41] * Joins: Lachy (Lachlan@81.170.212.11)
  205. # [21:42] * Quits: Lachy (Lachlan@81.170.212.11) (Quit: Leaving)
  206. # [21:42] * Joins: Lachy (Lachlan@83.170.95.133)
  207. # [21:56] * Joins: Nikunj (Adium@64.186.167.205)
  208. # [21:57] * Joins: tlr (tlr@128.30.52.169)
  209. # [21:58] * Parts: tlr (tlr@128.30.52.169)
  210. # [21:59] <Zakim> -[Microsoft]
  211. # [21:59] <Zakim> -Shepazu
  212. # [21:59] <Zakim> IA_WebApps(DOM3)2:00PM has ended
  213. # [21:59] <Zakim> Attendees were Shepazu, Olli_Pettay, [Microsoft]
  214. # [22:00] * Quits: timeless_mbp (timeless@62.78.156.226) (Ping timeout)
  215. # [22:09] * Joins: timeless_mbp (timeless@88.115.8.36)
  216. # [22:27] * Joins: Nikunj1 (Adium@99.30.84.11)
  217. # [22:28] * Zakim excuses himself; his presence no longer seems to be needed
  218. # [22:28] * Parts: Zakim (rrs-bridgg@128.30.52.30)
  219. # [22:29] * Quits: Nikunj (Adium@64.186.167.205) (Ping timeout)
  220. # [22:30] * Quits: ArtB (chatzilla@192.100.124.219) (Client exited)
  221. # [22:51] * Quits: Travis (836b0056@128.30.52.43) (Quit: CGI:IRC (EOF))
  222. # [23:44] * Joins: sicking (chatzilla@63.245.220.240)
  223. # Session Close: Thu Feb 18 00:00:00 2010

The end :)