/irc-logs / freenode / #whatwg / 2008-02-14 / end

Options:

  1. # Session Start: Thu Feb 14 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:01] * Quits: phsiao (n=shawn@nat/ibm/x-ad79920a3ee2bb7d) (Read error: 110 (Connection timed out))
  4. # [00:08] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (IRC client for Emacs)")
  5. # [00:11] * Joins: gsnedders (n=gsnedder@host86-151-228-75.range86-151.btcentralplus.com)
  6. # [00:13] * Quits: webben (n=benh@82.152.229.45) (Connection timed out)
  7. # [00:16] * Joins: hober (n=ted@unaffiliated/hober)
  8. # [00:22] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com) (Read error: 104 (Connection reset by peer))
  9. # [00:37] * SadEagle is now known as AwayEagle
  10. # [01:07] * Quits: aroben (n=aroben@unaffiliated/aroben)
  11. # [01:21] * Quits: billmason (n=billmaso@ip129.unival.com) (".")
  12. # [01:37] <Hixie> well bummer
  13. # [01:37] * Hixie ends up speccing an event that fires on garbage collection
  14. # [01:37] <Hixie> that's clearly not a good plan
  15. # [01:40] <Dashiva> Very interoperable, no doubt :)
  16. # [01:42] <Philip`> Would it be non-conforming to just leak memory and not do GC?
  17. # [01:42] <Hixie> so here's the problem
  18. # [01:42] <Dashiva> You'd still be firing it every time you did GC, so it should be conforming
  19. # [01:43] <Hixie> this is for http://www.hixie.ch/specs/dom/messages/0.9
  20. # [01:43] <Hixie> what should happen if i create an end point, set its message handler, and then forget about my end of it, having passed the other end to another browsing context?
  21. # [01:43] <Hixie> clearly it shouldn't be garbage collected
  22. # [01:44] <Hixie> as it can still receive messages and respond usefully
  23. # [01:44] <Hixie> but then what happens if my Window is closed?
  24. # [01:44] <Hixie> or navigated?
  25. # [01:45] <Dashiva> Is the strong entangling really needed?
  26. # [01:45] <Hixie> should the other side get an unload event for the endpoint?
  27. # [01:45] <Hixie> how do you mean?
  28. # [01:45] <Dashiva> Instead of just having each endpoint have an "other end" property referring to the other endpoint
  29. # [01:46] <Hixie> i don't understand
  30. # [01:47] * Quits: jgraham (n=james@81-86-211-105.dsl.pipex.com) ("I get eaten by the worms")
  31. # [01:47] <Dashiva> Um. Well, could you treat it the same way any old DOM reference in a different window?
  32. # [01:47] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (IRC client for Emacs)")
  33. # [01:48] <Dashiva> With window references you have .closed, could something similar work for endpoints?
  34. # [01:48] <Hixie> i can set .active to false
  35. # [01:52] <Dashiva> The problematic event was something like "other endpoint is gone"?
  36. # [01:52] <Hixie> i think i've worked out how to spec it for now
  37. # [01:52] <Hixie> we'll see if it handles Workers too in a second
  38. # [01:53] <Dashiva> What's the reason for cloning endpoints sent via postMessage, by the way?
  39. # [01:53] <Hixie> cross-origin concerns
  40. # [01:55] <Hixie> for example, it would be bad if you could do foreignEndPoint.prototype.prototype.toString = function () { my evil function }
  41. # [01:55] <Hixie> or whatever
  42. # [01:56] <Dashiva> So the create function is usually making one just to throw it away later
  43. # [01:56] <Hixie> yep
  44. # [01:57] <Dashiva> I feel like it should be possible to do it the other way around, creating just one endpoint and having the semantics of send be "The endpoint received should be a new one entangled with this here local endpoint I have"
  45. # [01:57] <Hixie> what if you do it twice?
  46. # [01:58] <Hixie> also, you might want to pass the same end point down several pipes
  47. # [01:58] <Hixie> which you couldn't do the way you describe it
  48. # [01:59] <Dashiva> Aren't those two things mutually exclusive?
  49. # [01:59] <Hixie> hm?
  50. # [01:59] <Dashiva> If you want to pass it down several pipes, you are doing it twice (or more)
  51. # [02:00] <Hixie> say you have established pipes A1<->A2 and B1<->B2, and a newly created pipe C1<->C2.
  52. # [02:00] <Hixie> right now you can pass C2 down from A1 to A2, and then from there it can go from B1 to B2
  53. # [02:00] <Hixie> but your proposal can't do that, as i understand it
  54. # [02:01] <Hixie> however, your proposal would allow sending "C1's other point" down A1 to A2 creating C2, and then sending "C1's other point" again down A1 to A2, creating C2'?
  55. # [02:01] <Hixie> so now you have two C2s
  56. # [02:02] <Hixie> which is confusing
  57. # [02:02] <Hixie> and causes all kinds of problems
  58. # [02:02] <Dashiva> Let me work this out. So you pass C2 from A1 to A2, which gives A2 a C3 connected to C1. Then you pass C3 from B1 to B2, giving B2 a C4 which is connected to C1. In the process you've invalidated C2 and C3.
  59. # [02:03] <Hixie> yah
  60. # [02:03] <Hixie> (i'd prefer the notation C2, C2', C2'', C2''', but sure :-) )
  61. # [02:04] <Dashiva> Yeah, I see my idea wouldn't support chaining
  62. # [02:05] <Dashiva> (Unless the endpoint included a pointer to its twin)
  63. # [02:05] <Dashiva> And that's what the cloning was supposed to stop
  64. # [02:06] <Hixie> yeha
  65. # [02:06] <Hixie> yeah, even
  66. # [02:06] * Quits: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  67. # [02:07] <Dashiva> So I suppose I'd be writing function setupLink(w) { p = new Pair(); w.postMessage("New pair",p.two); return p.one; } or somesuch then
  68. # [02:27] <Hixie> hmmmmm
  69. # [02:27] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  70. # [02:27] <Hixie> workers have to die if no browsing contexts refer to them
  71. # [02:27] <Hixie> not just if nobody refers to them
  72. # [02:27] <Hixie> otherwise you could have a worker refer to another and vice versa
  73. # [02:27] <Hixie> and they'd keep each other alive
  74. # [02:28] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  75. # [02:33] * Quits: kingryan (n=ryan@dsl092-219-050.sfo1.dsl.speakeasy.net) (Read error: 113 (No route to host))
  76. # [02:39] * Quits: dbaron (n=dbaron@guest-228.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  77. # [02:41] <Lachy> I don't know how to address this comment for selectors api http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0000.html
  78. # [02:42] <Hixie> hm, i wrote that text
  79. # [02:42] <Hixie> or suggested it originally
  80. # [02:42] <Hixie> let's see
  81. # [02:42] <Lachy> I can't figure out how to rephrase it to make it clearer
  82. # [02:42] <Hixie> yeah
  83. # [02:42] <Hixie> User agents should ensure that they do not crash or behave erratically when facing...
  84. # [02:43] <Lachy> that might work
  85. # [02:43] <Hixie> ... For example, a user agent could apply a timeout to the NSResolver callback.
  86. # [02:43] <Lachy> but then I'm not totally convinced of the value of having that in there at all, since the same applies to all scripts
  87. # [02:44] <Hixie> well, the difference here is that the script is driving a UA algorithm
  88. # [02:44] <Hixie> i could easily imagine implementations of the algorithm where returning inconsistent results would cause a crash
  89. # [02:44] <Hixie> this is just saying, "beware"
  90. # [02:44] <Hixie> which is all security sections ever say, really
  91. # [02:44] <Lachy> ok
  92. # [02:45] <Hixie> but i can easily imagine someone not thinking about the fact that the resolver might hang, and accidentally not putting the usual scripting timeout constraints around that api
  93. # [02:45] <Hixie> same with changing the dom
  94. # [02:47] * Quits: eseidel (n=eseidel@nat/google/x-734a192f23081189)
  95. # [02:48] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  96. # [02:51] * Joins: eseidel (n=eseidel@nat/google/x-a63ff5dc2a6b0f6b)
  97. # [02:52] <Hixie> http://www.w3.org/2001/tag/doc/passwordsInTheClear-52
  98. # [02:53] <Hixie> "User agents SHOULD use password masking when passwords are displayed in an HTML form"
  99. # [02:53] <Hixie> i'm so glad the TAG is addressing critical unsolved problems
  100. # [02:53] <Hixie> and not, say, problems from 1993
  101. # [03:01] <Hixie> http://www.hixie.ch/specs/dom/workers/0.9 is finally ready for broader review
  102. # [03:03] * Joins: mpt (n=mpt@222-155-23-107.jetstream.xtra.co.nz)
  103. # [03:07] * Joins: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  104. # [03:09] * Quits: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net) (Client Quit)
  105. # [03:26] <roc> the recursive definition of "acceptable" is a bit dogy
  106. # [03:27] <roc> a cycle of WorkerWindows talking to each other but disconnected from all real Windows could be deemed "acceptable", and could also be deemed "not acceptable"
  107. # [03:29] <roc> you also need to say something about what's in scope for these worker threads
  108. # [03:30] <roc> oh I see you've got a one-line comment covering that :-)
  109. # [03:33] * Joins: mpt_ (n=mpt@222-155-28-171.jetstream.xtra.co.nz)
  110. # [03:35] <Lachy> is createWorker*() designed to make it possible to run JS as a separate thread in the background?
  111. # [03:35] <roc> yes
  112. # [03:35] <Lachy> cool
  113. # [03:35] <roc> a la Gears
  114. # [03:37] * Quits: mpt (n=mpt@222-155-23-107.jetstream.xtra.co.nz) (Read error: 110 (Connection timed out))
  115. # [03:42] * Quits: grimboy (n=grimboy@78-105-162-250.zone3.bethere.co.uk) (Read error: 110 (Connection timed out))
  116. # [03:45] * Quits: bzed (n=bzed@devel.recluse.de) (anthony.freenode.net irc.freenode.net)
  117. # [03:45] * Quits: syp_ (n=syp@lasigpc9.epfl.ch) (anthony.freenode.net irc.freenode.net)
  118. # [03:45] * Quits: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk) (anthony.freenode.net irc.freenode.net)
  119. # [03:45] * Joins: bzed (n=bzed@devel.recluse.de)
  120. # [03:46] * Joins: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk)
  121. # [03:49] * Quits: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk) (anthony.freenode.net irc.freenode.net)
  122. # [03:49] * Quits: hsivonen (n=hsivonen@kekkonen.cs.hut.fi) (anthony.freenode.net irc.freenode.net)
  123. # [03:49] * Quits: Philip` (n=philip@zaynar.demon.co.uk) (anthony.freenode.net irc.freenode.net)
  124. # [03:49] * Quits: roc (n=roc@202.0.36.64) (anthony.freenode.net irc.freenode.net)
  125. # [03:49] * Quits: didymos (i=jho@rapwap.razor.dk) (anthony.freenode.net irc.freenode.net)
  126. # [03:50] * Joins: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk)
  127. # [03:50] * Quits: tndH_ (n=Rob@87.102.19.166) ("ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  128. # [03:51] * Joins: roc (n=roc@202.0.36.64)
  129. # [03:51] * Joins: Philip` (n=philip@zaynar.demon.co.uk)
  130. # [03:51] * Joins: didymos (i=jho@rapwap.razor.dk)
  131. # [03:51] * Joins: hsivonen (n=hsivonen@kekkonen.cs.hut.fi)
  132. # [03:52] * Joins: syp_ (n=syp@lasigpc9.epfl.ch)
  133. # [04:06] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  134. # [04:08] * Joins: jwalden (n=waldo@STRATTON-THREE-EIGHTEEN.MIT.EDU)
  135. # [04:16] <Hixie> roc: yeah, i thought of that when i defined it (the 'acceptable' thing). i was hoping it would go unnoticed.
  136. # [04:16] <Hixie> fat chance of that, apparently :-)
  137. # [04:16] <Hixie> roc: any idea how to better phrase it?
  138. # [04:17] <roc> something like
  139. # [04:17] <roc> "Acceptability is defined inductively by the following rules:"
  140. # [04:17] <Hixie> (these two proposals are very much early early drafts, by the way, hey'll obviously be defined more rigorously if they ever make a real spec)
  141. # [04:18] <Hixie> roc: is that magic phrasing that makes it better? awesome
  142. # [04:18] * Hixie edits
  143. # [04:18] <roc> no
  144. # [04:18] <roc> "1. <a thread with an endpoint whose other end is a real Window, is acceptable>"
  145. # [04:18] <Hixie> oh, there's more, ok
  146. # [04:18] * Hixie waits
  147. # [04:18] <roc> "2. <a thread with an endpoint whose other end is an acceptable thread, is acceptable>"
  148. # [04:18] <roc> but yeah, "induction" is actually a magic word here :-)
  149. # [04:19] <roc> you might find it useful to take a class or read a book on methods for formal specification
  150. # [04:20] <roc> a lot of it's less useful than its practitioners wish
  151. # [04:20] <roc> but you might pick up some useful stuff anyway
  152. # [04:20] <Hixie> yeah, i try to read up on stuff like that occasionally
  153. # [04:20] <Hixie> do you have any suggestions?
  154. # [04:20] <Hixie> there's a lot of... less than readable material
  155. # [04:20] <roc> yeah
  156. # [04:20] <Hixie> that's either way over my head, or bogus
  157. # [04:20] <Hixie> i can't tell
  158. # [04:22] <roc> I'll ask my old PhD advisor(s), they're into this sort of thing
  159. # [04:23] <Hixie> cool
  160. # [04:23] <Hixie> that would be awesome
  161. # [04:24] <roc> BTW another way of phrasing those acceptability constraints would be to specify that you want the least solution to the constraints, i.e. the solution that makes the minimum number of workers acceptable
  162. # [04:25] <Hixie> true
  163. # [04:25] <Hixie> ok, i've tried taking your structure and applied it to the draft
  164. # [04:25] <Hixie> http://hixie.ch/specs/dom/workers/0.9
  165. # [04:25] <roc> that's quite a popular approach, although sometimes defining "minimal" is itself quite tricky
  166. # [04:26] <roc> looks good
  167. # [04:26] <Hixie> cool
  168. # [04:26] <Hixie> thanks
  169. # [04:35] * Quits: weinig (n=weinig@17.203.15.140)
  170. # [04:36] <roc> Hixie: weren't you originally an English major? How much mathematics have you done?
  171. # [04:36] <Hixie> physics
  172. # [04:36] <roc> ah ok cool
  173. # [04:37] <roc> so you probably learned lots of calculus and geometry, which is useless :-)
  174. # [04:37] <Hixie> pretty much
  175. # [04:37] <Hixie> and all the stats i learnt, which would have been useful, i forgot
  176. # [04:38] <Hixie> the scientific method is the main thing i got from my degree which i've applied to the spec work
  177. # [04:56] * Quits: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  178. # [05:07] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  179. # [05:22] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  180. # [05:41] * AwayEagle is now known as SadEagle
  181. # [05:57] * Quits: mpt_ (n=mpt@222-155-28-171.jetstream.xtra.co.nz) (Read error: 110 (Connection timed out))
  182. # [06:01] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  183. # [06:05] * Quits: eseidel (n=eseidel@nat/google/x-a63ff5dc2a6b0f6b)
  184. # [06:11] * Quits: roc (n=roc@202.0.36.64)
  185. # [06:20] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  186. # [07:19] * Quits: jeremyb (n=jeremy@unaffiliated/jeremyb) (Connection timed out)
  187. # [07:22] * MacDomeSleep is now known as MacDome
  188. # [07:28] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  189. # [07:31] * Joins: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  190. # [07:31] * Joins: eseidel_ (n=eseidel@72.14.224.1)
  191. # [07:42] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  192. # [07:43] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  193. # [07:44] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  194. # [07:49] * Quits: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  195. # [07:55] * Quits: gavin_ (n=gavin@firefox/developer/gavin)
  196. # [07:57] * Joins: mpt (n=mpt@222-155-28-171.jetstream.xtra.co.nz)
  197. # [08:01] * Joins: gavins (n=gavin@firefox/developer/gavin)
  198. # [08:01] * gavins is now known as gavin_
  199. # [08:05] * Joins: jeremyb (n=jeremy@unaffiliated/jeremyb)
  200. # [08:17] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) ("Verlassend")
  201. # [08:20] * Quits: jwalden (n=waldo@STRATTON-THREE-EIGHTEEN.MIT.EDU) ("ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  202. # [08:29] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  203. # [08:33] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  204. # [08:43] * Joins: roc (n=roc@121-72-31-154.dsl.telstraclear.net)
  205. # [08:44] * Quits: heycam|sydney (n=cam@b4F38.static.pacific.net.au) ("bye")
  206. # [09:10] * Quits: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com) ("Konversation terminated!")
  207. # [09:21] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  208. # [09:25] * Joins: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  209. # [09:33] * Quits: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  210. # [09:36] * Quits: eseidel_ (n=eseidel@72.14.224.1) (Read error: 110 (Connection timed out))
  211. # [09:37] * Joins: mpt_ (n=mpt@222-155-8-114.jetstream.xtra.co.nz)
  212. # [09:42] * Quits: mpt (n=mpt@222-155-28-171.jetstream.xtra.co.nz) (Read error: 110 (Connection timed out))
  213. # [09:52] * Quits: mpt_ (n=mpt@222-155-8-114.jetstream.xtra.co.nz) (Read error: 104 (Connection reset by peer))
  214. # [10:04] * Quits: bzed (n=bzed@devel.recluse.de) ("/forcefsck")
  215. # [10:07] * Joins: bzed (n=bzed@devel.recluse.de)
  216. # [10:21] * Joins: ROBOd (n=robod@89.122.216.38)
  217. # [10:33] * Joins: jgraham (n=james@81-86-211-105.dsl.pipex.com)
  218. # [10:33] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  219. # [10:34] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  220. # [10:35] * Joins: webben (n=benh@nat/yahoo/x-60d88e2bbaa5d496)
  221. # [10:51] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
  222. # [10:52] * Joins: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com)
  223. # [11:05] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Less talk, more pimp walk.")
  224. # [11:10] * Parts: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com)
  225. # [11:11] * Joins: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com)
  226. # [11:24] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  227. # [11:48] * Quits: roc (n=roc@121-72-31-154.dsl.telstraclear.net)
  228. # [11:55] * Joins: roc (n=roc@121-72-31-154.dsl.telstraclear.net)
  229. # [12:12] <annevk> passwordsInTheClear-52 lol
  230. # [12:14] <annevk> I wonder if I should point out a small mistake or not
  231. # [12:16] * Joins: raphman (n=raphael_@141.84.8.83)
  232. # [12:16] * Parts: raphman (n=raphael_@141.84.8.83)
  233. # [12:20] <Lachy> annevk, what's the mistake?
  234. # [12:20] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  235. # [12:21] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  236. # [12:21] <Lachy> Is this mail basically asking what string can be used for hasFeature() to test for selectors api? http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0035.html
  237. # [12:21] <annevk> I think so
  238. # [12:21] <Lachy> I don't see a compelling reason to define one
  239. # [12:22] <annevk> Me neither
  240. # [12:22] <hsivonen> if(document.whateverthenamewas)
  241. # [12:22] <annevk> exactly
  242. # [12:22] <Lachy> since hasFeature virtually never gets used int he wild and that alternative already works
  243. # [12:22] <annevk> and since hasFeature must die
  244. # [12:23] <Lachy> :-)
  245. # [12:24] * gsnedders stabs hasFeature
  246. # [12:27] <annevk> Lachy, as for -52, the second example they give in the HTML section is something the UA can't know and the Web author does and therefore the Web author doesn't use a password field at all and therefore the example is wrong
  247. # [12:29] * Philip` wonders how something like target="_blank-but-with-more-security-separation" would work, since JS code will have to determine whether the UA has that feature before deciding to use it (rather than falling back to window.open tricks) and that seems impossible to determine unless there's some API call that returns true when that feature is supported
  248. # [12:30] * Joins: myakura (n=myakura@p2098-ipbf4207marunouchi.tokyo.ocn.ne.jp)
  249. # [12:30] <annevk> the same is true for rel=noreferrer
  250. # [12:30] <annevk> oh, maybe rel=noreferrer is the solution?
  251. # [12:31] * annevk forgot
  252. # [12:31] * Joins: tndH_ (i=Rob@87.102.19.166)
  253. # [12:31] * tndH_ is now known as tndH
  254. # [12:32] <Lachy> annevk, I only see 1 HTML example, which appears to be missing the name attribute
  255. # [12:32] <Lachy> in section 3
  256. # [12:32] <Philip`> I guess in practice people would just use 'if (navigator.userAgent.indexOf('Firefox/4.0.) == -1) { /* use slow ugly fallback mechanism */ }' if they're not given any better way of determining supportedness
  257. # [12:33] <annevk> Lachy, the text that provides exceptions in terms of examples to the SHOULD-level requirement is what I was talking about
  258. # [12:33] <annevk> Philip`, yeah, transition periods are awkward now and then
  259. # [12:35] <Philip`> We're always in a transition period - nothing is going to settle down and stabilise until it's dead
  260. # [12:38] <annevk> individual features have shorter transition periods than that though
  261. # [12:38] <annevk> I agree that the Web as a whole has a slightly different model :)
  262. # [12:45] * Philip` wonders if by 2010 he'll be able to use transparent PNGs without style="-filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(...)"
  263. # [12:48] * hsivonen has used transparent PNGs without that kind of stuff since circa 2000
  264. # [12:49] * Philip` also needs the transparency to actually be transparent, and needs to work for a sufficiently large proportion of users
  265. # [12:54] * Quits: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  266. # [13:08] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  267. # [13:16] * Quits: webben (n=benh@nat/yahoo/x-60d88e2bbaa5d496)
  268. # [13:28] * Quits: roc (n=roc@121-72-31-154.dsl.telstraclear.net)
  269. # [13:28] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  270. # [13:29] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  271. # [14:01] * Joins: webben (n=benh@nat/yahoo/x-0bbca60bb57d2f3d)
  272. # [14:12] <Lachy> I just have 3 more issues to resolve in selectors api, and I'm done.
  273. # [14:13] <annevk> did you make a simple plain text issues list already?
  274. # [14:13] <Lachy> I'm not sure how to deal with these 2 regarding the IDL (see points 2 and 3 in this mail) http://lists.w3.org/Archives/Public/public-webapi/2007Dec/0072.html
  275. # [14:13] <annevk> point to DOM Bindings and say that we're going to use that
  276. # [14:14] <Lachy> not yet, I've just been tagging the mails in my mail archive. I will write out a list of issues from that later
  277. # [14:14] <annevk> k
  278. # [14:14] <annevk> in due course the Web API WG will use http://www.w3.org/TR/DOM-Bindings/ for its deliverables once that reaches a slightly more stable state
  279. # [14:15] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  280. # [14:15] <annevk> so currently the IDL syntax is more of an informative nature, really
  281. # [14:15] <Lachy> the 3rd issue is the one about using XHTML syntax instead of HTML syntax in examples http://lists.w3.org/Archives/Public/public-webapi/2008Jan/0004.html
  282. # [14:15] <annevk> and we do plan to fix that before going to PR
  283. # [14:15] <annevk> changing examples always introduces bugs is my experience
  284. # [14:16] <Lachy> I thought about using DOM Bindings, but wasn't sure, since it's not finished yet
  285. # [14:16] <Lachy> I'll check in my current revision now
  286. # [14:16] <annevk> we'll do DOM Bindings before CR or PR, whenever DOM Bindings itself is in PR/REC
  287. # [14:17] <annevk> (well, that's my idea anyway)
  288. # [14:21] <Philip`> When I buy postage stamps, I want them to have the Queen's head on them, not the word "LOVE" in large pink letters :-(
  289. # [14:25] <takkaria> I wonder why they have LOVE in large pink letters
  290. # [14:28] <Lachy> ann latest version checked in http://dev.w3.org/2006/webapi/selectors-api/
  291. # [14:28] <Lachy> s/ann/annevk/
  292. # [14:38] * Lachy sends off all responses to the last call comments for selectors api to public-webapi
  293. # [14:43] <annevk> I'm not really convinced with the exceptions story, still
  294. # [14:43] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  295. # [14:43] <annevk> even thoug I added them
  296. # [14:43] <annevk> using querySelector to test selector support seems wrong
  297. # [14:43] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  298. # [14:46] <Lachy> well, send mail about it to public-webapi and see what others think about the idea of removing exceptions
  299. # [14:46] <annevk> i remember having done that before
  300. # [14:50] <Lachy> you only sent me mail privately
  301. # [14:50] * Quits: Kuruma (n=Kuruman@h123-176-107-050.catv01.catv-yokohama.ne.jp) (Read error: 104 (Connection reset by peer))
  302. # [14:50] <Lachy> I don't recall seeing any discussion about removing exceptions on the mailing list
  303. # [14:51] <Lachy> here's that feedback I got from mjs about exceptions http://krijnhoetmer.nl/irc-logs/whatwg/20080208#l-17
  304. # [14:56] <annevk> i'm pretty sure it was on the list too and bjoern didn't like it for similar reasons as maciej or something
  305. # [15:00] <Lachy> if you did, I can't find it in pubilc-webapi
  306. # [15:09] * Joins: Kuruma (n=Kuruman@h123-176-107-050.catv01.catv-yokohama.ne.jp)
  307. # [15:41] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  308. # [15:44] * Quits: myakura (n=myakura@p2098-ipbf4207marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  309. # [15:48] * Joins: aroben (n=aroben@76.111.161.4)
  310. # [15:56] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("Leaving")
  311. # [15:56] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  312. # [15:57] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  313. # [16:00] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  314. # [16:02] * Quits: tndH (i=Rob@87.102.19.166) (Read error: 104 (Connection reset by peer))
  315. # [16:02] * Joins: tndH_ (i=Rob@87.102.19.166)
  316. # [16:02] * tndH_ is now known as tndH
  317. # [16:04] * Joins: phsiao (n=shawn@nat/ibm/x-35331374509b2387)
  318. # [16:20] * Joins: csarven (n=nevrasc@on-irc.csarven.ca)
  319. # [16:32] * Joins: billmason (n=billmaso@ip129.unival.com)
  320. # [16:34] <Philip`> Hmm, Firefox doesn't like setAttribute(':', ...)
  321. # [16:35] <gavin> I think jwalden might have a patch for that?
  322. # [16:35] <gavin> oh, no, I was thinking of bug 411103
  323. # [16:37] * Philip` tries filing https://bugzilla.mozilla.org/show_bug.cgi?id=417491
  324. # [16:41] <gavin_> data:text/html,%3Cbody%20:=""%20onload=%22try%20{%20document.body.setAttribute(':',%20'');%20alert('OK')%20}%20catch(e)%20{%20alert(e)%20}%22%3E works, though
  325. # [16:41] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  326. # [16:41] <gavin_> there's a bug on this already, I think
  327. # [16:42] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  328. # [16:42] <gavin_> https://bugzilla.mozilla.org/show_bug.cgi?id=390816
  329. # [16:43] <Philip`> gavin_: That looks different - ';' should be rejected because it's not a valid XML Name
  330. # [16:44] <hsivonen> Philip`: ":" is not a proper XMLNS name, though
  331. # [16:45] <hsivonen> (although Gecko has a dual XML 1.0 / XMLNS 1.0 nature in some things, IIRC)
  332. # [16:45] <Philip`> hsivonen: DOM just says it should be an XML name - the namespace things only affect setAttributeNS etc
  333. # [16:47] <gavin_> hmm
  334. # [16:47] * Philip` gives up trying to work out what DOMs can be safely constructed, and just wraps stuff in exception handlers
  335. # [16:47] <annevk> i think it makes sense to require XMLNS Name
  336. # [16:48] <annevk> so createElement can just become a shorthand for createElementNS(htmlns, name)
  337. # [16:49] * hsivonen agrees with annevk
  338. # [16:49] * gavin_ tries to understand MOZ_XMLCheckQName
  339. # [16:49] <hsivonen> on a second though, that won't work for XHR
  340. # [16:49] <hsivonen> so, no
  341. # [16:50] <hsivonen> since IE XHR is DOM Level 1, stuff like the Flickr API have to be XML 1.0 without XMLNS
  342. # [16:50] <hsivonen> yay for XMLNS
  343. # [16:51] <annevk> i don't understand
  344. # [16:51] <annevk> xhr requires a conforming xmlns parser
  345. # [16:52] <hsivonen> IE6 doesn't expose a namespace-aware API for XHR-loaded docs, IIRC
  346. # [16:53] <hsivonen> and Safari as shipped with Panther missealized namespaced XML
  347. # [16:53] <hsivonen> so RESTful XML APIs that want to be XHR-compatible have to live in the namespaceless XML 1.0 (< 5th ed.) world
  348. # [16:53] * gavin_ gives up trying to understand, uses a debugger instead
  349. # [16:54] <hsivonen> isserialized
  350. # [16:54] <hsivonen> misserialized
  351. # [16:54] <hsivonen> typo++
  352. # [16:54] <annevk> well namespaceless is fine
  353. # [16:55] <annevk> i'm just saying that they have to compatible with XMLNS for things to work
  354. # [16:56] <hsivonen> sure
  355. # [16:56] <Philip`> http://philip.html5.org/tools/parser/?%3C!DOCTYPE%20HTML%3E%0A%3Cx%3Ax%20x%3Ax%3E%3Cx%3A%3Ax%20x%3A%3Ax%3E%3Cx'x%20x'x%3E%3Cfoo%20%3Ax%3E
  356. # [16:56] <Philip`> Opera, Firefox and Safari all give different output :-(
  357. # [16:56] <Philip`> but at least Opera 9.2 and 9.5 are the same, and Firefox 2 and 3 are the same
  358. # [16:56] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  359. # [16:57] * Quits: bzed (n=bzed@devel.recluse.de) (Remote closed the connection)
  360. # [16:58] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) (Remote closed the connection)
  361. # [16:59] * Joins: bzed (n=bzed@devel.recluse.de)
  362. # [17:00] * Quits: bzed (n=bzed@devel.recluse.de) (Remote closed the connection)
  363. # [17:08] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  364. # [17:18] * Joins: bzed (n=bzed@devel.recluse.de)
  365. # [17:20] <annevk> Philip`, heh, cool stuff
  366. # [17:25] <annevk> weinig, jwalden (if you read this), any feedback on adding reply() ?
  367. # [17:36] <aroben> webben: Aaron's reply is interesting
  368. # [17:37] <aroben> annevk: ^^^
  369. # [17:37] <aroben> webben: sorry, misdirected that message
  370. # [17:38] <annevk> yeah, though then you want a callback for reply() too for longer conversations...
  371. # [17:39] <annevk> hmm
  372. # [17:41] <aroben> annevk: true
  373. # [17:41] <aroben> annevk: you could end up with some very long callback chains on either end
  374. # [17:41] <aroben> annevk: (well, I guess both ends, since the chains would have to be within one callback of each other in length)
  375. # [17:42] <annevk> yeah, seems icky
  376. # [17:43] <annevk> maybe postMessage should return a uuid and that uuid is exposed on the event
  377. # [17:43] <annevk> and when you invoke reply it automatically uses the same uuid
  378. # [17:44] <aroben> annevk: I guess that would be a little easier than what Gears does
  379. # [17:44] <aroben> annevk: since with Gears you have to embed the ID into your message string
  380. # [17:44] <annevk> yeah, with postMessage() you'd have to do that too now
  381. # [17:45] <aroben> annevk: right
  382. # [17:55] * Joins: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  383. # [17:56] <annevk> ok, posted that idea
  384. # [17:56] <annevk> i have a feeling that hixie's endpoints stuff does similar tricks, we'll see
  385. # [17:57] <annevk> but this proposal is not that more complex than what we have now, so it should be easier to have browsers updated in time with everyone's nearing release dates
  386. # [17:57] <aroben> annevk: "endpoints"?
  387. # [17:58] <annevk> http://hixie.ch/specs/dom/messages/0.9
  388. # [17:58] <annevk> i haven't carefully checked it yet after asking hixie for more rationale
  389. # [17:58] * aroben reads
  390. # [18:05] * Joins: virtuelv (n=virtuelv@109.80-202-65.nextgentel.com)
  391. # [18:11] <aroben> hm, I think there's a typo in the example on that page
  392. # [18:11] <aroben> gadgetWindow.endPoint.postMessage('get list-of-names', event.endPoint);
  393. # [18:11] <aroben> seems like it should just be
  394. # [18:12] <aroben> gadgetWindow.postMessage('get list-of-names', event.endPoint);
  395. # [18:13] <aroben> Hixie: ^^^
  396. # [18:29] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  397. # [18:54] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  398. # [19:12] <Hixie> oops. fixed.
  399. # [19:14] * Joins: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net)
  400. # [19:16] * aroben is now known as aroben|away
  401. # [19:22] * Joins: hober (n=ted@unaffiliated/hober)
  402. # [19:23] * Parts: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com)
  403. # [19:29] * Quits: webben (n=benh@nat/yahoo/x-0bbca60bb57d2f3d) (Connection timed out)
  404. # [19:39] * Joins: weinig (n=weinig@17.203.15.140)
  405. # [19:44] <Philip`> Ooh, a tokeniser change - how exciting
  406. # [19:47] * Philip` updates his four tokeniser implementations
  407. # [19:48] <Hixie> hah
  408. # [19:49] <Hixie> the graph of time-from-message-being-sent against probability of message being replied that day has a spike at t = 0 days
  409. # [19:51] <hsivonen> Hixie: do you have the graph online?
  410. # [19:54] * aroben|away is now known as aroben
  411. # [19:54] <Hixie> P|
  412. # [19:54] <Hixie> |
  413. # [19:54] <Hixie> |_
  414. # [19:54] <Hixie> | |
  415. # [19:54] <Hixie> | | ____ ?
  416. # [19:54] <Hixie> | |___...---'''
  417. # [19:54] <Hixie> |
  418. # [19:54] <Hixie> -+-------------------->t
  419. # [19:55] <Hixie> the start of it -- a few months -- looks like that
  420. # [19:55] <Hixie> dunno what the whole thing looks like
  421. # [19:55] <hsivonen> Hixie: thanks
  422. # [20:00] <Philip`> It's kind of odd how the Ruby html5lib claims to pass all the tokeniser tests, despite it not actually passing
  423. # [20:01] <Philip`> Aha, it does "return expected == received" instead of "assert_equal expected, received"
  424. # [20:01] <hsivonen> hmm. I wonder what the perf implications of query strings are with the new Access-Control-Policy-Path thing
  425. # [20:01] * hsivonen rereads the spec
  426. # [20:02] <hsivonen> hmm. looks good
  427. # [20:03] <hsivonen> now awaiting for an access-control-enabled browser, then
  428. # [20:03] <hsivonen> for validation mashups
  429. # [20:06] * Joins: maikmerten (n=maikmert@T60a1.t.pppool.de)
  430. # [20:14] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  431. # [20:15] <Philip`> So, I think the Python and Ruby and OCaml and C++ and JS and Perl tokenisers now match the spec again
  432. # [20:17] <Philip`> http://philip.html5.org/tools/parser/?%3C!DOCTYPE%20HTML%20%225%3E2%22%3E%0A...
  433. # [20:17] * Quits: bzed (n=bzed@devel.recluse.de) (Remote closed the connection)
  434. # [20:17] <Philip`> Hmm, that totally doesn't work right in Opera 9.2
  435. # [20:19] * Joins: bzed (n=bzed@devel.recluse.de)
  436. # [20:22] * Joins: G0k (n=hmason@rrdhcp78-57.redrover.cornell.edu)
  437. # [20:24] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  438. # [20:24] * Joins: DIrtyF (n=DirtyF@gar31-2-82-224-211-195.fbx.proxad.net)
  439. # [20:25] <zcorpan_> Philip`: you want http://philip.html5.org/tools/parser/?%3C!doctype%20html%20public%20%22%3E%20X
  440. # [20:25] * Quits: G0k (n=hmason@rrdhcp78-57.redrover.cornell.edu) (Client Quit)
  441. # [20:26] <Lachy> heh, I love how things are only bugs if one actually claims conformance :-) http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0071.html
  442. # [20:26] <hsivonen> Is RIM a browser vendor these days?
  443. # [20:26] <Philip`> zcorpan_: Argh, good point
  444. # [20:27] * Joins: G0k (n=hmason@rrdhcp78-57.redrover.cornell.edu)
  445. # [20:29] <Philip`> Lachy: I assume that means "claim" in the "returns true from hasFeature" sense, not in the "marketing material has it as a bullet pointed feature"; i.e. it would be alright for someone to have an incomplete/buggy implementation if hasFeature says it's not properly supported and shouldn't be used
  446. # [20:29] <Philip`> which seems more reasonable than how I initially read it :-)
  447. # [20:30] <zcorpan_> so if hasFeature returns false for everything, the UA is bug-free?
  448. # [20:30] <Lachy> zcorpan_, yes.
  449. # [20:30] <zcorpan_> awsome
  450. # [20:30] * Lachy goes to file a bug for opera about hasFeature returning true for somethings
  451. # [20:31] * SadEagle wonders whether there is a feature for hasFeature working...
  452. # [20:31] <SadEagle> Core 2.0 or something?
  453. # [20:31] <SadEagle> So if hasFeature for that returns false, doens't that mean that other return values are irrelevant? :-)
  454. # [20:31] <Lachy> SadEagle, I think it would be covered under the "DOM 2.0" features string (or whatever it is)
  455. # [20:32] <zcorpan_> hasFeature("hasFeature", "1.0")
  456. # [20:32] <zcorpan_> false
  457. # [20:32] <zcorpan_> :)
  458. # [20:33] <Philip`> If you return false for hasFeature then you will get the sort-of-gracefully degraded fallback path that authors have conscientiously provided for user agents that don't have the feature, and your users will hate you because they get a degraded experience, and so market forces will compel you to implement the feature perfectly so you can return true from hasFeature
  459. # [20:36] <Lachy> everything should just be implemented perfectly in every browser on the first attempt, and then hasFeature can be changed from a method to a single property that just equals true.
  460. # [20:38] <SadEagle> Philip`: might be interesting to see how many websites actually use hasFeature
  461. # [20:40] <Philip`> http://google.com/codesearch?q=show:mUNqRgxPl_s:oKMDwuYvdP4:CNlRzrngUHA&cs_p=http://www.devlib.org/apache/struts/source/struts-2.0.6-src.zip&cs_f=struts-2.0.6/src/core/src/main/resources/org/apache/struts2/static/dojo/dojo.js.uncompressed.js#l1157
  462. # [20:40] <Philip`> There's one
  463. # [20:41] <Philip`> http://google.com/codesearch?q=show:BNeIttp5oHc:5g2Z17w4TXQ:BXCuyDas2KE&cs_p=http://openrico.org/svn/openrico/trunk&cs_f=openrico/public/dist/1.1.2/rico.js#l1337
  464. # [20:41] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  465. # [20:42] <Philip`> http://google.com/codesearch?q=show:UWuK4cTDdZc:A3Gk8FzZWSM:L1InoVp7Omk&cs_p=http://gentoo.osuosl.org/distfiles/Plone-2.1.4.tar.gz&cs_f=Plone-2.1.4/kupu/common/sarissa_ieemu_xpath.js#l26
  466. # [20:42] <Philip`> It seems easy to find quite a few
  467. # [20:42] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  468. # [20:44] <SadEagle> heh, #1 follows it up with a UA sniff. #2 uses IE-specific path as a fallback, and will fail in konqueror, since it tests for "CSS", "2.0" --- odd thing to test if you want -events- support. #3 actually looks right :-)
  469. # [20:53] * Quits: maikmerten (n=maikmert@T60a1.t.pppool.de) (Remote closed the connection)
  470. # [21:02] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (IRC client for Emacs)")
  471. # [21:02] * Joins: mpt (n=mpt@222-155-7-6.jetstream.xtra.co.nz)
  472. # [21:07] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  473. # [21:15] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  474. # [21:15] * Joins: roc (n=roc@202.0.36.64)
  475. # [21:16] * Quits: bzed (n=bzed@devel.recluse.de) ("reboot")
  476. # [21:18] * Joins: bzed (n=bzed@devel.recluse.de)
  477. # [21:36] * Joins: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  478. # [21:38] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 110 (Connection timed out))
  479. # [21:39] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  480. # [21:40] <zcorpan_> "Making an implementation bug-free is outside the scope of the specification." -- http://www.w3.org/mid/24BE9C481C439C48831EB9E52639B9B60A8D4842@XCH42YKF.rim.net
  481. # [21:40] <zcorpan_> hmm, perhaps i have misunderstood the purpose of having specs
  482. # [21:42] * Quits: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  483. # [21:42] <SadEagle> it's to say what 'bug-free' means :-)
  484. # [21:43] <zcorpan_> i think its time for me to finetune my ignore flag again
  485. # [21:44] <gsnedders> I'm bug free.
  486. # [21:44] * Joins: csarven- (n=nevrasc@on-irc.csarven.ca)
  487. # [21:44] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  488. # [21:51] * Parts: DIrtyF (n=DirtyF@gar31-2-82-224-211-195.fbx.proxad.net)
  489. # [22:00] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  490. # [22:01] <Lachy> zcorpan_, technically that statement is correct, depending on how you read it. It's the implementor's responsibility to actually write the bug free code, not the specification. But it is the specification's responsibilty to ensure that things are defined well enough to be implemented in bug free ways
  491. # [22:14] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  492. # [22:15] * Quits: G0k (n=hmason@rrdhcp78-57.redrover.cornell.edu)
  493. # [22:36] * Quits: weinig (n=weinig@17.203.15.140)
  494. # [22:50] <gsnedders> RFC3986 doesn't reference RFC2119!
  495. # [22:50] * gsnedders is amazed
  496. # [22:53] <SadEagle> they don't capitalize SHOULD/MAY/etc.
  497. # [22:53] <Dashiva> http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0076.html
  498. # [22:53] <Dashiva> what on earth
  499. # [22:54] <Hixie> Sent from Yahoo! Mail - a smarter inbox
  500. # [22:59] <annevk> Lachy, one other thing to consider btw is to call StaticNodeList NodeList again and mention specifically that DOM Level 3 Core (and maybe previous versions) contains a bug as it calls it a live list where it just defines an interface
  501. # [23:00] <Hixie> isn't that what i said at the time :-P
  502. # [23:01] <annevk> i was convinced, but some other people were not
  503. # [23:01] <annevk> probably easier to get it through now, especially with webkit already doing it that way!
  504. # [23:02] <annevk> man, these SMIL people are pushy
  505. # [23:03] <Hixie> hm?
  506. # [23:04] <annevk> not really
  507. # [23:04] <annevk> just getting quite a bit of e-mail about this timesheets draft
  508. # [23:05] <Hixie> timesheets?
  509. # [23:05] <Hixie> wtf is that
  510. # [23:05] <gsnedders> That widely implemented draft, obviously.
  511. # [23:06] <Lachy> That would be easier
  512. # [23:06] <Lachy> I had assumed that window.DocumentSelector and window.ElementSelector would be exposed, since the interfaces for other DOM2 APIs are exposed
  513. # [23:06] * jgraham assumes timesheets is for doing things that were common on 90s era CD-ROMS
  514. # [23:08] <Lachy> aargh! What is wrong with Sergey's email client? Why is it putting one word per line?!
  515. # [23:08] <hsivonen> one of the spec editors demoed me timesheets
  516. # [23:08] <annevk> I think DocumentSelector and ElementSelector should not be exposed on Window
  517. # [23:08] <hsivonen> the demoed use case was doing S5 without the JS
  518. # [23:08] * gsnedders bravely presses send
  519. # [23:08] <annevk> they are redundant
  520. # [23:08] <annevk> hopefully DOM Bindings provides a way to say that
  521. # [23:09] <hsivonen> I quite liked the Apple CSS animation stuff for transitions and the like
  522. # [23:09] <annevk> yeah, we need that
  523. # [23:09] <SadEagle> Lachy: are DocumentTraversal, DocumentViews, ElementTarget, DocumentStyle, etc. exposed?
  524. # [23:09] <hsivonen> fits what already is there much better than SMIL
  525. # [23:09] <annevk> but the $%# CSS WG declared it out of charter
  526. # [23:10] <jgraham> I don't claim my assumptions about the purpose of timesheets are at all accurate
  527. # [23:10] <Lachy> SadEagle, Firefox exposes DocumentTraversal and DocumentStyle
  528. # [23:11] <SadEagle> Odd. But then the entire thing is a mozillaism everyone else had to emulate, making it a defacto standard :-)
  529. # [23:11] <annevk> SadEagle, EventTarget should be exposed, not sure what ElementTarget is
  530. # [23:11] <SadEagle> It's a very problematic thing to do, though.
  531. # [23:11] <annevk> I agree that exposing DocumentStyle and such makes no sense
  532. # [23:11] <SadEagle> annevk: that's what I meant... And I guess EventTarget makes sense, since it can be used as a base class.
  533. # [23:11] <SadEagle> Well, what should DocumentStyle.prototype point to?
  534. # [23:12] <Lachy> FF exposes EventTarget too. WebKit doesn't seem to expose any of them
  535. # [23:12] <annevk> probably maps to Document.prototype
  536. # [23:12] <annevk> I don't really like what Firefox does with interfaces at all
  537. # [23:12] <Lachy> why not?
  538. # [23:13] <annevk> there's now some Web content that relies on XMLDocument and HTMLSpanElement, HTMLUnknownElement and crap like that
  539. # [23:13] <Lachy> It makes sense for the ones that define constants, like Node.ELEMENT_NODE
  540. # [23:13] <annevk> well, that stuff makes sense
  541. # [23:13] <annevk> that stuff is also far more interoperable than what we're discussing here
  542. # [23:13] * Quits: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  543. # [23:14] <Hixie> good lord, the html wg is considering even more mailing lists
  544. # [23:15] <Lachy> Hixie, what more mailing lists are being considered?
  545. # [23:15] <Hixie> see #html-wg
  546. # [23:15] <SadEagle> annevk: those are the interfaces they have aren't in the DOM, right?
  547. # [23:18] <annevk> yeah
  548. # [23:22] * Joins: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  549. # [23:25] * Lachy ponders the idea of adding a hasFeature string to selectors api that implementors are not required to support :-)
  550. # [23:26] <Dashiva> hasFeature('Selectors.hasFeature')
  551. # [23:26] * aroben is now known as aroben|meeting
  552. # [23:27] <Hixie> good to know that the chair of the html working group doesn't read all the mail to the html working group
  553. # [23:30] * jgraham doesn't find that too encouraging
  554. # [23:31] * gsnedders wonders how many do
  555. # [23:31] <jgraham> Chairs of the WG or participants in general?
  556. # [23:31] <gsnedders> everyone in the WG
  557. # [23:31] <annevk> I skim each e-mail, though I delete some right away based on subject/sender
  558. # [23:32] <annevk> (that's not specific to the HTML WG though)
  559. # [23:32] <Hixie> i read everything, and save anything that looks useful to the folders for further study later
  560. # [23:33] <Hixie> i read public-html (and whatwg, and public-appformats and -webapi) before reading anything from the groups i'm not as actively in, like css or tag or http
  561. # [23:33] <jgraham> I ignore anything to do with <abbr> vs <acronym> as a matter of course. And occasionally I never get round to reading some messages.
  562. # [23:33] <gsnedders> I skim most things, though there are some things which I know so little about I just ignore from the subject
  563. # [23:34] <Philip`> I tend to look at all the words in everything, but I'm not sure if it counts as reading
  564. # [23:34] <Philip`> Mostly it's just a way of getting rid of the 'unread messages' marker
  565. # [23:35] <Hixie> yeah well some e-mails certainly don't get a very thorough reading
  566. # [23:35] <Hixie> especially those written in reply to e-mails that themselves didn't seem to get a thorough reading
  567. # [23:35] <Hixie> and i rarely spend more time reading an e-mail than the other person spent writing it
  568. # [23:36] <Hixie> (or thinking about it)
  569. # [23:36] <gsnedders> Hixie: I guess that means 10 seconds for most of my emails :)
  570. # [23:36] <gsnedders> (sadly)
  571. # [23:38] <Hixie> :-)
  572. # [23:41] <annevk> http://weblogs.mozillazine.org/doron/archives/2008/02/exe_tld_coming_soon.html :o
  573. # [23:41] * Joins: hober (n=ted@unaffiliated/hober)
  574. # [23:41] * gsnedders squints
  575. # [23:41] <SadEagle> that's not a new issue, though, see .pl :-)
  576. # [23:41] <gsnedders> silly Poland, thinking they deserve a TLD!
  577. # [23:42] <gsnedders> Or perhaps: Why's that relevant? I mean, who uses perl nowadays?
  578. # [23:42] * Joins: kingryan (n=ryan@dsl092-219-050.sfo1.dsl.speakeasy.net)
  579. # [23:42] * Joins: eseidel (n=eseidel@nat/google/x-c514d7883d400009)
  580. # [23:43] <annevk> SadEagle, heh, true
  581. # [23:43] * gsnedders is too tired to be truly witty
  582. # [23:43] <annevk> SadEagle, well, actually, .pl is not handled by the browser
  583. # [23:43] <Hixie> i'm mildly amused at how the w3c staff (except for mike) aren't actually an active part of the html5 community, despite them making process decision on the htmlwg
  584. # [23:44] <annevk> i don't really like it
  585. # [23:45] <SadEagle> annevk: it could be though, viewed as text... I am not sure where this distinction matters in mozilla, though (it showed up in KDE, but that was outside a web browser)
  586. # [23:46] <annevk> i wonder where browsers do extension sniffing though
  587. # [23:46] <annevk> HTML5 contains no such thing!
  588. # [23:46] <roc> there's also .au
  589. # [23:46] <Hixie> browsers do extension sniffing in the places where html5 explicitly says not to do extension sniffing
  590. # [23:47] <roc> there was a famous Gecko bug that only happened on files downloaded from Australia
  591. # [23:47] <roc> that took a while to figure out
  592. # [23:47] <Hixie> hah
  593. # [23:47] * Joins: heycam|sydney (n=cam@b4F38.static.pacific.net.au)
  594. # [23:50] * gsnedders waves g'nite
  595. # [23:52] <Hixie> 'course if .com is no problem, why would .exe be a problem
  596. # [23:54] <Philip`> http://eicar.com/download/eicar.com
  597. # [23:56] <annevk> Dashiva, you registered?
  598. # Session Close: Fri Feb 15 00:00:00 2008

The end :)