/irc-logs / freenode / #whatwg / 2008-09-24 / end

Options:

  1. # Session Start: Wed Sep 24 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:02] * Quits: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com) (Read error: 110 (Connection timed out))
  4. # [00:03] <gavin__> Hixie: I think you missed the "rather than" in front of "anonymous"
  5. # [00:03] * gavin__ is now known as gavin
  6. # [00:06] <Hixie> ah, yes, good call
  7. # [00:06] <Hixie> ok then i'll complain that "not enough time for research" is ridiculous given that we do more research and have more time in our timetable than any w3c project to date
  8. # [00:09] * Quits: heycam` (n=cam@203-217-71-234.dyn.iinet.net.au) (Read error: 104 (Connection reset by peer))
  9. # [00:13] * Quits: csarven (n=csarven@80.76.201.52) (Remote closed the connection)
  10. # [00:14] * Quits: eric_carlson (n=ericc@17.244.18.204)
  11. # [00:28] * Quits: eseidel (n=eseidel@72.14.224.1)
  12. # [00:33] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  13. # [00:34] * Joins: eseidel (n=eseidel@adsl-76-202-58-169.dsl.pltn13.sbcglobal.net)
  14. # [00:35] * Quits: eseidel (n=eseidel@adsl-76-202-58-169.dsl.pltn13.sbcglobal.net) (Client Quit)
  15. # [00:35] * Joins: eseidel (n=eseidel@72.14.224.1)
  16. # [00:36] * Quits: malde_ (n=chatzill@cpe-075-176-017-240.carolina.res.rr.com) (Read error: 110 (Connection timed out))
  17. # [00:42] * Quits: Lachy (n=Lachlan@101.329.dsl.syd.iprimus.net.au) ("This computer has gone to sleep")
  18. # [01:07] * Joins: webben (n=benh@91.84.255.169)
  19. # [01:12] * Quits: nessy (n=nessy@124-168-137-162.dyn.iinet.net.au) ("This computer has gone to sleep")
  20. # [01:33] * Quits: dglazkov (n=dglazkov@nat/google/x-6e93933a31c11122)
  21. # [01:40] * Quits: webben (n=benh@91.84.255.169)
  22. # [01:50] * Quits: eseidel (n=eseidel@72.14.224.1)
  23. # [01:50] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  24. # [02:11] * Joins: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  25. # [02:31] * Quits: fishd (n=Darin@nat/google/x-ce535fad3107910b) ("Leaving")
  26. # [02:35] * Joins: eseidel (n=eseidel@c-24-130-13-197.hsd1.ca.comcast.net)
  27. # [02:40] * Quits: weinig (n=weinig@nat/apple/x-f8eccaf4d2eea562)
  28. # [02:43] * Joins: fishd (n=Darin@nat/google/x-dd263e871de9cdf7)
  29. # [02:49] <Hixie> well crap
  30. # [02:49] <Hixie> html5 doesn't have anything that's comma-separated
  31. # [02:49] <Hixie> so making accept= comma separated is way more work than it should be
  32. # [02:52] * Quits: billmason (n=billmaso@ip75.unival.com) (".")
  33. # [02:54] * Joins: malde_ (n=chatzill@cpe-075-176-017-240.carolina.res.rr.com)
  34. # [03:15] * Quits: malde_ (n=chatzill@cpe-075-176-017-240.carolina.res.rr.com) (Read error: 110 (Connection timed out))
  35. # [03:18] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
  36. # [03:21] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  37. # [03:25] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  38. # [03:30] * Joins: nessy (n=nessy@124-168-137-162.dyn.iinet.net.au)
  39. # [03:30] * Quits: roc (n=roc@202.0.36.64)
  40. # [03:37] <Dashiva> Hixie: But once you have comma support there's room for input @type=email-list :D
  41. # [03:38] <Hixie> -_-
  42. # [03:39] <Dashiva> awh, don't give me that face
  43. # [03:40] * Joins: tndH (n=Rob@james-baillie-pc083-137.student-halls.leeds.ac.uk)
  44. # [03:51] <Hixie> wow
  45. # [03:52] <Hixie> rfc2045 doesn't actually define anything that matches type "/" subtype
  46. # [03:59] * Joins: kangax (n=kangax@ool-182f8118.dyn.optonline.net)
  47. # [04:20] * Joins: MikeSmith (n=MikeSmit@r125-63-184-214.cpe.unwired.net.au)
  48. # [04:25] * Quits: MikeSmith (n=MikeSmit@r125-63-184-214.cpe.unwired.net.au) ("Less talk, more pimp walk.")
  49. # [04:32] * Joins: MikeSmith (n=MikeSmit@r125-63-184-214.cpe.unwired.net.au)
  50. # [04:33] * Quits: MikeSmith (n=MikeSmit@r125-63-184-214.cpe.unwired.net.au) (Client Quit)
  51. # [04:34] * Joins: MikeSmith (n=MikeSmit@r125-63-184-214.cpe.unwired.net.au)
  52. # [04:35] * Quits: MikeSmith (n=MikeSmit@r125-63-184-214.cpe.unwired.net.au) (Client Quit)
  53. # [04:36] * Joins: MikeSmith (n=MikeSmit@r125-63-184-214.cpe.unwired.net.au)
  54. # [04:38] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  55. # [04:48] * Joins: fishd_ (n=Darin@nat/google/x-883b55b156645692)
  56. # [04:48] * Quits: kangax (n=kangax@ool-182f8118.dyn.optonline.net)
  57. # [04:53] <MikeSmith> wakaba: you there?
  58. # [04:54] <MikeSmith> wanted to ask about you conformance-checker implementation
  59. # [05:03] * Quits: fishd (n=Darin@nat/google/x-dd263e871de9cdf7) (Read error: 110 (Connection timed out))
  60. # [05:05] * Joins: dglazkov (n=dglazkov@72.14.224.1)
  61. # [05:06] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  62. # [05:10] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  63. # [05:15] * Joins: Thezilch (n=fuz007@cpe-76-171-111-7.socal.res.rr.com)
  64. # [05:24] <MikeSmith> http://blog.mozilla.com/blassey/2008/09/23/camera-input-tag/
  65. # [05:33] * Quits: hdh (n=hdh@118.71.126.252) (Remote closed the connection)
  66. # [05:37] * Quits: dglazkov (n=dglazkov@72.14.224.1)
  67. # [05:38] * Quits: jgraham (n=jgraham@web22.webfaction.com) (Read error: 60 (Operation timed out))
  68. # [05:50] * Joins: eric_carlson_ (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  69. # [05:57] * Quits: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Read error: 110 (Connection timed out))
  70. # [06:06] <MikeSmith> Hixie: you there?
  71. # [06:06] <Hixie> yo
  72. # [06:07] <MikeSmith> hey man. Wanted to ask if I might be able to steal your demos from your presentation earlier this week
  73. # [06:10] <Hixie> yeah, totally
  74. # [06:10] <Hixie> you asked earlier and i said yes already in fact :-)
  75. # [06:11] <MikeSmith> Hixie: sorry, I guess I missed your Yes. I got a crap network connection here
  76. # [06:11] <MikeSmith> Hixie: you got a URL?
  77. # [06:12] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  78. # [06:13] <Hixie> whatwg.org/demos/
  79. # [06:13] <Hixie> link near the bottom
  80. # [06:14] <MikeSmith> OK
  81. # [06:14] <MikeSmith> thanks
  82. # [06:19] * Joins: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  83. # [06:20] * Quits: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  84. # [06:25] * Joins: roc (n=roc@202.20.0.134)
  85. # [06:26] * Quits: eric_carlson_ (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Remote closed the connection)
  86. # [06:39] * Joins: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  87. # [06:44] * Quits: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  88. # [07:08] * Joins: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  89. # [07:13] * Quits: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  90. # [07:36] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  91. # [07:36] * Quits: roc (n=roc@202.20.0.134)
  92. # [07:37] * Joins: roc (n=roc@202.20.0.134)
  93. # [07:40] * Quits: roc (n=roc@202.20.0.134) (Client Quit)
  94. # [07:45] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  95. # [07:48] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  96. # [08:08] * Joins: Maurice` (i=copyman@cc90688-a.emmen1.dr.home.nl)
  97. # [08:08] * Quits: MikeSmith (n=MikeSmit@r125-63-184-214.cpe.unwired.net.au) ("Less talk, more pimp walk.")
  98. # [08:23] * Quits: Thezilch (n=fuz007@cpe-76-171-111-7.socal.res.rr.com) (Client Quit)
  99. # [08:28] * Quits: fishd_ (n=Darin@nat/google/x-883b55b156645692) ("Leaving")
  100. # [08:37] * Joins: BenMillard (n=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  101. # [09:03] <Hixie> aw, still no tag minutes
  102. # [09:08] * Parts: BenMillard (n=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  103. # [09:29] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  104. # [09:36] * Joins: jgraham (n=jgraham@web22.webfaction.com)
  105. # [09:49] * Quits: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  106. # [09:57] * Joins: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  107. # [09:58] * Quits: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net) (Client Quit)
  108. # [09:59] * Joins: Lachy (n=Lachlan@sydney.marquehotels.com.au)
  109. # [10:11] * Joins: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  110. # [10:19] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  111. # [10:22] * Joins: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  112. # [10:25] * Quits: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  113. # [10:25] * Joins: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  114. # [10:28] <hsivonen> no XHTML2 minutes, either
  115. # [10:34] * Joins: zcorpan_ (n=zcorpan@pat.se.opera.com)
  116. # [10:35] * Quits: eseidel (n=eseidel@c-24-130-13-197.hsd1.ca.comcast.net)
  117. # [10:42] * Quits: tndH (n=Rob@james-baillie-pc083-137.student-halls.leeds.ac.uk) (Remote closed the connection)
  118. # [10:51] <zcorpan_> i just marked all new (since yesterday) emails on public-html as read
  119. # [10:51] <zcorpan_> hope i didn't miss something interesting
  120. # [10:52] <hsivonen> I just learned that I'm not getting email due to an electricity outage
  121. # [10:57] * Joins: ROBOd (n=robod@89.122.216.38)
  122. # [11:00] * Quits: Lachy (n=Lachlan@sydney.marquehotels.com.au) ("Leaving")
  123. # [11:00] * Joins: webben (n=benh@nat/yahoo/x-ba663575241ff849)
  124. # [11:11] * Joins: webben_ (n=benh@nat/yahoo/x-d2ce97cce944f608)
  125. # [11:15] * Joins: Thezilch (n=fuz007@cpe-76-171-111-7.socal.res.rr.com)
  126. # [11:17] * Quits: webben (n=benh@nat/yahoo/x-ba663575241ff849) (Read error: 110 (Connection timed out))
  127. # [11:22] * Joins: glazou (n=daniel@zeus.disruptive-innovations.fr)
  128. # [11:22] <glazou> hell
  129. # [11:22] <glazou> o
  130. # [11:23] <glazou> I have a question related to html5 drag and drop, section 6.8.4.2
  131. # [11:23] * Quits: webben_ (n=benh@nat/yahoo/x-d2ce97cce944f608)
  132. # [11:24] * Joins: eseidel (n=eseidel@c-24-130-13-197.hsd1.ca.comcast.net)
  133. # [11:25] <glazou> how can the drag source know the draganddrop succeeded but on the desktop ?
  134. # [11:26] <glazou> I want my script, from onDrop on the source, to perform a special operation in that case
  135. # [11:29] * Quits: mal (n=mal@nat/google/x-ffd139d9cf8dfbce) ("Nettalk6 - www.ntalk.de")
  136. # [11:32] * Parts: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  137. # [11:39] <annevk2> funny, 3 out of 5 WHATWG demos are obsolete per latest thinking
  138. # [11:41] * Quits: eseidel (n=eseidel@c-24-130-13-197.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  139. # [11:42] <glazou> hi annevk2
  140. # [11:42] <hsivonen> glazou: bonjour. nice to see you here
  141. # [11:42] <glazou> hi henri
  142. # [11:42] <glazou> I'm playing with html5 d&d and find a few issues in a multi-app environmet
  143. # [11:43] <glazou> environment even
  144. # [11:43] <glazou> I think i'll send it to the mailing-list
  145. # [11:45] <annevk2> bonjour, dunno much about d&d
  146. # [11:45] <hsivonen> d&d isn't my area, either
  147. # [11:45] <annevk2> there is this demo though: http://www.whatwg.org/demos/2008-sept/dnd/dnd.html
  148. # [11:46] <glazou> looking
  149. # [11:48] <glazou> yeah does not help me
  150. # [11:48] * glazou writes an email to the list
  151. # [12:08] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  152. # [12:09] <glazou> sent
  153. # [12:09] <glazou> hey tantek was here and I did not see hm :-(
  154. # [12:09] <annevk2> he's mostly lurking
  155. # [12:13] * Quits: Thezilch (n=fuz007@cpe-76-171-111-7.socal.res.rr.com) (Read error: 110 (Connection timed out))
  156. # [12:15] <Hixie> oh hey, i should have checked irc before my e-mail
  157. # [12:16] <Hixie> glazou: just replied to your message
  158. # [12:16] <glazou> thanks Hixie
  159. # [12:17] <glazou> Hixie, you can't use mouse events...
  160. # [12:17] <glazou> you're outside of the window !
  161. # [12:17] <glazou> you don't even get the evens
  162. # [12:17] <glazou> events
  163. # [12:17] <Hixie> right, hence the capture API
  164. # [12:17] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
  165. # [12:17] <glazou> exactly but it's not here yet
  166. # [12:17] <Hixie> (the idea is the (new) method would make it so all mouse events until the button is released would go to the element you pick, instead of the real target)
  167. # [12:17] <Hixie> correct, there's no real solution for this today
  168. # [12:18] <Hixie> even with that API, you still couldn't position or scale the window, so you couldn't do, e.g., what chrome or safari do with dragging of tabs
  169. # [12:18] <glazou> sigh
  170. # [12:18] <glazou> yep
  171. # [12:18] * glazou is missing this right now in FF
  172. # [12:18] <Hixie> that's probably more something for css animation and css transform though
  173. # [12:19] <Hixie> at least the scaling and animation aspects
  174. # [12:19] <glazou> I guess the "detach sidebar item" menuitem is all I can do for the time being :-(
  175. # [12:19] <Hixie> the window positioning, i don't know
  176. # [12:19] <Hixie> part of the problem is that we're somewhat moving away from letting web authors control windows
  177. # [12:19] <Hixie> e.g. i see what chrome does with window.open() to be the way forward for window.open()
  178. # [12:19] <Hixie> which is in-tab
  179. # [12:20] <Hixie> i'd expect things like docking, snapping, and dragging of ui elements to be a ua-level feature rather than webapp-level
  180. # [12:21] <glazou> Hixie: never heard of Prism or Adobe Air ? web-apps are ua-level these days...
  181. # [12:21] <Hixie> even with prism (or apps generated by <bb type=makeapp> in html5) the apps are still webapps, so they're still sandboxed
  182. # [12:22] <Hixie> adobe air apps are privileged, so they're not subject to the limitations (and they're as dangerous as native apps)
  183. # [12:28] * Joins: aboodman (n=aboodman@165.Red-80-33-158.staticIP.rima-tde.net)
  184. # [12:29] * glazou is now known as glazou_lunch
  185. # [12:35] <othermaciej> I don't think we'd want to give Safari standalone web apps any special privs
  186. # [12:48] <Hixie> it's quite amusing how much of wf2 is written defensively. it's almost like a manifesto in places rather than a spec.
  187. # [12:49] <othermaciej> yet another way in which it is too reactive against XForms
  188. # [12:49] <Hixie> yeah
  189. # [13:06] * Joins: heycam (n=cam@203-217-88-112.dyn.iinet.net.au)
  190. # [13:07] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  191. # [13:13] * Joins: roc (n=roc@202.20.0.134)
  192. # [13:14] * glazou_lunch is now known as glazou
  193. # [13:20] <annevk2> Karl is leaving the W3C: http://twitter.com/karlw3c/statuses/932668509
  194. # [13:20] <glazou> yep
  195. # [13:20] <glazou> Hixie: you've seen <input type="camera"> ?
  196. # [13:21] <annevk2> he's changing it in <input type=file accept=image/png>, no?
  197. # [13:21] <annevk2> or some such
  198. # [13:21] <Hixie> glazou: i haven't; uri?
  199. # [13:21] <annevk2> mikesmith posted it earlier
  200. # [13:21] <glazou> http://blog.mozilla.com/blassey/2008/09/23/camera-input-tag/
  201. # [13:22] <glazou> very ineresting
  202. # [13:22] <glazou> see also my blog for my comments
  203. # [13:22] <glazou> annevk2: hmm seems a bad change to me
  204. # [13:23] <Hixie> ah, yeah
  205. # [13:23] <annevk2> wasn't sure about it either
  206. # [13:23] <Hixie> this is an area that needs some serious infrastructure work
  207. # [13:23] <hsivonen> glazou: so if I don't have a webcam, how do I connect a jpg file to type=camera?
  208. # [13:23] <Hixie> because what we really need is a way to get stream objects
  209. # [13:23] <Hixie> so we can send video streams
  210. # [13:23] <Hixie> forms aren't really suitable for that
  211. # [13:24] <hsivonen> (actually, all my Internet devices have a camera, but I run my MacBook with lid closed and Cinema Displays don't have cameras for some reason)
  212. # [13:24] <Hixie> probably an area for WebSocket, too
  213. # [13:24] <Hixie> and the blob apis, whenever we get around to those
  214. # [13:25] <hsivonen> given the security considerations, <input type=file> makes sense
  215. # [13:25] <hsivonen> if the text field is zapped
  216. # [13:25] <hsivonen> and there's UI for both browsing the file system and activating a camera
  217. # [13:25] * Quits: aboodman (n=aboodman@165.Red-80-33-158.staticIP.rima-tde.net) (Read error: 110 (Connection timed out))
  218. # [13:27] <Hixie> woah, runaway error on the validator
  219. # [13:27] * Hixie gets thousands of errors
  220. # [13:28] <glazou> hsivonen: if you don't have a webcam the input element shows "no webcam"
  221. # [13:29] <glazou> " UI for both browsing the file system and activating a camera" is faaaaar beyond an average user's knowledge
  222. # [13:29] <Hixie> hsivonen, aha, originally the error here was <span title="foo</span> instead of <span title="foo">foo</span>
  223. # [13:29] * Joins: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  224. # [13:30] <hsivonen> glazou: how is it beyond user's knowledge to have something like:
  225. # [13:30] <hsivonen> Upload photo: [Use Camera] [Choose file]
  226. # [13:30] <hsivonen> ?
  227. # [13:30] <glazou> that should be author's decision
  228. # [13:31] <hsivonen> [Use Camera] [Choose file] is browser-managed
  229. # [13:31] <glazou> if the web page is made for cameras only for instance
  230. # [13:31] <hsivonen> glazou: why author decisions instead of user decision?
  231. # [13:31] <glazou> author's decision overridable by user
  232. # [13:32] <glazou> hsivonen: when a web site gives you a wysiwyg editable area, do you need to override author's decision to show a textarea for source code ?
  233. # [13:32] <Hixie> so did karl decide to move on like dino?
  234. # [13:33] <glazou> Hixie: I started pondering about it long ago
  235. # [13:33] <glazou> and w3c has a few financial issues these days
  236. # [13:33] <glazou> seemed the right time to move on I guess
  237. # [13:34] <othermaciej> I think we'd probably let <input type="file" accept="image"> have a camera option
  238. # [13:34] <glazou> d'oh firefox does not set screenX/screenY on ondragend
  239. # [13:34] <othermaciej> but that might not be as nice as an in-page preview
  240. # [13:34] <hsivonen> glazou: camera is more hardware and user situation dependent
  241. # [13:34] * Quits: roc (n=roc@202.20.0.134)
  242. # [13:34] <glazou> othermaciej, hsivonen: my only goal here is the following one : get rid of the dozens of flash-based widgets that do only webcam capture
  243. # [13:35] <glazou> and "please attach a portrait" with file upload
  244. # [13:35] <hsivonen> glazou: shouldn't the camera input degrade to file upload in old UAs, though?
  245. # [13:36] <glazou> yep
  246. # [13:36] <glazou> hsivonen: but that's a camera or input ; you suggested above camera and input
  247. # [13:36] <hsivonen> that argues for type=file plus something in another attribute
  248. # [13:36] <othermaciej> glazou: I like replacing things that Flash does
  249. # [13:36] <glazou> not necessarily
  250. # [13:36] <glazou> othermaciej: eheh :)
  251. # [13:36] <othermaciej> is it important for picture taking UI to be direct in the browser window?
  252. # [13:36] <othermaciej> the preview at least?
  253. # [13:36] <glazou> yes
  254. # [13:36] <glazou> it's a webapp
  255. # [13:36] <glazou> standalone
  256. # [13:37] <othermaciej> the dialog on <input type="file"> is an important security feature in a way
  257. # [13:37] <othermaciej> since it prevents Web Apps from tricking you into uploading a file
  258. # [13:37] <hsivonen> glazou: why can't the browser put up a preview dialog/sheet?
  259. # [13:37] <glazou> well the browser should always ask "do you want to let this web page use your webcam ?"
  260. # [13:37] <othermaciej> a preview where you click a separate button to upload with no dialog could have security issues
  261. # [13:37] <glazou> hsivonen: because dialogs are bad
  262. # [13:37] <hsivonen> glazou: that seems like the wrong way. rather, I'd want the capture to be user action initiated
  263. # [13:37] <othermaciej> security alerts are bad, especially when divorced from the task
  264. # [13:38] <hsivonen> like the Browse button on file upload today
  265. # [13:38] <glazou> hsivonen: I can live with that too
  266. # [13:38] * glazou has a meeting at the French Senate and must run
  267. # [13:38] <glazou> bye people
  268. # [13:38] <hsivonen> bye
  269. # [13:38] * Quits: glazou (n=daniel@zeus.disruptive-innovations.fr) ("meeting in town")
  270. # [13:42] <Hixie> i should go too
  271. # [13:43] <Hixie> i have a meeting with my bed.
  272. # [13:43] <Hixie> nn
  273. # [13:43] <hsivonen> nn
  274. # [13:49] * Quits: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  275. # [14:05] * Parts: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  276. # [14:15] <annevk2> you could have an overlay the moment you hit "use webcam"
  277. # [14:15] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  278. # [14:15] <annevk2> just like you get an overlay for <input type=date>
  279. # [14:20] * Quits: starjive (i=beos@213-66-217-32-no30.tbcn.telia.com)
  280. # [14:21] * Joins: virtuelv (n=virtuelv@213.236.208.247)
  281. # [14:37] <zcorpan_> i wonder if i need something more generic for HIERARCHY_REQUEST_ERR checking
  282. # [14:38] <zcorpan_> than listing all conditions for all methods when it should throw
  283. # [14:39] <zcorpan_> maybe i should say "this is a legal tree" and "if running this algorithm would result an illegal tree, raise exception"
  284. # [14:41] <annevk2> how do you get a node from a cross origin document?
  285. # [14:41] <annevk2> re: adoptNode
  286. # [14:46] * Quits: annevk2 (n=annevk@pat-tdc.opera.com) (Read error: 104 (Connection reset by peer))
  287. # [14:47] * Philip` sees that Gandi's hosting will cost double what the beta did, and wonders if that affects hsivonen's preferences much
  288. # [14:47] * Joins: annevk2 (n=annevk@pat-tdc.opera.com)
  289. # [14:48] <annevk2> something made Ubuntu crash...
  290. # [14:49] * Joins: myakura (n=myakura@p1226-ipbf3201marunouchi.tokyo.ocn.ne.jp)
  291. # [14:50] <hsivonen> Philip`: the new price makes it less attractive to keep both the Kotisivut.com VM and the Gandi VM
  292. # [14:57] <hsivonen> Philip`: having only a Gandi VM is a bit iffy considering that I'd have no practical recourse if Gandi opted to delete my VM (dealing with a local company is safer in that sense)
  293. # [14:57] <hsivonen> Philip`: having only the Kotisivut.com VM isn't that great, either, because it can't flex
  294. # [14:59] * Joins: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  295. # [15:07] * Quits: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  296. # [15:13] * Joins: csarven (n=csarven@80.76.201.52)
  297. # [15:19] * Joins: sbublava (n=stephan@77.119.85.74)
  298. # [15:26] * Joins: sbublava_ (n=stephan@77.116.51.128)
  299. # [15:26] * Quits: virtuelv (n=virtuelv@213.236.208.247) ("Leaving")
  300. # [15:27] * Quits: wakaba (n=wakaba@30.165.210.220.dy.bbexcite.jp) (kubrick.freenode.net irc.freenode.net)
  301. # [15:27] * Quits: bdash (n=bdash@fire/developer/bdash) (kubrick.freenode.net irc.freenode.net)
  302. # [15:28] * Joins: wakaba (n=wakaba@30.165.210.220.dy.bbexcite.jp)
  303. # [15:28] * Joins: bdash (n=bdash@fire/developer/bdash)
  304. # [15:38] * Quits: nessy (n=nessy@124-168-137-162.dyn.iinet.net.au) ("This computer has gone to sleep")
  305. # [15:41] <zcorpan_> annevk2: you set document.domain
  306. # [15:42] * Joins: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  307. # [15:44] * Quits: sbublava (n=stephan@77.119.85.74) (Read error: 110 (Connection timed out))
  308. # [15:51] <annevk2> zcorpan_, why should importNode not work when both sites have set document.domain?
  309. # [15:54] <zcorpan_> annevk2: it should
  310. # [15:55] * Quits: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  311. # [15:59] * Joins: malde_ (n=chatzill@cpe-075-176-017-240.carolina.res.rr.com)
  312. # [16:01] <annevk2> zcorpan_, then it's still not clear to me when you can exchange nodes cross origin (because document.domain doesn't matter)
  313. # [16:04] <zcorpan_> annevk2: you can exchange nodes when both nodes's ownerDocument have the same effective script origin
  314. # [16:05] * Quits: aaronlev_ (n=chatzill@f051105214.adsl.alicedsl.de) ("ChatZilla 0.9.83-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  315. # [16:05] * Joins: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  316. # [16:05] * Joins: aaronlev (n=chatzill@f051105214.adsl.alicedsl.de)
  317. # [16:06] <zcorpan_> annevk2: setting document.domain affects the effective script origin
  318. # [16:06] <annevk2> "Providing search engines with dynamic URLs should be favored over hiding parameters to make them look static." from http://googlewebmastercentral.blogspot.com/2008/09/dynamic-urls-vs-static-urls.html wtf
  319. # [16:06] <annevk2> zcorpan_, in what scenario would the SECURITY_ERR be raised?
  320. # [16:10] * Joins: aroben (n=aroben@unaffiliated/aroben)
  321. # [16:12] <zcorpan_> annevk2: hmm i see what you mean... it's not possible to get a reference to a node that you can't adopt
  322. # [16:12] <zcorpan_> or is it?
  323. # [16:15] <annevk2> I don't think it is
  324. # [16:16] <zcorpan_> sweet then i can just remove the check
  325. # [16:16] <annevk2> though now I wonder what the origin of responseXML is
  326. # [16:18] * Joins: smedero (n=smedero@mdp-nat251.mdp.com)
  327. # [16:26] * Quits: zcorpan_ (n=zcorpan@pat.se.opera.com)
  328. # [16:27] * Joins: nessy (n=nessy@124-168-137-162.dyn.iinet.net.au)
  329. # [16:28] * Quits: nessy (n=nessy@124-168-137-162.dyn.iinet.net.au) (Remote closed the connection)
  330. # [16:31] * Joins: billmason (n=billmaso@ip75.unival.com)
  331. # [16:35] <Philip`> annevk2: That blog post seems to be kind of confusing at getting the intended point across
  332. # [16:36] * Quits: sbublava_ (n=stephan@77.116.51.128)
  333. # [16:37] <Philip`> where the point seems to be that answer.foo?language=en&answer=3&sid=98971298178906&query=URL is better than answer.foo/en/3/98971298178906/URL because it's easier for a computer to work out what part of the URL is a parameter and hence might not significantly affect the document retrieved from that URL
  334. # [16:38] <Philip`> but it sounds quite easily misinterpretable as e.g. saying answer.foo?answer=3&... is better than answer.foo/3?..., which (I think) it doesn't mean
  335. # [16:50] <annevk2> yeah
  336. # [16:50] <annevk2> my weblogis indexed fine
  337. # [16:51] <annevk2> and they better keep it that way
  338. # [16:52] * Joins: virtuelv (n=virtuelv@163.80-202-65.nextgentel.com)
  339. # [16:57] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) (Client Quit)
  340. # [17:09] * Joins: tndH (n=Rob@james-baillie-pc083-137.student-halls.leeds.ac.uk)
  341. # [17:16] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  342. # [17:25] * Quits: aaronlev (n=chatzill@f051105214.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  343. # [17:25] * Joins: dglazkov (n=dglazkov@nat/google/x-79984f077b4ae0be)
  344. # [17:37] * myakura finds client-side storage implementation for IE6/IE7 (using DHTML behavior): http://translate.google.com/translate?u=http%3A%2F%2Fd.hatena.ne.jp%2FZIGOROu%2F20080924%2F1222221363&hl=ja&ie=UTF-8&sl=ja&tl=en
  345. # [17:40] <hsivonen> myakura: cool. have you tested it?
  346. # [17:41] <myakura> hsivonen: no. just started reading the code.
  347. # [17:42] <myakura> there's a test case though http://svn.coderepos.org/share/lang/javascript/exdomstorage/trunk/sample/index.html
  348. # [17:45] * Quits: myakura (n=myakura@p1226-ipbf3201marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  349. # [17:48] <hsivonen> only the localStorage part of the demo works for me
  350. # [17:48] <hsivonen> anyway, I think this should be on the wiki
  351. # [17:48] * Joins: Thezilch (n=fuz007@cpe-76-171-111-7.socal.res.rr.com)
  352. # [17:52] <Philip`> Looks like it's just implemented with cookies
  353. # [17:53] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  354. # [17:58] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  355. # [17:59] * Joins: hdh (n=hdh@118.71.121.191)
  356. # [18:10] * Quits: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  357. # [18:35] * Joins: hdh0 (n=hdh@118.71.125.71)
  358. # [18:38] * Joins: sicking (n=chatzill@corp-241.mountainview.mozilla.com)
  359. # [18:41] * Quits: Thezilch (n=fuz007@cpe-76-171-111-7.socal.res.rr.com) (Connection timed out)
  360. # [18:44] * Joins: weinig (n=weinig@nat/apple/x-3b6a1a7de9a7d413)
  361. # [18:45] * Quits: annevk2 (n=annevk@pat-tdc.opera.com) (Read error: 104 (Connection reset by peer))
  362. # [18:46] * Joins: annevk2 (n=annevk@pat-tdc.opera.com)
  363. # [18:54] * Quits: hdh (n=hdh@118.71.121.191) (Read error: 113 (No route to host))
  364. # [19:05] <hsivonen> annevk2: Stack Overflow also has: http://stackoverflow.com/questions/42169/if-you-were-programming-a-calendar-in-html-would-you-use-table-tags-or-div-tags
  365. # [19:07] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  366. # [19:10] * Joins: fishd_ (n=Darin@nat/google/x-bb72d39244982ad1)
  367. # [19:10] * Quits: fishd_ (n=Darin@nat/google/x-bb72d39244982ad1) (Read error: 104 (Connection reset by peer))
  368. # [19:11] * Joins: fishd (n=Darin@nat/google/x-a2aa0627cdc5249e)
  369. # [19:25] * Joins: virtuelv_ (n=virtuelv@163.80-202-65.nextgentel.com)
  370. # [19:26] * Joins: maikmerten (n=maikmert@Lb48b.l.pppool.de)
  371. # [19:26] <sicking> Hixie, shouldn't you use .data rather than .message in the workers spec?
  372. # [19:26] * Quits: virtuelv (n=virtuelv@163.80-202-65.nextgentel.com) (Read error: 110 (Connection timed out))
  373. # [19:26] <sicking> Hixie, event.data vs. event.message that is
  374. # [19:30] <annevk2> seems the mistake is only in the examples
  375. # [19:30] <sicking> annevk2, yeah
  376. # [19:38] * Joins: aboodman (n=aboodman@165.Red-80-33-158.staticIP.rima-tde.net)
  377. # [19:44] * Joins: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  378. # [19:47] * virtuelv_ is now known as virtuelv
  379. # [19:49] <aboodman> sicking: yt?
  380. # [19:49] <sicking> yo, talking workers with Ben :)
  381. # [19:51] <aboodman> i think the key point you're missing is that it should be easy to create 'conversations'
  382. # [19:51] <aboodman> in fact, i would argue that should really be the only way to communicate with a worker
  383. # [19:51] <aboodman> this is real feedback we have gotten on gears workers
  384. # [19:52] <aboodman> once you accept that, it pretty much leads to my proposed design
  385. # [19:52] <sicking> aboodman, it's just as easy now as with your proposal, no? The difference is just in the name 'startConversaion' vs 'connect'
  386. # [19:53] <aboodman> sicking: one sec, loading spec
  387. # [19:53] * Philip` thinks 'connect' looks much easier to spell :-)
  388. # [19:54] <sicking> aboodman, though there is a different way, as well, to communicate with dedicated workers, yes
  389. # [19:54] <aboodman> what is supposed to happen in the current spec when someone calls 'startconversation' on a dedicated worker
  390. # [19:54] <aboodman> does a 'connect' event fire inside the worker?
  391. # [19:54] <sicking> yeah
  392. # [19:55] <aboodman> k, there is a bug in the spec then
  393. # [19:55] <sicking> (btw, i'm fine with renaming 'startConversaion' to 'connect' if that makes a difference)
  394. # [19:55] <sicking> oh?
  395. # [19:55] <aboodman> onconnect is only on SharedWorkerGlobalScope from what I can see
  396. # [19:55] <aboodman> yes, we should make that change, startConveration() -> connect()
  397. # [19:56] <sicking> oh
  398. # [19:56] <sicking> wait
  399. # [19:56] <sicking> you're right
  400. # [19:56] <sicking> when startConversaion is called onmessage is called
  401. # [19:56] <sicking> not onconnect
  402. # [19:56] <aboodman> oh, because startConversation takes a message
  403. # [19:56] <aboodman> and where does the port show up?
  404. # [19:57] <sicking> and you get an event with a string and a port
  405. # [19:57] <sicking> right
  406. # [19:57] <aboodman> so we basically have *three* different mechanisms at work
  407. # [19:57] <aboodman> a) you can use workers the old school way, like gears is today, with one channel shared between all clients
  408. # [19:57] <sicking> two in shared and two in dedicated, with one existing in both
  409. # [19:57] <sicking> yeah
  410. # [19:58] <aboodman> b) you can call startConversation(), which fires a message event, and the worker code has to know to fish the port out of the event, instead of using the global port object
  411. # [19:58] <aboodman> c) you can create an instance of a shared worker, which will fire onconnect
  412. # [19:58] <aboodman> which has a port you can use to respond
  413. # [19:58] <aboodman> i think it would be very nice to combine all these into one mechanism
  414. # [19:58] <sicking> 'a' only exists for dedicated, and 'c' only for shared
  415. # [19:59] <sicking> i agree it seems excessive
  416. # [19:59] <aboodman> right, but there are still three things to understand
  417. # [19:59] <sicking> yup
  418. # [19:59] * sicking ponders
  419. # [19:59] <aboodman> in my proposal usage is always the same
  420. # [19:59] <aboodman> connect() gets you a port
  421. # [19:59] <aboodman> call sendMessage() on port
  422. # [19:59] <aboodman> on the inside, you get onconnect
  423. # [19:59] <aboodman> reply on the port you got from onconnect
  424. # [19:59] <sicking> it does make it painful for the most simple case though
  425. # [20:00] <aboodman> i don't agree :)
  426. # [20:00] <aboodman> it makes it one line more painful
  427. # [20:00] <aboodman> a small price i think
  428. # [20:00] <sicking> everybody will end up with code like onconnect = function(e) { myPort = e.port; myPort.onmessage = myHandler }
  429. # [20:01] <sicking> everyone will have to write that snippet of code
  430. # [20:01] <aboodman> i would really prefer that we have a global onconnect, which would help that case
  431. # [20:01] <sicking> that is with a global onconnect
  432. # [20:01] <aboodman> sorry,
  433. # [20:01] <aboodman> global onmessage
  434. # [20:01] <sicking> that gets very messy with passable ports
  435. # [20:01] <aboodman> how so?
  436. # [20:02] * Joins: kangax (n=kangax@74.201.136.194)
  437. # [20:02] <sicking> all of a sudden your global onmessage starts receiving more messages since someone passed in a port
  438. # [20:03] <sicking> and will your global onmessage still receive messages from ports that have been passed elsewhere?
  439. # [20:03] <aboodman> that would presumably only happen if the passed port is live
  440. # [20:03] <aboodman> but that's a good point with the idea of having a global onmessage
  441. # [20:03] <aboodman> that is a problem
  442. # [20:03] <aboodman> ok, i'm fine not having a global onmessage. the inside code becomes:
  443. # [20:03] <sicking> i think we can narrow it down to two communication methods maybe
  444. # [20:03] <sicking> the simple one for dedicated workers
  445. # [20:03] <aboodman> onconnect = function(e) { e.onmessage = function() { ... } }
  446. # [20:04] <aboodman> which is not that different from what people do with onload today
  447. # [20:04] <sicking> how so? today you just do onload = function () { ... }
  448. # [20:04] <aboodman> onload = function() { myButton.onclick = function() { ... } }
  449. # [20:04] <sicking> also you need to store e.port so you can post stuff out
  450. # [20:04] <aboodman> no you dont
  451. # [20:05] <aboodman> you get the port in the messages
  452. # [20:05] <aboodman> (i thought)
  453. # [20:05] <sicking> you do?
  454. # [20:05] <sicking> maybe as the source
  455. # [20:05] <aboodman> yeah, as the source
  456. # [20:05] <sicking> though that only works if you're inside a message handler
  457. # [20:05] <sicking> it doesn't work if you are just producing data
  458. # [20:06] <sicking> such as polling data from the network and sending out stuff to the window
  459. # [20:06] <aboodman> that is a lesser use case
  460. # [20:06] <aboodman> we only need to support it, not make it beautiful
  461. # [20:06] <aboodman> imo
  462. # [20:06] <sicking> isn't that what you guys needed for gmail?
  463. # [20:06] <aboodman> gmail? gears? what?
  464. # [20:06] <aboodman> :)
  465. # [20:06] <aboodman> no, we don't do that
  466. # [20:06] <aboodman> it was a hypothetical use case
  467. # [20:07] <aboodman> anyway you still don't need to store the port for that use case if you use closures, which is pretty common
  468. # [20:07] <aboodman> but i admit: there is more leg work here.
  469. # [20:08] <aboodman> on both sides.
  470. # [20:08] <aboodman> it's a tradeoff for having the api be consistent across all use cases.
  471. # [20:09] <sicking> so i think we should reduce to 2 communication methods. A simple one for the most common (imho) and simple case, dedicated worker with a single communication channel. And one complicated one for shared workers and/or multiple conversaions
  472. # [20:10] <aboodman> multiple conversations will be very common
  473. # [20:10] <sicking> i really think anything beyond just a single dedicated worker that you put off some heavy work onto is going to be much more rare
  474. # [20:10] * Joins: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  475. # [20:10] <aboodman> the most common case that I'm aware of is synchronization
  476. # [20:10] <aboodman> of a local db with the network
  477. # [20:11] <aboodman> in that case, the common implementation will be: a single shared worker
  478. # [20:11] <aboodman> each UI action will create a conversation
  479. # [20:11] <aboodman> and wait for it's reply
  480. # [20:11] <sicking> i think it'll be more stuff like crypto or parsing or stuff like that
  481. # [20:11] <aboodman> the shared worker is filling the role of a server. so you need transaction ids.
  482. # [20:12] <sicking> for a shared worker i agree that having multiple conversaions is going to be the common case
  483. # [20:12] <aboodman> not just for a shared worker though.
  484. # [20:12] <sicking> which is why we should make that the only way to communicate to a shared worker
  485. # [20:12] <sicking> for a dedicated i think just a single conversation is going to be much more common
  486. # [20:12] <aboodman> if you have a worker providing services for a UI, and the user can initiate multiple actions in parallel, thenyou need conversations.
  487. # [20:14] <aboodman> say you have a UI that has three buttons, and each button sets off a lengthy operation that you perform in a worker.
  488. # [20:14] <aboodman> without conversations, you need to keep track of which reply went with which button manually.
  489. # [20:14] <aboodman> blech.
  490. # [20:15] <sicking> i agree that we should have conversaions for sure
  491. # [20:16] <sicking> but i don't think we should force that onto the usecase of a single dedicated worker wanting to perform some heavy work such as crypto on a worker
  492. # [20:16] <aboodman> in that case, it's just one extra line
  493. # [20:16] <aboodman> or 10 extra characters if you chain the method call :)
  494. # [20:16] <sicking> the difference is that i think it'll be the common case
  495. # [20:16] <sicking> so i prefer to optimize for making that simple
  496. # [20:17] <aboodman> s/10/8/g (i can't spell)
  497. # [20:18] <aboodman> ok, but at the very least, it sounds like you agree the api can be simplified for shared workers and conversations on a dedicated worker along the lines i proposed:
  498. # [20:18] <aboodman> * remove the port properties in the shared worker interfaces
  499. # [20:19] <aboodman> * make startconversation just return a port, and fire onconnect
  500. # [20:19] <sicking> are there port properties on shared workers?
  501. # [20:19] <aboodman> http://www.whatwg.org/specs/web-workers/current-work/#shared1
  502. # [20:20] <sicking> oh
  503. # [20:20] <sicking> ooh
  504. # [20:20] <sicking> i remember
  505. # [20:20] <aboodman> there is none on the inside, i don't know why
  506. # [20:20] <sicking> yeah, i'm fine with removing that
  507. # [20:21] <sicking> the way it works now is that when you create a shared worker
  508. # [20:21] <sicking> that basically calls startConversation
  509. # [20:21] <sicking> except onconnect rather than onmessage is fired
  510. # [20:21] <aboodman> right
  511. # [20:21] <sicking> and the 'outer' port is put on the .port rather than being returned anywhere
  512. # [20:22] <sicking> btw, there is basically no way we can remove onmessage as a way to set up conversaions
  513. # [20:22] <sicking> since you can just use postMessage("here ya go", myPort)
  514. # [20:23] <aboodman> i don't follow
  515. # [20:23] <sicking> so today you can do this:
  516. # [20:23] <sicking> ch = new MessageChannel;
  517. # [20:23] <sicking> w = new SharedWorker(...);
  518. # [20:24] <sicking> w.postMessage("lets talk", ch.port2);
  519. # [20:24] <sicking> ch.port1.onmessage = function(e) { ... }
  520. # [20:25] <aboodman> i guess
  521. # [20:25] <aboodman> i still don't understand this use case at all
  522. # [20:25] <aboodman> but it is orthagonal to what i'm talking about
  523. # [20:25] <sicking> yeah, that's basically already part of HTML5, not part of workers at all
  524. # [20:25] <aboodman> if people also want the ability to pass ports around, ok...
  525. # [20:25] <sicking> Hixie has been talking about that a lot
  526. # [20:25] <aboodman> html5 is not really set in stone
  527. # [20:26] <sicking> so i assume that google wants that
  528. # [20:26] <aboodman> nobody has implemented this feature yet, right?
  529. # [20:26] <sicking> for widgets and the like
  530. # [20:26] <aboodman> somebody wants it, just not me.
  531. # [20:26] <sicking> not sure if the other postMessage implementations do that
  532. # [20:26] <sicking> heh :)
  533. # [20:26] <aboodman> i don't think it's valid to say 'it's already in html5, we can't remove it'
  534. # [20:27] <aboodman> the spec specifically says that it is in progress
  535. # [20:27] <aboodman> if there are good reasons to pass ports around, hey, great, let's keep them.
  536. # [20:27] <sicking> so i don't want to talk for hixie, but from what i understand there were requirements around widgets that required that
  537. # [20:27] <aboodman> he explained them in our last meeting, i just am still not convinced.
  538. # [20:27] <aboodman> anyway, i think that issue can be separated.
  539. # [20:29] <sicking> sure
  540. # [20:31] <aboodman> so would you be in favor of: (my proposal - global onmessage) + DedicatedWorker::sendMessage + DedicatedWorkerGlobalScope::onmessage
  541. # [20:31] <sicking> yup, think so :)
  542. # [20:31] <aboodman> ok, that is still a significant change from the current spec
  543. # [20:32] <sicking> i think it can be discussed if we should have an 'onconnect' or if we should reuse 'onmessage'
  544. # [20:32] <aboodman> you mean just overloading the event?
  545. # [20:32] <aboodman> so you get an onmessage event when a connection happens?
  546. # [20:32] * sicking ponders
  547. # [20:32] <sicking> right, some such
  548. # [20:33] <sicking> hmm
  549. # [20:33] <sicking> doesn't really work for shared workers since they don't have onmessage
  550. # [20:33] <sicking> so yeah, what you said :)
  551. # [20:34] * Quits: hdh0 (n=hdh@118.71.125.71) ("Konversation terminated!")
  552. # [20:35] <aboodman> thanks, i will reply to the mail thread pointing to this irc log and summarizing
  553. # [20:45] * Philip` reads the log and sees 'startConversaion', 'startconversation', 'startConversaion', 'startConveration', 'startConversaion', 'startConversation', and continues to think that renaming to 'connect' would be good
  554. # [20:46] <aboodman> :)
  555. # [20:46] <aboodman> as a rule, my poor typing should not be taken as indication of the quality of an api.
  556. # [20:47] <Philip`> aboodman: It's an indication of the problems that many other people are likely to experience
  557. # [20:48] <aboodman> i'm in favor of 'connect()'
  558. # [20:48] <Philip`> Data suggests that <script langauge="..."> is pretty common
  559. # [20:48] * Joins: hdh0 (n=hdh@118.71.127.216)
  560. # [20:49] <Philip`> which is apparently why we have <meter> instead of <gauge>
  561. # [20:49] <Philip`> So I think those typos are relevant evidence :-)
  562. # [20:50] <Philip`> although I'm probably wrong
  563. # [20:50] <Philip`> because people take more care when typing code than typing IRC
  564. # [20:50] * Joins: aaronlev (n=chatzill@g226208165.adsl.alicedsl.de)
  565. # [20:50] <Philip`> and so typos will be much rarer when people write actual code, and only real spelling difficulties matter
  566. # [20:52] <sicking> aboodman, so with connect there will still be 3 ways to have a conversation (sort of) on a dedicated worker
  567. # [20:52] <sicking> aboodman, as the html5 spec stands today
  568. # [20:52] <aboodman> explain/
  569. # [20:53] <sicking> aboodman, i'm not really opposed to changing that, but it would need changing
  570. # [20:53] <aboodman> sicking: how so?
  571. # [20:53] <sicking> aboodman, so there will be worker.postMessage('hi there');
  572. # [20:53] <sicking> ch = new MessageChannel(); worker.postMessage('lets converse', ch.port1);
  573. # [20:54] <sicking> and port = worker.connect();
  574. # [20:54] <sicking> i'm not in love with the second one, but as things stand it's there
  575. # [20:55] <aboodman> i guess, i don't count that one because i don't see people doing it.
  576. # [20:55] <aboodman> you'll only use that when you want to do ... whatever it is hixie forsees people doing with it
  577. # [20:55] <sicking> well
  578. # [20:55] <aboodman> but ok.
  579. # [20:55] <sicking> there is the argument that impls will end up having to impl all 3 since hixie will use it in acid7
  580. # [20:56] <aboodman> let's keep the issue of passing ports separate.
  581. # [20:56] <sicking> no matter if people want it or not
  582. # [20:56] <aboodman> i think they really are separate concerns.
  583. # [20:56] <sicking> ok
  584. # [21:00] * Quits: weinig (n=weinig@nat/apple/x-3b6a1a7de9a7d413)
  585. # [21:03] * Quits: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  586. # [21:04] * Joins: weinig (n=weinig@17.244.25.147)
  587. # [21:15] * Joins: sverrej (n=sverrej@89.10.27.245)
  588. # [21:17] * Quits: tndH (n=Rob@james-baillie-pc083-137.student-halls.leeds.ac.uk) ("ChatZilla 0.9.83-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  589. # [21:17] * Joins: aaronlev_ (n=chatzill@g226208165.adsl.alicedsl.de)
  590. # [21:23] * Quits: aaronlev (n=chatzill@g226208165.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  591. # [21:23] * aaronlev_ is now known as aaronlev
  592. # [21:23] * Quits: virtuelv (n=virtuelv@163.80-202-65.nextgentel.com) ("Leaving")
  593. # [21:27] * Joins: hsivonen_ (n=hsivonen@kekkonen.cs.hut.fi)
  594. # [21:28] * Quits: hsivonen (n=hsivonen@kekkonen.cs.hut.fi) (Read error: 110 (Connection timed out))
  595. # [21:28] * hsivonen_ is now known as hsivonen
  596. # [21:35] * Quits: aboodman (n=aboodman@165.Red-80-33-158.staticIP.rima-tde.net) (Read error: 110 (Connection timed out))
  597. # [21:37] * Joins: sbublava (n=stephan@77.116.107.194)
  598. # [21:44] * Quits: Amorphous (i=jan@unaffiliated/amorphous) ("shutdown")
  599. # [21:46] * Quits: maikmerten (n=maikmert@Lb48b.l.pppool.de) (Remote closed the connection)
  600. # [21:53] * Hixie is very confused about the feedback on workers
  601. # [21:53] <gsnedders> Hixie: n00b.
  602. # [21:54] <Hixie> sicking: the original API had just one way of using messages, and you and aaron both asked for more ways (he asked for .startConversation, you asked for the API to be flattened onto the dedicated workers for ease of use)
  603. # [21:54] <Hixie> sicking: and now you're both asking for the APIs to be unified again but leaving some of the differences?
  604. # [21:54] <Hixie> what changed?
  605. # [22:05] * Quits: weinig (n=weinig@17.244.25.147)
  606. # [22:08] * svl is now known as sml
  607. # [22:09] * sml is now known as svl
  608. # [22:09] * Joins: roc (n=roc@202.20.0.134)
  609. # [22:18] <Hixie> holy wow
  610. # [22:19] <Hixie> i scanned 100 million documents and found absolutely no occurances of <input type=file accept>
  611. # [22:19] * Hixie increases his sample by a factor of 10 and tries again
  612. # [22:28] <gsnedders> I am far too good at procrasintating.
  613. # [22:28] * Joins: eseidel (n=eseidel@nat/google/x-d33bc2fae7b8f8c9)
  614. # [22:28] <gsnedders> Must. write. personal. statement.
  615. # [22:29] <gsnedders> But my stomach hurts and I don't wanna.
  616. # [22:29] * Quits: roc (n=roc@202.20.0.134)
  617. # [22:38] * Philip` sees some with <input type=text accept> and <input type=submit accept>, but isn't surprised that he doesn't see any on type=file because it's very unlikely that a site will have a file upload box on public pages
  618. # [22:39] <Hixie> there were lots of <input type=file> elements
  619. # [22:39] <Hixie> just none with accept
  620. # [22:40] <Philip`> http://google.com/codesearch?q=type%3D%22file%22+accept%3D
  621. # [22:41] <Philip`> Seems reasonably common and varied there
  622. # [22:43] * Joins: weinig (n=weinig@nat/apple/x-c3e8998d0e48bad8)
  623. # [22:43] <Hixie> what does "Generating the page that the server would have generated on the fly on the client side while offline seems really hacky. I really don't
  624. # [22:43] <Hixie> er
  625. # [22:44] <Hixie> what does |accept="{@mime-types}"| do in xslt?
  626. # [22:45] <Philip`> Wild guess: Sets the accept attribute value on the output element to be the value of the mime-types attribute on the input element (i.e. the element that matched the <xsl:template>)
  627. # [22:45] * Hixie sees accept="text/*.xml" and is a little sadder
  628. # [22:45] <Hixie> ooh, that makes sense
  629. # [22:45] <Hixie> ok
  630. # [22:46] <Hixie> looks like a lot of people use foo/*
  631. # [22:46] <Hixie> including text/*
  632. # [22:46] <Hixie> which is odd
  633. # [22:46] <Hixie> and people seem to put spaces around their commas
  634. # [22:46] <Philip`> where I guess {...} is string interpolation, and contains an XPath expression that returns a string, or something like that
  635. # [22:47] <Philip`> because it'd be kind of crazy and unintuitive if they designed the language in any other way
  636. # [22:47] <Philip`> and I like to assume people aren't crazy :-)
  637. # [22:48] <Hixie> accept="text/*.*"
  638. # [22:48] <Hixie> that fails in so many ways
  639. # [22:54] * Quits: kangax (n=kangax@74.201.136.194)
  640. # [23:00] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  641. # [23:14] * Joins: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  642. # [23:15] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  643. # [23:18] * Quits: sverrej (n=sverrej@89.10.27.245) (Read error: 110 (Connection timed out))
  644. # [23:26] * Quits: csarven (n=csarven@80.76.201.52) (Remote closed the connection)
  645. # [23:40] * Quits: Maurice` (i=copyman@cc90688-a.emmen1.dr.home.nl) ("Disconnected...")
  646. # [23:43] * Quits: weinig (n=weinig@nat/apple/x-c3e8998d0e48bad8) (Read error: 110 (Connection timed out))
  647. # [23:46] * Joins: weinig (n=weinig@nat/apple/x-bcd777eb03fdfc83)
  648. # Session Close: Thu Sep 25 00:00:00 2008

The end :)