/irc-logs / freenode / #whatwg / 2008-12-17 / end

Options:

  1. # Session Start: Wed Dec 17 00:00:01 2008
  2. # Session Ident: #whatwg
  3. # [00:01] * Quits: shepazutoo (n=schepers@c-69-139-224-74.hsd1.md.comcast.net) (Read error: 110 (Connection timed out))
  4. # [00:02] * Quits: billmason (n=bmason@ip55.unival.com) ("Leaving.")
  5. # [00:04] * Quits: weinig (n=weinig@17.244.17.169)
  6. # [00:05] * Joins: tndH (n=Rob@adsl-87-102-93-106.karoo.KCOM.COM)
  7. # [00:06] * Joins: erlehmann_ (n=erlehman@dslb-088-075-216-082.pools.arcor-ip.net)
  8. # [00:06] * Hixie comes across webkit's LayoutTests/fast/forms/old-names.html
  9. # [00:06] <Hixie> you have GOT to be kidding me
  10. # [00:06] <Hixie> jesus
  11. # [00:06] * Quits: erlehmann (n=erlehman@dslb-088-075-216-082.pools.arcor-ip.net) (Read error: 131 (Connection reset by peer))
  12. # [00:07] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  13. # [00:08] <Hixie> http://trac.webkit.org/browser/trunk/LayoutTests/fast/forms/old-names.html
  14. # [00:09] <gavin> ugh
  15. # [00:09] <Lachy> what's so bad about it?
  16. # [00:10] <Hixie> well the most crazy part is the "third" part
  17. # [00:10] <gavin> emulating a Firefox bug because one site depended on it is pretty gross
  18. # [00:10] <Hixie> but the whole thing is insane
  19. # [00:10] <Hixie> it's not just emulating a Firefox bug
  20. # [00:10] <Hixie> Firefox is emulating an IE bug
  21. # [00:11] <Hixie> IE doesn't update the array at all when names change
  22. # [00:11] <Hixie> which is clearly wrong, but sites rely on it it seems
  23. # [00:11] <gavin> oh
  24. # [00:11] <Lachy> oh crap
  25. # [00:11] <gavin> so Firefox explicitly chose that behavior
  26. # [00:12] <gavin> presumably
  27. # [00:12] * Joins: weinig (n=weinig@nat/apple/x-9aa5eaee9e4c0633)
  28. # [00:12] <gavin> to both be compatible, and try to Do The Right Thing
  29. # [00:12] <Hixie> yeah
  30. # [00:12] <Hixie> i'm most amused and horrified that form.x and form.elements.x are different
  31. # [00:12] <gavin> I feel better about it now
  32. # [00:13] <hallvors> I know that issue. We had to do it too.
  33. # [00:13] * Hixie wonders how to spec it
  34. # [00:13] <Lachy> Opera fails this test, but I don't see why based on the result: FAIL form.third should be [object HTMLInputElement]. Was [object HTMLInputElement].
  35. # [00:13] <Hixie> opera probably remembers the last settign isntead of the first
  36. # [00:14] <Hixie> which does firefox do?
  37. # [00:14] <Lachy> possibly, but I mean it's telling me the expected result is the same as the actual result, but still fails
  38. # [00:14] <hallvors> (some years ago some software vendor who apparently sold web backends to banks relied on this IE bug. Several banks had login forms doing excactly nothing if you behaved per the spec)
  39. # [00:14] <Lachy> Firefox 3 passes everything
  40. # [00:15] <Hixie> the expected result is 'a' and you're getting (i guess) 'b'. But they are both HTMLInputElement objects, so the output isn't very helpful
  41. # [00:15] <Hixie> hallvors: good times
  42. # [00:15] <Lachy> webkit does too
  43. # [00:15] <Hixie> makes sense that webkit passes it :-)
  44. # [00:15] * Lachy fires up VMWare to test IE8
  45. # [00:16] <Hixie> i guess i'll have a list of objects to remember
  46. # [00:16] <Hixie> this is going to be Fun!
  47. # [00:16] * Quits: eric_carlson (n=ericc@nat/apple/x-ac2deb61eed7a023)
  48. # [00:16] * hallvors crosses fingers and toes that no page depends on the stuff Firefox does
  49. # [00:17] <Hixie> ok i'll do this after heycam reviews my last checkin
  50. # [00:17] <Lachy> I wonder why VMWare is taking an extra long time to start up this time?
  51. # [00:22] <Lachy> my iMac desperately needs more RAM
  52. # [00:22] <Philip`> Lachy: Do you have IE8b2, or the newer release?
  53. # [00:23] <Lachy> I installed the newest release a couple of days ago
  54. # [00:23] <Philip`> The non-public newest one?
  55. # [00:24] <Lachy> yes
  56. # [00:24] <Philip`> Okay
  57. # [00:24] <Philip`> That version says "FAIL successfullyParsed should be true. Threw exception [object Error] / TEST COMPLETE"
  58. # [00:25] <Lachy> it's version 8.0.6001.18343, Release Candidate 1
  59. # [00:25] <Philip`> There's a script error "Object doesn't support this property or method" on "line 14, char 5"
  60. # [00:28] * Joins: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  61. # [00:28] <Lachy> That doesn't make any sense. Line 14 is: form = document.getElementById('form');
  62. # [00:28] * Joins: ghostbyte (n=ghost@208.85.88.2)
  63. # [00:30] <Lachy> oh, IE's developer tools are broken. It's says the error is line 14 of the script, but points to line 14 of the file, without taking into account the lines before the script.
  64. # [00:30] * Quits: aroben (n=aroben@unaffiliated/aroben) ("Leaving")
  65. # [00:31] <Philip`> It is actually the getElementById line that's failing, as far as I can tell
  66. # [00:31] <Philip`> (if I make a local copy and then insert alerts everywhere)
  67. # [00:31] <ghostbyte> Anyone know where the PDF version for WCAG2 guides are? They talk about them but don't link to it
  68. # [00:32] <Philip`> Actually, no, it's the "form = ..." that's failing
  69. # [00:32] <Philip`> "var form" works much better
  70. # [00:32] <Lachy> ah
  71. # [00:33] <Dashiva> Is there an id="form" perhaps?
  72. # [00:33] <Lachy> wow, IE8 fails most of those tests after fixing that line
  73. # [00:33] <Lachy> Dashiva, yes
  74. # [00:34] <Philip`> http://paste.lisp.org/display/72262
  75. # [00:38] * Quits: aaronlev (n=chatzill@e179201169.adsl.alicedsl.de) ("ChatZilla 0.9.84-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  76. # [00:39] * Quits: tantek (n=tantek@204.9.180.30)
  77. # [00:41] * Quits: drry (n=drry@it17.opt2.point.ne.jp)
  78. # [00:42] * Joins: drry (n=drry@it17.opt2.point.ne.jp)
  79. # [00:45] * Joins: famicom (i=famicom@5ED2FF2D.cable.ziggo.nl)
  80. # [01:06] * Quits: Dorward (i=foobar@91.84.53.6) (Read error: 60 (Operation timed out))
  81. # [01:07] * Joins: Dorward (i=foobar@91.84.53.6)
  82. # [01:07] * Philip` commits trivial fixes to make html5lib ~20% faster
  83. # [01:09] <hallvors> Hixie: how is work on security contexts for script execution going?
  84. # [01:10] <olliej> Philip`: what did you do?
  85. # [01:11] <Philip`> olliej: Changed the tokeniser and inputstream from new-style classes to old-style classes
  86. # [01:11] <olliej> Philip`: ah
  87. # [01:11] <olliej> python?
  88. # [01:11] <Philip`> olliej: (and also cached a len() call, for 1-2% extra speed)
  89. # [01:11] <Philip`> olliej: Yes
  90. # [01:15] * Quits: dglazkov (n=dglazkov@nat/google/x-0ffe6225a0427ccf) (Read error: 145 (Connection timed out))
  91. # [01:16] <Philip`> Getting rid of the position() stuff saves another 20%, but that's occasionally a useful feature when you want error locations...
  92. # [01:18] <takkaria> christ, I'm going to have to optimise the hell out of hubbub or htm5lib will be faster :)
  93. # [01:19] <Philip`> I think that's pretty unlikely :-p
  94. # [01:20] <Philip`> This is still Python, where a method call takes a thousand clock cycles
  95. # [01:21] * Quits: erlehmann_ (n=erlehman@dslb-088-075-216-082.pools.arcor-ip.net) (Remote closed the connection)
  96. # [01:23] <Hixie> hallvors: hm?
  97. # [01:25] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  98. # [01:36] <Philip`> It'd be nice if html5lib never had an unget buffer larger than one character
  99. # [01:36] <Philip`> but it seems not entirely trivial to make it do that :-(
  100. # [01:38] <Philip`> but probably worthwhile, because that would also involve it being properly streaming and not doing lots of lookahead like it does now
  101. # [01:38] <Philip`> (and then I think the whole line-length / position thing could be simplified, because you'll never to unget more than one newline character)
  102. # [01:39] <Philip`> s/to//
  103. # [01:46] <hallvors> Hixie: I was just looking at some tricky tests using with() to sneak stuff from another security context into a script's scope. I guess you haven't written any spec for such things yet ;) .. and I suppose you should also try to make the ES4 people deal with it rather than do it yourself..
  104. # [01:47] * Joins: Lachy_ (n=Lachlan@85.196.122.246)
  105. # [01:55] * Quits: Lachy (n=Lachlan@85.196.122.246) (Read error: 110 (Connection timed out))
  106. # [01:57] * Quits: ghostbyte (n=ghost@208.85.88.2) ("heading home")
  107. # [02:00] * Quits: tndH (n=Rob@adsl-87-102-93-106.karoo.KCOM.COM) (Remote closed the connection)
  108. # [02:09] * Quits: karlcow (n=karl@modemcable168.84-81-70.mc.videotron.ca) ("This computer has gone to sleep")
  109. # [02:10] * Joins: WulfTheSaxon_ (i=meh@cpe-76-178-221-42.maine.res.rr.com)
  110. # [02:13] * Joins: karlcow (n=karl@modemcable024.84-81-70.mc.videotron.ca)
  111. # [02:19] * Quits: WulfTheSaxon (i=meh@cpe-76-178-221-42.maine.res.rr.com) (Nick collision from services.)
  112. # [02:19] * WulfTheSaxon_ is now known as WulfTheSaxon
  113. # [02:21] * Quits: hallvors (n=hallvord@cm-84.208.78.204.getinternet.no)
  114. # [02:30] * Quits: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  115. # [02:33] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Operation timed out)
  116. # [02:38] * Joins: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  117. # [02:40] * Quits: yecril71 (n=giecrilj@piekna-gts.2a.pl)
  118. # [02:44] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  119. # [02:48] <Hixie> hallvord: if you see this, can you give an example?
  120. # [02:49] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  121. # [03:07] * weinig is now known as weinig|dinner
  122. # [03:10] * Quits: Hish (n=chatzill@mail2.n-e-s.de) (Read error: 54 (Connection reset by peer))
  123. # [03:12] * weinig|dinner is now known as weinig
  124. # [03:15] * Quits: WulfTheSaxon (i=meh@cpe-76-178-221-42.maine.res.rr.com) ("bbs -- rebooting (*smacks Bill Gates in the face with a pie*)")
  125. # [03:33] * Quits: shepazu (n=schepers@c-69-139-224-74.hsd1.md.comcast.net) (Read error: 110 (Connection timed out))
  126. # [03:37] * Quits: weinig (n=weinig@nat/apple/x-9aa5eaee9e4c0633)
  127. # [03:39] * Parts: ojan (n=ojan@72.14.229.81) ("Leaving")
  128. # [03:44] * Joins: dglazkov_ (n=dglazkov@72.14.224.1)
  129. # [03:57] * Quits: dave_levin (n=dave_lev@72.14.227.1) (Read error: 110 (Connection timed out))
  130. # [04:01] * Joins: maodun (n=stopgo@c-67-180-49-1.hsd1.ca.comcast.net)
  131. # [04:01] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  132. # [04:07] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  133. # [04:07] * Joins: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  134. # [04:09] <Hixie> tag cloud markup
  135. # [04:09] <Hixie> hmmmm
  136. # [04:09] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net) (Client Quit)
  137. # [04:11] <Hixie> http://24ways.org/examples/marking-up-a-tag-cloud/example.html seems plausible
  138. # [04:12] <Hixie> (though without all the duplication)
  139. # [04:15] * Joins: weinig (n=weinig@c-69-181-81-233.hsd1.ca.comcast.net)
  140. # [04:18] * Quits: maodun (n=stopgo@c-67-180-49-1.hsd1.ca.comcast.net) ("Leaving.")
  141. # [04:22] * Joins: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  142. # [04:25] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  143. # [04:30] * Quits: dglazkov_ (n=dglazkov@72.14.224.1) (Read error: 110 (Connection timed out))
  144. # [04:32] <BenMillard> Hixie, tag clouds were discussed on #whatwg here: http://krijnhoetmer.nl/irc-logs/whatwg/20081004
  145. # [04:33] <BenMillard> Hixie, the lead-in to that conversation started here: http://krijnhoetmer.nl/irc-logs/whatwg/20081003#l-581
  146. # [04:37] <Hixie> thanks
  147. # [04:38] <Hixie> that's kind of in line with what i just wrote in this omnibus e-mail
  148. # [04:42] * Quits: Mustafa51 (n=mustafa@122.164.164.128)
  149. # [04:47] <BenMillard> Hixie, it's nice when things like that happen. :)
  150. # [04:57] * Quits: annevk (n=annevk@217.174.106.250) (Read error: 110 (Connection timed out))
  151. # [04:57] * Quits: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net) (Read error: 104 (Connection reset by peer))
  152. # [04:58] <Hixie> good lord
  153. # [04:58] <Hixie> http://www.w3.org/History/1991-WWW-NeXT/Implementation/ParseHTML.h
  154. # [04:59] <Hixie> i love the way the main function is called "readSGML"
  155. # [05:07] * Joins: aboodman2 (n=aboodman@dsl081-073-212.sfo1.dsl.speakeasy.net)
  156. # [05:10] * Parts: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  157. # [05:32] * Quits: dimich (n=dimich@c-98-203-230-54.hsd1.wa.comcast.net) (Read error: 60 (Operation timed out))
  158. # [05:37] * Quits: dolske (n=dolske@firefox/developer/dolske)
  159. # [05:37] * Joins: dave_levin (n=dave_lev@72.14.224.1)
  160. # [05:40] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  161. # [05:46] * Quits: doublec (n=chris@202.0.36.64) ("Leaving")
  162. # [05:47] * Joins: dbaron (n=dbaron@c-71-204-152-23.hsd1.ca.comcast.net)
  163. # [05:52] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  164. # [05:54] * Quits: roc (n=roc@202.0.36.64)
  165. # [05:54] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net) (Client Quit)
  166. # [06:06] * Quits: dbaron (n=dbaron@c-71-204-152-23.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  167. # [06:07] * Joins: dolske (n=dolske@c-76-103-41-195.hsd1.ca.comcast.net)
  168. # [06:10] * Quits: karlcow (n=karl@modemcable024.84-81-70.mc.videotron.ca) ("This computer has gone to sleep")
  169. # [06:12] * Joins: dimich (n=dimich@c-98-203-230-54.hsd1.wa.comcast.net)
  170. # [06:13] * Joins: doublec (n=Chris_Do@118-92-151-230.dsl.dyn.ihug.co.nz)
  171. # [06:26] * Joins: dbaron (n=dbaron@c-71-204-152-23.hsd1.ca.comcast.net)
  172. # [06:29] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  173. # [06:30] * Joins: billyjackass (n=MikeSmit@58.157.21.205)
  174. # [06:31] * Quits: doublec (n=Chris_Do@118-92-151-230.dsl.dyn.ihug.co.nz) (Read error: 104 (Connection reset by peer))
  175. # [06:31] * Joins: doublec (n=Chris_Do@118-92-151-230.dsl.dyn.ihug.co.nz)
  176. # [06:31] * Quits: billyjackass (n=MikeSmit@58.157.21.205) (Read error: 104 (Connection reset by peer))
  177. # [06:32] * Joins: karlcow (n=karl@modemcable057.209-70-69.mc.videotron.ca)
  178. # [06:50] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Remote closed the connection)
  179. # [06:50] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  180. # [07:09] * Joins: heycam (n=cam@203-217-82-242.dyn.iinet.net.au)
  181. # [07:10] * Quits: dimich (n=dimich@c-98-203-230-54.hsd1.wa.comcast.net)
  182. # [07:43] * Joins: maikmerten (n=merten@ls5dhcp195.cs.uni-dortmund.de)
  183. # [07:44] <gsnedders> That's odd seeming it was originally not even meant to be SGML, just something like it
  184. # [07:47] * Quits: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  185. # [07:47] <gsnedders> hmmm…
  186. # [07:47] <gsnedders> html5lib fails a lot of tests
  187. # [07:55] <heycam> Hixie, i think it would be better if DOMStringMap still had operations annotated with [NameGetter] etc., and then for me to introduce something in Web IDL to indicate that the operations don't correspond to functions, and then for you to use that functionality
  188. # [07:58] <heycam> Hixie, so something like http://paste.lisp.org/display/72289
  189. # [07:58] * Joins: erlehmann (n=erlehman@dslb-088-075-216-082.pools.arcor-ip.net)
  190. # [07:58] * Joins: tantek (n=tantek@12.140.254.34)
  191. # [07:59] <heycam> it'd have the advantage of both making the description of the named property accessors simpler (since you'd just do your usual description of operations) and also makes the interfaces suitable for languages that don't support object indexing
  192. # [07:59] <heycam> s/makes/making/
  193. # [08:01] <heycam> i can add that [OmitNamedPropertyOperations] (or something like it) before Web IDL is republished later in the week, probably
  194. # [08:01] * Quits: tantek (n=tantek@12.140.254.34) (Client Quit)
  195. # [08:16] * Joins: zcorpan (n=zcorpan@c83-252-193-84.bredband.comhem.se)
  196. # [08:20] * Joins: roc (n=roc@121-72-208-254.dsl.telstraclear.net)
  197. # [08:24] * Joins: ap (n=ap@195.239.126.12)
  198. # [08:27] * Quits: weinig (n=weinig@c-69-181-81-233.hsd1.ca.comcast.net)
  199. # [08:29] * Joins: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  200. # [08:29] * Joins: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  201. # [08:29] * Joins: pesla (n=retep@procurios.xs4all.nl)
  202. # [08:29] * olliej is now known as fakeolliej
  203. # [08:31] * Quits: famicom (i=famicom@5ED2FF2D.cable.ziggo.nl) (Read error: 110 (Connection timed out))
  204. # [08:32] * Joins: deane (n=opera@121-72-173-193.dsl.telstraclear.net)
  205. # [08:32] * Quits: zcorpan (n=zcorpan@c83-252-193-84.bredband.comhem.se) (Read error: 110 (Connection timed out))
  206. # [08:40] * Joins: weinig (n=weinig@c-69-181-81-233.hsd1.ca.comcast.net)
  207. # [08:41] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
  208. # [08:43] * Quits: jwalden (n=waldo@guest-225.mountainview.mozilla.com) ("ChatZilla 0.9.82.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  209. # [08:45] * Joins: annevk (n=annevk@217.174.106.250)
  210. # [08:47] * weinig is now known as weinig|zZz
  211. # [08:50] * Quits: deane (n=opera@121-72-173-193.dsl.telstraclear.net) (Read error: 110 (Connection timed out))
  212. # [08:51] * Joins: deane (n=opera@121-72-191-38.dsl.telstraclear.net)
  213. # [09:00] * Joins: jwalden (n=waldo@c-67-180-39-55.hsd1.ca.comcast.net)
  214. # [09:02] * Quits: deane (n=opera@121-72-191-38.dsl.telstraclear.net) (Read error: 60 (Operation timed out))
  215. # [09:09] * Joins: zcorpan_ (n=zcorpan@c83-252-193-84.bredband.comhem.se)
  216. # [09:09] * Quits: dbaron (n=dbaron@c-71-204-152-23.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  217. # [09:14] <Hixie> heycam: well, i want for (var i in element.dataSet) to work
  218. # [09:16] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Remote closed the connection)
  219. # [09:16] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  220. # [09:26] * Quits: zcorpan_ (n=zcorpan@c83-252-193-84.bredband.comhem.se) (Read error: 110 (Connection timed out))
  221. # [09:28] <Philip`> gsnedders: It only fails about 906 out of 9953, so it's correct most of the time
  222. # [09:34] <heycam> Hixie, right that's still fine, because it comes from the use of [NameGetter]
  223. # [09:35] <heycam> and the definition in prose as to which named properties exist
  224. # [09:35] * heycam goes to cook some curried sausages
  225. # [09:38] <roc> mmm
  226. # [09:39] * Philip` gets confused, until he realises that 'curried' is a culinary term and not a functional programming term
  227. # [09:48] * Quits: erlehmann (n=erlehman@dslb-088-075-216-082.pools.arcor-ip.net) ("Ex-Chat")
  228. # [09:58] <Dashiva> Does prefab count as curried food? :)
  229. # [10:06] * Quits: doublec (n=Chris_Do@118-92-151-230.dsl.dyn.ihug.co.nz) ("ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  230. # [10:10] * Joins: aaronlev (n=chatzill@e176248168.adsl.alicedsl.de)
  231. # [10:12] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
  232. # [10:16] * jgraham has a mostly working html5lib at home
  233. # [10:16] <jgraham> But I have no internet access
  234. # [10:18] <jgraham> But it gets parse errors wrong, doesn't do xml cocecion properly (I started working on that) and fails a bunch of stuff in the liberal xml parser and in the validator, both of which I am tempted to mark as abandoned unless someone fixes them
  235. # [10:19] <jgraham> s/parse/some parse/
  236. # [10:19] <jgraham> Oh and doesn't do MathML or SVG
  237. # [10:20] * jgraham feels bad using old style classes for something as trivial as performance :)
  238. # [10:21] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
  239. # [10:23] <Philip`> Having the parser pass tests seems more valuable than having the liberal XML parser and validator pass tests
  240. # [10:23] <Philip`> so I wouldn't complain about that :-)
  241. # [10:24] <Philip`> jgraham: If performance was trivial, we wouldn't talk about chtml5lib as much as we have :-)
  242. # [10:24] * Parts: Dorward (i=foobar@91.84.53.6)
  243. # [10:25] <jgraham> Philip`: :p
  244. # [10:26] <Philip`> I wouldn't think it was worthwhile if it only gained 1-2%, but it appears to be ten times that
  245. # [10:27] <Philip`> Actually, that's not true, I probably would still think it was worthwhile, but I wouldn't change it if people objected on the grounds of compatibility or something
  246. # [10:28] * Joins: famicom (i=famicom@5ED2FF2D.cable.ziggo.nl)
  247. # [10:28] <jgraham> Philip`: Well it will have to change for Python3 anyway
  248. # [10:30] <Philip`> jgraham: Does Python 3 just remove the "class X:" syntax, rather than redefining it to mean new-style classes?
  249. # [10:31] <jgraham> Philip`: AIUI class Foo(): now means a new style class
  250. # [10:32] <Philip`> I'd guess that's the least of our worries when porting to Python 3, given the whole unicode vs string thing
  251. # [10:33] <jgraham> Philip`: Porting to python 3 will indeed be awful (I expect)
  252. # [10:33] <jgraham> Unless the 2to3 tool is actually a way ofreleasing magic pixies into your computer that do all the work for you
  253. # [10:39] * Joins: nessy (n=nessy@124-171-30-131.dyn.iinet.net.au)
  254. # [10:39] <Philip`> Gentoo only added Python 2.5 as stable a few months ago, so I think it's going to be rather a long time before everyone stops using 2.x and switches to 3.x
  255. # [10:40] <Philip`> so I guess it's more useful for html5lib to be written for 2.x than for 3.x for the next few years
  256. # [10:42] <Philip`> (It took that long because dozens of packages were incompatible with 2.5)
  257. # [10:58] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  258. # [11:20] * Joins: svl (n=me@86.87.68.167)
  259. # [11:21] * Quits: aboodman (n=aboodman@72.14.229.81)
  260. # [11:22] * Joins: aboodman (n=aboodman@72.14.229.81)
  261. # [11:23] * Quits: Lachy_ (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  262. # [11:24] * Joins: ROBOd (n=robod@89.122.216.38)
  263. # [11:43] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  264. # [12:00] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  265. # [12:23] <heycam> Hixie, http://dev.w3.org/2006/webapi/WebIDL/#NoIndexingOperations
  266. # [12:30] * Quits: nessy (n=nessy@124-171-30-131.dyn.iinet.net.au) ("This computer has gone to sleep")
  267. # [12:42] * Joins: hdh (n=hdh@118.71.125.158)
  268. # [12:45] * Joins: xcombelle (n=chatzill@AToulouse-158-1-49-193.w90-50.abo.wanadoo.fr)
  269. # [13:08] * Joins: pauld (n=pauld@host217-43-109-48.range217-43.btcentralplus.com)
  270. # [13:22] * Quits: famicom (i=famicom@5ED2FF2D.cable.ziggo.nl) (Read error: 110 (Connection timed out))
  271. # [13:25] <Philip`> jgraham: Does your mostly working html5lib have lots of changes that would cause annoying conflicts if I was trying to make other changes to reduce the use of unget()?
  272. # [13:37] <jgraham> Philip`: Nothing in the tokenizer iirc
  273. # [13:43] * Joins: tndH (n=Rob@adsl-87-102-93-106.karoo.KCOM.COM)
  274. # [13:45] * Quits: karlcow (n=karl@modemcable057.209-70-69.mc.videotron.ca) ("This computer has gone to sleep")
  275. # [14:02] * Joins: karlcow (n=karl@modemcable168.84-81-70.mc.videotron.ca)
  276. # [14:04] * Quits: karlcow (n=karl@modemcable168.84-81-70.mc.videotron.ca) (Client Quit)
  277. # [14:06] * Joins: karlcow (n=karl@modemcable168.84-81-70.mc.videotron.ca)
  278. # [14:07] * Quits: karlcow (n=karl@modemcable168.84-81-70.mc.videotron.ca) (Client Quit)
  279. # [14:11] <hsivonen> Hixie: is value of input type=datetime supposed to allow as conforming time zone designators other than "Z"?
  280. # [14:11] * Joins: karlcow (n=karl@modemcable168.84-81-70.mc.videotron.ca)
  281. # [14:12] <hsivonen> as far as I can tell, the fourth para under http://www.whatwg.org/specs/web-apps/current-work/#date-and-time-state says that any time zone is valid, but the third para requires UAs to produce only UTC results
  282. # [14:18] <hsivonen> what happened to oninput and oninvalid?
  283. # [14:30] * Quits: maikmerten (n=merten@ls5dhcp195.cs.uni-dortmund.de) (Read error: 110 (Connection timed out))
  284. # [14:36] * Joins: mstange (n=markus@aixd3.rhrk.uni-kl.de)
  285. # [14:48] <Philip`> jgraham: Okay, good
  286. # [14:49] <Philip`> jgraham: (My vague poorly-thought-through plan is to get rid of the unget buffer, and only allow a single character to be ungotten at once, because then there's no need for the lineLengths array and all the related complexity)
  287. # [14:50] <Philip`> jgraham: (But a much more useful plan would be to make the tokeniser match the spec and pass tests, before trying to optimise anything)
  288. # [14:50] <Philip`> jgraham: (so maybe I should try that instead)
  289. # [14:52] * Quits: xcombelle (n=chatzill@AToulouse-158-1-49-193.w90-50.abo.wanadoo.fr) (Read error: 110 (Connection timed out))
  290. # [14:55] * Joins: WulfTheSaxon (i=meh@cpe-76-178-221-42.maine.res.rr.com)
  291. # [15:09] * Joins: aroben (n=aroben@unaffiliated/aroben)
  292. # [15:12] * Joins: harig (n=harig_in@122.160.12.230)
  293. # [15:15] <Philip`> (Or maybe I should fix my OCaml tokeniser generator, and then generate an html5lib-compatible tokeniser, so it's easier to attempt fancier optimisations like inlining stuff to avoid function calls)
  294. # [15:25] <jgraham> Philip`: How will you do readahead one token at a time?
  295. # [15:26] <jgraham> s/token/character/
  296. # [15:26] <jgraham> s/read/look/ maybe
  297. # [15:27] <jgraham> Philip`: Also, if what's checked in has test faliures in the tokenizer other than ones related to non-BMP unicode characters then I probably have changed something there
  298. # [15:28] <Philip`> jgraham: By looking ahead one character, and if it's not what was expected then unget it, otherwise look ahead one more character, and if it's not what was expected then unget the latest character and do something special to the first character (like emit it as a character token or whatever is appropriate)
  299. # [15:28] <Philip`> and then repeat until done
  300. # [15:30] <Philip`> Oh, I haven't actually run the tokeniser tests, I just assumed it hadn't been updated when the spec was changed to add MathML and suchlike
  301. # [15:30] <Philip`> and I assumed the tests had been updated
  302. # [15:30] <Philip`> so either of those assumptions could be wrong
  303. # [15:31] <jgraham> Philip`: Does that work for things like entities where you need multiple characters before you decide what the right thing to emit is?
  304. # [15:31] <jgraham> Philip`: Oh I might just have disbaled things to do with namespaces, MathML, etc. locally
  305. # [15:31] * Joins: maikmerten (n=merten@ls5dhcp195.cs.uni-dortmund.de)
  306. # [15:32] <jgraham> s/things/tests/
  307. # [15:33] <Philip`> jgraham: Yes, because if you're not going to treat it as an entity then you're going to (output it as a character token | append it to the attribute value), so you can do those directly with the list of characters you've collected inside the entity function instead of ungetting and passing control back to some other state
  308. # [15:33] <Philip`> Uh, I'm not sure that sentence entirely made sense
  309. # [15:34] <jgraham> Philip`: I think it does. Basically you just end up buffering characters locally inside the state rather than globally, right?
  310. # [15:34] <Philip`> Yep
  311. # [15:35] <Philip`> and you can ensure those characters are only [^"'>&], so you can trivially process those buffered characters without sending them through the whole tokeniser state machine again
  312. # [15:36] <jgraham> Well it sounds good if you can make it work :)
  313. # [15:39] <Philip`> But at best it'll probably only make things 20% faster, which isn't a groundbreaking improvement :-(
  314. # [15:41] <jgraham> I seem to remember that the linelengths thing seemed very complicated so getting rid of that seems like a win in any case
  315. # [15:42] <Philip`> jgraham: I get quite a few doctype wrong-number-of-ParseError test failures - is that something you fixed locally?
  316. # [15:45] <jgraham> Philip`: Dunno. I seem to remember something related to doctypes
  317. # [15:45] <jgraham> If you fix it, I will deal with the merge problems :)
  318. # [15:46] <Philip`> Okay :-)
  319. # [16:04] * Quits: harig (n=harig_in@122.160.12.230) (Read error: 110 (Connection timed out))
  320. # [16:09] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  321. # [16:12] * Parts: WulfTheSaxon (i=meh@cpe-76-178-221-42.maine.res.rr.com)
  322. # [16:14] <takkaria> Hubbub doesn't have an unget buffer at all, but I don't know if that approach is portable to html5lib
  323. # [16:15] <jgraham> takkaria: What does it use instead?
  324. # [16:19] <takkaria> it sort-of does, but really it just doesn't advance into the buffer until it knows that there is not going to be ungetting necessary
  325. # [16:20] <takkaria> well, until it's not going to be necessary to unget
  326. # [16:20] <takkaria> it peeks ahead instead
  327. # [16:21] <Philip`> takkaria: How does it work when there aren't enough characters in the buffer for lookahead (because it hasn't come across the network yet, so it's not EOF)?
  328. # [16:22] <takkaria> it returns control back to the caller to push more characters into the input stream
  329. # [16:22] <takkaria> and keeps track of how far ahead it was looking
  330. # [16:23] <takkaria> just means that after every peek call, you check that the return code wasn't "out of data"
  331. # [16:26] <hsivonen> The Validator.nu HTML Parser has no lookahead. Instead, I've transformed the tokenizer states in such a way that no lookahead is needed
  332. # [16:27] <Philip`> takkaria: Does it retain enough state that if the input is "<!doctype publi", and it's parsed until before the 'p' and then done some lookahead and returned "out of data", and then receives a "c" character, it doesn't have to reread the "publi"?
  333. # [16:28] * Joins: aaronlev_ (n=chatzill@e176248168.adsl.alicedsl.de)
  334. # [16:28] <jgraham> hsivonen: So what you have InAttributeValueMaybeEntity states?
  335. # [16:28] * Joins: aaronlev__ (n=chatzill@e176248168.adsl.alicedsl.de)
  336. # [16:28] <jgraham> (and so on)
  337. # [16:29] <takkaria> Philip`: yup. the only state it needs to retain is the number of characters it's peeking ahead
  338. # [16:29] * Joins: erlehmann (n=erlehman@dslb-088-075-080-123.pools.arcor-ip.net)
  339. # [16:29] * Quits: aaronlev_ (n=chatzill@e176248168.adsl.alicedsl.de) (Client Quit)
  340. # [16:31] * Philip` guesses that html5lib is the only implementation that will receive "<!doctype p>" and then require another four characters before it emits the token
  341. # [16:32] <takkaria> yeah
  342. # [16:32] <jgraham> OK so html5lib sucks, there's no need to rub it in
  343. # [16:32] <jgraham> :)
  344. # [16:33] <takkaria> well, it's hardly a performance issue :)
  345. # [16:33] <Philip`> html5lib was the first(?) implementation so it can't be expected to do everything perfectly, and now it has the opportunity to benefit from the experience of all the other implementations
  346. # [16:34] * Joins: dglazkov_ (n=dglazkov@72.14.224.1)
  347. # [16:34] <Philip`> takkaria: It's (indirectly) a performance issue in html5lib :-(
  348. # [16:35] <Philip`> because if the input is "<!doctype p>\nx\n\n" then it'll unget a load of newlines, and it'll have to fiddle around to work out what line number it should report errors from
  349. # [16:35] <takkaria> ah
  350. # [16:36] <takkaria> hubbub switches into a special state for the SYSTEM and PUBLIC bits, that seems like the best solution really
  351. # [16:37] <jmb> it's "a" solution, at least :)
  352. # [16:38] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net) (Read error: 60 (Operation timed out))
  353. # [16:39] <Philip`> There are other cases like "<script></\n\n\n\n\n\n" with the same problem in html5lib
  354. # [16:39] <jgraham> I hate computers
  355. # [16:40] * Philip` quite likes them
  356. # [16:40] <takkaria> jmb: I can't see any better one for hubbub, but maybe python has some constructs which are better for it :)
  357. # [16:41] <jmb> takkaria: I agree it's what fits best with hubbub :)
  358. # [16:41] <Philip`> takkaria: The character processing model is probably a more significant difference than the language
  359. # [16:41] <Philip`> html5lib's tokeniser calls stream.char() which always returns the next character (which might involve reading chunks of bytes from the underlying input stream)
  360. # [16:42] <Philip`> s/bytes/characters/ maybe
  361. # [16:42] * Quits: aaronlev (n=chatzill@e176248168.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  362. # [16:42] <Philip`> It's not possible to suspend the tokeniser and wait for more input
  363. # [16:45] * Quits: mstange (n=markus@aixd3.rhrk.uni-kl.de) (Remote closed the connection)
  364. # [16:53] * Joins: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  365. # [16:54] <takkaria> oh, I see
  366. # [16:59] * Quits: maikmerten (n=merten@ls5dhcp195.cs.uni-dortmund.de) (Remote closed the connection)
  367. # [17:01] * Quits: dglazkov_ (n=dglazkov@72.14.224.1)
  368. # [17:01] * Philip` doesn't fancy changing that, so he won't
  369. # [17:01] * Joins: mstange (n=markus@aixd3.rhrk.uni-kl.de)
  370. # [17:02] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
  371. # [17:07] * Joins: eric_carlson_ (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  372. # [17:09] * Joins: hallvors (n=hallvord@pat-tdc.opera.com)
  373. # [17:13] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  374. # [17:15] * Quits: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Read error: 110 (Connection timed out))
  375. # [17:16] <hsivonen> jgraham: The entity state is essentially a "maybe" state in the sense that if it's not an entity, it appends what it saw
  376. # [17:16] <hsivonen> jgraham: so it buffers what it saw instead of looking ahead
  377. # [17:21] <takkaria> appends back on to the front of the buffer?
  378. # [17:23] <hsivonen> appends to the attribute value buffer
  379. # [17:25] <takkaria> ah, I see
  380. # [17:30] * Joins: dglazkov (n=dglazkov@nat/google/x-32a458f7ca805563)
  381. # [17:53] * Joins: famicom (i=famicom@5ED2FF2D.cable.ziggo.nl)
  382. # [17:58] <gsnedders> Philip`: is http://philip.html5.org/tests/ie8/cases/unknown-element-styling.html fixed in the latest build?
  383. # [18:03] <zcorpan> gsnedders: seems like it
  384. # [18:03] <gsnedders> zcorpan: thx
  385. # [18:04] <Philip`> gsnedders: I'm almost entirely sure it is
  386. # [18:04] <Philip`> http://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=364356
  387. # [18:04] <zcorpan> i'd like it to work without the script workaround
  388. # [18:07] * Philip` wonders how html5lib tokenises "<xmp>foo</xmp/" into [[u'Character', u'foo'], u'ParseError', [u'EndTag', u'xmp'], u'ParseError', [u'EndTag', u'xmp']]
  389. # [18:07] <Philip`> (Uh, ignore the lack of a StartTag token - that's not relevant)
  390. # [18:09] <jgraham> Philip`: Wow, really?
  391. # [18:10] <Philip`> jgraham: That's the output I get from a test case
  392. # [18:10] <Philip`> and I don't think it's using code that I've locally modified
  393. # [18:14] * weinig|zZz is now known as weinig
  394. # [18:14] <jgraham> Wow, that is really bad
  395. # [18:17] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  396. # [18:20] <Philip`> Seems to happen when the input is a simple plain "<x/" too
  397. # [18:23] <Philip`> Ah, it's just ignoring the return value of self.processSolidusInTag()
  398. # [18:25] <hsivonen> http://twitter.com/perrins/statuses/1062462587
  399. # [18:29] * Quits: zcorpan (n=zcorpan@pat.se.opera.com)
  400. # [18:29] * Quits: pesla (n=retep@procurios.xs4all.nl) ("( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )")
  401. # [18:32] * Joins: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  402. # [18:34] * Philip` gets quite worried when he can comment out lines of code in the middle of important functions without causing any tests to fail
  403. # [18:37] <takkaria> hmm, I really should get round to contributing all of the hubbub tests back to html5lib
  404. # [18:38] <takkaria> we have character encoding stuff that html5lib didn't have tests for
  405. # [18:39] <Philip`> That would be a nice thing to have
  406. # [18:40] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl) (Connection timed out)
  407. # [18:40] * Quits: eric_carlson_ (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Read error: 110 (Connection timed out))
  408. # [18:43] * Joins: Maurice (n=copyman@5ED548D4.cable.ziggo.nl)
  409. # [18:59] * Quits: Maurice (n=copyman@5ED548D4.cable.ziggo.nl) (Connection reset by peer)
  410. # [19:04] * Joins: Maurice (n=copyman@5ED548D4.cable.ziggo.nl)
  411. # [19:12] * Joins: shepazu (n=schepers@c-69-139-224-74.hsd1.md.comcast.net)
  412. # [19:26] * Philip` doesn't think the idea to deprecate text/html is going to get much traction in the WHATWG
  413. # [19:27] <Philip`> (in response to mailing list)
  414. # [19:27] * Quits: pauld (n=pauld@host217-43-109-48.range217-43.btcentralplus.com)
  415. # [19:35] <Hixie> hsivonen: yeah i wanted to allow authors to use their own time zone when setting the value
  416. # [19:36] <hsivonen> Hixie: ok. thanks
  417. # [19:37] <Hixie> heycam: i'm scared that that's like giving implementors a loaded gun and telling them to point it at their foot and set the safety and then pull the trigger -- implementors who aren't paying attention will shoot themselves
  418. # [19:37] <Hixie> heycam: i.e. they'll think "what's NoIndexingOperations? oh well let's ignore it for now" and we'll get the functions exposed
  419. # [19:38] <Hixie> heycam: i'd much rather have the idl look like the js object and have [IndexSetter] etc take arguments to provide names for the other languages
  420. # [19:39] * Quits: aboodman2 (n=aboodman@dsl081-073-212.sfo1.dsl.speakeasy.net) (Read error: 110 (Connection timed out))
  421. # [19:39] * Quits: weinig (n=weinig@c-69-181-81-233.hsd1.ca.comcast.net)
  422. # [19:48] * Joins: pauld (n=pauld@host217-43-109-48.range217-43.btcentralplus.com)
  423. # [19:51] * Quits: Maurice (n=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
  424. # [19:54] * Joins: aboodman2 (n=aboodman@72.14.229.81)
  425. # [20:05] * Quits: shepazu (n=schepers@c-69-139-224-74.hsd1.md.comcast.net) ("Core Breach")
  426. # [20:11] * Quits: pauld (n=pauld@host217-43-109-48.range217-43.btcentralplus.com)
  427. # [20:19] * Quits: drry (n=drry@it17.opt2.point.ne.jp)
  428. # [20:20] * Joins: drry (n=drry@it17.opt2.point.ne.jp)
  429. # [20:23] * Quits: dave_levin (n=dave_lev@72.14.224.1)
  430. # [20:25] * Joins: Lachy (n=Lachlan@85.196.122.246)
  431. # [20:25] * Quits: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  432. # [20:27] * Quits: sicking (n=chatzill@corp-242.mountainview.mozilla.com) (Remote closed the connection)
  433. # [20:27] <hsivonen> Hixie: http://html5.validator.nu/?doc=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2F
  434. # [20:28] <hsivonen> it's a bit disturbing that in the past year and a half or so, I've had to change the max file size from 1 MB to 4 MB to accommodate the spec
  435. # [20:30] <Hixie> the file size sharnk significantly since i complained
  436. # [20:31] <Hixie> shrank
  437. # [20:32] * Joins: dimich (n=dimich@72.14.227.1)
  438. # [20:34] * Quits: dolske (n=dolske@firefox/developer/dolske)
  439. # [20:35] * Joins: weinig (n=weinig@nat/apple/x-4e6290598b3860bb)
  440. # [20:35] <Hixie> it was only big temporarily because i had all the rfc2119 terms marked up as a test
  441. # [20:37] <hsivonen> Hixie: it's still over 3 MB, though
  442. # [20:37] <Hixie> yup
  443. # [20:37] * Parts: annevk (n=annevk@217.174.106.250)
  444. # [20:41] * Quits: weinig (n=weinig@nat/apple/x-4e6290598b3860bb)
  445. # [20:44] * Joins: sicking (n=chatzill@corp-242.mountainview.mozilla.com)
  446. # [20:44] * Joins: Maurice (n=copyman@5ED548D4.cable.ziggo.nl)
  447. # [20:44] * Joins: dave_levin (n=dave_lev@72.14.227.1)
  448. # [20:46] * Quits: sicking (n=chatzill@corp-242.mountainview.mozilla.com) (Remote closed the connection)
  449. # [20:46] * Joins: weinig (n=weinig@nat/apple/x-e7f85e2f20caddb8)
  450. # [20:46] * Quits: roc (n=roc@121-72-208-254.dsl.telstraclear.net)
  451. # [20:47] * Quits: jwalden (n=waldo@c-67-180-39-55.hsd1.ca.comcast.net) ("ChatZilla 0.9.82.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  452. # [20:55] * Joins: sicking (n=chatzill@corp-242.mountainview.mozilla.com)
  453. # [20:55] * Joins: dolske (n=dolske@corp-241.mountainview.mozilla.com)
  454. # [20:55] <sicking> Hixie, ping
  455. # [21:05] * Quits: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  456. # [21:06] <Hixie> sicking: pong
  457. # [21:07] <sicking> Hixie, why is outerHTML/insertAdjecentHTML in HTML5. Alternatively, why aren't they supported in XML 'mode'?
  458. # [21:09] * Joins: annevk (n=annevk@217.174.106.250)
  459. # [21:21] * Joins: roc (n=roc@202.0.36.64)
  460. # [21:22] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  461. # [21:26] * Joins: jwalden (n=waldo@guest-225.mountainview.mozilla.com)
  462. # [21:26] <gsnedders> Anyone found any more release critical bugs in Anolis, or can I push 1.0?
  463. # [21:28] <Hixie> sicking: they're in HTML5 because several browsers support them
  464. # [21:29] <Hixie> sicking: they're not supported in XML because I didn't spec it and nobody asked for it
  465. # [21:29] <sicking> Hixie, so they are considered required for web compat?
  466. # [21:29] <Hixie> apparently several browser vendors think so, yes
  467. # [21:29] <sicking> well, we all know that browser vendors are on crack most of the time...
  468. # [21:30] <Hixie> that's not a line of argument you want to convince me of :-)
  469. # [21:30] <Hixie> doesn't really matter if they're on crack or not though
  470. # [21:30] <sicking> i'm surprised you are not convinced of that already?
  471. # [21:31] <Hixie> i find browser vendors as a group to be amongst the sanest of the people i deal with on a daily basis
  472. # [21:31] <sicking> so given that criteria, why isn't document.all in html5?
  473. # [21:31] <Hixie> mainly, i haven't gotten around to it yet
  474. # [21:31] <sicking> ok
  475. # [21:31] <Hixie> partially because i have no idea how to spec its magical behavior
  476. # [21:32] <Hixie> (there's lots that i haven
  477. # [21:32] <Hixie> 't specced yet, like window.focus())
  478. # [21:33] <sicking> a nice thing about document.all is that it's unlikely that we can ever get browser compat on one critical aspect of it
  479. # [21:33] <sicking> namely weather if |document.all| produces true or not
  480. # [21:34] <sicking> for the same reason that we'll unlikely to get compat on what Navigator.appName returns
  481. # [21:34] <Hixie> well i just need two complete bug-free implementations of HTML5, and I've already given up on IE being one of those two
  482. # [21:34] <Hixie> Navigator.appName doesn't have to return the same value in all browsers, it just has to return a value that conforms to the spec
  483. # [21:34] <Hixie> and the spec says: Must return either the string "Netscape" or the full name of the browser, e.g. "Mellblom Browsernator".
  484. # [21:34] <Hixie> ...which it is possible to implement interoperably
  485. # [21:34] <sicking> my point is that document.all is used as browser detection as much as navigator.appName is
  486. # [21:35] <sicking> so people *want* it to return different things for different browsers
  487. # [21:35] <Hixie> given the route IE is taking, i wouldn't be surprised if that changed
  488. # [21:35] <Hixie> but yeah
  489. # [21:35] <Hixie> anyway
  490. # [21:35] <Hixie> that's not a huge deal
  491. # [21:36] <Hixie> i don't really see how to define document.all returning false anyway
  492. # [21:36] <sicking> magic pixie dust :)
  493. # [21:36] <Hixie> yeah
  494. # [21:36] <sicking> but back to my original question. If we think outerHTML is worth implementing, why not do it for XML mode?
  495. # [21:36] <Hixie> maybe i can argue that document.all should be in zcorpan's Web DOM Core instead of HTML5!
  496. # [21:37] <sicking> hah!
  497. # [21:38] * Philip` re-discovers why parsing entities is not much fun
  498. # [21:39] <Philip`> It has too many edge cases :-(
  499. # [21:40] * Joins: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  500. # [21:40] <Philip`> and I have to transform the spec's notion of unconsuming multiple characters into an implementation that can't unconsume more than one
  501. # [21:42] * gsnedders wonders why on earth Anolis failing ow
  502. # [21:42] <gsnedders> *now
  503. # [21:43] * Joins: kingryan (n=ryan@adsl-99-50-23-198.dsl.pltn13.sbcglobal.net)
  504. # [21:43] <gsnedders> http://pastebin.com/m7e39a551 — ideas
  505. # [21:44] <sicking> Hixie, but back to my original question. If we think outerHTML is worth implementing, why not do it for XML mode as well? Seems like all the parts are there anyway due to innerHTML being supported
  506. # [21:45] * hallvors thinks outerHTML is mainly useful for debugging
  507. # [21:46] <Philip`> gsnedders: That line is codec = inputstream.codecName(atributes["charset"])
  508. # [21:46] <Philip`> gsnedders: which is clearly not going to work because it spells "attributes" wrong
  509. # [21:46] <Philip`> gsnedders: so presumably it's never been tested
  510. # [21:46] <gsnedders> Philip`: But the line numbers don't even match up
  511. # [21:46] <Philip`> gsnedders: so presumably nobody noticed it probably needs a "import inputstream" too
  512. # [21:47] <Philip`> gsnedders: Don't they? That's what I get on line 588 in html5parser.py
  513. # [21:47] * gsnedders doesn't
  514. # [21:47] <gsnedders> hmm
  515. # [21:47] <gsnedders> oh, I'm just being stupid
  516. # [21:48] <Philip`> gsnedders: It'd be good if you could add a test case to html5lib for that problem :-)
  517. # [21:48] <gsnedders> Philip`: So even more can fail? :)
  518. # [21:49] <gsnedders> Philip`: where should the import go? Just after import sys?
  519. # [21:50] <gsnedders> which test dir should parser go under? tree-constructor?
  520. # [21:50] <Philip`> gsnedders: So it can be fixed and no longer fail :-)
  521. # [21:50] <Philip`> gsnedders: That sounds fine for the import
  522. # [21:50] <gsnedders> and then how do I know which test[1-12].dat to put it in? :\
  523. # [21:50] * gsnedders has never got this
  524. # [21:50] * Joins: xcombelle (n=chatzill@AToulouse-158-1-24-63.w90-50.abo.wanadoo.fr)
  525. # [21:51] * Joins: nessy (n=nessy@124-171-30-131.dyn.iinet.net.au)
  526. # [21:52] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  527. # [21:52] <Philip`> gsnedders: I don't know if it's possible to test using that framework - I'd guess they're all Unicode strings, so you couldn't get it to give charEncoding[1] == "tentative" and trigger the bug
  528. # [21:52] <gsnedders> Yeah, that is a bit of a problem
  529. # [21:53] <gsnedders> now AttributeError: HTMLInputStream instance has no attribute 'changeEncoding'
  530. # [21:53] <gsnedders> yay
  531. # [21:54] * gsnedders just changes it to raise NotImplementedError
  532. # [21:54] <Philip`> gsnedders: Might be easier to just write the test case in Python, in tests/test_encoding.py (as a new method in Html5EncodingTestCase)
  533. # [21:54] <gsnedders> But that still doesn't help me
  534. # [21:54] <Philip`> or it might not; I don't know really
  535. # [21:54] <Hixie> sicking: i wouldn't mind doing it for XML too if you think we should (innerHTML is available in XML too)
  536. # [21:55] * gsnedders wonders why it used to work but why it doesn't anymore
  537. # [21:55] <Philip`> gsnedders: Just force everything to be UTF-8, then you can avoid all these encoding issues :-)
  538. # [21:55] <Hixie> sicking: nobody (other than you now) has asked for it though, and generally i'd rather people used something more compile-time-checked than strings in innerHTML/outerHTML
  539. # [21:55] <Hixie> sicking: (e.g. e4x, though that doesn't seem to be doign well)
  540. # [21:55] <sicking> Hixie, just seems silly to basically add |if (DocIsXML()) return;| to the top of the implementation of those functions
  541. # [21:56] <sicking> e4x is doomed IMHO
  542. # [21:56] <sicking> it's a good idea, but with a terrible execution
  543. # [21:56] * Joins: roc_ (n=roc@202.0.36.64)
  544. # [21:57] <sicking> maybe someone could come up with a decent e5x that actually works more like JS
  545. # [21:57] * Joins: weinig_ (n=weinig@nat/apple/x-99ca6a4a2c5eb4fa)
  546. # [21:57] <Hixie> well if we support this in XML instead of |if (DocIsXML()) return;| you'd have |if (DocIsXML()) { /* something much more complicated than return */; return; }| instead
  547. # [21:57] <gsnedders> Philip`: seems like jgraham broke it
  548. # [21:57] <gsnedders> Philip`: That n00b.
  549. # [21:58] <Hixie> sicking: we if the goal is making the implementation easier, not supporting it is easier. :-)
  550. # [21:58] <sicking> Hixie, i'd imagine not. I'd think that the code that implements this for HTML will work out of the box for XML too. Since that code will likely implement innerHTML as well
  551. # [21:59] * Philip` realises this is the fifth programming language in which he has implemented entity parsing
  552. # [21:59] <Hixie> sicking: the idea is that if you have an XHTML-only UA, you don't need an HTML parser
  553. # [21:59] <sicking> Hixie, sure
  554. # [21:59] <sicking> Hixie, we'd do the same as for innerHTML and use the XML parser
  555. # [22:00] <Hixie> oh
  556. # [22:00] <Hixie> well then
  557. # [22:00] <Hixie> quite different code, no?
  558. # [22:00] <gsnedders> Philip`: I guess you must be getting good at it now
  559. # [22:01] <Dashiva> "XML is neither more performant nor stricter than XML."
  560. # [22:01] <Hixie> sicking: innerHTML for HTML and XML are quite different in the spec
  561. # [22:01] <Hixie> Dashiva: oops
  562. # [22:03] <sicking> basically i'd structure the code as follows |insertMarkupInContext(Node context, String markup) { DocumentFragment res; if (IsXML(context)) { res = parseUsingXMLParser(context, markup) } else { res = parseUsingHTMLParser(context, markup) } context.appendChild(res); }
  563. # [22:03] <sicking> and just call that function from innerHTML/outerHTML/insertAdjecentHTML
  564. # [22:04] * Joins: virtuelv (n=virtuelv@74.80-202-66.nextgentel.com)
  565. # [22:04] <sicking> codereuse FTW
  566. # [22:04] <Philip`> gsnedders: Not at all
  567. # [22:04] <Philip`> gsnedders: Every implementation has been almost entirely different
  568. # [22:07] <Hixie> sicking: fair enough
  569. # [22:07] <sicking> Hixie, it'd be a bit more complicated since an insertion point is needed as well, but it seems trivial to add
  570. # [22:07] <sicking> Hixie, i guess i don't care much, but as an implementor i'd argue that the cost is very low to implement. And it's always ugly with difference between HTML and XHTML IMHO
  571. # [22:08] <Hixie> sicking: well, send mail and i'll add it... i have nothing intrinsically against adding it, i just wanted to add the bare minimum when i added it
  572. # [22:08] <sicking> Hixie, cool
  573. # [22:09] * Quits: roc (n=roc@202.0.36.64) (Read error: 113 (No route to host))
  574. # [22:12] <dave_levin> I don't know if this an html5 question or a webapps question. When one clicks an <a href=url"... in a something like a webapp/prism, is there something to indicate to whether the new window should still be part of the webapp/prism or launch a new browser?
  575. # [22:12] * Quits: weinig (n=weinig@nat/apple/x-e7f85e2f20caddb8) (Read error: 110 (Connection timed out))
  576. # [22:12] * Quits: annevk (n=annevk@217.174.106.250) (Read error: 110 (Connection timed out))
  577. # [22:12] <Philip`> (Hooray, numeric entities pass tests)
  578. # [22:13] * Quits: ap (n=ap@195.239.126.12)
  579. # [22:14] <dave_levin> The closest thing I found was "sidebar" but that isn't right for what I'm asking about.
  580. # [22:17] <Philip`> (Hooray, all entities pass tests)
  581. # [22:17] <Philip`> (and now I'm not calling unget() at all)
  582. # [22:19] <gsnedders> Philip`: what tests?
  583. # [22:22] <Philip`> gsnedders: The ones in testdata/tokenizer
  584. # [22:22] <gsnedders> Philip`: But only the entity ones? /me shrugs
  585. # [22:23] <gsnedders> http://hg.gsnedders.com/anolis — tip is currently last call for blockers before shipping 1.0 :P
  586. # [22:23] <gsnedders> oh, entities.dat
  587. # [22:23] <gsnedders> That simplifies things
  588. # [22:23] <Philip`> gsnedders: All of them, not only the entities ones
  589. # [22:30] * Quits: heycam (n=cam@203-217-82-242.dyn.iinet.net.au) ("bye")
  590. # [22:36] <gsnedders> right
  591. # [22:36] <gsnedders> Anolis 1.0 now available
  592. # [22:38] * Joins: yecril71 (n=giecrilj@piekna-gts.2a.pl)
  593. # [22:38] <yecril71> outerHTML is good for breaking MSHTML.
  594. # [22:38] <yecril71> It causes null pointer exception when applied carefully.
  595. # [22:40] <yecril71> A validating XML parser checks for attribute types.
  596. # [22:40] <yecril71> In the case of HTML, whether the attribute definition must be quoted or not does not depend on attribute type.
  597. # [22:41] <yecril71> It depends on the attribute value.
  598. # [22:41] <yecril71> And it is not a bottleneck.
  599. # [22:42] <yecril71> Parsing HTML or XML does not require a browser.
  600. # [22:43] <yecril71> <div><p>some text</div> does not trigger quirks mode.
  601. # [22:44] <yecril71> It is official: the closing tag is optional.
  602. # [22:44] <yecril71> <div><p>some text<p>some more text</div> is <div><p>some text</p ><p>some more text</p ></div>.
  603. # [22:44] <yecril71> There is no ambiguity.
  604. # [22:45] <yecril71> Strict checking means less errors but it also means less content.
  605. # [22:46] <gsnedders> Wow. I've not blogged since September
  606. # [22:47] <yecril71> Because the authors will find it too much trouble to comply, or they will use Microsoft Word, which will only be for worse.
  607. # [22:47] <gsnedders> yecril71: That does trigger quirks, as it has no doctype
  608. # [22:47] <yecril71> It was meant to be a fragment.
  609. # [22:48] <gsnedders> ah
  610. # [22:48] <yecril71> I am commenting on a recent message from Giovanni.
  611. # [22:49] <gsnedders> It wasn't clear in that email whether it was meant as a fragment or not either :)
  612. # [22:50] <yecril71> He explicitly stated that </div > triggered quirks mode in his universe.
  613. # [22:51] <yecril71> XHTML1.0 explicitly refers to HTML4 as semantic base.
  614. # [22:54] <Philip`> gsnedders: You negatively rated r1235, which was my commit, not jgraham's
  615. # [22:54] <Hixie> dave_levin: it's somewhat up to the app
  616. # [22:54] <Hixie> dave_levin: html5 defines target="" which could be used as a key
  617. # [22:55] * Quits: mstange (n=markus@aixd3.rhrk.uni-kl.de) ("ChatZilla 0.9.84 [Firefox 3.2a1pre/20081216020422]")
  618. # [22:59] * Quits: aaronlev__ (n=chatzill@e176248168.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  619. # [23:07] <dave_levin> Hixie: So if a given user agent (UA1), choose target="_SomeCoolNameHere", then the web app should modify the links to have this target *only* when running in UA1. This is to avoid other user agents would interpret this as a name and replacing the contents of that window as links are clicked. Right?
  620. # [23:11] <yecril71> I have read that FONT is more powerful than CSS with respect to size.
  621. # [23:12] * Philip` appears to have made html5lib about 10% faster, but it's still spending about 10% of its time computing line numbers :-(
  622. # [23:16] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  623. # [23:17] <gsnedders> Philip`: sod
  624. # [23:19] <gsnedders> Philip`: OK, fixed
  625. # [23:21] * Quits: weinig_ (n=weinig@nat/apple/x-99ca6a4a2c5eb4fa)
  626. # [23:22] * Joins: doublec (n=chris@202.0.36.64)
  627. # [23:25] <Philip`> "some_string == None" is surprisingly expensive compared to "some_string is None"
  628. # [23:26] <Hixie> dave_levin: i would not recommend minting a new value
  629. # [23:26] <gsnedders> Philip`: what's the diff between == and is?
  630. # [23:26] <Hixie> dave_levin: i would recommend supporting target="" as is, but saying that any links that would normally open a new browsing context should instead open a browser window
  631. # [23:27] * Quits: doublec (n=chris@202.0.36.64) (Read error: 104 (Connection reset by peer))
  632. # [23:29] <Philip`> http://www.google.com/search?q=python+%3D%3D+is
  633. # [23:29] <Philip`> Hmph, stupid search engine :-(
  634. # [23:29] * Quits: Maurice (n=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
  635. # [23:29] <Philip`> I assume the difference is that == does type coercion in some cases, and 'is' doesn't
  636. # [23:31] * Joins: aaronlev (n=chatzill@e176248168.adsl.alicedsl.de)
  637. # [23:33] * Quits: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  638. # [23:40] * Quits: aaronlev (n=chatzill@e176248168.adsl.alicedsl.de) (Read error: 60 (Operation timed out))
  639. # [23:45] * Quits: dimich (n=dimich@72.14.227.1)
  640. # [23:46] * Joins: doublec (n=chris@202.0.36.64)
  641. # [23:51] <yecril71> HTML5 can roughly describe some semantics but you cannot encode a semantic network in HTML.
  642. # [23:52] * Joins: hdh0 (n=hdh@118.71.125.158)
  643. # [23:52] <yecril71> HTML can say <span class="Person" >John</span >, but it cannot encode that John likes Mary.
  644. # [23:53] <yecril71> And John can dislike Mary "on the fly".
  645. # [23:55] <Philip`> <span>John likes Mary</span> - that's encoding the semantics in HTML
  646. # [23:56] <yecril71> It is no better than "John likes Mary", i.e. no encoding.
  647. # [23:59] <yecril71> If Siemens is a name of a company, the browser can offer to look it up on Yellow Pages.
  648. # Session Close: Thu Dec 18 00:00:00 2008

The end :)