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

Options:

  1. # Session Start: Wed Mar 17 00:00:00 2010
  2. # Session Ident: #webapps
  3. # [00:00] <eiras> no. pointing device events, or mouse cursor are a different beast
  4. # [00:00] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  5. # [00:00] <eiras> this is specifically about controlling panning/scrolling
  6. # [00:00] <eiras> hich can be triggered in an unimaginable amount of ways
  7. # [00:01] <smaug> I'm happy to add beforescroll if I see some use case :)
  8. # [00:02] <smaug> some use case which explains *why* the page wants to prevent scrolling
  9. # [00:02] <eiras> I'll reply to the www-dom if you want to participate
  10. # [00:02] <smaug> I do read www-dom
  11. # [00:03] <eiras> but please don't mix input actions with ui events. I have enough headaches already explaning people here that those are very different :)
  12. # [00:03] <smaug> I guess you want beforescroll as input action
  13. # [00:03] <eiras> smaug: you mention *add*. To the wiki or are you one of the spec editors ?
  14. # [00:04] <smaug> shepazu is the editor
  15. # [00:04] <smaug> but I'm actively participating conference calls and other spec work
  16. # [00:05] <eiras> beforescroll as a UI Event. Whether the user agent can implement for virtually all possible use cases of scrolling is a user agent problem
  17. # [00:05] <eiras> regarding AIDE or whatever you want to call it, I have discussed with Chaals that same issue, and we might, in the future present a proposal of our own
  18. # [00:06] <smaug> that would be great
  19. # [00:06] <smaug> actually, could you explain what you mean with input action vs ui event
  20. # [00:06] <eiras> however, I disagree about differentiating between taps, pens, joysticks and whatever. Last thing we need is a device specific hell and fragmentation. The mouse events spec can be extended to support all use cases, with a clean and backward compatible way (I've been giving it lots of thought)
  21. # [00:07] <smaug> "input action event" isn't used commonly
  22. # [00:07] <eiras> input action is an event directly related to an input device -> keyboard, mouse or voice events for instance.
  23. # [00:07] <smaug> and ui event is ?
  24. # [00:08] <eiras> ui event is something that the user agent triggers in regards to specific input actions -> clipboard actions, scrolling, zooming, navigation, all the default actions of events, etc.
  25. # [00:08] <smaug> note, per DOM terminology for example a mouse event is a ui event
  26. # [00:08] <smaug> but I see what you mean
  27. # [00:08] <eiras> I hope I'm clear enough
  28. # [00:08] <smaug> need to just clarify the terminology
  29. # [00:09] <eiras> for instance, a 'copy' event can be triggered by doing Ctrl+C, Edit menu>Copy, right click>Copy, or document.execCommand('Copy'), etc...
  30. # [00:09] <eiras> yet copy is not the user input action by itself, but a deault action triggered by the user agent, in response to user interaction
  31. # [00:10] <eiras> if I refer to ui event, tat will most likely fall in the UIEvents section of dom 3 events
  32. # [00:10] <smaug> ok, what if you call those events ua events
  33. # [00:11] <smaug> since seems like you mean really events triggered by ua
  34. # [00:11] <smaug> and because using ui event in DOM Events context is misleading
  35. # [00:12] <eiras> think of UIEvents sectoin :)
  36. # [00:14] <smaug> by your definition mouse events aren't ui events
  37. # [00:14] <smaug> but per DOM Events they are ui events
  38. # [00:15] <eiras> there is only one occurence of "ui event" in this document http://www.w3.org/TR/DOM-Level-3-Events/
  39. # [00:16] <smaug> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html MouseEvent interface extends UIEvent
  40. # [00:16] <eiras> http://www.w3.org/TR/DOM-Level-3-Events/#events-uievents
  41. # [00:18] <smaug> DOM Events doesn't really have proper terminology to explain input action events and ui events
  42. # [00:18] <eiras> oh, magnify event ! woot :)
  43. # [00:18] <smaug> that is going away, maybe
  44. # [00:19] <eiras> well, we (Opera) need it :)
  45. # [00:19] <eiras> whether it's called magnify or zoom, I honestly don't have strong opinions, as long as the feature is there
  46. # [00:19] <eiras> zoom sounds more familiar though
  47. # [00:20] <smaug> I believe all agree that magnify is useful
  48. # [00:20] <smaug> but it doesn't necessarily need to go to DOM 3 Events
  49. # [00:20] <eiras> it is not useful if there is no way to query the current zoom level applied to the viewport
  50. # [00:20] <eiras> detail could have the *new* zoom level, which a window proeprty, like window.zoomLevel could have the current
  51. # [00:21] <eiras> which -> while
  52. # [00:21] <eiras> hum...
  53. # [00:21] <smaug> yeah
  54. # [00:21] <smaug> anyway, getting a bit late here
  55. # [00:21] <eiras> where are you at ?
  56. # [00:21] <smaug> Helsinki
  57. # [00:21] <smaug> are you in Oslo?
  58. # [00:21] <eiras> ye
  59. # [00:21] <eiras> yes
  60. # [00:22] <smaug> that is CET, Finland is EET
  61. # [00:22] <eiras> yeap, one hour later
  62. # [00:27] <eiras> smaug: but for your headaches, we need also something like a beforezoom or beforemagnify :) which cna be prevented. Again, maps come intoplay
  63. # [00:29] <smaug> if you have the usecases, could you post those to the mailing list
  64. # [00:29] <smaug> beforemagnify is probably easier to define than beforescroll
  65. # [00:31] <eiras> good night
  66. # [00:31] <eiras> god kveld as they say here
  67. # [01:11] * Joins: dydz (dydz@75.37.25.164)
  68. # [01:34] * Joins: sicking (chatzilla@63.245.220.240)
  69. # [01:46] * Quits: sicking (chatzilla@63.245.220.240) (Ping timeout)
  70. # [02:07] * Joins: sicking (chatzilla@63.245.220.240)
  71. # [02:26] * Quits: dydz (dydz@75.37.25.164) (Quit: dydz)
  72. # [02:40] * Joins: tlr (tlr@128.30.52.169)
  73. # [03:59] * Quits: sicking (chatzilla@63.245.220.240) (Ping timeout)
  74. # [04:00] * Joins: sicking (chatzilla@63.245.220.240)
  75. # [04:03] * Quits: sicking (chatzilla@63.245.220.240) (Ping timeout)
  76. # [04:25] * Quits: MikeSmithX (MikeSmith@114.48.199.9) (Ping timeout)
  77. # [04:35] * Joins: shepazu (schepers@128.30.52.169)
  78. # [05:18] * Joins: sicking (chatzilla@99.24.216.224)
  79. # [05:21] * Quits: sicking (chatzilla@99.24.216.224) (Ping timeout)
  80. # [05:35] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: Leaving)
  81. # [06:46] * Joins: dydz (dydz@75.37.25.164)
  82. # [07:33] * Joins: anne (annevk@83.227.7.248)
  83. # [07:56] * Quits: dydz (dydz@75.37.25.164) (Quit: dydz)
  84. # [07:57] * Quits: anne (annevk@83.227.7.248) (Client exited)
  85. # [07:57] * Joins: anne (annevk@83.227.7.248)
  86. # [08:30] * Quits: anne (annevk@83.227.7.248) (Ping timeout)
  87. # [08:31] * Joins: dydz (dydz@75.37.25.164)
  88. # [09:12] * Joins: anne (annevk@88.131.66.80)
  89. # [09:18] * Quits: dydz (dydz@75.37.25.164) (Quit: dydz)
  90. # [09:25] * Joins: darobin (robin@212.24.153.156)
  91. # [11:19] * Quits: shepazu (schepers@128.30.52.169) (Ping timeout)
  92. # [12:05] * Quits: darobin (robin@212.24.153.156) (Ping timeout)
  93. # [12:07] * Joins: ArtB (chatzilla@192.100.124.219)
  94. # [12:07] * Quits: tlr (tlr@128.30.52.169) (Client exited)
  95. # [12:59] * Joins: tlr_ (tlr@128.31.35.228)
  96. # [13:03] * Joins: tlr (tlr@128.30.52.169)
  97. # [13:37] * Joins: aroben (aroben@71.58.77.15)
  98. # [13:43] * Joins: darobin (robin@212.24.153.156)
  99. # [14:05] * Quits: tlr_ (tlr@128.31.35.228) (Ping timeout)
  100. # [14:21] * Quits: timeless_mbp (timeless@88.115.8.36) (Quit: Leaving.)
  101. # [14:22] * Joins: timeless_mbp (timeless@88.115.8.36)
  102. # [14:25] * Quits: anne (annevk@88.131.66.80) (Client exited)
  103. # [14:25] * Joins: anne (annevk@88.131.66.80)
  104. # [14:35] * Quits: ArtB (chatzilla@192.100.124.219) (Ping timeout)
  105. # [15:05] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  106. # [15:13] * Joins: ArtB (chatzilla@192.100.124.219)
  107. # [15:17] * Quits: darobin (robin@212.24.153.156) (Ping timeout)
  108. # [15:19] * Quits: anne (annevk@88.131.66.80) (Client exited)
  109. # [15:19] * Joins: anne (annevk@88.131.66.80)
  110. # [15:44] * Joins: dydz (dydz@76.199.100.248)
  111. # [15:49] * Joins: darobin (robin@212.24.153.156)
  112. # [15:59] * Joins: tlr (tlr@128.30.52.169)
  113. # [16:01] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  114. # [16:06] * ArtB is now known as ArtB_
  115. # [16:08] * Joins: tlr (tlr@128.30.52.169)
  116. # [16:09] * Quits: timeless_mbp (timeless@88.115.8.36) (Quit: Leaving.)
  117. # [17:03] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  118. # [17:11] * Joins: shepazu (schepers@128.30.52.169)
  119. # [17:17] * Quits: shepazu (schepers@128.30.52.169) (Quit: Core Breach)
  120. # [17:27] * Quits: dydz (dydz@76.199.100.248) (Quit: dydz)
  121. # [17:28] * Quits: darobin (robin@212.24.153.156) (Ping timeout)
  122. # [17:32] * ArtB_ is now known as ArtB
  123. # [17:47] * Quits: anne (annevk@88.131.66.80) (Client exited)
  124. # [17:47] * Joins: anne (annevk@88.131.66.80)
  125. # [18:09] * Joins: sicking (chatzilla@173.13.145.30)
  126. # [18:27] * Joins: tlr (tlr@128.30.52.169)
  127. # [18:46] * Quits: sicking (chatzilla@173.13.145.30) (Ping timeout)
  128. # [19:24] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  129. # [19:24] * Quits: anne (annevk@88.131.66.80) (Client exited)
  130. # [19:25] * Joins: anne (annevk@88.131.66.80)
  131. # [20:02] <smaug> Hixie: in websocket API, why the need to .wasClean? Couldn't error event be dispatched, and then close?
  132. # [20:03] <smaug> that way there isn't need for yet another event interface
  133. # [20:25] * Joins: tlr (tlr@128.30.52.169)
  134. # [20:25] * Quits: tlr (tlr@128.30.52.169) (Client exited)
  135. # [20:26] * Joins: tlr (tlr@128.30.52.169)
  136. # [20:26] * Quits: tlr (tlr@128.30.52.169) (Client exited)
  137. # [20:26] * Joins: tlr (tlr@128.30.52.169)
  138. # [20:32] * Joins: timeless_mbp (timeless@88.115.8.36)
  139. # [21:25] * Quits: ArtB (chatzilla@192.100.124.219) (Client exited)
  140. # [21:54] <smaug> Hixie: so which version of the web socket protocol is the "most valid"?
  141. # [21:54] <smaug> the one pointed by the Websocket API document
  142. # [21:54] <smaug> or the one located in whatwg.org?
  143. # [21:54] <smaug> I guess the latter one
  144. # [22:11] * Joins: sicking (chatzilla@63.245.220.240)
  145. # [22:19] * Joins: shepazu (schepers@128.30.52.169)
  146. # [22:23] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  147. # [22:35] * Quits: sicking (chatzilla@63.245.220.240) (Ping timeout)
  148. # [22:49] * Joins: MikeSmith (MikeSmith@208.54.95.254)
  149. # [22:51] <Hixie> smaug: that's what i had originally (error then close) but people complained that that made it unnecessarily hard to know whether to try to reconnect
  150. # [22:52] <Hixie> smaug: whatwg.org is the latest one
  151. # [22:52] <Hixie> smaug: personally i recommend the complete.html file since it has the api and the protocol all together in done doc with cross-references
  152. # [22:53] <smaug> Hixie: are there emails about the error and close in some mailing list?
  153. # [22:55] <Hixie> i don't recall if it was mailing list feedback or irc feedback
  154. # [22:58] <smaug> Hixie: why reconnecting is hard?
  155. # [22:58] <smaug> er, to know whether to reconnect
  156. # [22:59] <smaug> and how does wasClean help with that
  157. # [23:01] <Hixie> with wasClean you just do if (!event.wasClean) { reconnect() } else { doNormalShutdown(); }
  158. # [23:01] <Hixie> without it you have to set a flag in the error handler and check the flag in the close handler
  159. # [23:01] <Hixie> it's certainly not a big effort
  160. # [23:02] <Hixie> but it seems more than necessary, especially if the only reason to avoid it is to make implementation life easier
  161. # [23:02] <Hixie> the order of priorities goes: users > authors > implementors > spec writers
  162. # [23:02] <Hixie> so authors basically always get their way unless the pain on implementors is inordinate
  163. # [23:03] <smaug> without wasClean you reconnect in the error handler
  164. # [23:03] <Hixie> and the else?
  165. # [23:03] <smaug> ah, right
  166. # [23:03] <Hixie> anyway i'm not the one you should argue with -- i agree with you :-)
  167. # [23:04] <smaug> hmm
  168. # [23:05] <smaug> actually
  169. # [23:05] <smaug> shouldn't there just be a state for error
  170. # [23:05] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  171. # [23:05] <smaug> or couldn't there...
  172. # [23:06] <Hixie> moving the wasClean flag from a boolean on the onclose handler to a three-state flag on the WebSocket object? or adding a different readyState so that the progression can go either 0,1,2,3 or 0,1,2,4?
  173. # [23:07] <smaug> the latter one
  174. # [23:07] <Hixie> i guess we could do that. ask the list what they think? i'm doing some stuff for bz right now so i can't do the edit right now
  175. # [23:07] <smaug> ok
  176. # [23:08] <Hixie> (some people like readyState to progress without jumps, so it might be a bit controversial, i dunno)
  177. # [23:08] <Hixie> (it does make it different than other uses of readyState)
  178. # [23:09] <smaug> well, I assume that in simple cases people don't care about readyState
  179. # [23:09] <smaug> they just check that there is the close
  180. # [23:09] <smaug> same with error handler, it won't be used always
  181. # [23:36] <smaug> "The server specifies which origin it is willing to receive requests from by including a |Sec-WebSocket-Origin| field with that origin. If multiple origins are authorized, the server
  182. # [23:36] <smaug> echoes the value in the |Origin| field of the client's handshake."
  183. # [23:36] <smaug> I'm not quite sure what that tries to say
  184. # [23:37] <smaug> (could be just my bad English or 0:30am)
  185. # [23:39] <smaug> Hixie: how did you come up with the Sec-WebSocket-KeyX thing?
  186. # [23:40] <smaug> especially the part which allows dividing by 0
  187. # [23:41] <smaug> er
  188. # [23:41] <smaug> ah it is explained
  189. # [23:41] <smaug> still, this all sounds strange
  190. # [23:43] <Hixie> it's pretty crazy yeah
  191. # [23:43] <Hixie> it was hard to come up with something that's hard to screw up
  192. # [23:44] <Hixie> not sure what you don't understand about hte origin thing... can you elaborate?
  193. # [23:44] <Hixie> not sure which part to explain :-)
  194. # [23:44] <Hixie> it's just saying that if you have a simple script that just expects to talk to pages hosted from one page, it can just hard-code the Sec-WebSocket-Origin response field
  195. # [23:45] <Hixie> but if it's a more complicated script that talks to many sites on the web, it'll need to look at the Origin field from the client first
  196. # [23:45] <Hixie> and then only echo the one that the client sent
  197. # [23:45] <smaug> Hixie: the multiple origins part
  198. # [23:47] <smaug> Hixie: so client sends Origin: and server sends back Sec-WebSocket-Origin:
  199. # [23:47] <smaug> and in some cases Origin:
  200. # [23:48] <smaug> which is the same as what client sent to server?
  201. # [23:49] <Hixie> the server always sends back Sec-WebSocket-Origin
  202. # [23:49] <Hixie> and its value is either hard-coded, or derived from the client's Origin:
  203. # [23:49] <smaug> why is Sec-WebSocket-Origin needed?
  204. # [23:49] <Hixie> to make sure you can't talk to a server who doesn't want to talk to you
  205. # [23:50] <Hixie> (and so that the client is the one doing the check, not the server)
  206. # [23:50] <Hixie> (since we don't trust the server to get things right)
  207. # [23:50] <smaug> well, if also server sends Origin
  208. # [23:50] <Hixie> server never sends Origin
  209. # [23:51] <Hixie> Origin: is the field that describes the client's origin
  210. # [23:51] <smaug> oh, ok
  211. # [23:51] <smaug> my bad
  212. # [23:51] <smaug> misread
  213. # [23:51] <smaug> thanks
  214. # [23:51] <Hixie> np
  215. # [23:52] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
  216. # [23:52] <smaug> still, the protocol is getting far from being trivial to implement
  217. # [23:53] <Hixie> it's still pretty simple on the server. the client isn't trivial, certainly.
  218. # [23:54] <Hixie> the latest changes added about 50% extra complexity to the server based on my attempts to implement a perl one
  219. # [23:54] <Hixie> it was 99 lines, it's now about 150
  220. # [23:54] <smaug> Hixie: "; the wire protocol including error-handling and forward-compatible parsing rules" doesn't seem to contain closing frame
  221. # [23:54] * Hixie looks
  222. # [23:54] <Hixie> closing-frame is part of binary-frame in that version
  223. # [23:55] <smaug> ah, right
  224. # [23:55] <smaug> again, hard to read
  225. # [23:55] <smaug> I wonder how the protocol can be really used in isp webservers
  226. # [23:56] <Hixie> the recent changes got rid of all the binary blobs and stuff that people complained about, so hopefully it's a little easier now
  227. # [23:56] <smaug> I doubt I can reserve any ports for my use
  228. # [23:56] <Hixie> you mean web hosting providers?
  229. # [23:56] <smaug> yeah
  230. # [23:56] <Hixie> dreamhost allow me to run arbitrary scripts that open any port above 1024
  231. # [23:56] <Hixie> dunno about others
  232. # [23:56] <smaug> interesting
  233. # [23:56] <smaug> surprising
  234. # [23:57] <Hixie> if you can run arbitrary code on unix, it's pretty hard to stop it, as i understand it
  235. # [23:57] <Hixie> short of a firewall
  236. # [23:57] <Hixie> dunno how common that is
  237. # [23:58] <smaug> Hixie: still another thing, which was mentioned in hybi list
  238. # [23:58] <smaug> the need for bigint
  239. # [23:59] <smaug> do we really need to be able to handle huge binary frames?
  240. # [23:59] <Hixie> you can just bail if you get a length that's too big
  241. # [23:59] <Hixie> i don't see why people would send long lengths today
  242. # [23:59] <Hixie> but when everyone is using 256 bit chips and petabit ethernet to the house, i don't see why we'd want to rev the entire protocol
  243. # Session Close: Thu Mar 18 00:00:00 2010

The end :)