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

Options:

  1. # Session Start: Tue Sep 22 00:00:00 2009
  2. # Session Ident: #webapps
  3. # [00:09] * Quits: heycam (cam@210.84.32.112) (Quit: bye)
  4. # [00:17] * Joins: taf2 (taf2@216.15.54.105)
  5. # [00:17] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
  6. # [00:23] * Quits: taf2 (taf2@216.15.54.105) (Quit: taf2)
  7. # [00:43] * Joins: taf2 (taf2@98.218.77.43)
  8. # [00:48] * Joins: heycam (cam@130.194.72.84)
  9. # [01:36] * Quits: taf2 (taf2@98.218.77.43) (Quit: taf2)
  10. # [02:14] * Joins: gsnedders (gsnedders@217.44.35.222)
  11. # [02:14] * Quits: gsnedders (gsnedders@217.44.35.222) (Client exited)
  12. # [02:28] * Joins: gsnedders (gsnedders@217.44.35.222)
  13. # [08:44] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
  14. # [09:11] * Joins: darobin (robin@62.213.145.151)
  15. # [09:31] * Joins: zalan (zalan@192.100.124.156)
  16. # [09:32] * Joins: heycam (cam@210.84.32.112)
  17. # [09:36] * Joins: tlr (tlr@128.30.52.169)
  18. # [09:39] * Joins: arve (arve@213.236.208.247)
  19. # [09:48] <heycam> shepazu, were load, error, abort, etc. UIEvents before?
  20. # [09:50] <shepazu> heycam: they all used UIEvent or Event before, yes... I didn't change the definitions, just the location in the spec
  21. # [09:51] <heycam> ok
  22. # [09:51] <heycam> i wouldn't have guessed that load would be a UIEvent
  23. # [09:51] <heycam> s/would/could/
  24. # [09:51] <heycam> when would that happen?
  25. # [09:53] <shepazu> not sure, actually...
  26. # [09:53] <shepazu> I could just as happily move it to Event interface
  27. # [09:53] <heycam> it would be good to define exactly when the view attribute is in use, for those that say "may be in use"
  28. # [09:54] <shepazu> they were in this weird non-interface category before
  29. # [09:54] <shepazu> yeah, I was trying to figure that out yesterday... what does that mean?
  30. # [09:55] <heycam> they weren't in the Basic Events category?
  31. # [09:55] <heycam> (which uses Event?)
  32. # [09:55] <heycam> s/category/module/, or whatever
  33. # [09:59] <shepazu> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.93&content-type=text/html;%20charset=iso-8859-1
  34. # [09:59] <shepazu> that's the version before I changed it
  35. # [10:00] <heycam> not sure what you mean by non-interface category
  36. # [10:00] <heycam> is it that "load" was in the Basic Events module, but sometimes used Event and other times UIEvent?
  37. # [10:01] <shepazu> look at the TOC
  38. # [10:02] <shepazu> all the other events were organized under their interface... the Basic Events module was just free-floating
  39. # [10:02] <shepazu> it offended my sense of architectural purity!
  40. # [10:03] <shepazu> also, all this "module" stuff seems to simply be overhead
  41. # [10:03] <heycam> you mean the Event interface wasn't defined in the 5.2.2 Basic Event Types?
  42. # [10:03] <heycam> (i can't see a TOC entry for the event interfaces in section 5)
  43. # [10:03] <shepazu> I'm trying to simplify the spec, reduce the number of extraneous concepts
  44. # [10:04] <heycam> sure
  45. # [10:04] <heycam> though note the module stuff implies feature string stuff
  46. # [10:04] <heycam> hasFeature("UIEvents", "3.0"), etc.
  47. # [10:04] <shepazu> no, Event interface is defined in 4. Basic Event Interfaces
  48. # [10:05] <heycam> shepazu, ok
  49. # [10:05] <shepazu> yeah, but we all know that's useless at that level of detail
  50. # [10:05] <heycam> though as i see it Event needs to be defined early on because other interfaces reference it
  51. # [10:05] <shepazu> I'm really tempted to define a feature string for each event type
  52. # [10:05] <heycam> (for ease of reading)
  53. # [10:05] <shepazu> yes
  54. # [10:06] <heycam> feature string for event type => canDispatch?
  55. # [10:06] <shepazu> I want to jettison canDispatch
  56. # [10:06] <shepazu> it's not implemented
  57. # [10:06] <heycam> yes i notice it is red
  58. # [10:06] <shepazu> whereas hasFeature is
  59. # [10:07] <heycam> just saying that feature strings for event types would be equivalent functionality to canDispatch
  60. # [10:07] <heycam> i assume
  61. # [10:07] <shepazu> right, same sort of thing... just as useless
  62. # [10:07] <shepazu> well... of limited use
  63. # [10:07] <heycam> heh
  64. # [10:07] <shepazu> it is somewhat useful
  65. # [10:08] <shepazu> but... well, lots of false positives and false negatives
  66. # [10:08] <heycam> anyway if you want to drop the concept of modules, go ahead :)
  67. # [10:08] <heycam> (underlying specs like DOM Core still use them... but...)
  68. # [10:09] <shepazu> I could simply say that each event interface is a module
  69. # [10:09] <shepazu> which includes all the events that use that interface
  70. # [10:09] <shepazu> easy to understand
  71. # [10:09] <heycam> except for "load" which uses either Event or UIEvent, i suppose :)
  72. # [10:10] <heycam> still i'm unsure about when load would use UIEvent
  73. # [10:10] <shepazu> a few of those, actually
  74. # [10:10] <heycam> that doesn't concord with the table in 5.1.1 anyway
  75. # [10:10] <heycam> which just says Event
  76. # [10:10] <shepazu> yeah
  77. # [10:11] <shepazu> I meant to change that, but first I want to figure out why some use both/either
  78. # [10:11] <heycam> yeah so if you can define exactly what it means for a context attribute to be "in use", that'd be good
  79. # [10:11] <heycam> i've always found that phrase to be a bit wishy washy
  80. # [10:11] <heycam> i'll review the spec on the plane on friday btw
  81. # [10:12] <heycam> oh, and some of the images' arrowheads have gone wonky
  82. # [10:13] * Joins: dom (dom@128.30.52.169)
  83. # [10:13] <shepazu> reload the page... the PNG has wonky arrowheads
  84. # [10:14] * dom wonders if anyone knows if marcos is around somewhere
  85. # [10:14] <shepazu> but the SVG is lovely
  86. # [10:14] <shepazu> hi, dom
  87. # [10:14] <shepazu> haven't seen him
  88. # [10:14] * dom didn't mean to interrupt :)
  89. # [10:14] <dom> ok, thx
  90. # [10:15] <shepazu> heycam: that UIEvent/Event thing seems to be something that Björn might have put into the spec
  91. # [10:15] <heycam> ah the arrowheads are in place now
  92. # [10:15] <shepazu> but I can't blame him for "is in use"
  93. # [10:15] <heycam> though... they look like shoe horns :)
  94. # [10:15] <heycam> right
  95. # [10:16] * Parts: dom (dom@128.30.52.169)
  96. # [10:16] <heycam> maybe in the definition for, e.g. UIEvent.view, it would say "If defined to be in use, has the value blah. Otherwise, has the value null."
  97. # [10:16] <shepazu> they are from the symbol for CONTAINS AS MEMBER
  98. # [10:16] <heycam> ah i see
  99. # [10:16] <heycam> and i meant horse shoe, not shoe horn =P
  100. # [10:16] <shepazu> I was being clever
  101. # [10:17] <shepazu> yeah, I wondered what kind of shoes aussies wear...
  102. # [10:17] <heycam> thongs of course
  103. # [10:17] <heycam> you know that
  104. # [10:17] <shepazu> ah, naturally!
  105. # [10:18] * shepazu wonders if aussie shoes ever ride up the crack of their toes...
  106. # [10:19] <shepazu> Björn made a good start at reorganizing the spec into some semblance of order... the W3C Note version is rubbish
  107. # [10:19] <shepazu> very poorly organized
  108. # [10:20] <heycam> and i like the style used for the event descriptions
  109. # [10:20] <heycam> with the gold
  110. # [10:20] <shepazu> http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html
  111. # [10:20] <shepazu> yes
  112. # [10:20] <shepazu> you're going to help me with the Web Idolizing, right?
  113. # [10:20] <heycam> yeah
  114. # [10:21] <heycam> bow down before me?
  115. # [10:21] <shepazu> erm...
  116. # [10:22] <shepazu> so, Garrett successfully drew attention away from your proposal to deprecate the interface-specific Init*Event methods
  117. # [10:22] <heycam> although it seems he did also suggest it
  118. # [10:22] <heycam> well, i didn't get a url out of him
  119. # [10:22] <shepazu> not really, actually
  120. # [10:22] <heycam> but i suppose he did
  121. # [10:22] <shepazu> his proposal was rather different
  122. # [10:23] <shepazu> same motivation, different mechanism
  123. # [10:23] <heycam> oh with the object literal syntax, yeah
  124. # [10:23] <shepazu> right
  125. # [10:23] <shepazu> and the diversion into discussion of feature detection... sigh
  126. # [10:24] * tlr is now known as tlr-packing
  127. # [10:24] <heycam> i don't really see the problem with making the attributes writable, and leaving the existing init methods in
  128. # [10:24] <heycam> existing content will continue to work
  129. # [10:25] <shepazu> so, maybe I simply need to make good on the threat of creating a generic event initializer and saying you can write to the attributes until you dispatch the event... then somebody will have to comment
  130. # [10:25] <heycam> new content can either use the init methods that are still there, or if they need to initialize a new attribute on an event, then by then the implementation will support writable attributes
  131. # [10:25] <shepazu> yup
  132. # [10:25] <heycam> why do we need a generic one?
  133. # [10:25] <heycam> instead of just assigning to attributes?
  134. # [10:27] <shepazu> sorry, I just meant use initEvent http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.94#events-event-type-initEvent
  135. # [10:27] <shepazu> it's late here
  136. # [10:28] <heycam> that's fine by me
  137. # [10:28] <shepazu> maybe I should just do that... say events attributes are writable until dispatch...
  138. # [10:28] <heycam> i reckon createEvent() should explain how it initializes the attributes on the object it creates
  139. # [10:29] <shepazu> oh, right!
  140. # [10:29] <shepazu> brain is fuzzy...
  141. # [10:29] <shepazu> yes, quite right
  142. # [10:30] <heycam> "NNBSP" in the keyboard diagram
  143. # [10:30] <heycam> or is that deliberate?
  144. # [10:33] <heycam> gtg out for dinner, later
  145. # [10:33] <shepazu> U+202F narrow no-break space
  146. # [10:33] <shepazu> later
  147. # [10:52] * Joins: arve_ (arve@213.236.208.22)
  148. # [10:53] * Quits: arve (arve@213.236.208.247) (Ping timeout)
  149. # [10:54] * Joins: arve (arve@213.236.208.247)
  150. # [10:55] * Quits: arve_ (arve@213.236.208.22) (Ping timeout)
  151. # [11:14] * Quits: zalan (zalan@192.100.124.156) (Ping timeout)
  152. # [11:16] * Joins: zalan (zalan@192.100.124.156)
  153. # [11:20] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  154. # [11:30] * Quits: tlr-packing (tlr@128.30.52.169) (Quit: tlr-packing)
  155. # [11:33] * Quits: zalan (zalan@192.100.124.156) (Ping timeout)
  156. # [11:33] * Joins: zalan (zalan@192.100.124.156)
  157. # [11:46] <darobin> dinner at 1030 in the morning? bloody australians
  158. # [11:48] * Joins: Lachy (Lachlan@213.236.208.22)
  159. # [11:54] * Quits: zalan (zalan@192.100.124.156) (Ping timeout)
  160. # [11:59] * Joins: Marcos (Marcos@41.215.38.99)
  161. # [12:41] * Joins: ArtB (d0309a43@128.30.52.43)
  162. # [12:47] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC)
  163. # [12:47] * Joins: ArtB (d0309a43@128.30.52.43)
  164. # [12:49] * ArtB changes topic to 'WebApps WG; this channel is logged at http://krijnhoetmer.nl/irc-logs/; Widget Test Workshop discussion in #widgets'
  165. # [12:52] * Quits: Marcos (Marcos@41.215.38.99) (Ping timeout)
  166. # [12:57] * Joins: Marcos (Marcos@41.215.38.99)
  167. # [13:20] <Marcos> arve, hows the new office?
  168. # [13:30] * Joins: zalan (zalan@192.100.124.156)
  169. # [13:34] * Quits: zalan (zalan@192.100.124.156) (Ping timeout)
  170. # [13:45] <arve> Marcos: I'm gonna have a chat to Lars Erik
  171. # [13:45] <arve> you can't fit two people and a sofa in here
  172. # [14:04] * Quits: arve (arve@213.236.208.247) (Quit: Ex-Chat)
  173. # [14:04] * Joins: arve (arve@213.236.208.247)
  174. # [14:21] * Quits: arve (arve@213.236.208.247) (Quit: Ex-Chat)
  175. # [14:21] * Joins: arve (arve@213.236.208.247)
  176. # [14:30] * Joins: arve_ (arve@213.236.208.22)
  177. # [14:32] * Quits: arve (arve@213.236.208.247) (Ping timeout)
  178. # [14:41] * Quits: arve_ (arve@213.236.208.22) (Quit: Ex-Chat)
  179. # [15:54] * Joins: arve (arve@212.251.175.125)
  180. # [16:44] * Joins: aroben (aroben@71.58.77.15)
  181. # [16:51] <arve> ArtB: can we get viewmodes on the agenda for next teleconf?
  182. # [17:19] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  183. # [17:22] * Quits: darobin (robin@62.213.145.151) (Ping timeout)
  184. # [17:23] <anne> shepazu, the Unicode scalar value is most definitely not a string in the form of U+xxx
  185. # [17:23] <anne> it's an elaborate word for Unicode character as defined by the Unicode spec
  186. # [17:23] <anne> i guess I should say so on the list
  187. # [17:24] <shepazu> ok, that's contrary to what I read, please provide a link
  188. # [17:24] <shepazu> but it doesn't matter, the point is the same
  189. # [17:32] * Joins: Lachy (Lachlan@85.196.122.246)
  190. # [17:32] * Quits: Lachy (Lachlan@85.196.122.246) (Client exited)
  191. # [17:32] * Joins: Lachy (Lachlan@85.196.122.246)
  192. # [17:39] <ArtB> arve, which VM spec? Media Features or the Interfaces?
  193. # [17:47] <arve> interfaces
  194. # [17:47] <arve> the bit that troubles me is rotation
  195. # [17:48] <arve> I'll write up the problems I see with it in a mail tomorrow (unless baby decides to arrive first, though)
  196. # [17:56] <ArtB> Arve, I'll add the VM-I spec
  197. # [19:33] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
  198. # [20:09] * Quits: Marcos (Marcos@41.215.38.99) (Ping timeout)
  199. # [20:24] * Joins: ArtB (c0646811@128.30.52.43)
  200. # [22:13] * Joins: taf2 (taf2@38.99.201.242)
  201. # [23:36] * Quits: taf2 (taf2@38.99.201.242) (Quit: taf2)
  202. # Session Close: Wed Sep 23 00:00:00 2009

The end :)