/irc-logs / freenode / #whatwg / 2007-06-06 / end

Options:

  1. # Session Start: Wed Jun 06 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:01] * Quits: weinigLap (n=weinig@17.255.98.62)
  4. # [00:10] * Joins: KevinMarks (i=KevinMar@nat/google/x-78e6ab47bd9ae617)
  5. # [00:11] * Joins: markp (i=markp@nat/google/x-8caa3f48f491982f)
  6. # [00:13] * Quits: virtuelv_ (n=virtuelv@47.80-202-66.nextgentel.com) ("Leaving")
  7. # [00:15] * Quits: Lachy (n=Lachy@203-217-56-97.dyn.iinet.net.au) (Read error: 110 (Connection timed out))
  8. # [00:16] * Quits: briansuda (n=briansud@82.221.34.106)
  9. # [00:17] * Joins: weinigLap (n=weinig@17.255.98.62)
  10. # [00:18] * Joins: briansuda (n=briansud@82.221.34.106)
  11. # [00:31] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  12. # [00:45] * Joins: Lachy (n=Lachy@203-217-56-97.dyn.iinet.net.au)
  13. # [00:52] * Quits: yod (n=ot@cpe-72-224-179-1.maine.res.rr.com) ("This computer has gone to sleep")
  14. # [01:01] * Joins: othermaciej_ (n=mjs@17.255.105.77)
  15. # [01:15] * Quits: weinigLap (n=weinig@17.255.98.62)
  16. # [01:16] * Quits: kingryan (n=kingryan@corp.technorati.com) (Remote closed the connection)
  17. # [01:16] * Quits: othermaciej (i=mjs@nat/apple/x-e91b0ca9b60d8cc2) (Read error: 110 (Connection timed out))
  18. # [01:17] * Joins: kingryan (n=kingryan@corp.technorati.com)
  19. # [01:18] * Joins: weinigLap (n=weinig@17.255.98.62)
  20. # [01:20] * Quits: jruderman (n=jruderma@guest-230.mountainview.mozilla.com)
  21. # [01:24] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  22. # [01:27] * Quits: bzed (n=bzed@dslb-084-059-100-091.pools.arcor-ip.net) ("Leaving")
  23. # [01:27] * Joins: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  24. # [01:29] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  25. # [01:31] * Joins: KevinMarks (i=KevinMar@nat/google/x-e57026d967cdda53)
  26. # [01:34] * Quits: kingryan (n=kingryan@corp.technorati.com)
  27. # [01:35] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  28. # [01:36] * Joins: yod (n=ot@cpe-72-224-179-1.maine.res.rr.com)
  29. # [01:36] * Quits: yod (n=ot@cpe-72-224-179-1.maine.res.rr.com) (Remote closed the connection)
  30. # [01:45] * Quits: weinigLap (n=weinig@17.255.98.62)
  31. # [01:49] * Quits: markp (i=markp@nat/google/x-8caa3f48f491982f) (Read error: 110 (Connection timed out))
  32. # [01:55] * Joins: markp (i=markp@nat/google/x-fc129dc5538a2301)
  33. # [01:57] * Joins: weinigLap (n=weinig@17.255.98.62)
  34. # [02:01] * Joins: karlUshi (n=karl@133.27.247.173)
  35. # [02:04] * Quits: briansuda (n=briansud@82.221.34.106)
  36. # [02:06] * Joins: briansuda (n=briansud@82.221.34.106)
  37. # [02:08] * Joins: kingryan (n=kingryan@corp.technorati.com)
  38. # [02:11] * Quits: briansuda (n=briansud@82.221.34.106)
  39. # [02:11] * Quits: clotman (n=louis@shell.icgroup.com) (Remote closed the connection)
  40. # [02:21] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  41. # [02:25] * Joins: KevinMarks (i=KevinMar@nat/google/x-cf033b8ba693f795)
  42. # [02:33] * Quits: kingryan (n=kingryan@corp.technorati.com)
  43. # [02:34] * Joins: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net)
  44. # [02:35] * Quits: Toolskyn (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl) (Read error: 110 (Connection timed out))
  45. # [02:42] * Quits: weinigLap (n=weinig@17.255.98.62) (Read error: 104 (Connection reset by peer))
  46. # [02:43] * Joins: weinigLap (n=weinig@17.255.98.62)
  47. # [02:51] * Quits: weinigLap (n=weinig@17.255.98.62)
  48. # [02:54] * Joins: weinigLap (n=weinig@17.203.15.158)
  49. # [02:55] * Joins: kingryan (n=kingryan@corp.technorati.com)
  50. # [02:56] * Quits: kingryan (n=kingryan@corp.technorati.com) (Client Quit)
  51. # [02:59] * Quits: othermaciej_ (n=mjs@17.255.105.77)
  52. # [03:00] * Parts: zcorpan (n=zcorpan@84-216-42-10.sprayadsl.telenor.se)
  53. # [03:11] * Quits: h3h (n=w3rd@66-162-32-234.static.twtelecom.net)
  54. # [03:21] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  55. # [03:44] * Joins: h3h (n=w3rd@cpe-66-75-149-197.san.res.rr.com)
  56. # [04:02] * Joins: zcorpan (n=zcorpan@84-216-42-148.sprayadsl.telenor.se)
  57. # [04:13] * Quits: weinigLap (n=weinig@17.203.15.158)
  58. # [04:19] * Joins: weinigLap (n=weinig@17.203.15.158)
  59. # [04:20] <MikeSmith> (asked the following over on public-html, but want to ask here also)
  60. # [04:20] <MikeSmith> I think it would be useful to have a somewhere a high-level "What problems we are trying to solve with HTML5" description.
  61. # [04:20] <MikeSmith> Suggestions?
  62. # [04:21] <MikeSmith> I think "interoperability among browsers" may be a big one (and interoperable error handling).
  63. # [04:22] <MikeSmith> maybe also, "better support for writing Web applications (instead of just Web documents)"
  64. # [04:22] * Quits: markp (i=markp@nat/google/x-fc129dc5538a2301) (Read error: 110 (Connection timed out))
  65. # [04:23] <zcorpan> that part is interesting
  66. # [04:23] <MikeSmith> ... "riqorously/thoroughly documenting conformant application behavior"
  67. # [04:23] <zcorpan> because html5 introduces new features for web apps, people think that html5 is good for web apps, but xhtml2 is better for "structured documents"
  68. # [04:24] <MikeSmith> zcorpan - yeah, I can see that being a inference that some would draw
  69. # [04:24] * Joins: othermaciej (i=mjs@nat/apple/x-9caecf6a555f3203)
  70. # [04:25] <zcorpan> some also think that xhtml2 is better because you can embed svg and other xml namespaces in it, and not realising that you can do the same in xhtml5
  71. # [04:26] <othermaciej> we could even make it possible in HTML
  72. # [04:27] <zcorpan> yeah
  73. # [04:30] * mpt_ is now known as mpt
  74. # [04:33] <MikeSmith> I think that engaging much in that discussion might obscure that the important distinction is that HTML5 has as probably its primary goal to precisely specify behavior of conformant UAs (HTML processing applications), less so conformant authoring applications
  75. # [04:34] <MikeSmith> XHTML2 spec does not really have that as a goal (as far as I can see)
  76. # [04:34] <MikeSmith> I guess my take on the which-is-better-for-authoring thing is, it's mostly a matter of what your authoring requirements are, or a matter of taste ... anyway, not something worth battling about
  77. # [04:35] <MikeSmith> or to put it another way, author in whatever language you want, as long as you transform your source into conformant HTML5 before delivering it to UAs
  78. # [04:37] <MikeSmith> for many use cases, neither authoring directly in HTML5 nor in XHTML2 are the best choice
  79. # [04:37] <MikeSmith> but authoring instead on some custom vocabulary whose content models closely match your content, then transform that to what you deliver to UAs
  80. # [04:38] <othermaciej> HTML5 does indeed define conforming documents and therefore what conforming authoring tools must output
  81. # [04:38] <othermaciej> I think authoring in HTML is better than authoring in a custom vocabulary if you are going to do anything dynamic
  82. # [04:38] <othermaciej> because then your script code can act directly on the model rather than a transformed view
  83. # [04:41] <karlUshi> othermaciej: are you promoting the end of MySQL ;)
  84. # [04:42] <MikeSmith> othermaciej - I guess my point about that is there are a range of opinions about what's best for authoring, and it's open to debate and there's more value as far as communicating "what problems is HTML5 trying to solve" in focusing on the stuff that's not really debatable
  85. # [04:43] <karlUshi> agreed with MikeSmith
  86. # [04:45] <othermaciej> well, HTML5 aims to make things better for UA interoperability, as a target format, and as a direct authoring format
  87. # [05:11] * Joins: KevinMarks (n=KevinMar@h-68-164-93-9.snvacaid.dynamic.covad.net)
  88. # [05:21] * Quits: zcorpan (n=zcorpan@84-216-42-148.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  89. # [05:26] * Quits: Lachy (n=Lachy@203-217-56-97.dyn.iinet.net.au) (Read error: 104 (Connection reset by peer))
  90. # [05:46] * Quits: dbaron (n=dbaron@corp-242.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  91. # [05:47] * Quits: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net) (Remote closed the connection)
  92. # [06:08] * Joins: othermaciej_ (n=mjs@17.255.105.77)
  93. # [06:25] * Quits: othermaciej (i=mjs@nat/apple/x-9caecf6a555f3203) (Read error: 110 (Connection timed out))
  94. # [06:26] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  95. # [06:32] * othermaciej_ is now known as othemaciej
  96. # [06:33] * Quits: weinigLap (n=weinig@17.203.15.158)
  97. # [06:34] * Quits: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  98. # [06:55] * Joins: jruderman (n=jruderma@c-67-169-24-116.hsd1.ca.comcast.net)
  99. # [06:58] * Quits: othemaciej (n=mjs@17.255.105.77)
  100. # [07:00] * Joins: othemaciej (n=mjs@17.255.105.77)
  101. # [07:00] * Quits: othemaciej (n=mjs@17.255.105.77) (Remote closed the connection)
  102. # [07:01] * Joins: othemaciej (n=mjs@17.255.105.77)
  103. # [07:02] * Joins: weinigLap (n=weinig@c-67-188-78-122.hsd1.ca.comcast.net)
  104. # [07:30] * Joins: othemaciej_ (n=mjs@17.255.105.77)
  105. # [07:30] * Parts: othemaciej_ (n=mjs@17.255.105.77)
  106. # [07:30] * Joins: othemaciej_ (n=mjs@17.255.105.77)
  107. # [07:31] * Quits: othemaciej_ (n=mjs@17.255.105.77) (Remote closed the connection)
  108. # [07:34] * othemaciej is now known as othermaciej
  109. # [07:49] * Quits: othermaciej (n=mjs@17.255.105.77)
  110. # [07:55] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Get thee behind me, satan.")
  111. # [08:32] * Quits: KevinMarks (n=KevinMar@pdpc/supporter/active/kevinmarks) ("brb")
  112. # [08:32] * Joins: KevinMarks (n=KevinMar@h-68-164-93-9.snvacaid.dynamic.covad.net)
  113. # [08:36] * Joins: bzed (n=bzed@dslb-084-059-126-174.pools.arcor-ip.net)
  114. # [08:44] * Joins: ddfreyne (n=ddfreyne@d54C57894.access.telenet.be)
  115. # [08:46] * Joins: Charl (n=charlvn@net-153-111.mweb.co.za)
  116. # [09:26] * Quits: mpt (n=mpt@121-72-131-30.dsl.telstraclear.net) ("This computer has gone to sleep")
  117. # [09:27] * Joins: mpt (n=mpt@121-72-131-30.dsl.telstraclear.net)
  118. # [09:28] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  119. # [09:31] * Quits: karlUshi (n=karl@133.27.247.173) ("Where dwelt Ymir, or wherein did he find sustenance?")
  120. # [09:36] * Joins: hendry (n=hendry@91.84.53.136)
  121. # [09:46] * Quits: weinigLap (n=weinig@c-67-188-78-122.hsd1.ca.comcast.net)
  122. # [09:58] * Quits: h3h (n=w3rd@cpe-66-75-149-197.san.res.rr.com)
  123. # [10:24] * Joins: Toolskyn (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl)
  124. # [10:25] * Joins: aroben_ (n=adamrobe@17.255.104.88)
  125. # [10:26] * Joins: Lachy (n=Lachy@203-217-56-97.dyn.iinet.net.au)
  126. # [10:26] * Quits: aroben_ (n=adamrobe@17.255.104.88) (Read error: 104 (Connection reset by peer))
  127. # [10:27] * Joins: aroben_ (n=adamrobe@17.255.104.88)
  128. # [10:41] * Quits: aroben (i=adamrobe@nat/apple/x-78940f26b5f45072) (Read error: 110 (Connection timed out))
  129. # [10:49] <annevk> http://edward.oconnor.cx/2007/BarCamp-San-Diego/
  130. # [10:50] * Joins: Toolskyn88 (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl)
  131. # [10:52] * Quits: jruderman (n=jruderma@c-67-169-24-116.hsd1.ca.comcast.net)
  132. # [10:52] * Joins: jruderman (n=jruderma@c-67-169-24-116.hsd1.ca.comcast.net)
  133. # [11:01] * Joins: duryodhan (i=3ba31e02@gateway/web/cgi-irc/ircatwork.com/x-57b9d80701847509)
  134. # [11:01] * Joins: ROBOd (n=robod@86.34.246.154)
  135. # [11:04] * Quits: duryodhan (i=3ba31e02@gateway/web/cgi-irc/ircatwork.com/x-57b9d80701847509) (Client Quit)
  136. # [11:04] * Joins: duryodhan (i=3ba31e02@gateway/web/cgi-irc/ircatwork.com/x-5508d9a6844f6096)
  137. # [11:06] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  138. # [11:07] <annevk> seems the <pre>\n "hack" needs to be implemented for <textarea> as well jeremyb
  139. # [11:07] <annevk> euh jgraham
  140. # [11:07] * Quits: Toolskyn (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl) (Read error: 110 (Connection timed out))
  141. # [11:09] * Quits: duryodhan (i=3ba31e02@gateway/web/cgi-irc/ircatwork.com/x-5508d9a6844f6096) (Client Quit)
  142. # [11:10] * Joins: duryodhan (i=3ba31e03@gateway/web/cgi-irc/ircatwork.com/x-54c138e6cd3ea693)
  143. # [11:10] <annevk> the spec now deals with the entities but not yet with the incorrect bytes...
  144. # [11:13] * Quits: duryodhan (i=3ba31e03@gateway/web/cgi-irc/ircatwork.com/x-54c138e6cd3ea693) (Client Quit)
  145. # [11:14] * Joins: duryodhan (i=3ba31e03@gateway/web/cgi-irc/ircatwork.com/x-7d7415d05b224f7b)
  146. # [11:14] * Joins: BenWard (i=BenWard@nat/yahoo/x-07779192dcef0819)
  147. # [11:19] * Quits: duryodhan (i=3ba31e03@gateway/web/cgi-irc/ircatwork.com/x-7d7415d05b224f7b) (Client Quit)
  148. # [11:28] * Joins: tantek (n=tantek@62-50-198-192.client.stsn.net)
  149. # [11:43] <annevk> http://ln.hixie.ch/?start=1181118077&count=1
  150. # [11:44] <othermaciej> I've been reading that
  151. # [11:44] <othermaciej> lots of amusing lines
  152. # [11:48] * annevk barely has the time for rewriting the CSSOM
  153. # [11:48] <annevk> there's only a few people on this planet who understand CSS well enough to write a spec for it
  154. # [11:49] <annevk> then there's only a few people who are good at writing specifications
  155. # [11:49] <annevk> the union of both is Hixie I think
  156. # [11:50] * annevk wants <datagrid> to handle sortable tables without scripting
  157. # [11:53] <tantek> annevk, there's also very few who have the time to write/edit a CSS spec
  158. # [11:55] <annevk> yeah, it be much like the fulltime job HTML5 is
  159. # [11:56] <othermaciej> the combination of having the time and the ability rules out a whole lot of possible candidates
  160. # [11:57] <annevk> all of them so far :(
  161. # [11:57] <othermaciej> I guess one could also add "inclination"
  162. # [11:58] <annevk> same goes for some of the SVG stuff btw...
  163. # [11:59] <tantek> annevk, I'd rather see a CSS Shapes draft before an SVG rewrite
  164. # [11:59] <othermaciej> in the SVG WG, having spec-writing ability and knowledge of relevant technology does not seem to be a requirement for editorship
  165. # [11:59] <tantek> it seems that most use of shapes on the web are decorative, not content
  166. # [11:59] <tantek> thus more appropriate to be done as a "styling"
  167. # [11:59] <tantek> and besides, markup is for *marking up* text
  168. # [12:00] <annevk> you could use XBL to hide the SVG images from actual content
  169. # [12:02] <othermaciej> SVG does contain some but not all of the needed capabilities, but it makes them all pretty awkward to use in combination with HTML markup
  170. # [12:41] * Joins: tantek_ (n=tantek@62-50-198-192.client.stsn.net)
  171. # [12:41] * Quits: tantek (n=tantek@62-50-198-192.client.stsn.net) (Read error: 104 (Connection reset by peer))
  172. # [12:42] * Joins: mikeday (n=mikeday@CPE-60-224-50-129.vic.bigpond.net.au)
  173. # [12:44] <hsivonen> btw, I'm finding that the tokenizer can easily be implemented as a recursive descent tokenizer without an explicit state variable
  174. # [12:45] <hsivonen> wrapper loops are needed for attributes and the data state to avoid arbitrarily deep recursion
  175. # [12:46] <mikeday> buffering?
  176. # [12:46] <mikeday> oh, you're doing SAX
  177. # [12:46] <hsivonen> mikeday: I intend to do SAX with and without buffering, DOM and XOM
  178. # [12:46] <mikeday> so the recursion is just for eg. see a '<', call parseStartTag() ?
  179. # [12:46] <hsivonen> mikeday: this is the Tokenizer only
  180. # [12:47] * mikeday nods
  181. # [12:47] <hsivonen> mikeday: yes
  182. # [12:47] <mikeday> so if you don't use arbitrary recursion, technically you don't need to recurse at all, right?
  183. # [12:47] <annevk> if you introduce new states...
  184. # [12:47] <annevk> and allow it to start in arbitrary states
  185. # [12:47] <mikeday> you could just jump around inside a big single function
  186. # [12:47] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  187. # [12:48] * Quits: tantek_ (n=tantek@62-50-198-192.client.stsn.net)
  188. # [12:48] <hsivonen> mikeday: well, to avoid stack overflow regardless of input, I have a loop around the attribute states so that the stack rewinds back to the loop between attributes
  189. # [12:48] * Joins: tantek (n=tantek@62-50-198-192.client.stsn.net)
  190. # [12:49] <mikeday> right, eg. while getAttribute() ...
  191. # [12:49] <hsivonen> yes
  192. # [12:49] <mikeday> but you don't actually need recursive calls, if you're not parsing a recursive grammar
  193. # [12:49] <mikeday> it's just for convenience structuring your code, yes?
  194. # [12:49] <hsivonen> this is for code structuring, yes
  195. # [12:50] <hsivonen> also, I am assuming that a straight final method invocation in Java is going to be faster than state lookup plus method dispatch
  196. # [12:50] <mikeday> hmm, Java has no goto, right? :)
  197. # [12:51] <hsivonen> mikeday: no goto in .java level
  198. # [12:51] <mikeday> right
  199. # [12:51] <mikeday> sounds pretty good then :)
  200. # [12:51] <hsivonen> mikeday: my reasoning is that this is as good as it gets without goto and jump arithmetic based on input token
  201. # [12:51] <othermaciej> the way to code a state machine is a loop with a switch statement
  202. # [12:52] <othermaciej> not via dynamic method dispatch
  203. # [12:52] <mikeday> s/the way/a way/ :)
  204. # [12:52] <othermaciej> the efficient way
  205. # [12:53] <hsivonen> othermaciej: you get as many method invocations either way, right?
  206. # [12:53] <othermaciej> hsivonen: well, I'm not sure why you contrasted "static final method invocation" with the other option
  207. # [12:54] <hsivonen> straight--not static
  208. # [12:54] <hsivonen> othermaciej: if you have one method per state
  209. # [12:55] <hsivonen> othermaciej: and state B follows A, why would I return to a dispatch loop in between?
  210. # [12:55] <othermaciej> depends on whether function calls are more expensive in your language than conditional branches
  211. # [12:56] <hsivonen> othermaciej: ah, you are assuming that I could do away with function calls
  212. # [12:56] <hsivonen> othermaciej: I am assuming one method per state either way for code structuring sanity
  213. # [12:56] <hsivonen> (since this is human-maintained code--not generated code)
  214. # [12:56] <hsivonen> I'm hoping the HotSpot does some inlining
  215. # [12:57] <othermaciej> well, with the switch, the compiler and/or the Java runtime can definitely inline everything into the switch statement
  216. # [12:57] <mikeday> I guess a parsing DSL that compiled down to Java byte code could help
  217. # [12:57] <othermaciej> if each processing method is final and they don't call each other
  218. # [12:57] <hsivonen> othermaciej: good point
  219. # [12:57] <hsivonen> othermaciej: thanks
  220. # [12:58] <othermaciej> anyway I don't know which way would be faster in Java
  221. # [12:58] <othermaciej> I don't have a lot of experience performance-tuning Java code
  222. # [12:58] <othermaciej> (though I do have performance-tuning experience in general)
  223. # [12:58] <hsivonen> yeah, this is guesswork without either benchmarking or knowing what HotSpot inlines
  224. # [12:59] <hsivonen> ok. I'll convert to a switch that is potentially inlineable
  225. # [13:00] <mikeday> a bit of premature optimisation going on here perhaps :)
  226. # [13:00] <mikeday> by the way, have you done meta charset detection yet?
  227. # [13:00] <hsivonen> mikeday: written--not run
  228. # [13:00] <othermaciej> depends on whether hsivonen finds it easier to code a finite state machine or a recursive descent parser
  229. # [13:01] <mikeday> hmm, I better hurry up then, I've been dragging my feet over it
  230. # [13:01] * Quits: Charl (n=charlvn@net-153-111.mweb.co.za) ("Leaving")
  231. # [13:01] <hsivonen> mikeday: in C?
  232. # [13:01] <mikeday> yes
  233. # [13:02] <othermaciej> mikeday: you're writing an HTML5 parser in C?
  234. # [13:02] <mikeday> yes, that's why I come here, to make me feel guilty enough to work on it some more
  235. # [13:02] <hsivonen> hmm. come to think of it, I still think the way I have coded this is potentially a bit more efficient if HotSpot does deep inlines
  236. # [13:03] <hsivonen> perhaps I leave the optimization for later after all
  237. # [13:03] * Joins: ROBOd (n=robod@86.34.246.154)
  238. # [13:04] <annevk> a collegue did some testing on tokenization in C/C++ versus Python and JavaScript
  239. # [13:04] <annevk> C: ~1ms, Python: ~100ms, JavaScript: ~500ms
  240. # [13:04] <mikeday> lucky no one is writing a parser in JavaScript I guess
  241. # [13:04] <mikeday> ...or ARE they
  242. # [13:05] <hsivonen> annevk: I would expect buffering to matter a lot in that case (and string object creation)
  243. # [13:05] <mikeday> I guess you could use a dictionary and avoid creating new string objects where possible
  244. # [13:05] <mikeday> eg. precache tag names and attribute names
  245. # [13:07] <othermaciej> which JavaScript implementation?
  246. # [13:07] <hsivonen> mikeday: how do you look at a character in Python or JS without creating a string object?
  247. # [13:07] <othermaciej> JavaScript suffers from the boxed/unboxed distinction for strings there I guess
  248. # [13:07] <othermaciej> if you actually use string methods
  249. # [13:08] <Philip`> HotSpot should be happy with inlining methods even when they're not final or are potentially recursive
  250. # [13:08] <mikeday> hsivonen, buffer file to array of int instead?
  251. # [13:09] <hsivonen> Philip`: these are final and to a finite recursion depth
  252. # [13:09] <hsivonen> mikeday: ok
  253. # [13:09] <othermaciej> array of int is much less efficient than a string in JS
  254. # [13:09] <annevk> othermaciej, string methods were used, Opera 9.2 was used for testing I think
  255. # [13:09] <Philip`> (e.g. http://java.sun.com/developer/technicalArticles/Networking/HotSpot/inlining.html (from 1999) talks about inlining non-final methods, and it just remembers enough to undo the optimisation if its assumptions are ever violated)
  256. # [13:10] <annevk> Python is already a hundred times slower...
  257. # [13:10] <mikeday> how about Ruby? :)
  258. # [13:10] <othermaciej> it's hard to beat C
  259. # [13:10] <annevk> We really need a C implementation if we want to use it for surveys and such
  260. # [13:10] <othermaciej> except sometimes with C++
  261. # [13:10] <mikeday> surveys?
  262. # [13:10] <annevk> Well, surveys covering lots of pages...
  263. # [13:10] <othermaciej> if I were doing it I would use C++
  264. # [13:10] <mikeday> bleh.
  265. # [13:11] <annevk> mikeday, like the research Ian did
  266. # [13:11] <Philip`> Even with a thousand pages, the Python one is unpleasantly slow :-(
  267. # [13:11] <mikeday> oh, right
  268. # [13:11] <othermaciej> and probably at least two open source HTML5 parsers will be written in C++ sooner or later
  269. # [13:11] * annevk wonders how hard the browser parsers are to extract
  270. # [13:11] <hsivonen> IIRC, HotSpot beats C for some problems
  271. # [13:11] <hsivonen> will be interesting to see if this is one of them :-)
  272. # [13:12] <mikeday> Java beats C for malloc()
  273. # [13:12] <mikeday> so... don't use malloc :)
  274. # [13:12] <hsivonen> :-)
  275. # [13:13] <othermaciej> annevk: our current HTML parser does the DOM building, so probably not that easily separable
  276. # [13:13] <Philip`> C always wins because you can implement a JVM in it :-)
  277. # [13:14] <annevk> othermaciej, that's what I thought, main reason why I think having a third would be good
  278. # [13:15] <othermaciej> having a standalone one would be nice, it it was packaged well
  279. # [13:16] <mikeday> indeed.
  280. # [13:17] <mikeday> yay, testhtml is parsing attribute names and getting "http-equiv"
  281. # [13:18] <othermaciej> if I were doing it for fun, I'd do C++ implementation, C API
  282. # [13:18] <othermaciej> but if I have hobby coding time it will probably be spent on WebKit hacking
  283. # [13:19] <mikeday> hmm, not getting attribute values though. That's slightly useless.
  284. # [13:20] <hsivonen> (fwiw, recursive call to a finite depth with loops in the right places seems to be how others have written XML parsers in Java)
  285. # [13:20] <mikeday> that's also how libxml2 is written I think
  286. # [13:22] * Joins: maikmerten (n=maikmert@L926d.l.pppool.de)
  287. # [13:25] * Quits: mikeday (n=mikeday@CPE-60-224-50-129.vic.bigpond.net.au) ("-")
  288. # [13:26] * othermaciej is now known as om_sleep
  289. # [13:27] * Quits: aroben_ (n=adamrobe@17.255.104.88)
  290. # [13:52] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  291. # [13:52] * Quits: kfish (n=conrad@61.194.21.25) ("pike!")
  292. # [13:53] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  293. # [13:58] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  294. # [13:58] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  295. # [13:59] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  296. # [14:01] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Client Quit)
  297. # [15:18] * Joins: smaug (n=chatzill@cs181141013.pp.htv.fi)
  298. # [15:28] * Joins: Ducki__ (n=Alex@dialin-212-144-064-210.pools.arcor-ip.net)
  299. # [15:34] * Joins: jcgregorio (i=chatzill@nat/ibm/x-b7c03906d3e815a9)
  300. # [15:54] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  301. # [15:55] * Joins: Ducki_ (n=Alex@dialin-212-144-065-045.pools.arcor-ip.net)
  302. # [15:58] * Joins: yod (n=ot@cpe-72-224-179-1.maine.res.rr.com)
  303. # [16:02] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  304. # [16:02] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) ("Chatzilla 0.9.75.1 [SeaMonkey 1.1.2/2007050918]")
  305. # [16:05] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  306. # [16:11] * Quits: tantek (n=tantek@62-50-198-192.client.stsn.net)
  307. # [16:18] * Quits: Ducki__ (n=Alex@dialin-212-144-064-210.pools.arcor-ip.net) (Read error: 110 (Connection timed out))
  308. # [16:24] * annevk started testing <base> himself
  309. # [16:24] <annevk> tests here: http://tc.labs.opera.com/html/base/
  310. # [16:36] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  311. # [16:36] * Joins: billmason (n=billmaso@ip156.unival.com)
  312. # [16:37] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  313. # [16:39] * Joins: briansuda (n=briansud@82.221.34.106)
  314. # [16:48] <annevk> seems that IE7 happily does dynamic changes
  315. # [16:48] * annevk just added 005 and 006
  316. # [16:49] <annevk> I actually already figured that out while testing XMLHttpRequest but never feeded it back to the HTML5 spec I think
  317. # [17:00] <annevk> So open questions: support xml:base? do dynamic changes affect baseURI or also inserted <img> etc? suport xml:base in text/html? reverse engineer IE7 href= handling?
  318. # [17:00] <annevk> dunno, just baseURI, dunno, if it's simple...
  319. # [17:16] * Quits: maikmerten (n=maikmert@L926d.l.pppool.de) (Read error: 113 (No route to host))
  320. # [17:16] * Joins: maikmerten (n=maikmert@T6d56.t.pppool.de)
  321. # [17:16] * Joins: tantek (n=tantek@84-233-132-12.client.stsn.net)
  322. # [17:40] * Quits: KevinMarks (n=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  323. # [17:44] <gsnedders> ARGH!
  324. # [17:44] <gsnedders> people are _still_ arguing <p/> is a self-closing element, citing the validator (which is correctly parsing it as a NET)!
  325. # [17:45] <gsnedders> they're also saying HTML isn't SGML, despite me citing the spec.
  326. # [17:45] <annevk> correctly?
  327. # [17:45] <annevk> point them to HTML5 and tell them that that's what browsers will implement
  328. # [17:45] <gsnedders> well, under the spec it is parsing it as
  329. # [17:46] <gsnedders> annevk: the argument is in the context of what the HTML 4.01 spec says.
  330. # [17:46] <gsnedders> annevk: which most certainly is SGML.
  331. # [17:46] <annevk> HTML4 is irrelevant
  332. # [17:46] <gsnedders> agreed
  333. # [17:48] * Joins: h3h (n=w3rd@cpe-66-75-149-197.san.res.rr.com)
  334. # [17:55] * Joins: Ducki__ (i=Alex@dialin-145-254-189-223.pools.arcor-ip.net)
  335. # [17:57] <annevk> One use case for minlength= is search systems that don't work with less than 4 characters
  336. # [17:57] <annevk> However, I think that's a usability problem with those search systems and not really a good use case...
  337. # [18:03] <Philip`> minlength= and maxlength= seem largely unrelated, since the latter stops you entering out-of-range strings but the former presumably only stops you submitting out-of-range strings (because it'd be really horrible UI if it didn't let you delete and retype the contents of the box - though I suppose I've seen people do that anyway...)
  338. # [18:03] <annevk> good point
  339. # [18:04] * Quits: ROBOd (n=robod@86.34.246.154) (Remote closed the connection)
  340. # [18:04] * Joins: ROBOd (n=robod@86.34.246.154)
  341. # [18:08] * Quits: h3h (n=w3rd@cpe-66-75-149-197.san.res.rr.com)
  342. # [18:15] * Quits: Ducki_ (n=Alex@dialin-212-144-065-045.pools.arcor-ip.net) (Read error: 110 (Connection timed out))
  343. # [18:31] * Joins: duryodhan (i=duryodha@221.128.138.199)
  344. # [18:33] * Quits: BenWard (i=BenWard@nat/yahoo/x-07779192dcef0819) ("Fades out again…")
  345. # [18:33] * Quits: jcgregorio (i=chatzill@nat/ibm/x-b7c03906d3e815a9) (Read error: 104 (Connection reset by peer))
  346. # [18:37] <duryodhan> why were the digital signatures left out of the new Web Forms spec?? what patent problems are you referring to?
  347. # [18:42] * Joins: h3h (n=w3rd@66-162-32-234.static.twtelecom.net)
  348. # [18:43] <annevk> duryodhan, care to elaborate?
  349. # [18:44] <duryodhan> The Web Forms doc ...
  350. # [18:45] <duryodhan> sez that Digital Signatures weren't addressed because of Patent concerns
  351. # [18:45] <duryodhan> what are these concerns ?
  352. # [18:45] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  353. # [18:45] <duryodhan> cos GPG/PGP etc. are easily available ...
  354. # [18:45] <annevk> oh, I see
  355. # [18:46] * Joins: ROBOd (n=robod@86.34.246.154)
  356. # [18:47] <annevk> duryodhan, e-mail the list if you have a solution
  357. # [18:47] * Joins: jcgregorio (i=chatzill@nat/ibm/x-d22db9def6aa3d6f)
  358. # [18:50] <duryodhan> I wish :D
  359. # [18:50] <duryodhan> I don't know the problem ...
  360. # [18:55] * Quits: jcgregorio (i=chatzill@nat/ibm/x-d22db9def6aa3d6f) (Read error: 104 (Connection reset by peer))
  361. # [18:56] * Joins: KevinMarks (i=KevinMar@nat/google/x-21998e1024df2fa5)
  362. # [19:02] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("brb")
  363. # [19:02] * Joins: KevinMarks (i=KevinMar@nat/google/x-3965372045e627ef)
  364. # [19:03] * Joins: weinigLap (n=weinig@17.203.15.158)
  365. # [19:07] * Joins: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl)
  366. # [19:08] * Quits: briansuda (n=briansud@82.221.34.106)
  367. # [19:08] * Quits: weinigLap (n=weinig@17.203.15.158)
  368. # [19:08] * Joins: weinigLap (n=weinig@17.203.15.158)
  369. # [19:09] * Quits: bzed (n=bzed@dslb-084-059-126-174.pools.arcor-ip.net) ("Leaving")
  370. # [19:10] * Joins: aroben (i=adamrobe@nat/apple/x-9f9e33da6983d982)
  371. # [19:19] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  372. # [19:34] * Quits: jruderman (n=jruderma@c-67-169-24-116.hsd1.ca.comcast.net)
  373. # [19:35] * Joins: dbaron (n=dbaron@corp-242.mountainview.mozilla.com)
  374. # [19:56] * Joins: Ducki (n=Alex@dialin-145-254-189-047.pools.arcor-ip.net)
  375. # [19:57] * Joins: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  376. # [20:03] * Joins: kingryan (n=kingryan@corp.technorati.com)
  377. # [20:18] * Joins: jcgregorio (i=chatzill@nat/ibm/x-444b02d30cbcdb6e)
  378. # [20:19] * Joins: markp (n=markp@207.47.10.130.static.nextweb.net)
  379. # [20:20] * Quits: Ducki__ (i=Alex@dialin-145-254-189-223.pools.arcor-ip.net) (Read error: 110 (Connection timed out))
  380. # [20:31] * Joins: weinigLap_ (n=weinig@17.255.98.62)
  381. # [20:32] * Quits: weinigLap_ (n=weinig@17.255.98.62) (Remote closed the connection)
  382. # [20:32] * Joins: weinigLap_ (n=weinig@17.255.98.62)
  383. # [20:48] * Quits: weinigLap (n=weinig@17.203.15.158) (Read error: 110 (Connection timed out))
  384. # [20:57] * Joins: virtuelv_ (n=virtuelv@47.80-202-66.nextgentel.com)
  385. # [20:58] * om_sleep is now known as othermaciej
  386. # [21:05] * Quits: virtuelv_ (n=virtuelv@47.80-202-66.nextgentel.com) ("Leaving")
  387. # [21:08] * Quits: tantek (n=tantek@84-233-132-12.client.stsn.net)
  388. # [21:09] * Joins: tantek (n=tantek@84-233-132-12.client.stsn.net)
  389. # [21:18] * Quits: tantek (n=tantek@84-233-132-12.client.stsn.net)
  390. # [21:25] * Quits: dbaron (n=dbaron@corp-242.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  391. # [21:25] * Quits: weinigLap_ (n=weinig@17.255.98.62)
  392. # [21:27] * Joins: weinigLap (n=weinig@17.203.15.158)
  393. # [21:32] * Quits: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  394. # [21:33] * Joins: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  395. # [21:35] * Quits: markp (n=markp@207.47.10.130.static.nextweb.net) (Read error: 110 (Connection timed out))
  396. # [21:40] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  397. # [21:54] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  398. # [21:56] * Joins: Ducki_ (n=Alex@dialin-145-254-186-040.pools.arcor-ip.net)
  399. # [21:58] * Joins: markp (i=markp@nat/google/x-21e9e57d15cddf70)
  400. # [21:58] * Quits: maikmerten (n=maikmert@T6d56.t.pppool.de) (Remote closed the connection)
  401. # [22:03] * Joins: zcorpan (n=zcorpan@84-216-42-186.sprayadsl.telenor.se)
  402. # [22:07] * Quits: aroben (i=adamrobe@nat/apple/x-9f9e33da6983d982)
  403. # [22:08] * Quits: Ducki_ (n=Alex@dialin-145-254-186-040.pools.arcor-ip.net) (Client Quit)
  404. # [22:08] * Quits: Ducki (n=Alex@dialin-145-254-189-047.pools.arcor-ip.net) (Read error: 104 (Connection reset by peer))
  405. # [22:16] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) (Read error: 110 (Connection timed out))
  406. # [22:32] * Joins: KevinMarks (i=KevinMar@nat/google/x-46aa1afb46c37a33)
  407. # [22:43] * Quits: jcgregorio (i=chatzill@nat/ibm/x-444b02d30cbcdb6e) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007040314]")
  408. # [22:45] * Joins: othermaciej (n=mjs@17.255.97.147)
  409. # [23:12] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  410. # [23:13] * Quits: markp (i=markp@nat/google/x-21e9e57d15cddf70) (Read error: 110 (Connection timed out))
  411. # [23:13] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) (Client Quit)
  412. # [23:30] * Joins: weinigLap_ (n=weinig@17.255.98.62)
  413. # [23:31] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  414. # [23:35] * Joins: KevinMarks (i=KevinMar@nat/google/x-bb971ff962231b65)
  415. # [23:37] * Quits: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) (Read error: 110 (Connection timed out))
  416. # [23:46] * Quits: weinigLap (n=weinig@17.203.15.158) (Read error: 110 (Connection timed out))
  417. # [23:53] * Quits: hendry (n=hendry@91.84.53.136) ("slleeeeeeeeeeeeep")
  418. # [23:54] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  419. # [23:58] * Quits: weinigLap_ (n=weinig@17.255.98.62)
  420. # [23:58] * Quits: Lachy (n=Lachy@203-217-56-97.dyn.iinet.net.au) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007030919]")
  421. # [23:59] * Quits: ddfreyne (n=ddfreyne@unaffiliated/ddfreyne) ("kthxbai")
  422. # Session Close: Thu Jun 07 00:00:00 2007

The end :)