/irc-logs / w3c / #webapps / 2009-02-12 / end

Options:

  1. # Session Start: Thu Feb 12 00:00:00 2009
  2. # Session Ident: #webapps
  3. # [00:24] * Quits: heycam (cam@130.194.72.84) (Client exited)
  4. # [00:25] * Joins: heycam (cam@130.194.72.84)
  5. # [00:32] * Joins: hober (ted@206.212.254.2)
  6. # [02:43] * Quits: tlr-bbl (tlr@128.30.52.30) (Quit: tlr-bbl)
  7. # [04:19] * Quits: arve (arve@95.34.27.22) (Ping timeout)
  8. # [04:20] * Joins: arve (arve@95.34.27.22)
  9. # [04:39] * Quits: Dashiva (noone@84.48.51.1) (Ping timeout)
  10. # [04:41] * Joins: Dashiva (noone@80.202.223.46)
  11. # [04:43] * Quits: arve (arve@95.34.27.22) (Ping timeout)
  12. # [04:44] * Joins: arve (arve@95.34.27.22)
  13. # [04:47] * Quits: arve (arve@95.34.27.22) (Ping timeout)
  14. # [04:54] * Joins: arve (arve@95.34.27.22)
  15. # [05:00] * Quits: arve (arve@95.34.27.22) (Ping timeout)
  16. # [05:00] * Joins: arve (arve@95.34.27.22)
  17. # [05:06] * Quits: arve (arve@95.34.27.22) (Ping timeout)
  18. # [05:06] * Joins: arve (arve@95.34.27.22)
  19. # [05:09] * Quits: arve (arve@95.34.27.22) (Ping timeout)
  20. # [05:11] * Joins: arve (arve@95.34.27.22)
  21. # [05:20] * Quits: arve (arve@95.34.27.22) (Ping timeout)
  22. # [05:21] * Joins: arve (arve@95.34.27.22)
  23. # [06:24] * Quits: aroben (aroben@71.58.73.153) (Connection reset by peer)
  24. # [06:55] * Quits: Dashiva (noone@80.202.223.46) (Ping timeout)
  25. # [07:02] * Joins: Dashiva (noone@80.202.223.46)
  26. # [07:47] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
  27. # [08:22] * Quits: arve (arve@95.34.27.22) (Quit: Leaving)
  28. # [09:24] * Joins: heycam (cam@210.84.15.128)
  29. # [10:08] <anne> sicking, it's in line with IE currently, but it should be defined in terms of the event loop instead
  30. # [10:08] <anne> smaug, ^^
  31. # [10:23] <smaug> anne: you mean readystatechange?
  32. # [10:26] <anne> yes
  33. # [10:26] <anne> i just replied to the e-mail
  34. # [10:34] * Joins: arve (arve@213.236.208.22)
  35. # [10:38] * Quits: arve (arve@213.236.208.22) (Quit: Leaving)
  36. # [10:39] * Joins: arve (arve@213.236.208.22)
  37. # [10:39] * Quits: arve (arve@213.236.208.22) (Quit: Leaving)
  38. # [10:46] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  39. # [10:56] <anne> sicking, smaug, I guess it doesn't matter much, but since the events are dispatched after the request is completed the seem quite useless
  40. # [10:56] <anne> s/the seem/they seem/
  41. # [11:03] * Joins: arve (arve@213.236.208.22)
  42. # [11:05] <smaug> anne: "dispatched after the request is completed" ?
  43. # [11:06] <smaug> which events?
  44. # [11:06] * Quits: arve (arve@213.236.208.22) (Ping timeout)
  45. # [11:06] <smaug> and which implementation?
  46. # [11:07] <anne> smaug, readystatechange during sync, IE, afaict
  47. # [11:07] <anne> smaug, I mean, that's the point the script gets hold of them
  48. # [11:07] <smaug> oh, IE does that...
  49. # [11:07] <smaug> seems like a bug
  50. # [11:08] <anne> if they're dispatched during the request it's not quite sync anymore...
  51. # [11:08] <smaug> it can be still sync
  52. # [11:08] <anne> well, the method call would be sync I suppose...
  53. # [11:09] <smaug> right
  54. # [11:09] <smaug> I think readystatechanged shouldn't fire at all with sync
  55. # [11:09] <smaug> no events during sync
  56. # [11:09] <smaug> except load/error
  57. # [11:10] <anne> just before you guys were arguing the other way around?
  58. # [11:10] <smaug> sicking wanted the events during sync
  59. # [11:10] <smaug> I don't want
  60. # [11:10] <anne> i suppose not dispatching events during sync would make things easier to spec, but that doesn't sound like a good optimization
  61. # [11:10] <anne> i see
  62. # [11:11] * Joins: arve (arve@213.236.208.247)
  63. # [11:11] <anne> do you comprehend the thing that is the HTML5 "event loop"?
  64. # [11:11] <anne> i want to define XMLHttpRequest event handling in terms of that in due course
  65. # [11:11] * Quits: arve (arve@213.236.208.247) (Quit: Leaving)
  66. # [11:12] <smaug> anne: but we want load event anyway
  67. # [11:12] <smaug> and that fires before .send() returns
  68. # [11:12] * Joins: arve (arve@213.236.208.247)
  69. # [11:13] <smaug> though, load is fired just before send() returns
  70. # [11:13] <anne> it would be queued just before send() returns
  71. # [11:14] <anne> and run before the statement after the send() call
  72. # [11:14] <smaug> effectively the same thing yes
  73. # [11:15] <smaug> though it would be pretty strange implementation to dispatch the event when .send has returned
  74. # [11:15] <anne> i suppose, i try to think in terms of the event loop :)
  75. # [11:15] <smaug> IMO
  76. # [11:18] <smaug> anyway, I'm all for not firing readystatechange or progress during sync
  77. # [11:18] <anne> I suppose I have to test browsers again and such
  78. # [11:18] <anne> another thing I'd like Firefox to change is to dispatch readystatechange multiple times
  79. # [11:18] <anne> for readyState == 3
  80. # [11:19] <smaug> it is a bug in our progress events that they fire also when sync
  81. # [11:19] <smaug> I'm about to change that
  82. # [11:22] <smaug> anne: Btw, haven't tried with v10, but will Opera fix the event.target for XHR events?
  83. # [11:23] <smaug> with 9.x it is null, IIRC, and that breaks my tests
  84. # [11:23] <anne> I don't think so, we do support "this" properly
  85. # [11:24] <anne> though maybe Firefox doesn't :/
  86. # [11:24] * Joins: tlr (tlr@128.30.52.30)
  87. # [11:28] <smaug> we do support 'this'
  88. # [11:28] <smaug> with upload and xhr
  89. # [11:29] * Joins: chaals (chaals@89.130.83.193)
  90. # [11:31] <anne> smaug, k, cool, it used to point elsewhere iirc (Window object or some such)
  91. # [11:31] <smaug> yeah, probably in 3.0
  92. # [11:31] <smaug> in 3.1 XHR uses the same event handling code as DOM nodes
  93. # [11:33] <anne> sweet
  94. # [11:33] <anne> does send() without argument work too now?
  95. # [11:33] * Quits: arve (arve@213.236.208.247) (Ping timeout)
  96. # [11:34] <smaug> anne: yes
  97. # [11:34] <anne> yay
  98. # [11:34] <anne> be back in 20m
  99. # [11:34] * Parts: anne (annevk@85.196.122.246)
  100. # [11:35] <smaug> that was one line fix to .idl, adding [optional] ;)
  101. # [11:48] * Joins: arve (arve@213.236.208.22)
  102. # [11:51] * Joins: Lachy (Lachlan@213.236.208.247)
  103. # [11:52] * Joins: anne (annevk@213.236.208.22)
  104. # [11:54] * Quits: Lachy (Lachlan@213.236.208.247) (Ping timeout)
  105. # [11:54] * Joins: Lachy (Lachlan@213.236.208.22)
  106. # [11:56] <anne> i see, too you guys a long time then :p
  107. # [11:57] * Joins: billyjackass (MikeSmith@mcclure.w3.org)
  108. # [12:09] * Quits: billyjackass (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  109. # [12:23] <anne> timeless, there's a storage event for localStorage/sessionStorag
  110. # [12:23] <anne> e
  111. # [12:24] * Joins: ArtB (d0309a43@128.30.52.43)
  112. # [13:29] * Quits: arve (arve@213.236.208.22) (Ping timeout)
  113. # [13:35] * Joins: arve (arve@213.236.208.247)
  114. # [13:43] * Quits: arve (arve@213.236.208.247) (Ping timeout)
  115. # [14:21] * Joins: arve (arve@213.236.208.22)
  116. # [14:22] * Quits: arve (arve@213.236.208.22) (Client exited)
  117. # [14:32] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  118. # [14:33] * Joins: arve (arve@213.236.208.22)
  119. # [14:42] * Quits: arve (arve@213.236.208.22) (Client exited)
  120. # [14:43] * Joins: arve (arve@213.236.208.22)
  121. # [14:45] * Joins: arve_ (arve@213.236.208.22)
  122. # [14:47] * Quits: arve (arve@213.236.208.22) (Quit: Leaving)
  123. # [14:53] * Quits: arve_ (arve@213.236.208.22) (Quit: Leaving)
  124. # [14:55] * Joins: arve (arve@213.236.208.22)
  125. # [15:01] * Joins: aroben (aroben@71.58.73.153)
  126. # [15:07] * Quits: aroben (aroben@71.58.73.153) (Connection reset by peer)
  127. # [15:08] * Joins: aroben (aroben@71.58.73.153)
  128. # [15:11] * Joins: abraun (423912ae@128.30.52.43)
  129. # [15:13] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  130. # [15:17] * Quits: abraun (423912ae@128.30.52.43) (Quit: CGI:IRC)
  131. # [16:00] * Quits: chaals (chaals@89.130.83.193) (Quit: chaals)
  132. # [16:10] * Quits: arve (arve@213.236.208.22) (Quit: Leaving)
  133. # [16:21] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC)
  134. # [17:08] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  135. # [17:44] * Joins: ArtB (d0309a43@128.30.52.43)
  136. # [18:04] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  137. # [18:12] * Joins: chaals (chaals@89.130.83.193)
  138. # [18:30] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  139. # [18:49] * Joins: arve (arve@95.34.27.22)
  140. # [19:09] * Joins: Lachy (Lachlan@85.196.122.246)
  141. # [19:11] <sicking> smaug, why do you not want events during sync requests?
  142. # [19:11] <sicking> smaug, but do want load/error? (those seems like the least useful to me)
  143. # [19:11] <smaug> actually I don't want load/error either
  144. # [19:11] <sicking> ok, at least that's consistent then :)
  145. # [19:12] <sicking> so why no progress/readystatechange/etc events?
  146. # [19:12] <smaug> the api should be .send() and when that returns xhr has the document
  147. # [19:12] <sicking> that would still be the case, no?
  148. # [19:12] <smaug> well if those are dispatched, the api isn't working like alert()
  149. # [19:12] * sicking isn't seeing the downside of firing the events
  150. # [19:14] <smaug> load/error are anyway sort of different. Almost like try-catch
  151. # [19:14] <smaug> sicking: so why would you want progress events?
  152. # [19:15] <smaug> you can have them with async xhr
  153. # [19:15] <sicking> for the exact same reason as you'd want progress events for async requests. progress bars and such
  154. # [19:16] <smaug> but the UI is still blocked
  155. # [19:16] <sicking> we'd still reflow if the DOM was changed
  156. # [19:16] <smaug> yeah
  157. # [19:16] <sicking> but yeah, you couldn't put up a 'cancel' button
  158. # [19:19] <smaug> sicking: events during sync allow some nasty scripting
  159. # [19:19] <sicking> such as?
  160. # [19:19] <smaug> like reinitializing xhr which is still in running hte event loop
  161. # [19:19] <smaug> s/hte/the
  162. # [19:19] <sicking> so that'll be true as long as we allow *any* events
  163. # [19:20] <smaug> sure
  164. # [19:20] <sicking> but if we disallow all of them i agree with you
  165. # [19:20] <smaug> I think the new api (progress events) could behave better than the old api (readystatechange)
  166. # [19:21] <sicking> well, your last statement wasn't about better api, but about nasty nesting
  167. # [19:21] <smaug> load/error are again different. they happen sort right when we return from event loop
  168. # [19:21] <smaug> er, sort of
  169. # [19:22] <smaug> öslhfasdklöfjhasdlfkjha
  170. # [19:22] <sicking> but load/error is the most useless ones. Why would you do anything in there rather than just checking the result after send() returns
  171. # [19:22] <smaug> right
  172. # [19:22] <smaug> load/error are useless
  173. # [19:22] <smaug> but not so evil
  174. # [19:22] <sicking> i'd rather do useful evil stuff than useless non-evil :)
  175. # [19:23] <anne> are you going to define how it should in terms of the event loop?
  176. # [19:23] <smaug> what is the use case for sync+progress ?
  177. # [19:23] <sicking> same as for async+progress
  178. # [19:23] <sicking> basically my question to the list was: *why* are we disabling certain events. If the reason is performance then that's a bad reason
  179. # [19:23] <smaug> then you can do it using async+progress
  180. # [19:24] <smaug> performance can't be the reason
  181. # [19:24] <smaug> dispatching events is fast
  182. # [19:24] <sicking> that was my point :)
  183. # [19:25] <sicking> so i guess a follow up statement is: if we're doing it to allow evil nesting then we're failing by still allowing readystatechange
  184. # [19:26] <smaug> anne: did you test IE?
  185. # [19:26] <smaug> at which point does it dispatch readystatechange?
  186. # [19:27] <smaug> when things change, or just before returning from send() ?
  187. # [19:27] <anne> my recollection was that it was dispatched after the request completed
  188. # [19:27] <anne> so just before returning
  189. # [19:27] <smaug> so readystatechange behaves like load/error
  190. # [19:27] <anne> which would be relatively easy to specify i think
  191. # [19:27] <anne> yes
  192. # [19:28] <smaug> and doesn't allow that kind of evil nesting
  193. # [19:28] <anne> (the events do seem to encapsulate the state of the object at the time though)
  194. # [19:28] <anne> e.g. readyState != 4 for some of them
  195. # [19:29] <anne> i should probably do more testing; i'm basically up for specifying anything as long as enough vendors agree to implement it and someone can explain to me how to write it down
  196. # [19:29] <sicking> smaug, why doesn't load/error allow evil nesting? You're still spinning the event loop when they fire
  197. # [19:30] <smaug> well, the loop is just about to end
  198. # [19:30] <sicking> but it hasn't happened yet
  199. # [19:30] <smaug> sure it causes recursion
  200. # [19:33] <smaug> I'd like to have some good sync api
  201. # [19:33] <smaug> but because of backwards compatibility that isn't possible
  202. # [19:33] <smaug> because that api shouldn't dispatch any events
  203. # [19:34] <sicking> why is "good sync" == "no events"?
  204. # [19:34] <sicking> "sync" doesn't relate to reentrancy. It's related to performing function before returning
  205. # [19:35] <smaug> easy to use
  206. # [19:35] <smaug> sync == "works like alert" :)
  207. # [19:35] <smaug> but that isn't possible
  208. # [19:35] <sicking> that's the first time i've heard that definition for sync :)
  209. # [19:36] <sicking> and does firing events make it harder to use?
  210. # [19:37] <sicking> basically i don't care too much either way. But i'm not understanding any of the arguments against firing the events so far
  211. # [19:37] <smaug> no, but it allows bad ways to use it, IMO
  212. # [19:37] <smaug> I don't care either
  213. # [19:37] <smaug> too much
  214. # [19:38] <sicking> but we're forced to allow bad ways of using it. so we'll still have to write the code such that it works
  215. # [19:38] <smaug> right
  216. # [19:38] <sicking> which i think we don't right now :)
  217. # [19:38] <smaug> I think we can handle pretty evil cases
  218. # [19:39] <smaug> anne: so about event loop; what is the problem if events are dispatched when running the loop?
  219. # [19:39] <smaug> I think that happens anyway
  220. # [19:40] <smaug> elsewhere
  221. # [19:48] <smaug> um, fun. playing with sync+readystatechange+alert breaks webkit
  222. # [19:49] <smaug> Opera dispatches readystatechange during send(), so a lot before 'load'
  223. # [19:52] <smaug> anne: does opera 10 implement progress events?
  224. # [19:54] <anne> no
  225. # [19:54] <anne> smaug, I don't think there's any problem; it will just be complex
  226. # [19:55] <anne> i have to run now
  227. # [19:56] * Parts: anne (annevk@213.236.208.22)
  228. # [20:13] * Joins: anne (annevk@85.196.122.246)
  229. # [20:14] <anne> be back in 120m or so; watching a movie
  230. # [20:14] * anne is really quite tired; worked >10h
  231. # [20:24] * tlr is now known as tlr-icann
  232. # [20:32] * Joins: shepazu (schepers@128.30.52.30)
  233. # [21:06] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  234. # [21:06] * Joins: shepazu (schepers@128.30.52.30)
  235. # [21:41] * Quits: chaals (chaals@89.130.83.193) (Quit: chaals)
  236. # [21:41] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  237. # [22:05] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC)
  238. # [22:33] * Quits: heycam (cam@210.84.15.128) (Quit: bye)
  239. # [23:25] * Joins: heycam (cam@130.194.72.84)
  240. # [23:42] * Joins: shepazu (schepers@128.30.52.30)
  241. # [23:47] * Quits: arve (arve@95.34.27.22) (Quit: Leaving)
  242. # [23:49] * Joins: arve (arve@95.34.27.22)
  243. # Session Close: Fri Feb 13 00:00:00 2009

The end :)