/irc-logs / freenode / #whatwg / 2008-03-20 / end

Options:

  1. # Session Start: Thu Mar 20 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:00] * Joins: andersca_ (n=andersca@nat/apple/x-57fcee28143c3a54)
  4. # [00:01] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  5. # [00:10] * Joins: othermaciej_ (n=mjs@17.255.96.62)
  6. # [00:12] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("Leaving")
  7. # [00:14] * weinig is now known as weinig|away
  8. # [00:15] * Quits: andersca (n=andersca@17.255.103.184) (Read error: 110 (Connection timed out))
  9. # [00:18] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  10. # [00:25] * Quits: othermaciej (n=mjs@nat/apple/x-f4b85492af0ae608) (Read error: 110 (Connection timed out))
  11. # [00:25] * Quits: qwert666 (n=qwert666@acbe243.neoplus.adsl.tpnet.pl) ("Leaving")
  12. # [00:55] * Quits: andersca_ (n=andersca@nat/apple/x-57fcee28143c3a54) ("a")
  13. # [00:56] * Joins: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  14. # [00:56] * Quits: jgraham (n=james@81-86-216-20.dsl.pipex.com) ("I get eaten by the worms")
  15. # [00:57] * Joins: jgraham (n=james@81-86-216-20.dsl.pipex.com)
  16. # [01:00] * weinig|away is now known as weinig
  17. # [01:00] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  18. # [01:03] * Quits: othermaciej_ (n=mjs@17.255.96.62) (Read error: 104 (Connection reset by peer))
  19. # [01:03] * Joins: othermaciej (n=mjs@17.255.96.62)
  20. # [01:09] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  21. # [01:12] * Joins: andersca (n=andersca@nat/apple/x-1c2b6de8faabd54f)
  22. # [01:17] * Joins: othermaciej_ (n=mjs@nat/apple/x-485d014bb3829054)
  23. # [01:20] * Quits: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  24. # [01:20] * Joins: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  25. # [01:32] <andersca> is the idea that the offline cache should only be accessed when navigator.onLine is false?
  26. # [01:32] * Quits: tndH (i=Rob@adsl-87-102-35-111.karoo.KCOM.COM) ("ChatZilla 0.9.81-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  27. # [01:32] <Hixie> no
  28. # [01:32] <Hixie> the offline cache is always accessed
  29. # [01:32] <Hixie> is the spec not clear about that?
  30. # [01:33] <andersca> "The navigator.onLine attribute must return false if the user agent will not contact the network when the user follows links or when a script requests a remote page"
  31. # [01:33] <andersca> that's what got me confused
  32. # [01:34] <Hixie> ah, yeah, that should probably be clarified
  33. # [01:34] <Hixie> please send mail :-)
  34. # [01:34] <andersca> will do
  35. # [01:34] <Hixie> that text predates the offline cache
  36. # [01:34] <andersca> ah, got it
  37. # [01:34] <andersca> Hixie: also, can an application cache group ever have more than two caches?
  38. # [01:34] <Hixie> yes
  39. # [01:35] <Hixie> if there are many browsing contexts all using the same cache group
  40. # [01:35] * Quits: othermaciej (n=mjs@17.255.96.62) (Read error: 110 (Connection timed out))
  41. # [01:35] <Hixie> and the cache group gets upgraded a number of times
  42. # [01:35] <Hixie> with only one browsing context getting upgraded each time
  43. # [01:36] <andersca> ah, that makes sense
  44. # [01:37] <andersca> so I should be able to get rid of older caches as contexts referencing them go away
  45. # [01:40] <Hixie> yeah
  46. # [01:40] <andersca> cool
  47. # [01:41] <andersca> this is starting to make sense
  48. # [01:59] * Quits: eseidel (n=eseidel@nat/google/x-4ace7078de590f49)
  49. # [02:00] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  50. # [02:18] * Quits: othermaciej_ (n=mjs@nat/apple/x-485d014bb3829054) (Read error: 110 (Connection timed out))
  51. # [02:20] * weinig is now known as weinig|away
  52. # [02:25] * Quits: andersca (n=andersca@nat/apple/x-1c2b6de8faabd54f) (Read error: 110 (Connection timed out))
  53. # [02:39] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  54. # [02:44] * Joins: jwalden (n=waldo@RANDOM-THREE-O-EIGHT.MIT.EDU)
  55. # [02:45] * Joins: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  56. # [03:00] * Quits: KevinMarks (n=KevinMar@nat/google/x-a62ad34faf0ef3b8) ("The computer fell asleep")
  57. # [03:01] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 110 (Connection timed out))
  58. # [03:05] * weinig|away is now known as weinig
  59. # [03:26] <Hixie> i suppose we could handle the indent thing by using multiple colums
  60. # [03:26] <Hixie> but that feels like a hack
  61. # [03:27] * Quits: SadEagle (n=maksim@kde/orlovich) ("bye")
  62. # [03:41] * Joins: Thezilch (i=fuz007@cpe-76-171-105-220.socal.res.rr.com)
  63. # [04:21] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  64. # [05:47] * Quits: csarven (i=csarven@on-irc.csarven.ca) ("http://www.csarven.ca")
  65. # [05:49] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  66. # [06:25] <Hixie> ok i think i've looked at enough tables
  67. # [06:25] <Hixie> now to study the ones i marked as being interesting
  68. # [06:26] * Joins: gavin__ (n=gavin@people.mozilla.com)
  69. # [06:28] * Quits: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net) (kubrick.freenode.net irc.freenode.net)
  70. # [06:28] * Quits: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net) (kubrick.freenode.net irc.freenode.net)
  71. # [06:28] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (kubrick.freenode.net irc.freenode.net)
  72. # [06:28] * Quits: Pavlov (n=pavlov@shell.off.net) (kubrick.freenode.net irc.freenode.net)
  73. # [06:28] * gavin__ is now known as gavin_
  74. # [06:30] * Quits: Thezilch (i=fuz007@cpe-76-171-105-220.socal.res.rr.com) (Read error: 104 (Connection reset by peer))
  75. # [06:30] * Quits: jwalden (n=waldo@RANDOM-THREE-O-EIGHT.MIT.EDU) (kubrick.freenode.net irc.freenode.net)
  76. # [06:30] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (kubrick.freenode.net irc.freenode.net)
  77. # [06:30] * Quits: alp (n=alp@84.9.46.160) (kubrick.freenode.net irc.freenode.net)
  78. # [06:30] * Joins: Pavlov (n=pavlov@shell.off.net)
  79. # [06:31] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  80. # [06:31] * Joins: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  81. # [06:32] * Joins: jwalden (n=waldo@RANDOM-THREE-O-EIGHT.MIT.EDU)
  82. # [06:32] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  83. # [06:32] * Joins: alp (n=alp@84.9.46.160)
  84. # [06:33] * Joins: Thezilch (i=fuz007@cpe-76-171-105-220.socal.res.rr.com)
  85. # [06:59] * Quits: weinig (n=weinig@17.203.15.180)
  86. # [07:22] * Quits: mpt (n=mpt@canonical/launchpad/mpt) ("Ex-Chat")
  87. # [07:40] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  88. # [07:44] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  89. # [07:53] * Joins: peepo1234 (n=Jay@host86-129-187-211.range86-129.btcentralplus.com)
  90. # [07:55] * Quits: peepo1234 (n=Jay@host86-129-187-211.range86-129.btcentralplus.com) (Client Quit)
  91. # [07:55] * Joins: peepo1234 (n=Jay@host86-129-187-211.range86-129.btcentralplus.com)
  92. # [07:58] * Parts: peepo1234 (n=Jay@host86-129-187-211.range86-129.btcentralplus.com)
  93. # [08:01] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  94. # [08:02] * Quits: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  95. # [08:02] * Parts: MikeSmith (n=MikeSmit@58.157.21.205) ("Less talk, more pimp walk.")
  96. # [08:06] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  97. # [08:06] * Joins: billyjack (n=MikeSmit@58.157.21.205)
  98. # [08:06] * Quits: billyjack (n=MikeSmit@58.157.21.205) (Read error: 104 (Connection reset by peer))
  99. # [08:06] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) (Client Quit)
  100. # [08:06] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  101. # [08:15] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  102. # [08:35] * Quits: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  103. # [08:56] * Joins: qwert666 (n=qwert666@acbe243.neoplus.adsl.tpnet.pl)
  104. # [08:56] * Joins: bewes1 (n=ben@c-71-204-188-164.hsd1.ca.comcast.net)
  105. # [08:57] * bewes1 pokes othermaciej
  106. # [08:57] <othermaciej> bewes1: yes?
  107. # [08:57] <bewes1> oh, I wanted to ask you about geolocation
  108. # [08:58] <othermaciej> I am at your service
  109. # [08:58] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  110. # [08:58] <bewes1> I didn't think each HTTP request would re-consume the resources necessary to do geolocation
  111. # [08:59] <bewes1> is it unreasonable to assume the browser has some cached version of the geolocation results?
  112. # [09:00] <othermaciej> if there's a cached version it could be completely wrong
  113. # [09:00] <bewes1> without triggering new lookups?
  114. # [09:00] <othermaciej> let me use iPhone as an example
  115. # [09:00] <bewes1> so it's a cache invalidation issue?
  116. # [09:00] <othermaciej> I believe its geolocation has been discussed a little publicly
  117. # [09:00] <othermaciej> it uses a combination of WiFi (looking for nearby networks) and triangulation from cell towers
  118. # [09:00] <othermaciej> both of these fire up the radio
  119. # [09:01] <othermaciej> and may need to use high power signals
  120. # [09:01] <othermaciej> it does not do this all the time
  121. # [09:01] <othermaciej> only when you ask
  122. # [09:01] <othermaciej> if you put it in your pocket and drive across town, it has no idea if you are still near where you were
  123. # [09:01] <othermaciej> and it would have to suck a lot of battery to find out
  124. # [09:01] <othermaciej> so it's far better to only provide geolocation info on demand
  125. # [09:01] <othermaciej> instead of sending it to every server all the time
  126. # [09:01] <bewes1> yeah, I guess I was imagining there'd be some kind of reliable cache in between
  127. # [09:02] <othermaciej> how would you know if your cache is valid without geolocating again?
  128. # [09:02] <othermaciej> keep in mind, many sites (perhaps most) will not even use this data
  129. # [09:02] <bewes1> yeah
  130. # [09:03] <othermaciej> I would also add that it is awkward to get a request header to script code, and often the interesting location-based things you want to do will be in script
  131. # [09:03] <bewes1> yeah, I guess I was missing some perspective on devices for which it's really really expensive and a pretty unreliable cache
  132. # [09:03] <bewes1> although your points on usage are good too
  133. # [09:03] <othermaciej> I think what I said may be true for just about any phone with location support but no hardware GPS
  134. # [09:04] <bewes1> yeah
  135. # [09:04] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  136. # [09:06] <bewes1> how do you know where the wifi signals are? do you always require at least one cell tower?
  137. # [09:06] <othermaciej> I don't know all of the nitty gritty technical details
  138. # [09:07] * Quits: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  139. # [09:14] <MikeSmith> fwiw, I use location-based services from both from mobile browsers and other apps on devices here in Japan quite a lot, and location interaction from browsers deployed here is always as othermaciej describes
  140. # [09:15] <MikeSmith> that is, nothing is cached
  141. # [09:16] <MikeSmith> but some non-browser apps on mobile devices here are capable of dynamically updating as you move
  142. # [09:17] <MikeSmith> e.g., they can show you your update position on a map as you move
  143. # [09:17] <MikeSmith> in near real-time
  144. # [09:17] <MikeSmith> like the navigation systems in cars
  145. # [09:18] <MikeSmith> another thing is that the mechanism being used to determine the position isn't really exposed to apps
  146. # [09:19] <MikeSmith> there's just an API for making a location query, and the device makes a determination about what the optimal mechanism is for determining your location
  147. # [09:19] <bewes1> yeah, I was just curious
  148. # [09:20] * Joins: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  149. # [09:21] * Joins: eseidel_ (n=eseidel@72.14.224.1)
  150. # [09:25] <bewes1> MikeSmith: what kinds of apps use the near real-time movement?
  151. # [09:25] <MikeSmith> bewes1 - apps for trip-planning/trip-routing
  152. # [09:26] * Joins: tndH (i=Rob@adsl-87-102-35-111.karoo.KCOM.COM)
  153. # [09:26] <MikeSmith> most widely deployed one is this:
  154. # [09:27] <MikeSmith> http://www.navitime.com/howtouse.html
  155. # [09:27] <bewes1> oh, do you mean the ones in cars? I thought you meant devices you'd carry with you all the time
  156. # [09:27] <MikeSmith> Navitime
  157. # [09:27] <MikeSmith> not in cars, but on mobile handsets/ mobile phones
  158. # [09:27] <MikeSmith> but basically the same functionality as car navigation systems
  159. # [09:27] <bewes1> ah
  160. # [09:28] <MikeSmith> expect that since here in Tokyo most people don't drive cars, the apps are for train commuting and pedestrians
  161. # [09:28] <MikeSmith> use case is that you just fire up the app and tell it where you want to go
  162. # [09:29] <bewes1> pretty convenient
  163. # [09:29] <MikeSmith> e.g., give it an address or name of a business or something
  164. # [09:29] <MikeSmith> then the app shows you the route: tells what train station is closest, the shows you an interactive map of how to get to the train station
  165. # [09:30] <bewes1> that's pretty good stuff
  166. # [09:30] <MikeSmith> then same thing after you get off the train at the closest station to your destination
  167. # [09:30] <bewes1> does it include when the next train arrives?
  168. # [09:30] <MikeSmith> yep
  169. # [09:30] <MikeSmith> it has access to complete train schedules for all train lines in Japan
  170. # [09:31] <bewes1> how often are trains late?
  171. # [09:32] <MikeSmith> bewes1 - rarely
  172. # [09:33] <MikeSmith> typically only in cases of really bad weather
  173. # [09:33] <MikeSmith> or if somebody jumps in front of one of them
  174. # [09:34] <MikeSmith> btw, the actual Navitime app and others like it is either a Java/J2ME or BREW app, depending on which handset it's on
  175. # [09:34] <MikeSmith> but there's no real reason that a remote Web-based app could not provide the same features
  176. # [09:34] <MikeSmith> except that we don't have any standard scripting APIs that would enable Web developers to write such apps
  177. # [09:38] * Quits: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net) (Connection timed out)
  178. # [09:38] * eseidel_ is now known as eseidel
  179. # [09:46] * Quits: jgraham (n=james@81-86-216-20.dsl.pipex.com) ("I get eaten by the worms")
  180. # [09:47] * Joins: jgraham (n=james@81-86-216-20.dsl.pipex.com)
  181. # [09:50] * Parts: bewes1 (n=ben@c-71-204-188-164.hsd1.ca.comcast.net)
  182. # [10:01] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  183. # [10:07] <hsivonen> looks like headers='' hasn't registered on html4all yet
  184. # [10:09] * Joins: eseidel_ (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  185. # [10:23] * Joins: Pavlov_ (n=pavlov@shell.off.net)
  186. # [10:25] * Joins: ROBOd (n=robod@89.122.216.38)
  187. # [10:26] * Joins: virtuelv (n=virtuelv@109.80-202-65.nextgentel.com)
  188. # [10:27] * Quits: eseidel (n=eseidel@72.14.224.1) (Read error: 110 (Connection timed out))
  189. # [10:28] * Quits: Pavlov (n=pavlov@shell.off.net) (Read error: 113 (No route to host))
  190. # [10:29] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  191. # [10:30] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  192. # [10:33] * Parts: zcorpan (n=zcorpan@pat.se.opera.com)
  193. # [10:33] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  194. # [10:39] * othermaciej is now known as om_sleep
  195. # [10:42] * Joins: Camaban (n=adrianle@81.133.236.188)
  196. # [10:48] * om_sleep is now known as othermaciej
  197. # [10:51] <hsivonen> hmm. the restriction against entities in the internal character encoding decl is pretty annoying
  198. # [10:59] <hsivonen> Hixie: is "# ]
  199. # [10:59] <hsivonen> # The encoding name must be serialised without the use of character entity references or character escapes of any kind. "
  200. # [11:00] <hsivonen> based on browser behavior?
  201. # [11:00] <Philip`> I assume that's to make the preparse thing work correctly?
  202. # [11:00] <hsivonen> the way the spec is written, the tree builder's encoding switching thing works even with escaping
  203. # [11:01] <hsivonen> Philip`: presumably
  204. # [11:02] <hsivonen> but I have to wonder if this kind of layering-breaking restriction is right
  205. # [11:03] <hsivonen> Hixie: assuming that the restriction stays, shouldn't it apply not only to the encoding name but the entire attribute?
  206. # [11:04] <hsivonen> bah. I'll leave implementation for another day and send email for now
  207. # [11:05] <hsivonen> in a way, this restriction is even more annoying than the old 512-byte restriction
  208. # [11:05] <hsivonen> mainly because I implemented that one already
  209. # [11:11] * Philip` only sees half a dozen cases of & in charsets
  210. # [11:11] <Philip`> like <meta http-equiv="Content-Type" content="text/html;&gt;charset=iso-8859-1" />
  211. # [11:11] <Philip`> and <meta http-equiv="content-type" content="The 4 annual Los Angeles Independent Horror Film Festival ...and Music Too!! Creeping Your Way, October 2005&gt; &lt;meta name=" generator" content="Microsoft FrontPage 4.0">
  212. # [11:12] <Philip`> and similar things
  213. # [11:30] * Quits: heycam (n=cam@124-168-8-145.dyn.iinet.net.au) ("bye")
  214. # [11:32] * Joins: heycam (n=cam@124-168-8-145.dyn.iinet.net.au)
  215. # [11:37] * Quits: heycam (n=cam@124-168-8-145.dyn.iinet.net.au) ("bye")
  216. # [11:38] * Joins: heycam (n=cam@124-168-8-145.dyn.iinet.net.au)
  217. # [11:40] * Joins: webben (n=benh@nat/yahoo/x-08d7c4bc72ed2ae5)
  218. # [11:44] * Quits: virtuelv (n=virtuelv@109.80-202-65.nextgentel.com) ("Ex-Chat")
  219. # [11:47] <zcorpan> Philip`, or Hixie: it would be very useful to have data about pages that use "<!-- ... > ... EOF" and "<script><!-- ... </script> ... EOF" (with no --> before EOF)
  220. # [11:48] <zcorpan> we're a bit scared that we'll break many pages when fixing that
  221. # [11:51] * Joins: heycam` (n=cam@124-168-8-145.dyn.iinet.net.au)
  222. # [11:54] * Quits: heycam` (n=cam@124-168-8-145.dyn.iinet.net.au) (Client Quit)
  223. # [11:54] * Quits: heycam (n=cam@124-168-8-145.dyn.iinet.net.au) (Read error: 104 (Connection reset by peer))
  224. # [11:54] * Joins: heycam (n=cam@124-168-8-145.dyn.iinet.net.au)
  225. # [12:01] <zcorpan> or <script><!-- ... </script> ... --> (with no --> before </script>)
  226. # [12:02] <zcorpan> (and no further script blocks afterwards)
  227. # [12:46] * Quits: qwert666 (n=qwert666@acbe243.neoplus.adsl.tpnet.pl) ("Leaving")
  228. # [12:48] * Philip` needs a better grep
  229. # [12:53] * Quits: eseidel_ (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  230. # [12:53] * Joins: gsnedders (n=gsnedder@host86-138-199-53.range86-138.btcentralplus.com)
  231. # [12:58] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  232. # [12:59] <hsivonen> has anyone tested if meta can cause browsers to switch to a non-UTF-* non-US-ASCII superset encoding an reparse?
  233. # [13:05] * Quits: webben (n=benh@nat/yahoo/x-08d7c4bc72ed2ae5)
  234. # [13:07] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  235. # [13:08] * Quits: heycam (n=cam@124-168-8-145.dyn.iinet.net.au) ("bye")
  236. # [13:08] * Joins: heycam (n=cam@124-168-8-145.dyn.iinet.net.au)
  237. # [13:37] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  238. # [13:56] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
  239. # [13:58] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  240. # [13:58] <Philip`> zcorpan: http://philip.html5.org/data/pages-with-unclosed-comments.txt shows the pages that have unclosed comments, assuming my regexp was about right
  241. # [13:59] * Joins: webben (n=benh@nat/yahoo/x-d60d787128356f90)
  242. # [14:00] <hsivonen> what does the spec change about that relative to Opera's existing behavior?
  243. # [14:00] <Philip`> http://parsetree.validator.nu/?doc=http://brianyeedds.com/ - the HTML5 way doesn't seem to work very well
  244. # [14:02] <Philip`> http://parsetree.validator.nu/?doc=http://clubleonberg.free.fr/ loses content too
  245. # [14:02] <Philip`> http://parsetree.validator.nu/?doc=http://cyrilvictor.photo.free.fr/ too
  246. # [14:02] <Philip`> So it seems a reasonably common problem
  247. # [14:02] <hsivonen> Philip`: spec bug or validator.nu bug?
  248. # [14:03] <Philip`> hsivonen: Spec, since it doesn't reparse comments if it finds EOF inside them
  249. # [14:03] <hsivonen> reparsing is evil, though
  250. # [14:03] <Philip`> (as far as I'm aware)
  251. # [14:04] <Philip`> Why is it evil in this case?
  252. # [14:04] <Philip`> (when it's only reparsing comment text)
  253. # [14:04] <Philip`> (so it's already got the text saved in memory, and it hasn't been inserting elements that are hard to undo)
  254. # [14:04] <hsivonen> 1) I makes crafted network errors (EOF) cause scripts to run
  255. # [14:05] <Philip`> Oh, http://james.html5.org/cgi-bin/parsetree/parsetree.py?uri=http%3A%2F%2Fcyrilvictor.photo.free.fr%2F says something different
  256. # [14:05] <hsivonen> 2) It is a world of pain for parser developers
  257. # [14:07] <hsivonen> having to rewind the byte stream is seriously bad
  258. # [14:07] <Philip`> http://james.html5.org/cgi-bin/parsetree/parsetree.py?source=%3Cscript%3E%3C!----x%3E%3C/script%3Efoo - html5lib bug?
  259. # [14:07] <hsivonen> taking the decoded comment buffer and emulating document.writing it is also bad but not quite as bad
  260. # [14:22] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  261. # [14:27] <Philip`> jgraham: Is it intentional that you disabled all the Python tokeniser tests?
  262. # [14:28] <Philip`> Oh, looks like just a typo
  263. # [14:32] * Philip` fixes the --x> thing in html5lib
  264. # [14:36] <Philip`> (Not sure it's the most sensible fix, since it's only really the data='-' case that causes issues, but it should be safe enough...)
  265. # [14:47] * Joins: phsiao (n=shawn@nat/ibm/x-1a43d709ad634e47)
  266. # [14:58] * Joins: qwert666 (n=qwert666@acdd157.neoplus.adsl.tpnet.pl)
  267. # [15:00] <hsivonen> http://lists.w3.org/Archives/Public/www-style/2008Mar/0279.html
  268. # [15:01] * Quits: webben (n=benh@nat/yahoo/x-d60d787128356f90)
  269. # [15:04] <zcorpan> Philip`: wow thanks!
  270. # [15:04] * Joins: csarven (i=csarven@on-irc.csarven.ca)
  271. # [15:05] <zcorpan> the first has --!> ...
  272. # [15:13] <Philip`> http://parsetree.validator.nu/?doc=http://www.graniteschools.org/jr/churchill/
  273. # [15:13] <Philip`> That seems to be the <script> thing you were asking about too?
  274. # [15:13] <Hixie> zcorpan, hsivonen: send mail
  275. # [15:14] <hsivonen> already did about the encoding stuff
  276. # [15:14] <hsivonen> I'll send a pre-emptive mail about zcorpan's expected email :-)
  277. # [15:14] * Philip` needs to make his HTML-grep multithreaded, but isn't entirely sure how to do that without getting the output stream horribly confused
  278. # [15:16] <zcorpan> Philip`: yeah
  279. # [15:18] <Philip`> zcorpan: I'm using /(?is)(<script[^>]*>[^<]*<!--([^>]|(?<!--)>)*</script>)([^<]|<(?!/script))*-->([^<]|<(?!/script))*$/ which hopefully is something like what you meant by "<script><!-- ... </script> ... --> (with no --> before </script>"
  280. # [15:19] * Quits: jwalden (n=waldo@RANDOM-THREE-O-EIGHT.MIT.EDU) (Remote closed the connection)
  281. # [15:20] <Philip`> zcorpan: http://philip.html5.org/data/pages-with-unclosed-scripts-and-comment-stuff.txt
  282. # [15:21] * Joins: virtuelv (n=virtuelv@212.17.156.45)
  283. # [15:21] <hsivonen> zcorpan: does Opera mitigate the script running risk upon reparse?
  284. # [15:23] <zcorpan> Philip`: yep, thanks
  285. # [15:24] <zcorpan> hsivonen: i don't understand the question
  286. # [15:25] * zcorpan notes that firefox and safari close comments at --!>
  287. # [15:25] <zcorpan> and doing so has better compat with pages i've looked at so far
  288. # [15:26] <hsivonen> zcorpan: the security characteristics of the bytes in the "comment" changes radically depending on whether they are comments or markup that can run scripts and instatiate iframes
  289. # [15:27] <Philip`> zcorpan: In quirks or standards?
  290. # [15:27] <zcorpan> Philip`: both
  291. # [15:27] <zcorpan> hsivonen: yeah. the reparsed comment can run scripts and instatiate iframes...
  292. # [15:27] * Joins: aroben (n=aroben@unaffiliated/aroben)
  293. # [15:28] <Philip`> zcorpan: <!-- --foo> for any foo closes the comment in FF2 standards, as far as I can tell
  294. # [15:28] <Philip`> --!> is only special in quirks
  295. # [15:28] <zcorpan> i'm testing in firefox 3
  296. # [15:29] <zcorpan> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!doctype%20html%3E%3C!--x--!%3E%20x%20--%3E
  297. # [15:30] <Philip`> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!doctype%20html%3E%3C!--x--foo%3E%20x%20--%3E
  298. # [15:30] * zcorpan notes that some pages use // -- ></script>
  299. # [15:30] <Philip`> and
  300. # [15:31] <Philip`> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!--x--foo%3E%20x%20--%3E
  301. # [15:31] <Philip`> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!--x--!%3E%20x%20--%3E
  302. # [15:31] <zcorpan> Philip`: ah
  303. # [15:33] <Philip`> s/for any foo/for any foo not containing an odd number of '--'/
  304. # [15:34] <zcorpan> and is not > :)
  305. # [15:34] <hsivonen> gotta love the simplicity of comments
  306. # [15:35] <Philip`> foo = '>' will still cause the comment to close when writing <!-- --foo>, so I believe my statement is true without that detail :-)
  307. # [15:36] <zcorpan> so about half of the pages i've looked at so far would break if we implemented html5 comment parsing...
  308. # [15:36] <zcorpan> that's 1/2000 of pages
  309. # [15:37] * Quits: virtuelv (n=virtuelv@212.17.156.45) ("Ex-Chat")
  310. # [15:37] * Philip` calculated 0.05%, which agrees
  311. # [15:38] * Joins: virtuelv (n=virtuelv@212.17.156.45)
  312. # [15:44] <Hixie> crockford is still on his warpath
  313. # [15:45] <Hixie> http://www.internetnews.com/webcontent/article.php/3735341/Can+We+Fix+The+Web.htm
  314. # [15:45] <Hixie> http://diveintomark.org/archives/2008/02/21/the-bolero-of-troll
  315. # [15:47] <Philip`> It seems kind of obvious to me that the web is completely broken and can't be fixed, so we're just trying to improve at hobbling along as best we can
  316. # [15:48] * svl wishes everything he made was as successful and broken as the web.
  317. # [15:51] <Hixie> seriously
  318. # [15:51] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (Read error: 60 (Operation timed out))
  319. # [15:53] * Quits: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
  320. # [15:55] * Philip` wonders if there is any successful technology that *isn't* broken
  321. # [16:01] <Dashiva> The paperclip
  322. # [16:02] <Dashiva> Unless you count broken by design, that is
  323. # [16:02] <Philip`> Paperclips don't work in microwaves
  324. # [16:02] <Dashiva> I meant that character in office
  325. # [16:02] <Philip`> (at least the plastic-coated metal ones don't)
  326. # [16:02] <Philip`> Oh, okay
  327. # [16:03] <Philip`> I think being designed around a bad idea counts as being broken :-)
  328. # [16:04] * Quits: csarven (i=csarven@on-irc.csarven.ca) (Remote closed the connection)
  329. # [16:05] <Dashiva> And if you're counting missing features as broken, then anything that doesn't implement the universe is broken some way or another :)
  330. # [16:06] <Camaban> isn't the universe broken too? :)
  331. # [16:06] <Philip`> I don't count all feature requests as bugs :-)
  332. # [16:07] <Philip`> I think entropy is a fundamental long-term design flaw
  333. # [16:12] * Quits: virtuelv (n=virtuelv@212.17.156.45) (Read error: 110 (Connection timed out))
  334. # [16:14] <Camaban> lol
  335. # [16:14] <hsivonen> hmm. I wonder if I can trust all Java implementations to provide a non-buffering Windows-1252 decoder (on that can be swapped out without stuff getting lost in a buffer)...
  336. # [16:34] * Joins: SadEagle (n=maksim@cpe-24-58-154-192.twcny.res.rr.com)
  337. # [16:34] * Joins: webben (n=benh@nat/yahoo/x-4ac4d4d99412ee69)
  338. # [16:46] <hsivonen> does anyone have good test cases that should cause the parser switch encodings mid-stream or reparse?
  339. # [16:49] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) ("Verlassend")
  340. # [17:10] * Quits: webben (n=benh@nat/yahoo/x-4ac4d4d99412ee69)
  341. # [17:13] * Joins: webben (n=benh@nat/yahoo/x-90958a85891c48fd)
  342. # [17:18] * Quits: webben (n=benh@nat/yahoo/x-90958a85891c48fd) (Client Quit)
  343. # [17:24] * Quits: phsiao (n=shawn@nat/ibm/x-1a43d709ad634e47)
  344. # [17:25] <hsivonen> I deployed lots and lots of parser changes on Validator.nu.
  345. # [17:27] <Hixie> cool
  346. # [17:27] <Hixie> i'm looking at tables like this a lot:
  347. # [17:27] <Hixie> http://www.linz.govt.nz/publications/statement%2Dintent%2D0607/financial/financial-statements/financial-performance/index.html
  348. # [17:28] <Hixie> i'm tempted to say that a header cell in the first column, with no significant data cells on its row, should become a row group header
  349. # [17:28] <Hixie> but it actually breaks on that example
  350. # [17:28] <Hixie> so i don't know if i should
  351. # [17:28] <Hixie> (it breaks on the last row)
  352. # [17:28] <Hixie> (everything else could be fine)
  353. # [17:29] * Joins: webben (n=benh@nat/yahoo/x-6b29d4d44c800454)
  354. # [17:30] * hsivonen wishes each Gecko docshell had a thread
  355. # [17:31] <hsivonen> Firefox 3 beachballs on me
  356. # [17:36] <Pavlov_> i haven't had it beachball on me in ages
  357. # [17:37] <hsivonen> Pavlov_: try http://parsetree.validator.nu/?doc=http://www.whatwg.org/specs/web-apps/current-work/source
  358. # [17:37] <hsivonen> with lots of other tabs open
  359. # [17:38] <Hixie> wfm in ff2, though interaction is a bit jerky while the page is loading. (x11)
  360. # [17:41] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  361. # [17:42] <Hixie> ironically, i think the wide headers in tables like the following actually probably don't deserve to be read out regularly:
  362. # [17:42] <Hixie> http://broads-authority.gov.uk/boating/navigating/tide-tables.html
  363. # [17:44] * Joins: KevinMarks (n=KevinMar@nat/google/x-4ab0109dc4ba14ac)
  364. # [17:50] * Joins: phsiao (n=shawn@c-71-232-12-131.hsd1.ma.comcast.net)
  365. # [17:52] <Hixie> http://www.flickr.com/photos/joeclark/192878174/ is an insane table
  366. # [17:57] <Hixie> i don't plan on supporting this kind of table: http://www.flickr.com/photos/joeclark/185786111/
  367. # [17:58] <hsivonen> Hixie: why not if the icons have alt
  368. # [17:58] <Hixie> the problem with that table is the column headers
  369. # [17:58] <Hixie> there are two columns, but they vary in number of cells covered per row
  370. # [17:59] <Hixie> (the images are a non-issue)
  371. # [17:59] <hsivonen> I'd say there are 8 columns
  372. # [17:59] <Hixie> (i should clarify that i mean that i won't support it without use of scope or headers)
  373. # [17:59] <hsivonen> ah
  374. # [17:59] <Hixie> (obviously if you explicitly list the headers, you can do almost anything)
  375. # [18:03] <Hixie> http://sitesurgeon.co.uk/tables/astro/06-seasons/original.html is weird
  376. # [18:03] <Hixie> i don't understand why the years are duplicated
  377. # [18:04] <hsivonen> fwiw, the parser at parsetree.validator.nu is now configured to allow reparsing on late meta
  378. # [18:05] <Hixie> let me know if you ever get a page that validates despite having to trigger that
  379. # [18:06] <hsivonen> Hixie: the validator is configured to give up if the reparse would have to be triggered
  380. # [18:06] <hsivonen> since the validator is in the streaming mode and cannot undo the start of the document
  381. # [18:06] <Hixie> ah ok
  382. # [18:07] <hsivonen> I implemented on-the-fly encoder change if the characters decoded so far would decode the same way with all ASCII supersets
  383. # [18:07] <hsivonen> but I think that code path will be extremely rare, because when meta is seen, it's not only the past chararters that matter but only the decoded upcoming characters in the read buffer
  384. # [18:08] <Hixie> s/but only/but also/
  385. # [18:08] <hsivonen> the rarity of the code path occurred to me only after implementing
  386. # [18:10] <Hixie> http://www.biggerbras.com/bras-by-size-panties-shapers-sizing-catalog.shtml is weird because i don't know what column i'd use for the horizontal headers
  387. # [18:10] <hsivonen> I think the plausible real-world case would go like this: over 512 bytes of inline ASCII-only style and script, meta declaring utf-8, a couple of KB of ASCII text, a copyright sign at the footer
  388. # [18:11] <Hixie> a lot of the more complicated tables are financial
  389. # [18:11] <Hixie> i recommend we get rid of money
  390. # [18:12] <hsivonen> Hixie: if you consider the actual use case of converting measurements to bra sizes, you'd have "Back Size" cell as the row heading
  391. # [18:12] <hsivonen> since Band size is a computed value
  392. # [18:12] <Hixie> yeah, that was my conclusion too
  393. # [18:13] <Hixie> but i don't know if that's what blind users would find most useful
  394. # [18:13] <hsivonen> besides, band size culumn is redundant with the actual data cells
  395. # [18:13] <hsivonen> column
  396. # [18:20] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  397. # [18:23] * Parts: SadEagle (n=maksim@cpe-24-58-154-192.twcny.res.rr.com) ("Konversation terminated!")
  398. # [18:23] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  399. # [18:23] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  400. # [18:23] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net) (Client Quit)
  401. # [18:24] * hsivonen notes that a non-ASCII-superset sniffed by chardet can never become certain
  402. # [18:25] <hsivonen> I wonder if chardet-supported non-ASCII superset encodings are common
  403. # [18:25] <Hixie> are there any?
  404. # [18:26] <Hixie> or do you mean the BOM detection?
  405. # [18:26] * Joins: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  406. # [18:27] <hsivonen> I mean detecting UTF-16BE or UTF-16LE if those are supported by chardet
  407. # [18:29] <hsivonen> they seem to be
  408. # [18:29] <Hixie> my ff2 has stopped having a working "find", so i can't search for utf-16, sigh
  409. # [18:30] <hsivonen> There's nsUCS2BEVerifier and the same as LE
  410. # [18:32] * Joins: virtuelv (n=virtuelv@ti132110a341-3223.bb.online.no)
  411. # [18:33] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  412. # [18:34] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  413. # [18:44] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  414. # [18:44] * Joins: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net)
  415. # [18:45] * Joins: jwalden (n=waldo@RANDOM-THREE-O-EIGHT.MIT.EDU)
  416. # [18:46] <hsivonen> hmm. why am I seeing Ukranian and Russian in the Firefox autodetector menu but I'm not seeing them in the jchardet source?
  417. # [18:48] <hsivonen> bah! the port is incomplete!
  418. # [18:48] <hsivonen> it lack nsCyrillicDetector
  419. # [18:55] * Joins: maikmerten (n=maikmert@L991f.l.pppool.de)
  420. # [18:55] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 104 (Connection reset by peer))
  421. # [18:57] * Quits: webben (n=benh@nat/yahoo/x-6b29d4d44c800454)
  422. # [18:57] * Philip` sees an XML namespace "urn:ietf:params:xml:ns:netconf:base:1.0", which seems much harder to remember than the w3.org ones
  423. # [18:58] * Joins: andersca (n=andersca@nat/apple/x-14d44576faeafc49)
  424. # [18:59] <hsivonen> it comes from the IETF, so it has lots of colons like an IPv6 address :-)
  425. # [19:02] * Parts: Camaban (n=adrianle@81.133.236.188)
  426. # [19:06] <hsivonen> hmm. If both jchardet and the ICU detector are enabled, which one should run first?
  427. # [19:07] <Philip`> It quite looks like the NETCONF RFC misunderstands XML namespaces
  428. # [19:08] <Philip`> e.g. for <rpc message-id="101" xmlns="...netconf..." xmlns:ex="...example..." ex:user-id="fred"> it says "Note that the "user-id" attribute is not in the NETCONF namespace.", which seems to be implying that message-id is
  429. # [19:09] <Hixie> wait let me get this right
  430. # [19:09] <Hixie> are you saying that someone writing a standard... didn't understand xmlns?
  431. # [19:09] <Hixie> surely you jest
  432. # [19:10] <othermaciej> xmlns misunderstood, film at 11
  433. # [19:11] <Philip`> and also it has <rpc-reply xmlns="...netconf..." xmlns:xc="...netconf...">...<top xmlns="...example..."><interface xc:operation="replace"> in an example, to set "the operation attribute" (and it never says that should be a namespaced attribute, and never implies it except in the example)
  434. # [19:12] <Hixie> i am shocked.
  435. # [19:12] <Hixie> shocked, i say.
  436. # [19:12] <Hixie> shocked and dismayed.
  437. # [19:12] <hsivonen> attribute namespaces misunderstood film at 11
  438. # [19:13] <andersca> lo
  439. # [19:13] <andersca> l
  440. # [19:13] <Philip`> At least it forbids doctype declarations, which could be considered sensible
  441. # [19:14] * virtuelv is now known as standards_barbie
  442. # [19:14] <standards_barbie> xmlns is hard, let's go shopping
  443. # [19:14] * standards_barbie is now known as virtuelv
  444. # [19:16] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  445. # [19:18] <Hixie> i wonder if i should just treat "<tr><th>X</th> <!-- no significant content --> </tr>" the same as "<tr><th colspan=N>X</th></tr>" (where N = number of columns)
  446. # [19:18] <Hixie> instead of treating the former in a separate way
  447. # [19:22] <Hixie> data:text/html;base64,PHRhYmxlPjx0cj48dGg%2BSDx0aD5IPHRoPkg8dHI%2BPHRoPkg8dHI%2BPHRoPkg8dGQ%2BRDx0ZD5EPHRyPjx0aCBjb2xzcGFuPTM%2BSDx0cj48dGg%2BSDx0ZD5EPHRkPkQ8dHI%2BPHRoPkg8dHI%2BPHRoPkg8dGQ%2BRDx0ZD5EPHRyPg%3D%3D
  448. # [19:22] <Hixie> what should the default interpretation of that table be?
  449. # [19:23] * Quits: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com) (Read error: 110 (Connection timed out))
  450. # [19:32] * Hixie trips on some passing tumbleweed
  451. # [19:33] * Joins: weinig (n=weinig@17.203.15.180)
  452. # [19:33] <Philip`> I think the browser should add a <caption> element saying "ERROR: Table is too complex"
  453. # [19:35] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  454. # [19:35] * Quits: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  455. # [19:36] <Hixie> heh
  456. # [19:38] <Philip`> It seems helpful for authors if the algorithm is simple and predictable enough that they can tell whether their slightly-fancy table is going to be automatically headerised correctly, or if they're going to have to manually annotate it
  457. # [19:38] <Philip`> at least for authors who know a bit about the table thing, and care about it, but can't be bothered to use some awkward ugly tool to tell them how the table really is processed
  458. # [19:39] <Philip`> (rather than trying to make the algorithm really complex so it handles lots of weird edge cases)
  459. # [19:54] <andersca> Hixie: "If the resource is not being loaded as part of navigation of a top-level browsing context"
  460. # [19:55] <andersca> Hixie: that statement would be true when loading something in an iframe, right?
  461. # [20:03] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  462. # [20:05] * Joins: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net)
  463. # [20:11] <Hixie> andersca: or a stylesheet, or an image, or XMLHttpRequest, etc, yeah
  464. # [20:11] <Hixie> or script
  465. # [20:11] <Hixie> or any number of other things
  466. # [20:12] <Hixie> basically anything except the maii document :-)
  467. # [20:12] <Hixie> main
  468. # [20:12] <andersca> although I guess that only xmlhttprequests can cause the cache selection algorithm to be invoked
  469. # [20:13] <Hixie> i think the cache selection algorithm can only be invoked when there's a browsing context
  470. # [20:13] <andersca> ah, yeah
  471. # [20:18] * Quits: david__ (i=david@bsdguru.net) ("leaving")
  472. # [20:20] * Joins: othermaciej (n=mjs@nat/apple/x-56d591b8379bd398)
  473. # [20:49] * Quits: maikmerten (n=maikmert@L991f.l.pppool.de) (Remote closed the connection)
  474. # [20:54] <Hixie> http://www.pcworld.com/article/id,140408/article.html is funny
  475. # [20:55] <Hixie> (given safari 3.1)
  476. # [20:55] <andersca> ...nothing about safari :(
  477. # [20:56] <Hixie> yeah i love that the only browser to actually _ship_ <video> is the only one not mentioned
  478. # [20:57] <othermaciej> the point being, they wanted to do it, and a few months later we actually did it
  479. # [20:57] <Hixie> exactly
  480. # [20:57] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  481. # [20:57] <Hixie> http://www.linuxworld.com/community/?q=node/1768 is also funny
  482. # [20:57] <andersca> lol
  483. # [20:57] <Hixie> because actually, what the commenter doesn't realise is that if what he suggests were to happen, it would have the opposite effect
  484. # [20:58] <tomg> heh
  485. # [21:14] <hsivonen> clearly, one-way IO streams are the wrong abstraction for feeding an HTML parser from HTTP
  486. # [21:15] <hsivonen> the right interface would reuse the HTTP lib cache backing store for rewinding
  487. # [21:15] <othermaciej> that assumes the cache is available as a usable memory buffer during parsing
  488. # [21:15] <othermaciej> likely untrue
  489. # [21:15] <othermaciej> (unless the item is already in cache)
  490. # [21:16] <othermaciej> (or came in as one network read)
  491. # [21:16] * virtuelv refrains from commenting on <video>
  492. # [21:18] <hsivonen> othermaciej: it seems to me that the HTTP lib should create a memory cache object for uncacheable resources in case of rewinding
  493. # [21:19] <othermaciej> hsivonen: what I mean is, if it's a resizable buffer, you can't count on it remaining good while the network thread may be loading more data
  494. # [21:19] <othermaciej> though you could count on the individual chunks it gives you I suppose, depending on design of the library
  495. # [21:20] <virtuelv> or wait, I'll comment, but emphasizing that this is my highly personal opinion, and not reflecting anybody else's: Shipping video without support for a freely implementable codec is like not shipping <video> at all
  496. # [21:20] <hsivonen> oh yeah, the interface can't be a simple memory pointer
  497. # [21:20] <othermaciej> virtuelv: I'm sure at least one of the many codecs QuickTime handles is freely implementable
  498. # [21:21] <othermaciej> and I know for sure that you can download an Ogg codec, and that is believed by many to be freely implementable
  499. # [21:21] <hsivonen> I guess I should test if Safari 3.1 got the codecs parameter right
  500. # [21:21] <othermaciej> I'm not sure it did
  501. # [21:21] <othermaciej> test cases and/or bug reports welcome
  502. # [21:22] <othermaciej> don't worry about it poisoning the well, as you can see we are on a faster release cycle these days
  503. # [21:22] <virtuelv> othermaciej: yes, but unless codecs are automatically located and automatically installed, next to noone is going to install it, hence rendering it unusable
  504. # [21:22] <virtuelv> (the freely implementable quicktime codecs are likely aged and inefficient, no?)
  505. # [21:22] <hsivonen> actually, I'm worried that the codecs RFC may have too big a mismatch with QuickTime/GStreamer/DirectShow codec identities
  506. # [21:23] * Quits: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net) ("Leaving.")
  507. # [21:23] <gsnedders> that's hardly a new issue. Just look at charsets
  508. # [21:23] <othermaciej> of the codecs QuickTime supports, I am pretty sure at least H.261 and MPEG-1 are freely implementable (in the sense that all patents must be expired), and probably H.263 as well
  509. # [21:23] <othermaciej> I don't know if it is that bad a mismatch
  510. # [21:23] <gsnedders> othermaciej: H.263 is far too recent
  511. # [21:24] <gsnedders> othermaciej: MPEG-1 is too recent, but probably not by the time with get to REC
  512. # [21:24] <virtuelv> then again. this is what is wrong with the entire patent system
  513. # [21:24] <hsivonen> does any browser support any flavor of ISCII?
  514. # [21:25] <othermaciej> virtuelv: for now we are only exporting the platform capabilities, but we are trying to help the work towards a free baseline codec
  515. # [21:26] <othermaciej> gsnedders: I think I was a little mixed up, I believe the state with H.263 is that in practice none of the possibly relevant patent holders appear to ever assert their patents against it
  516. # [21:26] <gsnedders> othermaciej: what platform capabilities on Windows? DirectShow? Or do you require QT?
  517. # [21:26] <othermaciej> not sure if that counts as "freely implementable"
  518. # [21:26] <othermaciej> we require QT on Windows
  519. # [21:26] <othermaciej> the Gtk port uses GStreamer
  520. # [21:26] <othermaciej> the Qt port uses Phonon
  521. # [21:27] <othermaciej> I wouldn't rule out supporting DirectShow on Windows someday
  522. # [21:27] <gsnedders> othermaciej: I doubt whether that's good enough for the people who need to take the risk
  523. # [21:27] <othermaciej> or possibly having some built-in codecs
  524. # [21:28] <virtuelv> othermaciej: it is the use of a non-free format that irks me
  525. # [21:28] <gsnedders> I'm not sure how I feel about build-in codecs. On the fact of it, I'm against it. Why re-implement something that the platform provides?
  526. # [21:28] <virtuelv> many linux distros do not install stuff that has known patent issues
  527. # [21:29] <hsivonen> how recent is Phonon? I don't recall seeing it on Ubuntu package lists, so I was unaware of the whole framework
  528. # [21:29] <gsnedders> hsivonen: Part of KDE4
  529. # [21:29] <gsnedders> hsivonen: so pretty
  530. # [21:30] <othermaciej> gsnedders: I mean that if there is a common baseline then maybe we'd provide it for platforms that do not have a platform version, should there be any
  531. # [21:30] <gsnedders> othermaciej: hmm, I'd lean towards just installing it at a platform level with the browser
  532. # [21:30] <hsivonen> gsnedders: thanks. that explains it
  533. # [21:31] * Joins: anttik (n=antti@c-98-210-186-181.hsd1.ca.comcast.net)
  534. # [21:39] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  535. # [21:40] <Hixie> my whiteboard is full of little table diagrams
  536. # [21:48] <Hixie> http://junkyard.damowmow.com/306
  537. # [21:52] <andersca> nice
  538. # [21:53] * Joins: jruderman_ (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  539. # [22:02] * Quits: ROBOd (n=robod@89.122.216.38) (Read error: 110 (Connection timed out))
  540. # [22:07] <hsivonen> Philip`: did you develop a list of good chardet test URIs as a side effect of your chardet testing?
  541. # [22:09] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  542. # [22:11] <svl> One of my friends just brought up a 'problem' with dialog: how to use if the conversation has "branches"? (e.g. choose-your-own adventure, marking up a script from a computer game, ...)
  543. # [22:11] <svl> Personally I don't think anything is a good fit for that... but anyone care to differ?
  544. # [22:11] <Hixie> <dialog> is just for the dialog part
  545. # [22:11] <Hixie> the prose is still in <p>s
  546. # [22:12] <Hixie> so you'd have <p>...</p><p>...</p><dialog>...</dialog><p> Do you want to <a href=...>...</a> or <a href=...>...</a>?</p>
  547. # [22:13] <Philip`> hsivonen: I'm not quite sure which chardet testing you mean
  548. # [22:13] <svl> Ah! So start a new dialog for each branch.
  549. # [22:14] <Philip`> Oh, that thing with buffer lengths
  550. # [22:15] <Philip`> hsivonen: I'm not sure what a "good chardet test URI" would be, so I don't already have a list of them
  551. # [22:15] * Parts: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  552. # [22:16] <hsivonen> Philip`: ok. A good chardet test URI would be a real-world page that lacks an external encoding declaration, a BOM and a charset meta within the first 512 bytes
  553. # [22:18] <hsivonen> on the other hand, Windows-1252 pages with no declarations are needed for testing against the detector accidentally degrading the result compared to simple default
  554. # [22:21] * hsivonen realizes that Philip` already published http://philip.html5.org/data/charsets.html
  555. # [22:21] <andersca> Hixie: got another q for you
  556. # [22:21] <Hixie> shoot
  557. # [22:21] <andersca> Hixie: "If there is already an application cache identified by this manifest URI, and that application cache contains a resource with the URI of the manifest"
  558. # [22:21] <andersca> I should only look at the newest cache in the group there, right
  559. # [22:22] <Philip`> hsivonen: Ah, okay - I could fairly easily make a list of pages with no HTTP Content-Type and no meta in 512 bytes
  560. # [22:22] <Hixie> the newest "idle" or "complete" or whatever-i-called-it cache, right
  561. # [22:22] <Hixie> andersca: i should make that clearer, can you mail about that?
  562. # [22:22] <Philip`> hsivonen: (I don't believe I found a single page with a BOM, so that's not especially relevant)
  563. # [22:22] <andersca> Hixie: I sure can
  564. # [22:22] <Hixie> andersca: thanks
  565. # [22:23] * Hixie is so deep within the table algorithm it hurts
  566. # [22:23] <Hixie> right now i'm changing my boneheaded decision to make the table argorithm be one-based to being zero-based
  567. # [22:23] <Philip`> hsivonen: (or my BOM-detector was buggy)
  568. # [22:24] <hsivonen> Philip`: that kind of list would be useful
  569. # [22:29] <Hixie> i need to change y_current to y_next, someone remind me of that in about 25 minutes
  570. # [22:31] <andersca> Hixie: hmm, cache status is per group,
  571. # [22:31] <Philip`> hsivonen: I have a list of 42K URIs with neither HTTP content-type nor sniffable-in-512-bytes meta
  572. # [22:31] <Hixie> right
  573. # [22:31] <Philip`> hsivonen: (i.e. about a third of all the pages)
  574. # [22:31] <Hixie> but while you're running the update thingy, one of the caches isn't ready
  575. # [22:31] <Hixie> right?
  576. # [22:31] <Hixie> something like that
  577. # [22:31] <Hixie> i forget the terminology i made up
  578. # [22:31] <andersca> this is not the update thingy, this is the select thingy
  579. # [22:31] <andersca> :)
  580. # [22:31] <Hixie> right
  581. # [22:31] <Hixie> but they can happen at the same time
  582. # [22:31] <Hixie> so the select thingy needs to be aware of the update thingy
  583. # [22:32] <hsivonen> Philip`: great. do you have it at an URI?
  584. # [22:32] <Philip`> hsivonen: I have a file:// URI for it
  585. # [22:32] <andersca> Hixie: ah
  586. # [22:32] <andersca> Let cache be the most recently updated application cache identified by manifest URI (that is, the newest version found in cache group).
  587. # [22:32] <Hixie> right
  588. # [22:33] <andersca> so it doesn't need to be the newest cache, it needs to be the most recently updated cache
  589. # [22:33] <Hixie> isn't that the same thing?
  590. # [22:33] <hsivonen> Philip`: I think I can't dereference file:// properly. but then I don't need the whole list, since I'm not patient enough to inspect so many pages manully
  591. # [22:34] <Philip`> hsivonen: Also http://philip.html5.org/data/pages-without-obvious-charset.txt
  592. # [22:34] <Philip`> Uh, and s/&amp;/&/g before using it
  593. # [22:34] <hsivonen> Philip`: thank you
  594. # [22:34] <Philip`> (Actually, I might as well make that change...)
  595. # [22:36] * Philip` wonders why sed doesn't work
  596. # [22:37] <Philip`> Anyway, fixed ampersands now
  597. # [22:38] <Philip`> http://020epos.de/ - he's standing on a scarily enormous phone
  598. # [22:44] * jgraham cheers zero based table algorithm
  599. # [22:44] <Hixie> yeah i dunno why i did it one-based
  600. # [22:44] <Hixie> but let me tell you, there's nothing quite like offsetting an entire algorithm by one
  601. # [22:44] <hsivonen> surprisingly many frontpages are ascii-only meta refreshes
  602. # [22:46] <jgraham> I blame Pascal (that is one based by default, right?)
  603. # [22:46] <Hixie> not as far as i recall
  604. # [22:46] <Hixie> oh, their old-style strings were 1-based (in that index 0 was the length byte), if that's what you mean
  605. # [22:47] * jgraham has never programmed Pascal so doesn't actually know, but knows that Hixie has
  606. # [22:47] <Hixie> yeah, i grew up on pascal
  607. # [22:47] <Hixie> various kinds thereof
  608. # [22:48] <Philip`> $[ = 1;
  609. # [22:48] <Hixie> dude
  610. # [22:48] <Hixie> that's deprecated
  611. # [22:48] <Philip`> perlvar merely says it's "highly discouraged"
  612. # [22:49] <Hixie> that's what being deprecated means
  613. # [22:49] <Philip`> (unlike e.g. $* which is explicitly deprecated)
  614. # [22:49] <hsivonen> Pascal's indexing is harmful
  615. # [22:49] <Hixie> i really don't recall ever having any problem with indexing in pascal, but maybe the compilers i used had "fixed" that feature
  616. # [22:49] <Hixie> i don't recall using 1-based arrays
  617. # [22:50] <Hixie> and strings were 0-based, except for the anomaly of the zeroth byte of a string being its length instead of the first character
  618. # [22:50] <Hixie> (and more modern string types in pascal are all zero-based)
  619. # [22:51] <hsivonen> what's with all these Chinese government sites having a meta refresh instead of a proper root page?
  620. # [22:51] <Philip`> Option Base 1;
  621. # [22:51] <Philip`> Uh, without the semicolon
  622. # [22:51] <jgraham> Of course Fortran will let you set array indicies on a case-by-case basis
  623. # [22:51] <Hixie> never used basic
  624. # [22:51] <Hixie> i'm glad to say
  625. # [22:52] <Hixie> (well, except for a couple of things, but i never used "option base" in any basic i ever used)
  626. # [22:53] <hsivonen> haha. not even meta refresh:
  627. # [22:53] <hsivonen> UrlTable[0] = "index_cn.html";
  628. # [22:53] <hsivonen> location.href=UrlTable[Math.round(Math.random()*(UrlTable.length-1))];
  629. # [22:53] <jgraham> real a(-134, 126)
  630. # [22:53] <Hixie> jgraham: yeah, pascal is the same, you can set arrays to be whatever indicies you want
  631. # [22:53] <Philip`> hsivonen: Uh, isn't that going to go to undefined half the time?
  632. # [22:53] <Hixie> jgraham: on another note, i just regenned the spec, if you have a moment it'd be great to see if you can find bugs in the new algorithm (i only changed the base)
  633. # [22:53] <gsnedders> Hixie: weren't myself, you, and cwilso discussing Pascal a while back, when cwilso mentioned arrays could be any based?
  634. # [22:54] <hsivonen> Philip`: so it seems
  635. # [22:54] <jgraham> Hixie you wanted o be reminded now "i need to change y_current to y_next"
  636. # [22:54] <Hixie> yeah i did that
  637. # [22:54] <gsnedders> Hixie: sorry, I'm a bit behind reading
  638. # [22:54] <hsivonen> who needs 1-based indeces when you can select from one slot at random?
  639. # [22:54] <Hixie> gsnedders: yeah, "array[2..92] of byte;" or some such
  640. # [22:54] <gsnedders> fun :\
  641. # [22:54] <Philip`> For interoperability, HTML5 needs to define the random number generator seed that must be initialised at every page load
  642. # [22:55] * gsnedders ponders
  643. # [22:55] <jgraham> Apparently some well known scientific codes fake 1-based arrays in C just because the authors were more used to Fortran
  644. # [22:55] <gsnedders> It seems I'll likely be going to Cambridge twice this year.
  645. # [22:56] <hsivonen> hah. I found a chinese govt site that has over 512 bytes of style before meta. loading it in Firefox tells me it is an attack site
  646. # [22:56] * hsivonen is assuming that .gov.cn is government
  647. # [22:57] <Hixie> if 0<=z<5, z_max = 4, what would you call the constant 5? z_what?
  648. # [22:57] <Philip`> Mathematicians can't even decide whether N (the set of natural numbers) starts at 0 or 1
  649. # [22:57] <Hixie> or what you say z_max was 5?
  650. # [22:57] <gsnedders> Philip`: 1.
  651. # [22:57] <gsnedders> :P
  652. # [22:57] <Philip`> Hixie: Is z an integer?
  653. # [22:57] <hsivonen> I conclude that heuristics for Simplified Chinese work
  654. # [22:57] <hsivonen> onto Japanese
  655. # [22:58] <gsnedders> Hixie: z_max has any relevance elsewhere?
  656. # [22:58] <Hixie> Philip`: yes
  657. # [22:58] <Philip`> Hixie: I'd say z_max was the maximum z, i.e. 4, not 5, and I'd say anything else was crazy
  658. # [22:58] <Hixie> Philip`: ok, so what is 5?
  659. # [22:58] <Philip`> z_max+1
  660. # [22:58] <jgraham> z_max + 1
  661. # [22:59] <Hixie> well, if we were talking about x instead of z, i'd say it was "width"
  662. # [22:59] * Joins: othermaciej_ (n=mjs@17.255.98.222)
  663. # [22:59] <jgraham> Range?
  664. # [23:00] <Philip`> Just use numbers and letters, and don't bother with meaningful English words
  665. # [23:00] <jgraham> (but if you do that you need to define z_range = z_max - z_min +1)
  666. # [23:00] <Hixie> screw it, i'll use x_width and y_height
  667. # [23:01] * Joins: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  668. # [23:02] <Philip`> gsnedders: Hopefully at least one of those occasions won't be too rainy
  669. # [23:02] <gsnedders> Philip`: it tends to be all right in July, at least
  670. # [23:02] * Joins: eseidel_ (n=eseidel@72.14.224.1)
  671. # [23:04] <andersca> Hixie: another q about the selection process
  672. # [23:04] <andersca> "Otherwise, there is no matching application cache: create a new application cache identified by this manifest URI, store the resource in that cache, categorised as an implicit entry, and then invoke the application cache update process."
  673. # [23:04] <jgraham> gsnedders: We're having a conference in July and the conference "gift" will be an umbrella...
  674. # [23:05] <gsnedders> jgraham: heh.
  675. # [23:05] <andersca> Hixie: "store the resource" means store the headers + contents?
  676. # [23:05] <gsnedders> jgraham: I mean, I'm heading south (within the northern hemisphere)! The weather should be better, no?
  677. # [23:05] <Hixie> andersca: it means the resource, including any metadata, forks, alternate streams, anything that comes with it
  678. # [23:06] <andersca> Hixie: OK - so
  679. # [23:06] <andersca> Hixie: since this is during the selection process, the resource has most likely not finished loading yet
  680. # [23:06] <jgraham> gsnedders: Well it's supposed to be one of the dries places in he country, but I think he west coast of Scotland is too
  681. # [23:06] <jgraham> driest
  682. # [23:06] <gsnedders> jgraham: s/west/east
  683. # [23:07] <jgraham> er, yeah
  684. # [23:07] <Hixie> andersca: indeed
  685. # [23:08] <andersca> Hixie: and that is probably not a problem since the update process is started right after adding it
  686. # [23:09] <Hixie> andersca: i'm not sure why it would be a problem at all really, other than for implementation reasons
  687. # [23:10] <Hixie> as in, i could see architectural problems with systems not designed to support this being an issue
  688. # [23:10] <gsnedders> jgraham: yeah, it's as dry here as it is in Rome
  689. # [23:10] <andersca> Hixie: right
  690. # [23:10] <Hixie> but conceptually, it's just a matter of deciding where to stream the data to
  691. # [23:11] <andersca> what if I load my html file which has a cache manifest and an iframe which references the same html file
  692. # [23:11] <hsivonen> ok. I trust the heuristics work well enough. time to deploy
  693. # [23:11] <Hixie> andersca: the iframe always just uses the top-level browsing context's cache, and never ends up creating its own cache itself
  694. # [23:12] * Quits: othermaciej (n=mjs@nat/apple/x-56d591b8379bd398) (Nick collision from services.)
  695. # [23:12] <andersca> Hixie: yeah, but where would the iframe get the html file from? would it depend on whether the cache was finished updating or not?
  696. # [23:12] * othermaciej_ is now known as othermaciej
  697. # [23:13] <Hixie> andersca: it would get it from whatever cache its top-level browsing context is associated with. if it's not associated with anything, it would get it from the main cache.
  698. # [23:13] <Hixie> (or, failing that, the network)
  699. # [23:14] * Quits: eseidel_ (n=eseidel@72.14.224.1)
  700. # [23:16] <andersca> Hixie: I mean, let's say I have something like
  701. # [23:17] <andersca> a file called test.html which looks like
  702. # [23:17] <andersca> <html manifest=...><iframe src="test.html"></iframe></html>
  703. # [23:18] <Hixie> is this the first time you visit it, or the second time?
  704. # [23:18] <andersca> the first time
  705. # [23:18] <Hixie> i.e. do you already have a cache for it?
  706. # [23:18] <Hixie> ok
  707. # [23:18] <andersca> I do not
  708. # [23:18] <hsivonen> parsetree.validator.nu now uses both chardet and the ICU detector
  709. # [23:18] <hsivonen> the validation side doesn't use heuristics
  710. # [23:19] <Hixie> andersca: ok, so, regardless of what's going on with the manifest, the result is an infinitely nested iframe of the same document. however:
  711. # [23:19] <andersca> yeah, I agree it's a bad test case :)
  712. # [23:19] <Hixie> andersca: until such time as the manifest has been downloaded and processed, the iframes will be populated from the main cache
  713. # [23:19] <Hixie> andersca: then, once the manifest is processed, the iframe will start getting populated from the manifest cache
  714. # [23:20] * Quits: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net) (Connection timed out)
  715. # [23:20] <Hixie> 4.6.5.1. Changes to the networking model is the key section for this
  716. # [23:21] <Hixie> (note in particular step 5)
  717. # [23:21] <Hixie> (though it doesn't affect this case)
  718. # [23:21] <andersca> step 3 is the relevant step here, right
  719. # [23:22] <Hixie> the 3rd paragraph of step 24 of the application cache update process is the key here
  720. # [23:23] <Hixie> when that happens, suddenly the new network model takes effect
  721. # [23:24] * Philip` knows nothing about this algorithm, but the mere existence of a 3rd paragraph of a 24th step makes it sound unreasonably complex :-p
  722. # [23:24] <andersca> ah
  723. # [23:24] * Joins: csarven (i=csarven@on-irc.csarven.ca)
  724. # [23:24] <andersca> Philip`: not necessarily, it can also be detailed
  725. # [23:24] <hsivonen> why is it that I see more silly refresh and window.location front pages on Chinese and Korean sites than on German and Polish sites?
  726. # [23:24] <Hixie> Philip`: it's pretty verbose
  727. # [23:24] <Hixie> Philip`: and believe me, mucking in the way that browsers load files is always gonna be complex, unless it's underspecified :-)
  728. # [23:25] <Philip`> hsivonen: I would expect you'd see more <marquee>s on them too
  729. # [23:25] <Philip`> which presumably is a cultural issue
  730. # [23:26] <Philip`> or I'm just stereotyping :-)
  731. # [23:26] <hsivonen> Philip`: sure, marquee is cultural, but is failing to serve proper content at site root cultural?
  732. # [23:28] * Joins: eseidel (n=eseidel@adsl-76-204-78-156.dsl.pltn13.sbcglobal.net)
  733. # [23:29] <Philip`> Aha, fortunately I have evidence for my opinion - 30% of the .cn sites in dmoz.org use <marquee>, vs 3% of all sites
  734. # [23:30] <Philip`> (.kr and .jp are around 3%)
  735. # [23:31] <hsivonen> FrontPage sure seems to be popular on Taiwan
  736. # [23:31] <Philip`> (and .tw is about 3% too)
  737. # [23:32] * Philip` wonders if there's a good way of automatically finding significant correlations like this
  738. # [23:35] <Hixie> make a list of all the characteristics, get the characteristics for all the demographics you want tested, and then flag any values that are more than one stddev outside the mean?
  739. # [23:36] * Quits: eseidel (n=eseidel@adsl-76-204-78-156.dsl.pltn13.sbcglobal.net)
  740. # [23:36] <hsivonen> hmm. the detection fails big time in .ru
  741. # [23:36] <hsivonen> KOI-R get misdetected as Chinese UTF-16
  742. # [23:36] <Philip`> hsivonen: Is that because there's no Cyrillic detector in jchardet?
  743. # [23:37] <hsivonen> Philip`: probably
  744. # [23:37] <hsivonen> I think I should reject UTF-16 in the detectors
  745. # [23:37] <hsivonen> real UTF-16 comes with a BOM anyway
  746. # [23:37] <hsivonen> or so I would hope
  747. # [23:39] <Philip`> Real UTF-16 tends to stay away from web
  748. # [23:39] <Philip`> Actually, that's a completely unfounded statement
  749. # [23:40] <Philip`> The web tends to stay away from UTF-16
  750. # [23:40] * Joins: Charl (n=charlvn@196-209-25-154-nngy-esr-2.dynamic.isadsl.co.za)
  751. # [23:47] <bzed> lxml 2.0 seems to break the html5lib tests: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471638
  752. # [23:51] * Joins: eseidel (n=eseidel@70-2-96-174.area5.spcsdns.net)
  753. # [23:53] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  754. # [23:55] <jgraham> bzed: known issue that we will fix soonish (it's the second thing on my priority list)
  755. # [23:56] <jgraham> Do you need a fix for some release, in which case I will move it to first?
  756. # [23:59] * Quits: KevinMarks (n=KevinMar@nat/google/x-4ab0109dc4ba14ac) ("The computer fell asleep")
  757. # [23:59] <bzed> jgraham: as long as it is fixed before Debian's Lenny is frozen, I'll be fine. THat's not too far away, though, but I guess there're at least 4 weeks left to fix it
  758. # Session Close: Fri Mar 21 00:00:00 2008

The end :)