/irc-logs / w3c / #webapps / 2009-01-07 / end

Options:

  1. # Session Start: Wed Jan 07 00:00:00 2009
  2. # Session Ident: #webapps
  3. # [01:44] <Hixie> hm, no chairs
  4. # [01:44] <Hixie> shepazu: yt?
  5. # [01:45] <Hixie> shepazu: in case you see this, i had two topics i wanted to ask about:
  6. # [01:47] <Hixie> 1. DOM3 Events -- do you know what the timetable is for this? In particular, a number of things in HTML5 are blocking on mutation events, and we should communicate about whether DOM3 Events or HTML5 is the right place to solve the problem of events like 'load' that have somewhat magical behavior (they don't bubble but fire on multiple targets)
  7. # [01:48] <Hixie> 2. WebSockets -- it would make sense to extract this from html5 and put it into its own draft under the webapps wg. I'm about to split part of it into an RFC, and I'm not sure what to do with the remainder.
  8. # [02:43] * Quits: aroben (aroben@71.58.73.153) (Quit: Leaving)
  9. # [05:05] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  10. # [06:14] * Quits: anne (annevk@84.215.140.104) (Client exited)
  11. # [06:18] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
  12. # [06:21] <shepazu> Hixie: yt?
  13. # [07:00] * Joins: heycam (cam@210.84.43.231)
  14. # [07:35] <Hixie> shepazu: here now
  15. # [07:52] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: sex break)
  16. # [07:58] <shepazu> Hixie, D3E: I don't have a strict timetable, but I now have more time to spend on it, and will take a cue from implementer review what issues they think are outstanding and what they want changed, will resolve conflicts and propose solutions, and will address the general case for host language treatment of events
  17. # [07:58] <Hixie> cool
  18. # [07:58] <shepazu> as I recall, you didn't want me to address that last time I brought it up, though...
  19. # [07:59] <Hixie> oh?
  20. # [07:59] <shepazu> that was my impression
  21. # [07:59] <Hixie> well, shows what i know :-)
  22. # [08:01] <Hixie> btw, what's the plan for actually defining the requirements for things like mouse and key events, is that in dom3 events?
  23. # [08:02] <shepazu> Hixie: as in Use Cases and Requirements?
  24. # [08:03] <Hixie> as in, the text that says "when a user presses down on a key on the keyboard, the user agent must send a keydown event that..." or whatever
  25. # [08:03] <shepazu> I don't know that I was that systematic about it before, since I was picking up a spec that I thought was nearly done... but I see that we would benefit from having those well-defined beforehand
  26. # [08:03] <shepazu> oh, hmm
  27. # [08:03] <shepazu> oic
  28. # [08:04] <Hixie> would probably make sense to have that in a separate spec, but i'd imagine that e.g. for mouse events it would be the same spec that defines MouseEvent
  29. # [08:04] <shepazu> I think that it would be best to define that in the D3E spec, and then mention that a host language can override or repurpose them for that specific case
  30. # [08:04] <shepazu> how does that strike you?
  31. # [08:05] <shepazu> to me, it might clarify the context in which the event was "designed"
  32. # [08:05] <Hixie> seems independent of host language, since DOM3 Events presumably would work unchanged whether the Document object had any child nodes or not
  33. # [08:06] * Hixie doesn't really understand the concept of "host language" these days
  34. # [08:06] <Hixie> seems somewhat anachronistic
  35. # [08:06] <shepazu> well, I might be stretching the term a bit
  36. # [08:07] <shepazu> I use it to mean, another spec that reuses this spec as a sort of integrated module
  37. # [08:07] <shepazu> but I don't see that as an important point
  38. # [08:08] <shepazu> basically, I'd expect mouse events to function pretty much uniformly across SVG, HTML, MathML, etc.
  39. # [08:08] <Hixie> are we expecting dom3 events to be reused, rather than just implemented as is?
  40. # [08:09] <Hixie> reuse in that way sounds scary; i agree that we'd want it to behave uniformly everywhere
  41. # [08:09] <shepazu> but certain things, like the "load" event, have idiosyncratic behavior in HTML (eg)
  42. # [08:09] <shepazu> and thus HTML woudl define that behavior as a sort of extension to D3E
  43. # [08:09] <Hixie> well presumably we'd want that event to work the same regardless of what the root element happens to be
  44. # [08:10] <shepazu> that said, I'm not totally committed to that, it's just the way I had been thinking about it
  45. # [08:10] <Hixie> though that would mean defining the xml parser in a more useful way than currently, i guess
  46. # [08:10] * Hixie isn't sure what to do about the dependencies on an xml parser spec in html5
  47. # [08:10] <shepazu> hmmm... load works differently in HTML vs. SVG, iirc
  48. # [08:10] <Hixie> huh
  49. # [08:10] <Hixie> i thought SVG fired SVGLoad, not load
  50. # [08:11] <Hixie> if it's a 'load' event, how does a UA know how to fire it?
  51. # [08:11] <Hixie> maybe this should indeed be handled by the dom3 events spec somehow
  52. # [08:12] <Hixie> though really neither xhtml nor svg should be firing the 'load' event, that should just be fired by a generic "xml parsing for scripted uas" spec
  53. # [08:12] <shepazu> http://www.w3.org/TR/SVGTiny12/interact.html#LoadEvent
  54. # [08:12] <Hixie> hm
  55. # [08:12] <Hixie> is that defined anywhere?
  56. # [08:13] <Hixie> (or that description all there is?)
  57. # [08:13] <Hixie> s/or/or is/
  58. # [08:14] <shepazu> I think that's all
  59. # [08:15] <shepazu> what do you think is missing?
  60. # [08:17] <Hixie> well there are no requirements there, for one
  61. # [08:17] <Hixie> so nothing testable
  62. # [08:17] <Hixie> even if we pretend that the descriptive text is normative, it's also very vague, e.g.:
  63. # [08:17] <Hixie> what does "finishes loading the element" mean?
  64. # [08:17] <Hixie> what does "after" mean?
  65. # [08:18] <Hixie> is the event fired synchronously or asynchronously?
  66. # [08:18] <Hixie> what is the target of the event?
  67. # [08:19] <Hixie> what exactly are the dependent resources?
  68. # [08:19] <Hixie> does it trigger when the element is reinserted? some of the text suggests not, some suggests it is
  69. # [08:21] <shepazu> I understand that you prefer more precise wording, but I question whether that is strictly necessary for an implementer to create an interoperable implementation of the load event...
  70. # [08:21] <shepazu> I think some of the questions there are not a big deal, and a reasonable reading of the text would satisfy most developers
  71. # [08:22] <Hixie> well without violating the w3c process, how will svg 1.2 tiny get to CR if the spec isn't testable?
  72. # [08:22] <shepazu> that said, that text is very old and when we write SVG Core we will be more precise
  73. # [08:22] <Hixie> get past CR, i mean
  74. # [08:23] * Hixie apologises for being passive-aggressive
  75. # [08:24] <shepazu> I don't think we're headed in a productive direction, so let's save that discussion for another time
  76. # [08:24] <Hixie> anyway, html has taught us that if a technology gets widely deployed, this kind of detail will get locked down, de-facto if not de-jure, and if it's de-facto then it'll be mostly random
  77. # [08:24] <shepazu> wrt mutation events, I'm getting mixed signals from Mozilla and script library folks
  78. # [08:24] <Hixie> the mess that people complain about in html is basically all due to the people writing the specs in the past saying "I think some of the questions there are not a big deal, and a reasonable reading of the text would satisfy most developers"
  79. # [08:25] <Hixie> re mutation events; what are the options on the table?
  80. # [08:26] <shepazu> on the one hand, Moz has said they are fine with some of the mutation events staying as-is in the spec (which is what script librarians want), but they then say they won't implement them... I don't want to put features in D3E that Moz won't implement
  81. # [08:26] <Hixie> well that seems like an easy choice then
  82. # [08:26] <shepazu> Hixie, it's been a while, so why don't I review and summarize the issues, and send them to the webapps list?
  83. # [08:26] <Hixie> that might help, yeah
  84. # [08:27] <Hixie> to make progress on the html5 spec i don't really care what the mutation event spec says, i just need it to be precise so i know how to fiddle with the rules, basically
  85. # [08:27] <shepazu> understood
  86. # [08:27] <shepazu> what's your timetable
  87. # [08:27] <shepazu> ?
  88. # [08:27] <Hixie> there's some things where we want them to not fire at all and some where we want them to fire in particular ways, and right now i just don't know how to do it
  89. # [08:27] <Hixie> well, html5 is supposed to be locked down and done by october
  90. # [08:27] <shepazu> I can "finalize" parts of D3E in advance
  91. # [08:27] <Hixie> i expect to have most of this stuff done by end-of-q2
  92. # [08:28] <shepazu> ok, I can work with that
  93. # [08:28] <Hixie> cool
  94. # [08:28] <shepazu> I will aim to have the big issues solved (modulo LC review) in Q1
  95. # [08:28] <shepazu> or mid-q2
  96. # [08:28] <Hixie> okie dokie
  97. # [08:29] <Hixie> i never thought i'd see the day where html5's progress might be tied up waiting on a dependency on another spec :-P
  98. # [08:29] <shepazu> I will write up a summary of outstanding issues, and ask for review on the other parts
  99. # [08:29] <Hixie> cool
  100. # [08:29] <shepazu> I have no interest in holding up HTML5, I'll do my best
  101. # [08:30] <shepazu> wrt Websockets, aiui, some of that will be done by IETF, is that right?
  102. # [08:30] <shepazu> and what is "left over"?
  103. # [08:30] <Hixie> yeah the non-api parts are being shipped off to an ID
  104. # [08:30] <Hixie> the API basically
  105. # [08:30] <Hixie> idl block and related requirements
  106. # [08:31] <shepazu> will you be editor?
  107. # [08:32] <shepazu> or do you need someone else?
  108. # [08:32] <shepazu> I don't much care where it happens... I'm curious who would have a problem with it being done in either WebApps or HTML WG?
  109. # [08:33] <shepazu> most of the players are in both WGs
  110. # [08:33] <shepazu> I'm happy to have it added to WebApps, if that helps
  111. # [08:34] <shepazu> and I can put together a revised charter to that effect
  112. # [08:34] <Hixie> i can edit it, there won't be much to it
  113. # [08:34] <shepazu> ok
  114. # [08:34] <Hixie> i don't mind where it is, it just needs a home for patent protection
  115. # [08:35] <Hixie> i'm happy to continue assuming it's in the htmlwg charter, after all, it's already in the html5 spec at the moment
  116. # [08:35] <Hixie> but the last time i did that (Workers) the spec ended up being moved
  117. # [08:35] <Hixie> so i figured i'd just check first :-)
  118. # [08:36] <Hixie> any help would be greatly appreciated
  119. # [08:36] <Hixie> in all likelihood the spec will be done by the time the charter is approved, so if you need a timetable you can put FPWD, LC, and CR all within 3 months of each other
  120. # [08:36] <Hixie> as in, three months apart
  121. # [08:37] <shepazu> hmmm... looking at the charter, we have the Network API spec, already in scope (left over from removal from the SVG 1.2 spec)
  122. # [08:37] <shepazu> #
  123. # [08:37] <shepazu> Network Communication API (Network API)
  124. # [08:37] <shepazu> a socket interface to enable "push" content update
  125. # [08:37] <shepazu> would that suffice?
  126. # [08:37] <Hixie> close enough for me!
  127. # [08:37] * shepazu shakes on it
  128. # [08:37] <shepazu> well, that was easy!
  129. # [08:37] <Hixie> that's probably actually exactly what this was intended for -- i expect that came from the TCPConnection API in WHATWG
  130. # [08:38] <Hixie> which is what WebSocket came from
  131. # [08:38] <shepazu> no, I put that in there from the original requirement in the SVG 1.2 spec
  132. # [08:38] <Hixie> aah, cool
  133. # [08:38] <Hixie> well, this won't do quite the same as the networking stuff from svg
  134. # [08:38] <Hixie> that was raw sockets iirc
  135. # [08:38] <shepazu> we knew it needed doing, matter of convergence
  136. # [08:39] <Hixie> so there's no draft yet for this? i'm not stepping on anyone's editorship toes or anything?
  137. # [08:39] <Hixie> i've no desire to cause more trouble than necessary...
  138. # [08:39] <shepazu> actually, it was just loosely defined to take advantage of existing mechanisms in phones, mostly Java stuff... it was intended as a wrapper on native functionality
  139. # [08:40] <shepazu> Hixie: I will check on drafts and potential conflicts, but I will try to smooth any of that away and hand it over to you
  140. # [08:40] <Hixie> cool
  141. # [08:40] <shepazu> let's assume there won't be any problems that can't be solved
  142. # [08:40] <Hixie> let me know if/when i should mail anything to the list
  143. # [08:40] <shepazu> ok, I should know this week (hopefully tomorrow)
  144. # [08:40] <Hixie> my plan is to have the websocket text wrapped up by end-of-q1
  145. # [08:41] <shepazu> cool
  146. # [08:41] <Hixie> (and then just watch them painfully go through the ietf and w3c processes)
  147. # [08:59] <shepazu> ok, man, I will dig into the Network/WebSockets API stuff and let you know ASAP
  148. # [08:59] <Hixie> cool, thanks
  149. # [08:59] <shepazu> but now, I must lay the body down and let the weary bones rest... nn
  150. # [09:00] <Hixie> nn
  151. # [09:22] * Joins: anne (annevk@84.215.140.104)
  152. # [10:11] * Joins: arve (arve@213.236.208.22)
  153. # [10:39] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  154. # [11:00] * Joins: Lachy (Lachlan@213.236.208.22)
  155. # [11:50] * Joins: tlr (tlr@128.30.52.30)
  156. # [12:32] * Joins: ArtB (c0646811@128.30.52.43)
  157. # [13:16] * Quits: arve (arve@213.236.208.22) (Ping timeout)
  158. # [13:26] * Joins: arve (arve@213.236.208.247)
  159. # [13:26] * Joins: gorm (gormer@213.236.208.22)
  160. # [15:16] * Quits: arve (arve@213.236.208.247) (Quit: Leaving)
  161. # [15:17] * tlr is now known as tlr-bbiab
  162. # [15:24] * Parts: anne (annevk@84.215.140.104)
  163. # [15:33] * Joins: anne (annevk@84.215.140.104)
  164. # [15:55] * Parts: gorm (gormer@213.236.208.22)
  165. # [16:13] * tlr-bbiab is now known as tlr
  166. # [16:29] * Joins: aroben (aroben@71.58.73.153)
  167. # [17:02] * Joins: timeless (timeless@65.75.195.122)
  168. # [17:16] * Joins: arve (arve@80.202.82.48)
  169. # [18:10] * Disconnected
  170. # [18:10] * Attempting to rejoin channel #webapps
  171. # [18:10] * Rejoined channel #webapps
  172. # [18:10] * Topic is 'Web Applications WG (logged at http://krijnhoetmer.nl/irc-logs/)'
  173. # [18:10] * Set by ArtB on Thu Nov 06 14:06:04
  174. # [20:11] * Disconnected
  175. # [20:11] * Attempting to rejoin channel #webapps
  176. # [20:11] * Rejoined channel #webapps
  177. # [20:11] * Topic is 'Web Applications WG (logged at http://krijnhoetmer.nl/irc-logs/)'
  178. # [20:11] * Set by ArtB on Thu Nov 06 14:06:04
  179. # [22:11] * Disconnected
  180. # [22:11] * Attempting to rejoin channel #webapps
  181. # [22:11] * Rejoined channel #webapps
  182. # [22:11] * Topic is 'Web Applications WG (logged at http://krijnhoetmer.nl/irc-logs/)'
  183. # [22:11] * Set by ArtB on Thu Nov 06 14:06:04
  184. # [22:21] * Quits: smaug (chatzilla@82.181.141.13) (Ping timeout)
  185. # [22:25] * Joins: smaug (chatzilla@82.181.141.13)
  186. # [23:06] * Joins: Lachy (Lachlan@85.196.122.246)
  187. # [23:09] * Quits: anne (annevk@84.215.140.104) (Connection reset by peer)
  188. # [23:45] * Quits: gsnedders (gsnedders@86.136.52.180) (Quit: gsnedders)
  189. # [23:51] * Quits: heycam (cam@210.84.43.231) (Quit: bye)
  190. # [23:59] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  191. # Session Close: Thu Jan 08 00:00:00 2009

The end :)