/irc-logs / freenode / #whatwg / 2007-10-12 / end

Options:

  1. # Session Start: Fri Oct 12 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:03] * Quits: tantek_ (n=tantek@h460df832.area2.spcsdns.net) (Read error: 110 (Connection timed out))
  4. # [00:20] * Joins: hober (n=ted@unaffiliated/hober)
  5. # [00:42] * om_afk is now known as othermaciej
  6. # [00:53] <jeremyb> lastlog -clear
  7. # [01:19] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  8. # [01:26] * Quits: weinig (n=weinig@17.203.15.140) (Read error: 104 (Connection reset by peer))
  9. # [01:26] * Joins: weinig (n=weinig@17.203.15.140)
  10. # [01:28] * Joins: billmason (n=billmaso@ip156.unival.com)
  11. # [01:38] <Hixie_> mjs, others, any input on this? http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-October/012683.html
  12. # [01:38] <Hixie_> should i include such an API?
  13. # [01:40] <othermaciej> Hixie_: hadn't thought about it deeply - I can see how it might be useful, the only concern I have is that preflighting for the availability of a resource in the cache instead of looking for an error on access introduces possible races
  14. # [01:40] <othermaciej> (in other words the cache item could expire between when you ask and when you try to access it)
  15. # [01:40] <Hixie_> indeed
  16. # [01:41] <Hixie_> and vice versa, could be added in between
  17. # [01:41] <othermaciej> true
  18. # [01:41] <othermaciej> or you could go offline/online in between, thus changing the rules of what resources can be served even expired
  19. # [01:41] <othermaciej> but I'm not sure how to achieve the desired result without preflighting
  20. # [01:42] <Hixie_> yeah
  21. # [01:42] * Quits: tndH (i=Rob@87.102.2.12) ("ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  22. # [01:43] * Joins: heycam` (n=cam@clm-laptop.infotech.monash.edu.au)
  23. # [01:43] <kingryan> could the API take a function that is executed iff the resource is available? then the impl could synchronize on the cache
  24. # [01:43] <Hixie_> maybe
  25. # [01:43] * kingryan doesn't know how hard is suggestion would be to implement
  26. # [01:45] <othermaciej> the hard part to implement would be ensuring whatever load you may trigger uses that cached copy
  27. # [01:45] <othermaciej> it could be setting a frame's window.location, it could be setting an img src, it could be an XMLHttpRequest...
  28. # [01:45] <othermaciej> there's lots of ways to trigger a resource load
  29. # [01:45] <othermaciej> in a sense the most robust API would be to add a "try if local, otherwise error" version of all of those
  30. # [01:46] <othermaciej> or at least the ones that are considered important for this purpose
  31. # [01:48] * Joins: weinig_ (n=weinig@17.203.15.140)
  32. # [01:49] * Quits: weinig (n=weinig@17.203.15.140) (Read error: 104 (Connection reset by peer))
  33. # [01:50] * Quits: DrChirs (n=IceChat7@204-16-231-250-accuradio.pkh.ord.sparkplugbb.net) ("For Sale: Parachute. Only used once, never opened, small stain.")
  34. # [01:56] * Quits: kingryan (n=kingryan@corp.technorati.com)
  35. # [02:17] * Quits: doublec (n=doublec@202.180.114.137)
  36. # [02:18] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.2 (IRC client for Emacs)")
  37. # [02:29] * Joins: mpt (n=mpt@121-72-139-108.dsl.telstraclear.net)
  38. # [02:34] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  39. # [02:42] * Joins: doublec (n=doublec@202.180.114.137)
  40. # [02:48] * Joins: bzed_ (n=bzed@devel.recluse.de)
  41. # [02:49] * Quits: bzed (n=bzed@devel.recluse.de) (Read error: 104 (Connection reset by peer))
  42. # [02:49] * Quits: weinig_ (n=weinig@17.203.15.140) (Read error: 110 (Connection timed out))
  43. # [02:59] * Quits: billmason (n=billmaso@ip156.unival.com) (".")
  44. # [03:18] * Quits: h3h (n=w3rd@66-162-32-234.static.twtelecom.net) ("|")
  45. # [03:32] * Joins: weinig (n=weinig@adsl-71-138-134-104.dsl.pltn13.pacbell.net)
  46. # [03:42] * Quits: KevinMarks (i=KevinMar@nat/google/x-3c48cc411ee3aadc) ("The computer fell asleep")
  47. # [03:55] * Quits: othermaciej (n=mjs@17.255.111.81)
  48. # [04:04] * Joins: jruderman (n=jruderma@ip68-5-234-103.oc.oc.cox.net)
  49. # [04:35] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  50. # [04:50] * Quits: weinig (n=weinig@adsl-71-138-134-104.dsl.pltn13.pacbell.net) (Remote closed the connection)
  51. # [04:50] * Joins: weinig (n=weinig@adsl-71-138-134-104.dsl.pltn13.pacbell.net)
  52. # [05:00] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  53. # [05:08] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  54. # [05:10] * Quits: jruderman (n=jruderma@ip68-5-234-103.oc.oc.cox.net) (Read error: 110 (Connection timed out))
  55. # [05:19] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  56. # [06:01] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 110 (Connection timed out))
  57. # [06:06] * Quits: mpt (n=mpt@121-72-139-108.dsl.telstraclear.net) ("This computer has gone to sleep")
  58. # [06:22] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http:/www.csarven.ca")
  59. # [06:28] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  60. # [06:41] * Quits: doublec (n=doublec@202.180.114.137)
  61. # [07:00] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  62. # [07:02] * weinig is now known as weinig|zZz
  63. # [07:15] * Joins: mpt (n=mpt@222-155-23-106.jetstream.xtra.co.nz)
  64. # [07:23] * Joins: tantek (n=tantek@h460d99c6.area2.spcsdns.net)
  65. # [07:58] * Quits: heycam` (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  66. # [08:04] * Joins: hober (n=ted@unaffiliated/hober)
  67. # [08:22] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  68. # [08:33] * Quits: mpt (n=mpt@222-155-23-106.jetstream.xtra.co.nz) (Read error: 110 (Connection timed out))
  69. # [08:41] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  70. # [09:22] <Lachy> good morning :-)
  71. # [09:22] * Quits: weinig|zZz (n=weinig@adsl-71-138-134-104.dsl.pltn13.pacbell.net) (Read error: 104 (Connection reset by peer))
  72. # [09:23] * Joins: weinig (n=weinig@adsl-67-124-36-161.dsl.pltn13.pacbell.net)
  73. # [09:37] <hsivonen> Lachy: morning
  74. # [09:53] * Joins: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
  75. # [10:08] * Joins: ROBOd (n=robod@89.122.216.38)
  76. # [10:13] * Joins: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl)
  77. # [10:42] <hsivonen> I wonder what the point of the NCNameness of xml:id is or the point of the normalization
  78. # [10:44] <othermaciej> architecture
  79. # [10:44] <othermaciej> *xml* architecture
  80. # [10:47] <hsivonen> off-hand, I don't see what architectural problem the NCNameness solves here
  81. # [10:48] <hsivonen> it's just an arbitrary "we like this kind of strings but not other kinds of strings"
  82. # [10:48] <othermaciej> my implication is that everything about xml boils down to that sort of thing
  83. # [10:49] <hsivonen> yeah
  84. # [10:50] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  85. # [10:50] <hsivonen> so far, xml:id is taking me more than thrice the # of lines of code needed for XHTML5 ids.
  86. # [10:54] <hsivonen> for now, I'm going to pretend that the conditional IDness of SVG 1.2 id doesn't exist and SVG ids are unconditionally IDs.
  87. # [10:55] <othermaciej> conditional idness?
  88. # [10:56] <othermaciej> are id attributes not ID when an xml:id is also present or something?
  89. # [10:56] <hsivonen> othermaciej: according to SVG 1.2, IIRC, yes
  90. # [10:56] <hsivonen> not cool
  91. # [10:56] <othermaciej> they probably did that to work around the fact that you can't have id="x" xml:id="x"
  92. # [10:57] <othermaciej> which you would need to both work with older versions of SVG and to drink the latest kool-aid
  93. # [10:59] <hsivonen> othermaciej: it is easy to guess why they did it, but it is the wrong fix
  94. # [10:59] <hsivonen> othermaciej: the right fix is to use only id='x' without xml:id='x'
  95. # [10:59] <hsivonen> anyway, last bullet point under http://www.w3.org/TR/SVGMobile12/struct.html#Core.attrib
  96. # [10:59] <othermaciej> hsivonen: but that would entail not using xml:id, which is the cool new thing, and thus obviously right to use
  97. # [10:59] <hsivonen> so my memory didn't fail me
  98. # [11:03] <zcorpan> hsivonen: would you be shot down for not supporting xml:id at all? :)
  99. # [11:08] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (devel) (IRC client for Emacs)")
  100. # [11:11] * Joins: BenWard (i=BenWard@nat/yahoo/x-46114b8bb62daf9b)
  101. # [11:11] * Parts: BenWard (i=BenWard@nat/yahoo/x-46114b8bb62daf9b)
  102. # [11:13] <hsivonen> zcorpan: I don't know
  103. # [11:13] <hsivonen> I feel like venting on www-svg, but it would probably be wasted effort
  104. # [11:19] * othermaciej is now known as om_sleep
  105. # [11:20] * Quits: Lachy (n=Lachy@pat-tdc.opera.com) ("Leaving")
  106. # [11:44] * Joins: Lachy (n=Lachy@pat-tdc.opera.com)
  107. # [11:51] <hsivonen> I figured that now that the idea of href='' instead of xlink:href='' is no longer outrageous, I might as well try suggesting not working around the problems xml:id creates
  108. # [11:54] <OmegaJunior> Where would href i.o. xlink:href be outrageous? Not in html5, I suppose. In xhtml5 perhaps?
  109. # [11:56] <hsivonen> OmegaJunior: SVG
  110. # [11:56] <OmegaJunior> Ah
  111. # [12:00] * Joins: mpt (n=mpt@121-72-139-108.dsl.telstraclear.net)
  112. # [12:05] <hsivonen> Hixie_: is there a good reason why ID assignment shouldn't happen if the ID candidate is the empty string? why the exception?
  113. # [12:30] <zcorpan> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cp%20id%3D%22%22%3E%3Cscript%3Ew(document.getElementById(%22%22))%3C%2Fscript%3E
  114. # [12:30] <zcorpan> null in ie, firefox, safari
  115. # [12:31] <hsivonen> zcorpan: ok. thanks
  116. # [12:46] * bzed_ is now known as bzed
  117. # [12:52] <Lachy> Hixie_, yt?
  118. # [12:53] <Lachy> Hixie_, the data URI kitchen is broken http://software.hixie.ch/utilities/cgi/data/data
  119. # [12:54] <Lachy> Hixie_, it seems to only work for file uploads, not text input or http URIs
  120. # [13:02] * Quits: tantek (n=tantek@h460d99c6.area2.spcsdns.net) (Read error: 110 (Connection timed out))
  121. # [13:07] <jwalden> nice, roc followed up on isLocallyAvailable so I don't have to feel obligated to do so :-)
  122. # [13:09] * Joins: doublec (n=doublec@203-211-80-58.ue.woosh.co.nz)
  123. # [13:09] * Quits: jwalden (n=waldo@STRATTON-SIX-SEVENTY-EIGHT.MIT.EDU) ("good morning")
  124. # [14:09] * Quits: doublec (n=doublec@203-211-80-58.ue.woosh.co.nz)
  125. # [14:44] <zcorpan> was something interesting said during the telecon? reading the log it seemed pretty hollow
  126. # [14:47] <hsivonen> I suppose attributes that have IDness should have IDness and remain in the infoset even if the value is "". so all code everywhere that is ID-sensitive needs to check both for IDness and the value emptystringness :-(
  127. # [14:50] <zcorpan> why do you suppose so?
  128. # [14:51] <hsivonen> zcorpan: it seems wrong to change the IDness based on value. moreover, I'm not sure if non-validating DTD processing could inject ""-valued IDs into the pipeline
  129. # [14:52] <zcorpan> ok
  130. # [14:53] <zcorpan> then html5 shouldn't say that empty id="" doesn't do ID assignment, but dom core should say that the empty string as argument to getElementById() should return null
  131. # [14:54] <zcorpan> correct?
  132. # [15:03] <hsivonen> zcorpan: depends on whether ID assignment and IDness assignment mean different things
  133. # [15:03] <hsivonen> IDness assignment clearly means if querying the attribute for its type return "ID"
  134. # [15:04] <hsivonen> I'm not sure what ID assigment exactly means but I understood in to mean: put in a hashtable with the ID value as the key
  135. # [15:04] * hsivonen keeps mistyping assignment over and over
  136. # [15:21] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  137. # [15:25] * Quits: Lachy (n=Lachy@pat-tdc.opera.com) (Read error: 104 (Connection reset by peer))
  138. # [15:25] * Joins: Lachy_ (n=Lachy@pat-tdc.opera.com)
  139. # [15:31] * Quits: weinig (n=weinig@adsl-67-124-36-161.dsl.pltn13.pacbell.net) (Read error: 104 (Connection reset by peer))
  140. # [15:33] <zcorpan> i should write an xml-stylesheet spec that doesn't have fatal error requirements
  141. # [15:34] <zcorpan> which would also benefit xbl2
  142. # [15:34] * Joins: weinig (n=weinig@adsl-67-124-36-161.dsl.pltn13.pacbell.net)
  143. # [15:37] * Quits: weinig (n=weinig@adsl-67-124-36-161.dsl.pltn13.pacbell.net) (Remote closed the connection)
  144. # [15:38] * Joins: weinig (n=weinig@adsl-67-124-36-161.dsl.pltn13.pacbell.net)
  145. # [15:59] <zcorpan> i wonder how i should approach that...
  146. # [16:00] <zcorpan> i mean, to make progress, i should just go ahead and reverse engineer relevant implementations, write test cases and a spec, then ask for feedback
  147. # [16:01] * Joins: dglazkov (n=dglazkov@adsl-065-081-081-030.sip.bhm.bellsouth.net)
  148. # [16:01] <zcorpan> but politically that might not be the best way to do it
  149. # [16:03] <zcorpan> perhaps i should start out with reverse engineering and demos, and point out the problems to the relevant WG(s), and if i don't get a response then i go ahead and write a spec and then ask for feedback
  150. # [16:10] * Joins: tndH_ (i=Rob@87.102.2.12)
  151. # [16:10] * tndH_ is now known as tndH
  152. # [16:10] <zcorpan> any thoughts? which are the relevant WGs for xml-stylesheet?
  153. # [16:11] * Lachy_ is now known as Lachy
  154. # [16:12] <heycam> zcorpan, xml core wg seems most appropriate
  155. # [16:12] <zcorpan> heycam: ok
  156. # [16:13] <heycam> on http://www.w3.org/XML/Group/Core they list working on that document again as a "future task"
  157. # [16:15] * heycam sleeps
  158. # [16:19] * Quits: toolskyn (n=toolskyn@amy.bdick.de) ("leaving")
  159. # [16:24] <hsivonen> zcorpan: fwiw, the idea that XML Core WG has about "relevant implmentations" is likely to be radically different from yours
  160. # [16:40] <ROBOd> hello guys! pardon me barging into the discussion. i have one quick question: did microsoft (via chris wilson?) publish the complete html5 review? iirc, it was supposed they'll publish a review. i haven't seen it yet
  161. # [16:41] <Philip`> They haven't done, though ChrisW mentioned it yesterday
  162. # [16:42] <Philip`> 00:29 < DanC> ChrisW: yes, I'm working with the IE team on our review...
  163. # [16:42] <Philip`> 00:30 < DanC> ... I'll have some stuff sent out prior to the ftf meeting.
  164. # [16:43] <ROBOd> aha, thanks Philip`
  165. # [16:45] <zcorpan> hsivonen: i'd like to learn which implementations they consider relevant
  166. # [17:06] * Joins: maikmerten (n=maikmert@T75bd.t.pppool.de)
  167. # [17:14] * Quits: aaronlev (n=chatzill@c-66-31-86-217.hsd1.ma.comcast.net) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]")
  168. # [17:47] * Quits: maikmerten (n=maikmert@T75bd.t.pppool.de) (Read error: 110 (Connection timed out))
  169. # [17:47] * Joins: maikmerten (n=maikmert@T67c5.t.pppool.de)
  170. # [17:52] * Joins: virtuelv (n=virtuelv@51.80-203-76.nextgentel.com)
  171. # [17:55] <zcorpan> http://blogs.s60.com/browser/2007/10/coring_the_browser.html -- hmm, so they support SVG via plugin instead of using WebCore's native support? (remember that they parse xml with the html parser)
  172. # [17:58] <zcorpan> "The difference with browsing is that HTML, CSS and ECMAScript create a really complex system, and the standards can never exactly specify the "correct" behavior in every case."
  173. # [17:59] <zcorpan> oh?
  174. # [18:01] * Quits: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl) ("Trillian (http://www.ceruleanstudios.com")
  175. # [18:03] * Quits: weinig (n=weinig@adsl-67-124-36-161.dsl.pltn13.pacbell.net)
  176. # [18:23] * Quits: hsivonen (n=hsivonen@kekkonen.cs.hut.fi) (Remote closed the connection)
  177. # [18:29] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (Read error: 110 (Connection timed out))
  178. # [18:34] * Joins: hsivonen (n=hsivonen@kekkonen.cs.hut.fi)
  179. # [18:40] * Joins: weinig (n=weinig@17.203.15.140)
  180. # [18:40] * Joins: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  181. # [18:42] * Joins: h3h (n=w3rd@66-162-32-234.static.twtelecom.net)
  182. # [18:57] * Joins: peepo (n=Jay@host86-153-137-94.range86-153.btcentralplus.com)
  183. # [19:10] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) ("The computer fell asleep")
  184. # [19:11] * Quits: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  185. # [19:42] * Quits: peepo (n=Jay@host86-153-137-94.range86-153.btcentralplus.com) ("later")
  186. # [19:49] * Joins: Philip`_ (n=philip@zaynar.demon.co.uk)
  187. # [19:53] * Joins: kingryan (n=kingryan@corp.technorati.com)
  188. # [20:00] * Quits: Philip` (n=philip@zaynar.demon.co.uk) (Read error: 110 (Connection timed out))
  189. # [20:06] * Quits: psa (n=yomode@posom.com) (Remote closed the connection)
  190. # [20:13] * Joins: gavins (n=gavin@firefox/developer/gavin)
  191. # [20:20] * Quits: gavin (n=gavin@firefox/developer/gavin) (Read error: 110 (Connection timed out))
  192. # [20:21] * Joins: psa (n=yomode@posom.com)
  193. # [20:22] * Joins: doublec (n=doublec@202-74-213-84.ue.woosh.co.nz)
  194. # [20:22] * Quits: doublec (n=doublec@202-74-213-84.ue.woosh.co.nz) (Remote closed the connection)
  195. # [20:33] * Joins: grimboy (n=grimboy@85-211-251-94.dsl.pipex.com)
  196. # [20:40] <kingryan> is thomas broyer around here?
  197. # [20:42] * Joins: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  198. # [20:44] * Quits: maikmerten (n=maikmert@T67c5.t.pppool.de) (Remote closed the connection)
  199. # [20:56] * Joins: tantek (n=tantek@h460e2e0d.area3.spcsdns.net)
  200. # [21:04] <Hixie_> Lachy: odd
  201. # [21:04] <Hixie_> oh i know why
  202. # [21:04] <Hixie_> issues with the content-type sanitation
  203. # [21:06] <Hixie_> fixed
  204. # [21:07] * Joins: hober (n=ted@unaffiliated/hober)
  205. # [21:09] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  206. # [21:11] * Quits: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  207. # [21:15] * Quits: om_sleep (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  208. # [21:15] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  209. # [21:16] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Remote closed the connection)
  210. # [21:20] * Quits: weinig (n=weinig@17.203.15.140)
  211. # [21:21] * aroben is now known as aroben|out
  212. # [21:24] * Philip`_ is now known as Philip`
  213. # [21:51] * Joins: weinig (n=weinig@17.203.15.140)
  214. # [21:58] * Quits: ozamosi (n=ozamosi@unaffiliated/ozamosi) (Nick collision from services.)
  215. # [21:58] * Joins: ozamosi- (n=nozamosi@85.8.1.10.static.se.wasadata.net)
  216. # [22:04] * Joins: KevinMarks (i=KevinMar@nat/google/x-19db4d1798e53d37)
  217. # [22:05] * Quits: weinig (n=weinig@17.203.15.140) (Read error: 104 (Connection reset by peer))
  218. # [22:05] * Joins: weinig_ (n=weinig@17.203.15.140)
  219. # [22:08] * Quits: tantek (n=tantek@h460e2e0d.area3.spcsdns.net)
  220. # [22:14] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  221. # [22:28] * Joins: Vito` (i=vito@132.179.232.72.static.reverse.ltdomains.com)
  222. # [22:28] * Joins: DrChirs (n=IceChat7@204-16-231-250-accuradio.pkh.ord.sparkplugbb.net)
  223. # [22:30] <Vito`> hello, we're using html5lib to generate plain text from archived html pages. we're finding html5lib bombs out with maximum recursion errors on some pages.
  224. # [22:30] <kingryan> Vito`: please give an example
  225. # [22:32] <Vito`> http://mavra.perilith.com/~vito/html5lib/2002-0919-120019.html
  226. # [22:32] * Quits: virtuelv (n=virtuelv@51.80-203-76.nextgentel.com) (Read error: 104 (Connection reset by peer))
  227. # [22:33] <Vito`> this is the python html5lib, and we're just doing parser=html5lib.HTMLParser();dom=parser.parse(filecontents);
  228. # [22:33] <kingryan> backtrace?
  229. # [22:33] <Vito`> maximum recursion depth reached, or some such
  230. # [22:34] <Vito`> the backtrace is accordingly > 1000 lines
  231. # [22:34] <kingryan> that'd be the error message. do you have backtrace?
  232. # [22:34] <kingryan> ah
  233. # [22:34] <kingryan> can you at least give us an idea of where the recursion is happening?
  234. # [22:34] <Vito`> lines 273 and 866 are repeated
  235. # [22:34] <kingryan> of what file?
  236. # [22:35] <kingryan> and which version of html5lib are you using?
  237. # [22:35] <Vito`> html5parser.py, in endTagHtml, self.parser.phase.processEndTag(name) and self.endTagHandler[name](name)
  238. # [22:36] <kingryan> I can't reproduce the error in trunk in either python or ruby
  239. # [22:36] <Vito`> hm
  240. # [22:37] <kingryan> which version are you using?
  241. # [22:37] <Philip`> I get no error in the Python trunk version either
  242. # [22:37] <Vito`> trying to find out
  243. # [22:37] <Philip`> and http://james.html5.org/cgi-bin/parsetree/parsetree.py?uri=http%3A%2F%2Fmavra.perilith.com%2F%7Evito%2Fhtml5lib%2F2002-0919-120019.html looks alright
  244. # [22:39] * Joins: othermaciej (n=mjs@17.255.103.143)
  245. # [22:52] <Vito`> I thought it was the latest, but I guess we're running 0.9 or something. Installing 0.10 locally got the first batch of failures passing.
  246. # [22:52] <Vito`> I'll let you know if anything new comes up. Thanks for the sanity check.
  247. # [22:56] * Quits: grimboy (n=grimboy@85-211-251-94.dsl.pipex.com) (Connection timed out)
  248. # [22:57] * Joins: grimboy (n=grimboy@85-211-255-243.dsl.pipex.com)
  249. # [22:58] * Quits: KevinMarks (i=KevinMar@nat/google/x-19db4d1798e53d37) ("The computer fell asleep")
  250. # [22:59] <jgraham> Hmm. In principle there are places where html5lib could have problems with recursion as it uses recursive algorithms in some places where iterative ones could be used
  251. # [22:59] <jgraham> But AFAIK there was at least one infinite loop bug fixed since 0.9
  252. # [23:00] <Vito`> we have a bit over 23k archived pages and we were hitting something pretty frequently
  253. # [23:00] <Vito`> but it's all OKs so far with 0.10
  254. # [23:01] * Quits: dglazkov (n=dglazkov@adsl-065-081-081-030.sip.bhm.bellsouth.net)
  255. # [23:05] <Philip`> If you're parsing lots of pages, it may be worth looking at hsivonen's Java HTML5 parser since it's around a hundred times faster than the Python one
  256. # [23:07] <Vito`> alright, I've an AssertionError using 0.10. Should I try with trunk or are they the same?
  257. # [23:09] <kingryan> they're mostly the same
  258. # [23:11] <Vito`> happens with trunk as well
  259. # [23:12] <Vito`> http://mavra.perilith.com/~vito/html5lib/2003-0701-120001.html
  260. # [23:12] <Vito`> I can save these and stuff them all into the issue tracker as well, of course
  261. # [23:12] <Vito`> given that many more are passing than failing now
  262. # [23:16] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  263. # [23:34] * Quits: othermaciej (n=mjs@17.255.103.143)
  264. # [23:34] * Joins: othermaciej (n=mjs@17.255.103.143)
  265. # [23:36] <jgraham> Vito`: That looks like a recent regression. I'll have to investigate further
  266. # [23:37] <Vito`> I've had a handful of those now, plus one with an encoding error. I'll just put them all in the tracker.
  267. # [23:38] * ozamosi- is now known as ozamosi
  268. # [23:38] <jgraham> (in the meantime you can try removing the assertion that fires; I _think_ the only bad side effect is that the source position reported for errors might be wrong)
  269. # [23:38] <jgraham> Thanks
  270. # [23:40] <jgraham> Vito`: Add me as the owner for the bugs you file (jgraham.html)
  271. # [23:41] <Vito`> k
  272. # [23:44] * Quits: ozamosi (n=nozamosi@85.8.1.10.static.se.wasadata.net) (Nick collision from services.)
  273. # [23:45] * Joins: ozamosi- (n=nnozamos@85.8.1.10.static.se.wasadata.net)
  274. # [23:45] * ozamosi- is now known as ozamosi
  275. # [23:46] * Quits: ozamosi (n=nnozamos@85.8.1.10.static.se.wasadata.net) (Nick collision from services.)
  276. # [23:46] * Joins: ozamosi- (n=nnnozamo@85.8.1.10.static.se.wasadata.net)
  277. # [23:48] <Hixie_> othermaciej: do you mind if i skip replying to <video>-related e-mails from you if the spec already does everything you asked for in those e-mails, or would you rather have replies to all your mails? (either is fine, just checking which you prefer)
  278. # [23:48] <othermaciej> Hixie_: if the emails predate the current version of <video> then I can do without such replies
  279. # [23:49] <othermaciej> Hixie_: I will have new feedback from Apple soon relative to the current spec as a baseline, so I am not worried about things getting lost
  280. # [23:49] <Hixie_> k
  281. # [23:50] <Hixie_> these predate the <video> dinner at google
  282. # [23:56] * Joins: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  283. # [23:57] <jgraham> Vito`: I think I have fixed one of your issues. I'll update svn in a few minutes once I fix a few issues with my working copy
  284. # Session Close: Sat Oct 13 00:00:00 2007

The end :)