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

Options:

  1. # Session Start: Wed Jul 09 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:05] * Joins: Windstoss (n=wind@Ua8fe.u.pppool.de)
  4. # [00:08] * Quits: weinig (n=weinig@nat/apple/x-fb01de10b2f23a5c)
  5. # [00:15] * Joins: csarven (n=csarven@modemcable144.140-202-24.mc.videotron.ca)
  6. # [00:21] * Quits: heycam (n=cam@124-168-29-248.dyn.iinet.net.au) ("bye")
  7. # [00:28] * Quits: eseidel (n=eseidel@nat/google/x-9216514f7c33a535)
  8. # [00:31] * Quits: Windstoss (n=wind@Ua8fe.u.pppool.de)
  9. # [00:36] <Hixie> ok
  10. # [00:36] <Hixie> video
  11. # [00:37] * Joins: eseidel (n=eseidel@nat/google/x-fec18cc43e168926)
  12. # [00:39] <annevk> Hixie, any chance you can add tests for XMLHttpRequest and CSS url() to your URL encoding tests
  13. # [00:39] <annevk> Hixie, it would be good to know if the HTML5 definition of string->URI is implemented by browsers everywhere
  14. # [00:41] <Hixie> if you give me hte source of the test i'll add it
  15. # [00:41] <annevk> hmm, can you give me the source of the cgi script? maybe I can do something
  16. # [00:42] <Hixie> oh i just meant that if you provided what you wanted me to host i'd add it
  17. # [00:42] <Hixie> if you want to host it yourself, sure, i can send you the script too
  18. # [00:42] <Hixie> which would you prefer?
  19. # [00:42] <annevk> I want the results, I don't have anything yet to create the results
  20. # [00:42] <Hixie> i just don't want to spend time writing tests :-)
  21. # [00:42] <roc> doublec is now scared
  22. # [00:42] <doublec> very
  23. # [00:42] <annevk> right :)
  24. # [00:42] <annevk> Hixie, having the file would be a first step
  25. # [00:43] <annevk> Hixie, or maybe the entire directory as zip, while you're at it
  26. # [00:43] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  27. # [00:43] <Hixie> sure
  28. # [00:43] <jgraham> scared that Hixie doesn't want to spend ime writing testss? Or scared about the video work? Because I find the former scary...
  29. # [00:44] * jgraham swears the t key on this keybord is less senstive than the others
  30. # [00:44] <Hixie> annevk: ok, encoding.tar.gz in the parent directory
  31. # [00:44] <Hixie> doublec: any video feedback i should know of?
  32. # [00:44] <Hixie> s/of/about/
  33. # [00:44] <Philip`> jgraham: And the a and i keys too?
  34. # [00:45] <doublec> Hixie, nothing that hasn't already been discussed on the whatwg list
  35. # [00:45] <Hixie> doublec: k
  36. # [00:46] <jgraham> Philip`: Yeah maybe :)
  37. # [00:46] * Joins: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  38. # [00:49] * annevk notices Gears gets an Audio API
  39. # [00:49] * annevk wonders when it will tackle video codecs
  40. # [00:50] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  41. # [00:53] * Joins: franksalim (n=frank@ip-12-22-56-126.hqglobal.net)
  42. # [00:54] * annevk wonders what "rest of the world" means in the context of Roy Fielding
  43. # [00:55] <Hixie> I don't really identify with Roy's positions on standards-related things
  44. # [00:55] <jgraham> I was just wondering what the "error handling for the name on your birth certificate" comment was supposed to mean
  45. # [00:56] <Hixie> oh i missed that
  46. # [00:57] <jgraham> I mean I assume that there is some procedure that you can follow if the name on your birth certificate is wrong so there is defined error handling
  47. # [00:57] <annevk> I think he means that the protocol should not define the error handling, but the user of the protocol
  48. # [00:58] <jgraham> it happens that in that case there is two way communicaion between the client and the author which makes an interactive scheme possible but that's not a luxury we have
  49. # [00:58] <jgraham> How does "birth certificate" map to "protocol"? A birth certificate is a document
  50. # [00:59] <annevk> e.g. HTML can be implemented in a browser but also by some script. Each class would be allowed to have their own error handling or so...
  51. # [00:59] <jgraham> The protocol is the steps you go through to get one
  52. # [00:59] <annevk> though maybe I'm reading too much into it
  53. # [01:00] <jgraham> annevk: I understand that point but don't see how that corresponds to his analogy
  54. # [01:00] <jgraham> (as an aside there may be an issue worth considering in the context of non-browser applicaions
  55. # [01:01] <Hixie> validator.nu seems to be down
  56. # [01:01] <Hixie> different tools having different error handling is ridiculous
  57. # [01:02] <jgraham> which is that having a HTML-specific mapping between attribute values and URIs means that authors have to remember to use some HTML specific intermediary between their document representation and their IRI resolver
  58. # [01:02] <Hixie> the only variation that makes sense with error handling is aborting altogether on error
  59. # [01:02] <jgraham> s/URIs/IRIs/
  60. # [01:03] <jgraham> which is hard for script authors. It's much easier if here is one set of rules that everyone has to play by
  61. # [01:05] <annevk> I'm just trying to find out what his position is, but as you note, his example is confusing
  62. # [01:05] <hober> right, and that one set of rules needs to match what you need to work with the billions of documents out there, not what RFCNNNN says...
  63. # [01:06] <jgraham> hober: Indeed
  64. # [01:06] <annevk> I have a feeling URL as defined by HTML5 is what is used by browsers in most APIs they support
  65. # [01:25] * Quits: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  66. # [01:38] * Parts: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
  67. # [01:38] * Quits: eseidel (n=eseidel@nat/google/x-fec18cc43e168926)
  68. # [01:58] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 110 (Connection timed out))
  69. # [01:59] * Joins: othermaciej (n=mjs@17.255.96.90)
  70. # [02:08] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  71. # [02:08] * Joins: webben (n=benh@91.85.158.221)
  72. # [02:18] * Quits: othermaciej (n=mjs@17.255.96.90) (Success)
  73. # [02:23] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  74. # [02:30] <roc> annevk: what codecs does Gears support?
  75. # [02:33] <annevk> for Audio? dunno
  76. # [02:33] <annevk> ah, http://code.google.com/p/gears/wiki/AudioAPI says WAV and OGG
  77. # [02:33] <annevk> and that there's no clear plan for MP3
  78. # [02:34] * Joins: othermaciej (n=mjs@17.255.96.90)
  79. # [02:34] * Quits: billmason (n=billmaso@ip24.unival.com) (Read error: 104 (Connection reset by peer))
  80. # [02:46] <annevk> Hixie, Workers is going into HTML5?
  81. # [02:49] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  82. # [02:55] * annevk -> bed
  83. # [03:02] * Joins: svl (n=me@ppp105-186.static.internode.on.net)
  84. # [03:12] <roc> er
  85. # [03:12] <roc> Ogg "pending discussion about patent and license issues"
  86. # [03:12] <roc> hahaha
  87. # [03:12] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Less talk, more pimp walk.")
  88. # [03:13] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  89. # [03:20] <annevk> since I'm still awake, I thought Ogg Vorbis at least was shipped with the XBox et all and therefore "safe"
  90. # [03:33] * Joins: philipj (n=philipj@118.71.116.207)
  91. # [03:44] * Quits: philipj (n=philipj@118.71.116.207) (Remote closed the connection)
  92. # [03:44] * Joins: MikeSmith (n=MikeSmit@EM60-254-233-225.pool.e-mobile.ne.jp)
  93. # [03:51] * Quits: franksalim (n=frank@ip-12-22-56-126.hqglobal.net) ("Leaving")
  94. # [03:54] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  95. # [03:59] <MikeSmith> maybe it would be good to have a validator.nu mirror on html5.org .. v.html5.org
  96. # [04:00] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 60 (Operation timed out))
  97. # [04:15] * Joins: othermaciej_ (n=mjs@17.255.96.90)
  98. # [04:15] * Quits: othermaciej (n=mjs@17.255.96.90) (Read error: 104 (Connection reset by peer))
  99. # [04:20] * Quits: roc (n=roc@202.0.36.64)
  100. # [04:21] * Quits: MikeSmith (n=MikeSmit@EM60-254-233-225.pool.e-mobile.ne.jp) ("Less talk, more pimp walk.")
  101. # [04:21] * Quits: othermaciej_ (n=mjs@17.255.96.90)
  102. # [04:22] * Joins: othermaciej (n=mjs@17.255.96.90)
  103. # [04:35] * Joins: tantek (n=tantek@72-56-143-182.area2.spcsdns.net)
  104. # [04:41] * Joins: MikeSmith (n=MikeSmit@EM60-254-233-225.pool.e-mobile.ne.jp)
  105. # [04:44] * Quits: othermaciej (n=mjs@17.255.96.90)
  106. # [04:45] * Joins: othermaciej (n=mjs@17.255.96.90)
  107. # [04:56] * Quits: tantek (n=tantek@72-56-143-182.area2.spcsdns.net) (Read error: 54 (Connection reset by peer))
  108. # [04:58] * Joins: tantek (n=tantek@99-200-135-237.area2.spcsdns.net)
  109. # [05:04] <Hixie> annevk: either in html5 or a separate spec
  110. # [05:04] <Hixie> it isn't clear what is best for workers
  111. # [05:04] <Hixie> on the one hand, workers need to tightly integrate with much of html5, and an extra spec is a lot of overhead
  112. # [05:04] <Hixie> on the other hand, workers are a separate feature and adding making html5 bigger isn't going to be popular
  113. # [05:05] * Quits: tantek (n=tantek@99-200-135-237.area2.spcsdns.net) (Connection reset by peer)
  114. # [05:20] <othermaciej> my biggest worry about a separate spec is that we'd get lots of complaints (and attempted process blockage) about the inevitable HTML5 dependencies
  115. # [05:20] <othermaciej> I am ok with a separate spec if we have buy-in that such dependencies are acceptable
  116. # [05:22] <Hixie> i get the feeling this is complicated enough material that bikeshedding won't be an issue
  117. # [05:27] * Quits: svl (n=me@ppp105-186.static.internode.on.net) ("And back he spurred like a madman, shrieking a curse to the sky.")
  118. # [06:00] * Joins: othermaciej_ (n=mjs@17.255.96.90)
  119. # [06:00] * Quits: othermaciej (n=mjs@17.255.96.90) (Read error: 104 (Connection reset by peer))
  120. # [06:01] * Quits: othermaciej_ (n=mjs@17.255.96.90) (Read error: 104 (Connection reset by peer))
  121. # [06:01] * Joins: othermaciej (n=mjs@17.255.96.90)
  122. # [06:14] * Joins: othermaciej_ (n=mjs@17.255.96.90)
  123. # [06:14] * Quits: othermaciej (n=mjs@17.255.96.90) (Read error: 104 (Connection reset by peer))
  124. # [06:25] * Quits: othermaciej_ (n=mjs@17.255.96.90)
  125. # [06:26] * Joins: othermaciej (n=mjs@17.255.96.90)
  126. # [06:38] * Quits: csarven (n=csarven@modemcable144.140-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  127. # [06:58] * Joins: othermaciej_ (n=mjs@17.255.96.90)
  128. # [06:58] * Quits: othermaciej (n=mjs@17.255.96.90) (Read error: 104 (Connection reset by peer))
  129. # [07:03] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  130. # [07:14] * Quits: othermaciej_ (n=mjs@17.255.96.90)
  131. # [07:40] * Quits: MikeSmith (n=MikeSmit@EM60-254-233-225.pool.e-mobile.ne.jp) ("Less talk, more pimp walk.")
  132. # [07:45] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  133. # [07:48] * Quits: shepazu (n=schepers@cpe-069-134-123-228.nc.res.rr.com) (Read error: 104 (Connection reset by peer))
  134. # [07:49] * Joins: shepazu (n=schepers@cpe-069-134-123-228.nc.res.rr.com)
  135. # [07:56] * Joins: MikeSmith (n=MikeSmit@dhcp-246-138.mag.keio.ac.jp)
  136. # [08:07] * Quits: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
  137. # [08:07] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  138. # [08:07] * Joins: roc (n=roc@222-152-162-240.jetstream.xtra.co.nz)
  139. # [08:23] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  140. # [08:24] <annevk> I'd prefer a separate document, but I don't feel strongly about it
  141. # [08:29] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  142. # [08:29] <MikeSmith> I think Workers as a separate doc would make our lives easier
  143. # [08:30] <MikeSmith> And I'd certainly be willing to run cover on dealing with complaints about the HTML5 dependencies for it, and any process-blocking attempts
  144. # [08:32] <MikeSmith> as far as I can see, UA implementors seem to pretty much universally agree that having a standard workers spec would be great
  145. # [08:34] <annevk> I guess the main problem is that it bolds on top of postMessage in part, and also builds on top of Window
  146. # [08:35] <MikeSmith> yeah, but those kinds of dependencies on HTML5 are going to be true of any major feature that's introduced that has any implementation impact on UAs
  147. # [08:35] <MikeSmith> meaning pretty much everything
  148. # [08:35] <Hixie> ok
  149. # [08:35] <Hixie> so, separate doc it is
  150. # [08:35] <MikeSmith> impossible to get around that since HTML5 is defining many infrastructure details that have never been defined before
  151. # [08:36] <Hixie> how do people like "Web Threads"
  152. # [08:36] <annevk> I guess that's true, but from what I've seen of Workers it seems worse than for XMLHttpRequest, for instance
  153. # [08:36] <annevk> Hixie, hehe, fine by me :)
  154. # [08:38] <MikeSmith> Hixie: "Web Threads" seems nice and simple to me.. and consistent with current trends (Web IDL, Web Sockets)
  155. # [08:38] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  156. # [08:39] * Quits: webben (n=benh@91.85.158.221) (Read error: 110 (Connection timed out))
  157. # [08:41] * Hixie wonders how to set this up so he can still use his spec development toolchain
  158. # [08:42] * Joins: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  159. # [08:44] <Hixie> i guess i don't need the stuff to handle large files
  160. # [08:45] <Hixie> nor do i need the status annotation stuff
  161. # [08:45] <Hixie> and i can use the same issues system
  162. # [08:46] <othermaciej> Hixie: I would rather it use Workers instead of Threads in the name
  163. # [08:47] <othermaciej> Hixie: since they may not be implemented as threads
  164. # [08:47] <othermaciej> and it would be bad to bias the name
  165. # [08:47] <Hixie> Web Workers?
  166. # [08:47] <Hixie> that works too
  167. # [08:47] <othermaciej> also to some people Thread may imply shared memory, while these are shared-nothing
  168. # [08:47] <othermaciej> (w/ message passing)
  169. # [08:47] <othermaciej> or just Workers, though I don't mind the Web prefix
  170. # [08:48] <Hixie> if i work on it, it has the Web prefix. :-)
  171. # [08:48] * MikeSmith is less enthusiastic about "Web Workers", because of it already meaning something else
  172. # [08:49] <Hixie> Web Worker Threads? :-)
  173. # [08:49] <annevk> "web workers" only has ~52k hits on Google
  174. # [08:49] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  175. # [08:49] <Hixie> what does Web Workers mean?
  176. # [08:49] <Dashiva> Could always drag out SPMD or some other acronym :)
  177. # [08:50] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  178. # [08:50] <annevk> Hixie, it's about people making money on the Web, it seems
  179. # [08:50] <MikeSmith> here in Japan it's used a lot to describe people who do Web-related work -- Web designers and developers
  180. # [08:50] <othermaciej> Web WorkQueues?
  181. # [08:50] <MikeSmith> but then a lot of people I meet here have business cards that say "Markup Engineer"
  182. # [08:50] <annevk> Hixie, so it seems there's not much of a clash if you use it to describe a threading technology
  183. # [08:51] * Joins: hdh (n=hdh@58.187.60.226)
  184. # [08:51] <Hixie> "Web Workqueue" has no hits on google
  185. # [08:51] <Hixie> but i don't know if that's better than web workers
  186. # [08:52] <Dashiva> Maybe webapp or web application instead of web?
  187. # [08:52] <Hixie> i'll just use Web Workers
  188. # [08:52] <Hixie> we can always change the exact name later
  189. # [08:52] <Hixie> doesn't matter what the directory is called really
  190. # [08:52] <annevk> (workqueue is annoying to spell)
  191. # [08:52] <Hixie> i mean html5 still says "webapps"
  192. # [08:53] <Hixie> anne: but it has the shortname "wwq"
  193. # [08:53] <othermaciej> you can be silly and call it workq
  194. # [08:53] <Hixie> ew
  195. # [08:53] <othermaciej> though that has the downside of looking like a typo
  196. # [08:53] <othermaciej> I think worker is a fine name though
  197. # [08:53] <Dashiva> Webqueues
  198. # [08:54] <MikeSmith> I think it's likely that we're going to most often keep calling them just "workers" anyway, whatever the documented name is
  199. # [08:54] <Hixie> yep
  200. # [08:58] <annevk> othermaciej, I'm pretty sure we decided against double GET on day 3
  201. # [08:58] <annevk> othermaciej, like 99% certain
  202. # [08:59] <othermaciej> annevk: I don't think so - we agreed that would be good conditional on Microsoft committing to using the protocol profile
  203. # [08:59] <othermaciej> (and that was not even a formal RESOLUTION afaik)
  204. # [09:00] <Hixie> yet another reasons f2fs aren't any good -- you don't know what you agreed to
  205. # [09:00] <othermaciej> prior to that, we resolved to use the double-GET approach on the assumption that there was no way MS would change for IE8
  206. # [09:00] <Hixie> s/you don't/one doesn't/
  207. # [09:01] <othermaciej> currently we are waiting on their answer, though I believe Sunava has gone past his self-imposed deadline
  208. # [09:01] <Hixie> SHOCKING
  209. # [09:01] <annevk> othermaciej, you're indeed correct
  210. # [09:01] <annevk> per http://www.w3.org/2008/07/03-wam-minutes (W3C Member only) that is
  211. # [09:02] <MikeSmith> time for me or shepazu to ping Sunava about it, I guess
  212. # [09:02] <annevk> what's currently specified assumes a positive reply from MS; we'll see
  213. # [09:03] <MikeSmith> I thought the agreement was that we recognized we needed to move on regardless of whether we got a response from them or not
  214. # [09:03] <othermaciej> that is a generous assumption
  215. # [09:03] * Joins: heycam (n=cam@124-168-29-248.dyn.iinet.net.au)
  216. # [09:03] <othermaciej> I think our plan was not to change from the day 2 resolution until we got a response
  217. # [09:03] <othermaciej> at least that was my understanding
  218. # [09:03] <MikeSmith> OK
  219. # [09:03] <Hixie> me too
  220. # [09:03] <MikeSmith> yeah, that's what I was trying to say too
  221. # [09:04] <annevk> othermaciej, my understanding was also that I would draft the profile thing they could use before the end of this week
  222. # [09:04] <othermaciej> annevk: yeah, so maybe we need both versions drafted
  223. # [09:04] <annevk> othermaciej, and since the profile thing and not doing double GET goes hand in hand, I did that
  224. # [09:05] <annevk> othermaciej, hmm, yeah
  225. # [09:10] <Hixie> you'll likely have to write the other one anyway
  226. # [09:11] <Hixie> might as well write it and provide the two revisions as separate links to the wg
  227. # [09:11] <Hixie> it's easy to switch from one rev to another
  228. # [09:12] * Joins: svl (n=me@ppp105-186.static.internode.on.net)
  229. # [09:22] * Joins: Windstoss (n=wind@U9ff3.u.pppool.de)
  230. # [09:24] <Hixie> where on the mess that is dev.w3.org should this web-workers spec go?
  231. # [09:25] <Hixie> html5/web-workers?
  232. # [09:25] <Hixie> webapps/workers ?
  233. # [09:26] <MikeSmith> Hixie: either. we can move/renames it on the cvs server side later if needed
  234. # [09:26] <Hixie> k
  235. # [09:26] <annevk> (the last one makes more sense to me)
  236. # [09:26] <Hixie> html5/workers it is
  237. # [09:27] <Hixie> i'd use /webapps/ but i don't want to mint yet another root directory
  238. # [09:27] <annevk> fair enough
  239. # [09:27] <Hixie> i think i've minted two on that server already
  240. # [09:29] <Hixie> hey mike
  241. # [09:29] <Hixie> did anything ever come of that thing with rigo?
  242. # [09:30] <Hixie> i still plan to publish in august
  243. # [09:30] <Hixie> which is fast approaching
  244. # [09:34] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  245. # [09:36] <MikeSmith> Hixie: I've not gotten any resolution with Rigo about it
  246. # [09:37] <MikeSmith> I do realize we're going to need to before we publish the next WD
  247. # [09:38] <annevk> pointer?
  248. # [09:39] <Hixie> i don't think it was ever archived somewhere public
  249. # [09:39] <annevk> k, guess I sort of know what it is about
  250. # [09:39] <Hixie> not that anyone should take this as evidence that the w3c isn't fully open
  251. # [09:39] <Hixie> the other thing is the xhtml2wg's problem with the relationshiup to xhtml1 section
  252. # [09:39] <Hixie> which they haven't gotten back to us about
  253. # [09:40] <Hixie> i guess we just publish as is if they haven't gotten back to us
  254. # [09:41] <Hixie> maybe we should let them know that we plan to publish in august
  255. # [09:41] <Hixie> so they don't blame us for being too fast or something
  256. # [09:42] <annevk> seems they're working on something
  257. # [09:42] <Hixie> oh?
  258. # [09:42] <Hixie> i didn't see anything in the minutes
  259. # [09:43] <annevk> somewhere in the middle an action as assigned to Steven
  260. # [09:43] <annevk> there was no discussion around it
  261. # [09:43] <annevk> very weird
  262. # [09:43] <Hixie> ah, missed that
  263. # [09:44] <MikeSmith> I don't think the rationale that Roland gave (for their request to remove the offending text) will stand up to much scrutiny
  264. # [09:44] <MikeSmith> it seems like he was not questioning whether it was accurate
  265. # [09:44] <Hixie> what was the rationale?
  266. # [09:44] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  267. # [09:45] <MikeSmith> I think he was basically saying that it gave the appearance that the XHTML2 WG was not chartered to maintain the "XHTML family of languages"
  268. # [09:46] <MikeSmith> and I think I responded to say that was neither the intent nor the actual effect
  269. # [09:46] <Hixie> i don't really care what we say so long as it is clear, explanatory and accurate
  270. # [09:46] <MikeSmith> I think the current text qualifies as all those
  271. # [09:46] <Hixie> yes
  272. # [09:47] <Hixie> We could also add
  273. # [09:48] <Hixie> "Note that the W3C has also chartered another working group to work on the XHTML family of specifications."
  274. # [09:48] <Hixie> if they want
  275. # [09:48] <annevk> http://www.w3.org/2008/06/26-pf-minutes.html#item07 (W3C Member only) is also interesting
  276. # [09:48] <MikeSmith> Hixie: maybe that would be good. Maybe that's what they can request
  277. # [09:49] <MikeSmith> I'm not sure we should volunteer adding it unless/until they get back to us with suggested revised text
  278. # [09:49] <MikeSmith> and lacking that, I don't so that we are required to remove it simply because they've requested it
  279. # [09:50] <MikeSmith> if it were LC, it'd be a different matter, I guess
  280. # [09:50] <MikeSmith> but it's not LC
  281. # [09:50] <Hixie> well, from the point of view of working in good faith, i'm just saying we should let them know our timetable
  282. # [09:50] <Hixie> since they may not be expecting us to work punctually
  283. # [09:50] <MikeSmith> OK
  284. # [09:50] <MikeSmith> yeah, understood
  285. # [09:50] <Hixie> not rush them or anything
  286. # [09:53] <gDashiva> Speaking of xhtml2, are they exempt from heartbeat, or do all their non-xhtml2 drafts count towards it?
  287. # [09:53] <annevk> making this proposal seems like a goo thing too
  288. # [09:53] <annevk> gDashiva, heartbeat is ultimately a per-group and not a per-document requirement
  289. # [09:53] <annevk> gDashiva, and is also pretty much universally ignored
  290. # [09:56] <MikeSmith> the process doc still states clearly that groups should publish WDs of their specs every 3 months, and if they can't do that, instead publish some kind of status report at least
  291. # [09:58] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  292. # [09:58] <Hixie> the status document says a lot of things
  293. # [10:02] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  294. # [10:03] <annevk> and it continues: http://intertwingly.net/blog/2008/07/02/authoritative-true#c1215587954
  295. # [10:09] <Hixie> i love how rob refers to hte "the W3C priority of constituencies"
  296. # [10:09] <Hixie> i wonder if he realises taht that concept was basically first pushed by the whatwg crowd
  297. # [10:16] * Joins: aaronlev (n=chatzill@dslb-088-064-142-245.pools.arcor-ip.net)
  298. # [10:18] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
  299. # [10:18] * Quits: aaronlev (n=chatzill@dslb-088-064-142-245.pools.arcor-ip.net) (Read error: 104 (Connection reset by peer))
  300. # [10:21] * Parts: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
  301. # [10:22] * Quits: svl (n=me@ppp105-186.static.internode.on.net) ("And back he spurred like a madman, shrieking a curse to the sky.")
  302. # [10:23] * Joins: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
  303. # [10:26] * Joins: aaronlev (n=chatzill@dslb-088-064-142-245.pools.arcor-ip.net)
  304. # [10:27] <annevk> whatwg.org down?
  305. # [10:27] <Hixie> yeah
  306. # [10:27] <Hixie> nfs issues again
  307. # [10:28] <Hixie> sent them mail already
  308. # [10:30] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Remote closed the connection)
  309. # [10:41] * Joins: webben (n=benh@nat/yahoo/x-611b89e14ac1d943)
  310. # [10:43] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  311. # [10:57] * Joins: ROBOd (n=robod@89.122.216.38)
  312. # [10:58] <zcorpan> "Where is the HTML version of Line Rider? It is in Flash and Silverlight now. If you want to see something really interesting check out Hard Rock Cafe’s memorabilia page (Silverlight 2 required) and tell me if you’ve ever seen something like that with HTML." -- http://pseudosavant.com/blog/2008/07/08/a-proprietary-web-blame-the-w3c/
  313. # [11:00] <zcorpan> can that be implemented with canvas?
  314. # [11:00] <Philip`> (Also http://tech.slashdot.org/article.pl?sid=08/07/08/1730231 for other comments on that)
  315. # [11:01] <zcorpan> flash line rider http://www8.agame.com/mirror/flash/l/linerider_v1_5.swf
  316. # [11:01] <Philip`> I don't see any reason why it couldn't
  317. # [11:04] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  318. # [11:06] <zcorpan> so who's gonna implement it in canvas? :)
  319. # [11:08] <annevk> from the comments: "If WHATWG had done its job correctly, we’d be on HTML 6 by now and nobody would be using IE7 due to it being horribly out of date."
  320. # [11:08] <annevk> also, "But it became a victim of the same process bloat that plagues the W3C, and so we’re still stuck using proprietary technologies."
  321. # [11:09] <Philip`> zcorpan: You could :-)
  322. # [11:10] <zcorpan> Philip`: gotta file more canvas bugs first :P
  323. # [11:10] <zcorpan> Philip`: if you didn't write so many test cases i'd be done by now!
  324. # [11:12] <Philip`> zcorpan: Once you've finished, writing non-trivial canvas examples is a good way to find more bugs - I don't think I've ever written anything where I haven't encountered new bugs :-)
  325. # [11:13] <Philip`> zcorpan: Blame the Opera developers for having so many bugs in their code :-p
  326. # [11:13] <zcorpan> Philip`: :)
  327. # [11:15] <annevk> Philip`, what do you think filing a bug means? :p
  328. # [11:15] <Philip`> or blame Hixie for changing the spec so that what Opera implements is now a bug
  329. # [11:34] <MikeSmith> annevk: regarding that blog posting, seems like just yet another tale "full of sound and fury"
  330. # [11:34] <MikeSmith> http://clicknotes.com/macbeth/T55.html#26
  331. # [11:35] <MikeSmith> or yet another poor player just strutting and fretting
  332. # [11:37] <gDashiva> I wonder how many Tom Lehrer fans recognize the MacBeth quote
  333. # [11:43] <annevk> MikeSmith, he makes some valid points
  334. # [11:57] * Joins: jacobolus (n=jacobolu@pool-71-119-200-174.lsanca.dsl-w.verizon.net)
  335. # [12:13] <Lachy> ah, damn. the live-dom-viewer is down. :-(
  336. # [12:16] * Quits: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  337. # [12:16] * Quits: aaronlev (n=chatzill@dslb-088-064-142-245.pools.arcor-ip.net) (Read error: 60 (Operation timed out))
  338. # [12:20] <jgraham> The problem is that it is much easier to introduce cool new features unilaterally and ship them in the next version of your priprietry runtime than it is to take them through a standards process and then wait for your competitors to implement them before anyone is prepared to use them
  339. # [12:20] * Joins: myakura (n=myakura@p1216-ipbf601marunouchi.tokyo.ocn.ne.jp)
  340. # [12:22] <jgraham> So even though the w3c is pretty slow it's not clear that's where the real problem lies
  341. # [12:22] <Philip`> The problem is standards, so the solution is to not do standards
  342. # [12:23] <Lachy> JohnResig, are there any Firefox builds available publicly with support for selectors api?
  343. # [12:24] * Quits: myakura (n=myakura@p1216-ipbf601marunouchi.tokyo.ocn.ne.jp) (Client Quit)
  344. # [12:25] * Joins: tndH (i=Rob@adsl-77-86-108-88.karoo.KCOM.COM)
  345. # [12:25] <jgraham> Philip`: From the point of view of Microsoft that's really true. From the point of view of the end user it depends what your priorities are
  346. # [12:25] <Philip`> As an end user, I want cool stuff
  347. # [12:26] <jgraham> Yeah, clearly most end users are prepared to install Flash so they can watch the video at standardssuck.org and not worry about whether it is proprietry or not
  348. # [12:26] <jgraham> s/standardssuck.org/youtube/ maybe ;)
  349. # [12:33] <jgraham> I guess we're pretty lucky that Flash sucks so much at basic stuff like text form controls and bookmarkability
  350. # [12:33] <roc> Lachy: not that I know of, I think it's still in Boris' tree
  351. # [12:40] <annevk> I think with the WHATWG we're sort of getting to the state of specifying competitive features in a timely manner and getting them shipped
  352. # [12:42] <annevk> Lachy, IE throwing for |div and all is fine as IE doesn't support all of Selectors
  353. # [12:42] <othermaciej> Hixie: the Design Principles document shows the power of writing things down (and of actually having principles)
  354. # [12:42] <othermaciej> those were all things people fought about tooth and nail in the early days of the WG
  355. # [12:42] <othermaciej> now they are canon
  356. # [12:42] <annevk> that is indeed quite amazing
  357. # [12:43] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  358. # [12:45] <annevk> roc, fwiw, I'd be in favor of having it without prefix, there's plenty of precedent for that too (provided you're willing to make changes to details)
  359. # [12:45] <roc> yeah
  360. # [12:45] <roc> the Web isn't going to depend on it in a hurry
  361. # [12:46] <annevk> right
  362. # [12:47] <Lachy> annevk, ok.
  363. # [12:48] <Lachy> annevk, it seems IE8 makes it impossible to know what type of exception was thrown. I can't tell if it's a syntax err or namespace err
  364. # [12:49] <annevk> make sure to test it in the testsuite
  365. # [12:49] <annevk> e.code and all
  366. # [12:50] <Lachy> annevk, yeah, it will be
  367. # [12:50] * Joins: webben_ (n=benh@nat/yahoo/x-22c5c308469a2a9a)
  368. # [12:51] <Lachy> today, I'm going through the backlog of issues and responding.
  369. # [12:52] <Hixie> othermaciej: i'm not convinced the effort required to write them down was a price worth paying to get rob to quote those principles back at me as if i wasn't following them
  370. # [12:53] <annevk> it's certainly entertaining
  371. # [12:54] <Lachy> has anyone seen any demand for a hasFeature string from implementers of other languages implementing selecotrs api? e.g. Java?
  372. # [12:54] * Joins: webben__ (n=benh@nat/yahoo/x-7e56a9864acbbdce)
  373. # [12:55] * gDashiva looks for the "Don't disrupt the WG activity for no good reason" design principle
  374. # [12:55] <Lachy> gDashiva, look up netiquette guidelines for that
  375. # [12:56] * Quits: MikeSmith (n=MikeSmit@dhcp-246-138.mag.keio.ac.jp) (Read error: 110 (Connection timed out))
  376. # [12:56] <annevk> ah, whatwg.org is back up
  377. # [12:56] * annevk spots http://www.whatwg.org/specs/web-workers/current-work/
  378. # [12:58] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  379. # [12:58] <Hixie> any chance we can get http://html5.org/tools/web-workers-tracker ? :-)
  380. # [12:58] <Lachy> Hixie, why is there a new spec? Is HTML5 being split up into several?
  381. # [12:58] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  382. # [12:59] * jgraham notes that web workers seems like a very silly name
  383. # [12:59] <Hixie> people wanted workers not to be added to html5
  384. # [12:59] <jgraham> Just becauseit sounds funny
  385. # [12:59] <jgraham> But I don't actually object :)
  386. # [13:00] <jgraham> Isn't HTML5 supposed to be in feature freeze?
  387. # [13:00] <Hixie> well, technically this wasn't added to the html5 spec, so sure :-)
  388. # [13:00] <Lachy> ok, so what's the criteria for something to be moved to that spec, or left in the existing spec? Is it just the few things mentioned in the introduction like canvas, context menus and server-sent events?
  389. # [13:00] <Hixie> but in any case, the feature freeze is intended to prevent the spec from getting too far ahead of implementations
  390. # [13:00] <annevk> Hixie, http://html5.org/tools/web-apps-tracker?source=http://svn.whatwg.org/webworkers/source works...
  391. # [13:01] <annevk> Hixie, though the links and such will be broken, so it doesn't totally work
  392. # [13:01] <Hixie> so if implementations get ahead of the spec (as they were threatening to with workers), the freeze isn't useful
  393. # [13:01] <Hixie> Lachy: nothing will be moved to web workers
  394. # [13:01] <Hixie> Lachy: it's for workers
  395. # [13:01] <Hixie> Lachy: which are new
  396. # [13:01] <Lachy> oh, ok. What is a worker?
  397. # [13:02] <takkaria> Hixie: webworkers still has <title>HTML 5</title>
  398. # [13:02] <Hixie> background thread for js
  399. # [13:02] <annevk> Lachy, the introduction is a copy from somewhere else
  400. # [13:02] <Hixie> did i forget to change the intro?
  401. # [13:02] <Hixie> oops
  402. # [13:02] * Hixie goes to fix
  403. # [13:02] <Lachy> yeah, the abstract is from html5
  404. # [13:02] <Hixie> oh the abstract
  405. # [13:03] <annevk> abstract/intro, meh
  406. # [13:04] * Quits: webben (n=benh@nat/yahoo/x-611b89e14ac1d943) (Connection timed out)
  407. # [13:04] <Hixie> fixed
  408. # [13:07] <Lachy> Hixie, also, the abstract in HTML5 is wrong. It still mentions inline popup windows, which were never included.
  409. # [13:07] <gDashiva> Lachy: Apparently certain wg participants don't feel netiquette is part of our charter :)
  410. # [13:07] <Lachy> oh, it isn't? Cool. I should participate in more flamewars then.
  411. # [13:08] <takkaria> http://www.whatwg.org/specs/web-workers/current-work/'s <title> is still HTML 5. :)
  412. # [13:10] <Philip`> I hope you don't want a multipage version of this
  413. # [13:10] * Quits: webben_ (n=benh@nat/yahoo/x-22c5c308469a2a9a) (Read error: 113 (No route to host))
  414. # [13:11] <Hixie> takkaria: oops
  415. # [13:11] <gDashiva> Philip`: No, but he'll want it preprocessed using workers :P
  416. # [13:11] <Hixie> fixed.
  417. # [13:14] <roc> if flamewars aren't valid netiquette, then the spec should be changed to match reality
  418. # [13:15] <annevk> yeah, writing specs that are not implemented is no fun
  419. # [13:16] <Hixie> Lachy: updated the abstract
  420. # [13:20] <annevk> showModalDialog is sort of an inline popup
  421. # [13:22] <jgraham> Framewars should be non-conformant but have defined error handling
  422. # [13:22] <jgraham> s/Frame/Flame/
  423. # [13:23] <annevk> <frame>wars too!
  424. # [13:25] * Joins: MikeSmith (n=MikeSmit@EM119-72-86-230.pool.e-mobile.ne.jp)
  425. # [13:25] <Lachy> yeah, there are many things in RFC 1855 that need to be updated to deal with common situations, like bikeshedding, banning HTML mail, banning the use of broken mail clients that destroy threading and quoting, etc.
  426. # [13:28] <othermaciej> Hixie: sure, he's still irritating, but accepting your principles as the ground rules makes it harder for him to argue
  427. # [13:28] <othermaciej> remember, he could be much worse
  428. # [13:28] <othermaciej> and has been!
  429. # [13:30] * Joins: sverrej (n=sverrej@213.197.167.14)
  430. # [13:30] <Hixie> it doesn't seem to have made any difference to the quality of his arguments
  431. # [13:31] <Hixie> you know, i get mixed messages from the opera crowd
  432. # [13:31] <Hixie> or rather, i get mixed messages from chaals relative to the rest of opera.
  433. # [13:33] <Hixie> ok. i have my web workers dev environment set up. tomorrow i shall write the spec.
  434. # [13:33] <Hixie> nn
  435. # [13:34] <annevk> I think chaals was asking about major changes. I agree that those should go to public-html.
  436. # [13:34] <annevk> Actually, he didn't say that explicitly, so never mind
  437. # [13:54] * Joins: myakura (n=myakura@p1216-ipbf601marunouchi.tokyo.ocn.ne.jp)
  438. # [13:56] * Joins: webben (n=benh@nat/yahoo/x-4c7dd6972596b1ca)
  439. # [14:05] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  440. # [14:13] * Quits: webben__ (n=benh@nat/yahoo/x-7e56a9864acbbdce) (Read error: 113 (No route to host))
  441. # [14:14] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  442. # [14:14] * Quits: MikeSmith (n=MikeSmit@EM119-72-86-230.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  443. # [14:15] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  444. # [14:16] * Joins: othermaciej_ (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  445. # [14:16] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  446. # [14:17] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  447. # [14:17] * Quits: othermaciej_ (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  448. # [14:17] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  449. # [14:18] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  450. # [14:19] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  451. # [14:19] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  452. # [14:20] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 54 (Connection reset by peer))
  453. # [14:20] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  454. # [14:21] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 54 (Connection reset by peer))
  455. # [14:22] * Quits: jacobolus (n=jacobolu@pool-71-119-200-174.lsanca.dsl-w.verizon.net) (Read error: 110 (Connection timed out))
  456. # [14:22] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  457. # [14:22] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  458. # [14:23] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  459. # [14:24] * Joins: MikeSmith (n=MikeSmit@EM119-72-92-243.pool.e-mobile.ne.jp)
  460. # [14:24] * Joins: othermaciej_ (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  461. # [14:24] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  462. # [14:25] * Quits: othermaciej_ (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  463. # [14:26] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  464. # [14:47] * Joins: aaronlev (n=chatzill@f051064041.adsl.alicedsl.de)
  465. # [15:02] <JohnResig> Lachy: no public builds, no
  466. # [15:02] <JohnResig> Lachy: you can take the patch from the bug and build your own copy
  467. # [15:02] <JohnResig> Lachy: which I might do here soon in order to finish the test suite
  468. # [15:03] <Lachy> JohnResig, assume I don't have the time or skill to work out how to build my own.
  469. # [15:04] <Lachy> if you make one for the mac, can you send me a build?
  470. # [15:04] <JohnResig> Lachy: right, yeah - it's a pain - a full build won't be around for a while
  471. # [15:04] <JohnResig> Lachy: sure, I'll see what i can do
  472. # [15:04] <Lachy> thanks
  473. # [15:06] <Lachy> oh, btw, we need to make sure the test suite handles querySelector(null);. Currently, there's no interop on that issue. But it was recently defined in the spec
  474. # [15:09] * Joins: webben_ (n=benh@nat/yahoo/x-95fa8e0b8fcfccfc)
  475. # [15:23] * Quits: webben (n=benh@nat/yahoo/x-4c7dd6972596b1ca) (Read error: 110 (Connection timed out))
  476. # [15:26] <annevk> I think treating null like "null" is more consistent with most DOM APIs, but I don't really feel strongly about this issue
  477. # [15:27] <gDashiva> I wonder what kind of apps depend on null -> "null"
  478. # [15:29] <annevk> lots of stuff that does "(" + variable + ")" or something
  479. # [15:30] <Lachy> annevk, this way the null is handled the same way in all places throughout the spec, for both NSResolver return values and parameters
  480. # [15:31] <Lachy> plus, it seems more intuitive for null to match nothing, rather than inadvertenly match an element <null> in the document
  481. # [15:31] <annevk> I think "" would be a SYNTAX_ERR
  482. # [15:33] * Joins: philipj (n=philipj@118.71.116.169)
  483. # [15:33] <Lachy> annevk, yes. it is
  484. # [15:33] <Lachy> and therefore, so is null
  485. # [15:33] * Parts: philipj (n=philipj@118.71.116.169)
  486. # [15:33] * Joins: philipj (n=philipj@118.71.116.169)
  487. # [15:33] <Lachy> but if you still disagree, respond on the list and I'll take another look
  488. # [15:34] <Lachy> oh, looks like there's a thread from February neither I nor anyone else responded to. I'd better do that now.
  489. # [15:46] * Parts: philipj (n=philipj@118.71.116.169)
  490. # [15:47] * Joins: philipj (n=philipj@118.71.116.169)
  491. # [15:55] * Joins: csarven (n=csarven@on-irc.csarven.ca)
  492. # [16:00] * Parts: hdh (n=hdh@58.187.60.226) ("Konversation terminated!")
  493. # [16:01] * Quits: webben_ (n=benh@nat/yahoo/x-95fa8e0b8fcfccfc)
  494. # [16:03] * Joins: csarven- (n=csarven@on-irc.csarven.ca)
  495. # [16:08] * Joins: webben (n=benh@nat/yahoo/x-ed27e7a409383323)
  496. # [16:15] * Joins: aroben (n=aroben@unaffiliated/aroben)
  497. # [16:21] * Joins: hallvors (n=hallvord@pat-tdc.opera.com)
  498. # [16:40] * Joins: billmason (n=billmaso@ip24.unival.com)
  499. # [16:43] <JohnResig> Lachy: ok, I've got some interesting edge case here. Safari feels that :enabled does not include hidden input elements (Opera does). Also, no browser currently selects option[selected] when the selected is implied (e.g. selected by default) - even if you were to check .selected and see that it's true, it wouldn't match with this selector.
  500. # [16:43] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) (Remote closed the connection)
  501. # [16:49] * Quits: myakura (n=myakura@p1216-ipbf601marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  502. # [16:55] <Lachy> option[selected] shouldn't match when the selection is implied, because it's an attribute selector.
  503. # [16:55] <Lachy> so the implementations are correct according to the spec
  504. # [16:56] <JohnResig> Lachy: and :enabled?
  505. # [16:57] <Lachy> Selectors states: "An element is enabled if the user can either activate it or transfer the focus to it. "
  506. # [16:57] <Lachy> since a user can't do that to a hidden input, Safari's behaviour is correct
  507. # [16:58] <Lachy> if you've got a TC, I'll file a bug with Opear
  508. # [16:58] <Lachy> Opera*
  509. # [16:59] <Lachy> does option:checked work?
  510. # [16:59] <JohnResig> Lachy: let me see
  511. # [16:59] <Lachy> hmm. probably not. I think it only applies to checkboxes and radio button
  512. # [16:59] <JohnResig> err, yeah
  513. # [17:00] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 110 (Connection timed out))
  514. # [17:00] <Lachy> oh, wait, yeah, selectors says it should
  515. # [17:00] <Lachy> "The :checked pseudo-class initially applies to such elements that have the HTML4 selected and checked attributes..."
  516. # [17:00] <Lachy> which includes option
  517. # [17:03] <JohnResig> Lachy: heh, the test suite crashes gogi now
  518. # [17:03] <Lachy> cool
  519. # [17:03] <JohnResig> Lachy: well, in Safari option:checked doesn't select anything
  520. # [17:04] <annevk> I'd suggest not to trust Selectors on this and instead check how Web Forms 2.0 defines the mapping
  521. # [17:04] <annevk> Web Forms 2.0 is quite detailed on the subject and arguably the more correct place than Selectors anyway
  522. # [17:05] <Lachy> annevk, ok.
  523. # [17:05] <Lachy> option:checked doesn't match for me in gogi either.
  524. # [17:05] <JohnResig> ok - so we're up to about 1500 tests: http://ejohn.org/apps/selectortest/ - I've gotta move on to the namespace stuff now
  525. # [17:05] <Lachy> ok
  526. # [17:06] <annevk> JohnResig, hey man, that's awesome
  527. # [17:06] * Parts: philipj (n=philipj@118.71.116.169)
  528. # [17:06] <JohnResig> annevk: :)
  529. # [17:06] <Lachy> hmm, not working at all in gogi. I just get a blank white space where the results are supposed to be
  530. # [17:07] <JohnResig> Lachy: that's more than I got :-/
  531. # [17:07] <Lachy> heh. Yeah, that acid 3 build probably still had a few crashers in it
  532. # [17:09] <annevk> lies, our acid3 build was perfect!
  533. # [17:10] <Lachy> annevk, of course. our developers write bug free code. :-)
  534. # [17:13] <Lachy> JohnResig, I'm dealing with the thread about adding a selector detection mechanism. http://lists.w3.org/Archives/Public/www-style/2008Apr/0113.html ...
  535. # [17:13] <Lachy> As a JS library author, would you have any need for any such mechanism that isn't covered by catching exceptions for syntax errors and unsupported selectors?
  536. # [17:14] <Lachy> the whole thread is lacking compelling use cases, so I'm likely to just respond and reject the proposal
  537. # [17:14] <annevk> we don't have supportsHTMLAnchorElementWithPingAttribute() either...
  538. # [17:15] <JohnResig> Lachy: I asked for something a little more detailed back when I gave my comments - showing which portion of a selector was valid (or "at which point a token wasn't recognized by the selector engine") - but I had trouble convincing boris that he could actually implement it
  539. # [17:16] <Lachy> oh, yeah, I remember that.
  540. # [17:16] <annevk> what is the use case for a library?
  541. # [17:16] <Lachy> http://lists.w3.org/Archives/Public/www-style/2008Apr/0160.html has an interesting solution that JS authors could use if there really is a need it.
  542. # [17:16] <JohnResig> right now all we get is "hey an error happened somewhere in this selector - good luck in figuring out what went wrong and where"
  543. # [17:17] <annevk> but do you need an error console feature or a JS API
  544. # [17:17] <JohnResig> annevk: JS API - well, more precisely, a better-detailed error message (which is what I brought up for discussion on the mailing list)
  545. # [17:18] <Lachy> what would you want to do with the information if you got it?
  546. # [17:19] <annevk> Lachy, did you define whitespace when you added that note?
  547. # [17:20] <JohnResig> we could determine that (for example) given the selector: "#foo div span select > option:selected" that it was good up until ":selected" - we'd go back and pass through all the good parts and end up with a resulting string - then do our own filtering to implement the ":selected"
  548. # [17:20] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) ("The computer fell asleep")
  549. # [17:20] <Lachy> annevk, the one about trimming leading and trailing whitespace?
  550. # [17:21] <annevk> yes
  551. # [17:21] <Lachy> whitespace is defined in Selectors. Do you want me to add an explicit reference to its definition?
  552. # [17:21] <annevk> Lachy, maybe just a note that indicates where it comes from
  553. # [17:22] <Lachy> I'll add a link to http://www.w3.org/TR/css3-selectors/#whitespace
  554. # [17:23] <annevk> JohnResig, right... that does seem tricky and quite a bit over engineered and optimized for libraries
  555. # [17:24] <JohnResig> annevk: well - unless there's a drastic change in the flexibility of this spec - libraries are still going to be the primary consumer of this API
  556. # [17:24] * Quits: csarven (n=csarven@on-irc.csarven.ca) (Nick collision from services.)
  557. # [17:24] * csarven- is now known as csarven
  558. # [17:25] * Quits: sverrej (n=sverrej@213.197.167.14) (Connection timed out)
  559. # [17:30] * Joins: aroben_ (n=aroben@unaffiliated/aroben)
  560. # [17:32] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
  561. # [17:36] <zcorpan> Philip`: in http://philip.html5.org/tests/canvas/suite/tests/2d.path.clip.winding.2.html is it intentional that the ctx.lineTo(0, 0); line (after the second beginPath()) is lineTo and not moveTo?
  562. # [17:40] * Joins: smedero (n=smedero@mdp-nat251.mdp.com)
  563. # [17:52] <zcorpan> http://www.sitepoint.com/article/html-or-xhtml-does-it-matter hmm
  564. # [17:52] <Lachy> now I'm down to 100 more emails in my selectors-api folder to deal with. I'll try and finish those off tomorrow.
  565. # [17:52] <Lachy> (down from about 200 earlier today)
  566. # [17:54] <annevk> zcorpan, removal of alt=""?
  567. # [17:55] <annevk> headers=""?
  568. # [17:55] <annevk> when was this article written? before we introduced the <img> element?
  569. # [17:55] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  570. # [18:00] <takkaria> there so many uninformed opinions and bad arguments on the web, sometimes I get dizzy just thinking about it
  571. # [18:11] <zcorpan> annevk: today
  572. # [18:12] <zcorpan> brothercake wrote the article
  573. # [18:12] <zcorpan> gotta go
  574. # [18:12] * Quits: zcorpan (n=zcorpan@pat.se.opera.com)
  575. # [18:13] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  576. # [18:22] * Joins: Lachy (n=Lachlan@85.196.122.246)
  577. # [18:45] <Philip`> zcorpan: Oops, that's not intentional
  578. # [18:46] * Philip` fixes his local version
  579. # [18:53] * Joins: maikmerten (n=maikmert@La221.l.pppool.de)
  580. # [18:56] * aroben_ is now known as aroben
  581. # [18:59] <JohnResig> Lachy: "if the selectors argument is null, undefined, or omitted, the implementation must act as if the selectors argument was set to """ - is throwing a syntax_err a valid response?
  582. # [19:00] <annevk> yes, because that's what you're supposed to do for the empty string
  583. # [19:02] * Joins: KevinMarks (n=KevinMar@nat/google/x-1f28325b5f999421)
  584. # [19:04] * Quits: KevinMarks (n=KevinMar@nat/google/x-1f28325b5f999421) (Remote closed the connection)
  585. # [19:04] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  586. # [19:04] * Joins: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  587. # [19:16] <JohnResig> "Note: Authors are strongly discouraged from writing an NSResolver that returns inconsistent results. " - I'm actually tempted to try and write one that does a little rand() action - or maybe throw a % 2 on the resolver results
  588. # [19:32] <Lachy> JohnResig, see if you can break Opera by doing that. It seems to resolve each prefix every time it's used, so "x|div x|span" resolves x twice
  589. # [19:33] <Lachy> I need to ask our developers why they did that, cause it seems inefficient
  590. # [19:33] <JohnResig> Lachy: ok, I'll add that in, as well
  591. # [19:34] * Joins: KevinMarks (n=KevinMar@216.239.45.19)
  592. # [19:34] <annevk> maybe it was easier
  593. # [19:34] <annevk> as nobody uses namespaces anyway, it would be a premature optimization if the current thing was easier
  594. # [19:35] * annevk is still not really convinced Selectors API needs namespace support
  595. # [19:36] <JohnResig> it certainly ups the complexity of the spec
  596. # [19:36] * Joins: jmb^ (n=jmb@152.78.68.189)
  597. # [19:36] <Dashiva> Has anyone asked for namespace support, or was it just implicit with css namespaces existing?
  598. # [19:36] <JohnResig> Dashiva: dunno - I assume /someone/ asked for it
  599. # [19:37] <JohnResig> it wasn't me, though, heh
  600. # [19:37] <annevk> bzbarsky was in favor iirc
  601. # [19:37] <annevk> might be that someone at Opera liked it too, dunno
  602. # [19:37] <JohnResig> k
  603. # [19:38] <annevk> seems pointless to me
  604. # [19:38] <annevk> but then I specced it initially so you can all blame me
  605. # [19:41] * Quits: hallvors (n=hallvord@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  606. # [19:47] * Quits: jmb (n=jmb@login.ecs.soton.ac.uk) (Read error: 110 (Connection timed out))
  607. # [19:48] * Joins: weinig_ (n=weinig@17.203.15.154)
  608. # [19:51] * Joins: epeus (n=KevinMar@nat/google/x-2849fc5cd8ce1f85)
  609. # [19:51] <JohnResig> ugh... I fear running this test suite in IE
  610. # [19:52] * Quits: KevinMarks (n=KevinMar@216.239.45.19) (Nick collision from services.)
  611. # [19:53] * epeus is now known as KevinMarks
  612. # [19:53] * jmb^ is now known as jmb
  613. # [20:07] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  614. # [20:10] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  615. # [20:23] * Joins: othermaciej_ (n=mjs@nat/apple/x-efc063d03cf14448)
  616. # [20:23] * Quits: Windstoss (n=wind@U9ff3.u.pppool.de)
  617. # [20:24] * Joins: eseidel (n=eseidel@nat/google/x-a90bdb7678ca7eb1)
  618. # [20:24] * othermaciej_ is now known as othermaciej
  619. # [20:28] * Quits: MikeSmith (n=MikeSmit@EM119-72-92-243.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  620. # [20:32] * Quits: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  621. # [20:36] * Joins: dbaron_ (n=dbaron@corp-241.mountainview.mozilla.com)
  622. # [20:37] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) (Nick collision from services.)
  623. # [20:37] * dbaron_ is now known as dbaron
  624. # [20:38] <annevk> hmm, maybe SSD will be able to solve the slow boot up times of computers
  625. # [20:38] <annevk> (as opposed to software)
  626. # [20:40] * weinig_ is now known as weinig
  627. # [20:41] <Dashiva> Isn't software the reason? :)
  628. # [20:42] <annevk> I'd think so, but I don't really know
  629. # [20:43] <Dashiva> I know from experience that OS startup time increases with age, and I doubt my disks are getting slower
  630. # [20:47] <Lachy> hmm, I found this in my todo folder for selectors api. http://lists.w3.org/Archives/Public/public-webapi/2008May/0357.html Not sure how to deal with it, since I already responded to another thread on the same issue today saying the opposite
  631. # [20:48] <Lachy> JohnResig, as a JS library author, what seems most intuitive for you in regards to handling querySelector(null);? What the spec says, or what annevk is asking for (stringifying to "null")?
  632. # [20:48] <JohnResig> ew - stringifying sounds frightening
  633. # [20:49] <JohnResig> querySelector(null) finds all null elements on the page? not feeling that, heh
  634. # [20:49] <JohnResig> I'm fine with an exception
  635. # [20:49] <annevk> it accepts a DOMString after all
  636. # [20:49] <annevk> and null + "x" also gives "nullx"
  637. # [20:49] <JohnResig> sure - and if something that isn't a DOMString is passed in an exception should be thrown
  638. # [20:49] <annevk> no
  639. # [20:50] <annevk> that's not how JS works
  640. # [20:50] <Lachy> no, any object is stringified using .toString()
  641. # [20:50] <Lachy> the spec just makes an exception for null and undefined
  642. # [20:51] <JohnResig> then why are you asking me about null -> "null" - it's obviously a done deal, then?
  643. # [20:51] <Lachy> I'm asking because annevk wants the spec to change and I'm not sure if I should.
  644. # [20:51] <othermaciej> the spec is a draft
  645. # [20:52] <annevk> I don't feel strongly about this issue, as there are APIs that work either way
  646. # [20:52] <othermaciej> nothing is a done deal, yet
  647. # [20:52] <annevk> though for new specs sticking with the default behavior makes more sense to me
  648. # [20:52] <Lachy> I just want to know if null should be stringified to "null" or ""
  649. # [20:52] <Lachy> IIRC, Opera using "null", webkit uses ""
  650. # [20:52] <othermaciej> the way null and undefined convert to string in JS sucks, and it sucks more that DOM APIs are inconsistent about whether they treat null and/or undefined specially instead of using normal stringification rules
  651. # [20:52] <JohnResig> going to "" would make sense, considering that we're expecting the behavior of qSA(null) to be the same as qSA("")
  652. # [20:53] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  653. # [20:53] <othermaciej> it is not a big hassle either way implementation-wise, as long as it is specified
  654. # [20:54] <Lachy> othermaciej, so would you prefer to apply normal stringification rules then?
  655. # [20:54] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  656. # [20:54] <othermaciej> I have no real preference other a desire for closure on this issue
  657. # [20:55] <othermaciej> since it is a new API, doing whatever is less error-prone makes sense
  658. # [20:55] <Lachy> it's a bikeshed. There can be no closure :-)
  659. # [20:55] <JohnResig> null -> "", undefined -> "", (nothing) -> "" fit well with what's currently specified
  660. # [20:55] <JohnResig> and since "" throws an exception it'll be easy to handle
  661. # [20:56] <Dashiva> My paint color: If the user is going to see the result, "null" is good. If it's just a parameter, we want null to mean nothing and that puts it with ""
  662. # [20:57] <Lachy> having null result in an exception may make it easier for debugging. Consider calling querySelctor(myVar); and getting zero results returned and not understanding that myVar was accidentally left set to null.
  663. # [20:58] <JohnResig> Lachy: correct
  664. # [20:58] <Lachy> at least with an exception, it makes the error an obvious error, rather than a damn logic error that could go undetected.
  665. # [20:58] <Lachy> issue settled. Bikeshed painted a beautiful sky blue. :-)
  666. # [20:59] <takkaria> I say gray
  667. # [20:59] * Joins: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
  668. # [21:02] <Lachy> annevk, are you sure the raises thing in the IDL is optional?
  669. # [21:04] <annevk> yes
  670. # [21:04] <annevk> I'm positive it needs to be
  671. # [21:04] <Lachy> ok, in that case I'll remove it because it just makes the IDL more cluttered
  672. # [21:05] <annevk> indeed
  673. # [21:08] * Quits: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
  674. # [21:12] <Lachy> oh crap. I hate how we have a new mailing list. Now when I respond to old threads, I keep forgetting to change from public-webapi to public-webapps
  675. # [21:20] * Quits: maikmerten (n=maikmert@La221.l.pppool.de) ("Leaving")
  676. # [21:29] * Quits: weinig (n=weinig@17.203.15.154)
  677. # [21:32] * Joins: tommorris (n=tommorri@i-83-67-98-32.freedom2surf.net)
  678. # [21:47] * Joins: Windstoss (n=wind@mnhm-4d016982.pool.mediaWays.net)
  679. # [21:48] * Joins: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
  680. # [21:53] * Joins: franksalim (n=frank@ip-12-22-56-126.hqglobal.net)
  681. # [22:01] * Joins: rubys (n=rubys@cpe-075-182-087-110.nc.res.rr.com)
  682. # [22:02] <rubys> hsivonen: html5.validator.nu appears to be down
  683. # [22:03] <annevk> yeah, has been like that for a day or so now :/
  684. # [22:03] <annevk> seems hsivonen is not around
  685. # [22:04] <rubys> Thanks! I'm sure he'll attend to it when he gets back.
  686. # [22:05] * Joins: weinig (n=weinig@17.203.15.154)
  687. # [22:11] * Quits: webben (n=benh@nat/yahoo/x-ed27e7a409383323)
  688. # [22:12] * Parts: rubys (n=rubys@cpe-075-182-087-110.nc.res.rr.com)
  689. # [22:27] <MikeSmith> unfortunately, building from http://svn.versiondude.net/whattf/build/trunk also appears to be broke
  690. # [22:27] <MikeSmith> in my environment at least
  691. # [22:35] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  692. # [22:35] * Joins: aroben (n=adamrobe@c-71-58-56-76.hsd1.pa.comcast.net)
  693. # [22:37] * Quits: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
  694. # [22:38] <JohnResig> Lachy: hmm... no matter what I do I get NAMESPACE_ERRs from the Opera Gogi build
  695. # [22:38] <JohnResig> Lachy: I get the error if I give it an invalid namespace resolver or a valid one
  696. # [22:39] <Lachy> really? Show me a simple TC
  697. # [22:40] <JohnResig> well, let me see
  698. # [22:41] * Quits: aroben (n=adamrobe@unaffiliated/aroben)
  699. # [22:41] * Joins: aroben (n=aroben@unaffiliated/aroben)
  700. # [22:42] <roc> annevk: thanks man!
  701. # [22:43] <JohnResig> huh... works in my simple test case - time to work backwards
  702. # [22:43] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  703. # [22:43] * Joins: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
  704. # [22:44] <Lachy> ok, ping me when you work it out
  705. # [22:46] * Quits: Windstoss (n=wind@mnhm-4d016982.pool.mediaWays.net)
  706. # [22:47] <Lachy> JohnResig, remember to test :hover as well. That one is going to be a little tricky, and will need to be interactive
  707. # [22:47] * Joins: gsnedders (n=gsnedder@p57A200BA.dip0.t-ipconnect.de)
  708. # [22:47] * gsnedders now has a decent connection, and so shouldn't drop offline unexpectedly
  709. # [22:47] <annevk> roc, np, hopefully it kills the thread :)
  710. # [22:53] <gsnedders> annevk: The Xbox itself didn't, though many games have (Halo, anything using the Unreal Engine 2.5 and above)
  711. # [22:53] <gsnedders> annevk: (re: vorbis)
  712. # [22:54] <gsnedders> 712 unread emails. Yay.
  713. # [22:54] <JohnResig> Lachy: ok! fixed the bug and found one error - Opera doesn't throw an exception with this resolver: { lookupNamespaceURI: function(){} }
  714. # [22:55] <Lachy> while resolving the default ns or a prefix?
  715. # [22:56] <Lachy> if it's while resolving the default ns, that's fine because it's implicitly returning undefined
  716. # [22:56] <JohnResig> a prefix - it doesn't throw a NAMESPACE_ERR
  717. # [22:56] <Lachy> oh, ok. Let me see
  718. # [22:58] <JohnResig> weird, I'm having troubles with a reduction - although I'm able to get the others (return null, return "") to fail.
  719. # [22:58] <MikeSmith> Hixie: would be good to try to get the "Fetching resources" section completed before publishing the next WD
  720. # [22:59] <JohnResig> Lachy: ok, I'm still investigating - I'm not sure why this one would fail
  721. # [23:00] <JohnResig> oh! wait
  722. # [23:00] <JohnResig> Lachy: ok, nm - I was giving it a valid namespace - just one that wasn't on the page
  723. # [23:01] <JohnResig> OK! need to generate a lot more test cases, now that it appears to be working
  724. # [23:02] <Lachy> ah, ok. cool. FWIW, this worked for me:
  725. # [23:02] <Lachy> <!DOCTYPE html>
  726. # [23:02] <Lachy> <script>
  727. # [23:02] <Lachy> try {
  728. # [23:02] <Lachy> var p = document.querySelector("x|p", function(){});
  729. # [23:02] <Lachy> } catch (e) {
  730. # [23:02] <Lachy> alert(e);
  731. # [23:02] <Lachy> }
  732. # [23:02] <Lachy> </script>
  733. # [23:03] <JohnResig> k
  734. # [23:15] <Lachy> hmm, now I'm down to the difficult issues. Dealing with NSResolver problems. I've put it off long enough, I will have to deal with it all tomorrow.
  735. # [23:16] <Lachy> only about 90 emails on the topic :-(
  736. # [23:17] <JohnResig> Lachy: ok! I think I found a legitimate bug with test case: http://ejohn.org/apps/selectortest/tmp.html it seems like this should find, at least, one svg element
  737. # [23:21] <annevk> doublec, roc, btw, the VoidCallback stuff from <video> should be just a function in ECMAScript (will be part of Web IDL or might already be, dunno)
  738. # [23:22] * Quits: eseidel (n=eseidel@nat/google/x-a90bdb7678ca7eb1)
  739. # [23:22] <Lachy> JohnResig, yep, looks like a bug to me.
  740. # [23:23] * Joins: eseidel (n=eseidel@nat/google/x-03bc82dbcb0574d4)
  741. # [23:23] <JohnResig> Lachy: ok! I'll write a bunch of svg-in-xhtml cases (as I was going to do) - I'll just kind of have to eyeball how the results should go, since I don't have a reference at this point
  742. # [23:24] <JohnResig> Lachy: I'll leave this as a permanent URL, then: http://ejohn.org/apps/selectortest/svg-in-xhtml.html
  743. # [23:24] * Quits: aaronlev (n=chatzill@f051064041.adsl.alicedsl.de) ("ChatZilla 0.9.83 [Firefox 3.0/2008052906]")
  744. # [23:25] * MikeSmith reads message from Sunava stating "IE8 will ship the updated section of Access Control that enables public data aggregation (no creds on wildcard) while setting us up on a trajectory to support more in the future (post IE8) using the API flag in an XDR level 2"
  745. # [23:25] <roc> annevk: but HTML5 doesn't say that yet, right?
  746. # [23:25] <MikeSmith> http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0057.html
  747. # [23:26] <Lachy> JohnResig, it's not a bug
  748. # [23:26] <Lachy> it's your fault
  749. # [23:26] <roc> so they're not going to support anything in XHR, only XDR?
  750. # [23:27] <Lachy> JohnResig, the page is served as text/html. Serve it as XML and it works.
  751. # [23:27] <Lachy> since we don't yet support SVG in text/html, your test fails
  752. # [23:29] <annevk> roc, correct, twice
  753. # [23:31] <roc> that sucks, but no surprise
  754. # [23:32] <annevk> for the latter, yes
  755. # [23:36] * Quits: csarven (n=csarven@on-irc.csarven.ca) ("http://www.csarven.ca")
  756. # [23:43] <annevk> I'm glad I didn't specify the double GET algorithm :)
  757. # [23:44] <gsnedders> I'm glad I'm not spec'ing HTTP…
  758. # [23:44] <annevk> you stopped?
  759. # [23:44] <gsnedders> … oh, wait, I am :)
  760. # [23:44] <annevk> are you doing cookies too btw?
  761. # [23:45] <gsnedders> annevk: in the parsing spec? yeah.
  762. # [23:48] * Joins: weinig_ (n=weinig@nat/apple/x-81f23145a0a944d4)
  763. # [23:59] <Lachy> JohnResig, It seems Opera resolves duplicate namespace prefixes twice, but still use the first value returned.
  764. # [23:59] * Philip` discovers that Dehydra is quite neat
  765. # Session Close: Thu Jul 10 00:00:00 2008

The end :)