/irc-logs / freenode / #whatwg / 2009-05-24 / end

Options:

  1. # Session Start: Sun May 24 00:00:00 2009
  2. # Session Ident: #whatwg
  3. # [00:39] * Joins: weinig (n=weinig@cpe-76-173-121-31.socal.res.rr.com)
  4. # [00:44] * Quits: weinig (n=weinig@cpe-76-173-121-31.socal.res.rr.com)
  5. # [01:13] * Joins: virtuelv (n=virtuelv@084202133045.customer.alfanett.no)
  6. # [01:17] * Quits: drry (n=drry@dd25.opt2.point.ne.jp) ("Tiarra 0.1+svn-33115: SIGTERM received; exit")
  7. # [01:17] * Joins: drry (n=drry@dd25.opt2.point.ne.jp)
  8. # [01:23] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
  9. # [01:34] * Joins: hdh (n=hdh@118.71.96.142)
  10. # [01:47] * Quits: virtuelv (n=virtuelv@084202133045.customer.alfanett.no) ("Ex-Chat")
  11. # [01:56] * Joins: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  12. # [02:09] * Quits: Hixie (i=ianh@trivini.no) (Read error: 104 (Connection reset by peer))
  13. # [02:11] * Joins: aroben (n=aroben@209.116.40.3)
  14. # [02:12] * Joins: Hixie (i=ianh@trivini.no)
  15. # [02:42] * Quits: sid0 (n=sid0@unaffiliated/sid0) (Read error: 104 (Connection reset by peer))
  16. # [02:43] * Joins: sid0 (n=sid0@unaffiliated/sid0)
  17. # [03:30] * Quits: aroben (n=aroben@unaffiliated/aroben)
  18. # [03:34] * Joins: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  19. # [03:38] * Joins: doublec (n=doublec@203-167-184-29.dsl.clear.net.nz)
  20. # [03:51] * Joins: aroben (n=aroben@adsl-99-191-194-227.dsl.pltn13.sbcglobal.net)
  21. # [03:55] * Quits: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  22. # [03:59] * Joins: nessy (n=nessy@203-214-156-65.perm.iinet.net.au)
  23. # [04:16] * Quits: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  24. # [04:35] * Quits: aroben (n=aroben@unaffiliated/aroben)
  25. # [04:43] * Joins: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  26. # [04:52] * Joins: wakaba (n=wakaba@EM114-51-9-185.pool.e-mobile.ne.jp)
  27. # [04:58] * Quits: doublec (n=doublec@203-167-184-29.dsl.clear.net.nz) (Read error: 110 (Connection timed out))
  28. # [04:58] * Joins: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com)
  29. # [05:05] * Quits: tndH (n=Rob@james-baillie-pc083-229.student-halls.leeds.ac.uk) ("ChatZilla 0.9.84-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  30. # [05:10] * Quits: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  31. # [05:13] * Quits: wakaba (n=wakaba@EM114-51-9-185.pool.e-mobile.ne.jp) (Read error: 104 (Connection reset by peer))
  32. # [05:14] * Joins: wakaba (n=wakaba@EM114-51-23-205.pool.e-mobile.ne.jp)
  33. # [05:23] * Joins: annevk4 (n=annevk@5ED2D22C.cable.ziggo.nl)
  34. # [05:27] * Quits: annevk4 (n=annevk@5ED2D22C.cable.ziggo.nl) (Client Quit)
  35. # [05:30] * Quits: shepazu (n=schepers@adsl-144-137-232.rmo.bellsouth.net) ("Core Breach")
  36. # [05:58] * Joins: cgriego (n=cgriego@cpe-72-181-202-225.tx.res.rr.com)
  37. # [05:58] * Quits: cgriego (n=cgriego@cpe-72-181-202-225.tx.res.rr.com) (Remote closed the connection)
  38. # [06:06] * Joins: shepazu (n=schepers@adsl-144-137-232.rmo.bellsouth.net)
  39. # [06:42] * Joins: weinig (n=weinig@cpe-76-173-121-31.socal.res.rr.com)
  40. # [06:46] * Quits: Kuruma (n=Kuruman@p2085-ipbf3401hodogaya.kanagawa.ocn.ne.jp) ("Tiarra 0.1+svn-33115: SIGTERM received; exit")
  41. # [06:48] * Joins: Kuruma (n=Kuruman@p2085-ipbf3401hodogaya.kanagawa.ocn.ne.jp)
  42. # [07:21] * Joins: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  43. # [07:30] * Quits: weinig (n=weinig@cpe-76-173-121-31.socal.res.rr.com)
  44. # [07:33] * Joins: weinig (n=weinig@cpe-76-173-121-31.socal.res.rr.com)
  45. # [07:33] <Hixie> i'm no longer checking html5 for validity because validator.nu won't let me check it -- says it's too long :-(
  46. # [07:33] <Hixie> hsivonen: any chance you could increase the limit again :-)
  47. # [07:34] * Joins: sicking_ (n=chatzill@corp-241.mountainview.mozilla.com)
  48. # [07:38] * Quits: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  49. # [07:47] * Joins: zdobersek (n=zan@cpe-92-37-69-24.dynamic.amis.net)
  50. # [07:51] * Quits: weinig (n=weinig@cpe-76-173-121-31.socal.res.rr.com) (Success)
  51. # [07:51] * Quits: sicking (n=chatzill@corp-241.mountainview.mozilla.com) (Read error: 110 (Connection timed out))
  52. # [07:56] * Joins: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  53. # [08:12] * Joins: zdobersek1 (n=zan@cpe-92-37-69-40.dynamic.amis.net)
  54. # [08:15] * Quits: zdobersek (n=zan@cpe-92-37-69-24.dynamic.amis.net) (Read error: 60 (Operation timed out))
  55. # [08:20] * Joins: xydyx (n=hdh@58.187.200.200)
  56. # [08:29] <othermaciej> annevk42: are you around?
  57. # [08:34] * Joins: mhausenblas (n=mhausenb@wg1-nat.fwgal01.deri.ie)
  58. # [08:36] * Quits: hdh (n=hdh@118.71.96.142) (Read error: 113 (No route to host))
  59. # [08:49] * Quits: xydyx (n=hdh@58.187.200.200) (Remote closed the connection)
  60. # [09:16] <hsivonen> Hixie: I'll fix when I get to my work computer
  61. # [09:17] <Hixie> sweet :-)
  62. # [09:17] <hsivonen> I hadn't realized RDFa had this random restriction: http://www.w3.org/TR/rdfa-syntax/#col_Metainformation
  63. # [09:18] <hsivonen> Did I read right that Shane called UAs that lowercase names "legacy"?
  64. # [09:19] <othermaciej> hsivonen: well they haven't updated to XHTML2 yet
  65. # [09:19] <othermaciej> so obviously
  66. # [09:20] <Philip`> hsivonen: Which restriction are you referring to?
  67. # [09:20] <hsivonen> Philip`: not generating triples for rels not on that list
  68. # [09:20] * Quits: Kuruma (n=Kuruman@p2085-ipbf3401hodogaya.kanagawa.ocn.ne.jp) ("Tiarra 0.1+svn-33115: SIGTERM received; exit")
  69. # [09:21] <Philip`> hsivonen: Ah
  70. # [09:21] <Philip`> Seems a really bad idea in terms of forward-compatibility
  71. # [09:22] <Philip`> (At least one implementation (rdfQuery) throws a fatal error if you have a rel keyword that's not on the list, which can't be good)
  72. # [09:22] * Joins: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  73. # [09:22] <hsivonen> Philip`: are you implying compliance isn't good? :-)
  74. # [09:22] * Joins: Kuruma (n=Kuruman@p2085-ipbf3401hodogaya.kanagawa.ocn.ne.jp)
  75. # [09:24] <Philip`> hsivonen: Compliance doesn't require implementations to throw fatal errors, just to ignore the value, as far as I can tell
  76. # [09:24] <hsivonen> ah
  77. # [09:41] * mhausenblas wondering what in http://www.w3.org/TR/rdfa-syntax/#col_Metainformation is random to hsivonen
  78. # [09:44] <hsivonen> mhausenblas: the admittance of non-HTML4 relations seems arbitrary
  79. # [09:44] <mhausenblas> ahm. and if you compare that to http://wiki.whatwg.org/wiki/RelExtensions - this is good practice, then, right? ;)
  80. # [09:45] <hsivonen> mhausenblas: license is there. also role. nofollow isn't there
  81. # [09:45] <mhausenblas> if nofollow isn't there then it's a bug, IMHO
  82. # [09:45] <mhausenblas> I'll check and bring it up at next telecon, thanks
  83. # [09:46] <hsivonen> mhausenblas: the whatwg wiki doesn't make future-limiting processing restrictions
  84. # [09:46] * mhausenblas is not in the position to judge, but I personally like and prefer the 'open' vocabulary world
  85. # [09:47] * Philip` will refrain from making any suggestions on handling rel="alternate stylesheet" similarly to how HTML5 microdata handles it (as a single token)
  86. # [09:47] <hsivonen> a wiki page seems more 'open' than a list created by a TF
  87. # [09:47] <mhausenblas> experience tells that even if you allow people to come up with their own voc, over time the economics enforce few vocs per topic to survive
  88. # [09:48] * Philip` also refrains from commenting on rel="STYLESHEET" etc, which seemingly won't be accepted by an RDFa processor
  89. # [09:48] <mhausenblas> hsivonen: open in the sense of everyone can publish everywhere everything (why a single Wiki?)
  90. # [09:49] <hsivonen> mhausenblas: to avoid the step where you have overlapping vocabularies
  91. # [09:49] <mhausenblas> hsivonen: in my world this does not happen as each voc lives in its own namespace
  92. # [09:49] <Philip`> Regardless of where valid rel values are defined, they're going to be defined somewhere outside of RDFa, and so if RDFa defines it own parallel list then it's going to get out of sync at some point
  93. # [09:49] <Philip`> s/it/its
  94. # [09:50] <mhausenblas> I guess the Java and other communities have experienced this for years and it seems to work fine
  95. # [09:50] <mhausenblas> I have absolutely no idea why people oppose namespaces (note: I'm not talking about XMLNS per se)
  96. # [09:53] * mhausenblas BRB, gotta grab some coffee ;)
  97. # [09:53] * Quits: sid0 (n=sid0@unaffiliated/sid0) (Read error: 104 (Connection reset by peer))
  98. # [09:55] * Joins: sid0 (n=sid0@unaffiliated/sid0)
  99. # [10:02] <hsivonen> mhausenblas: I meant semantically overlapping
  100. # [10:03] <hsivonen> Philip`: already got out of sync
  101. # [10:03] <hsivonen> (even for XHTML2!)
  102. # [10:03] <mhausenblas> hsivonen: ok. but I don't see the problem there
  103. # [10:04] <mhausenblas> take for example Goolge. they decided not to reuse the already available vocs such as FOAF, etc.
  104. # [10:04] <mhausenblas> fine. no problem. see for example http://iandavis.com/blog/2009/05/googles-rdfa-a-damp-squib#comment-1407
  105. # [10:05] <hsivonen> mhausenblas: some people who seem to care more about RDF than about RDFa cheerleading see it as a problem
  106. # [10:05] <hsivonen> mhausenblas: http://www.jenitennison.com/blog/node/104 (incl. comments)
  107. # [10:06] <mhausenblas> hsivonen: not sure if I understand this. RDFa is just an RDF serialisation
  108. # [10:07] <mhausenblas> yes, I know Jeni's post and have left my 0.02€ at http://lists.w3.org/Archives/Public/public-lod/2009May/0095.html
  109. # [10:07] <Philip`> It sounds like Google is using it as a serialisation of a non-RDF data format, rather than of RDF
  110. # [10:07] <Philip`> (and they're using microformats as a different serialisation of the same internal non-RDF data format)
  111. # [10:07] <mhausenblas> Philip`: there you might be right ;)
  112. # [10:08] <hsivonen> Philip`: indeed, but it's stille cheered as a success for RDFa. go figure
  113. # [10:08] <mhausenblas> the thing is: I'm interested in the Web of Data where data comes from whatever nicely machine-processable format
  114. # [10:09] <hsivonen> Philip`: anything that has the slightest appearance of using RDFa is cheered as a success, regardless of conformance or RDF model alignment
  115. # [10:09] <Philip`> hsivonen: Kind of like cheering when Google starts using "<!doctype html>" on some of their pages? :-)
  116. # [10:10] <hsivonen> Philip`: cheering for just the privacy page is embarrassing
  117. # [10:10] <othermaciej> it does seem like there is some degree of fanboyism around RDFa
  118. # [10:10] <hsivonen> Philip`: but at least it validated as HTML5 instead of just using the doctype
  119. # [10:10] <othermaciej> like excitement about its superficial aspects instead of about the goals it is meant to achieve
  120. # [10:11] <mhausenblas> hsivonen: IIRC the microformats community even had a party celebrating it, but this is not the point (and I don't care)
  121. # [10:11] <othermaciej> I'll be excited when Web pages use new HTML5 tags/attributes/APIs
  122. # [10:12] <hsivonen> mhausenblas: celebrating what?
  123. # [10:12] <othermaciej> the doctype is not remotely exciting
  124. # [10:12] <mhausenblas> hsivonen: that Google supports microformats
  125. # [10:12] <Philip`> It seems there's some degree of fanboyism around every technology
  126. # [10:12] <hsivonen> mhausenblas: wow
  127. # [10:13] <mhausenblas> to be fair Gentlemen, I think each and everyone of us who has invested couple of years into a technology is happy when there is an uptake
  128. # [10:13] <mhausenblas> saying this is not the case is a simply dishonest
  129. # [10:13] <othermaciej> I like it when people use WebKit
  130. # [10:13] <mhausenblas> s/is a/is
  131. # [10:13] <Philip`> I guess it still could be useful for each group to point out the unjustified fanboyism of each other group, even if we're all doing it
  132. # [10:13] <mhausenblas> Philip`: +1
  133. # [10:14] <othermaciej> but I have distinctly mixed feelings if they use it in a way where they make significant changes which they don't contribute back
  134. # [10:14] <othermaciej> I think what's most important is to be aware of your own unjusfified fanboyism
  135. # [10:14] <othermaciej> and try to keep it from influencing technical decisions in a bad way
  136. # [10:14] <Philip`> It seems the kind of situation that makes self-awareness difficult, which is why it's helpful to have other people point it out
  137. # [10:17] <Philip`> (...though preferably in a way that's not too rude or condescending, I guess)
  138. # [10:17] <mhausenblas> as for me I just say: whatever data comes in there I'm happy (bonus if it links to other data, as this is the Web, right?)
  139. # [10:17] <mhausenblas> two examples: just started reading the wonderful RESTful Web Services book - awesome. so much useful stuff in it (and I see perfectly how linked data connects to it)
  140. # [10:17] <mhausenblas> other example: started to work with Erik on RESTful RDF (http://dret.typepad.com/dretblog/2009/05/rest-and-rdf-granularity.html)
  141. # [10:18] <mhausenblas> Philip`: yes. being polite and honest doesn't exclude each other ;)
  142. # [10:20] <mhausenblas> ok, back to some hacking ... cya laters
  143. # [10:24] * Quits: sid0 (n=sid0@unaffiliated/sid0) (Read error: 104 (Connection reset by peer))
  144. # [10:25] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  145. # [10:26] * Joins: sid0 (n=sid0@unaffiliated/sid0)
  146. # [10:31] <othermaciej> "These are the kind of pipe dreams that I used to ridicule semantic web folk about back before they body-snatched me!"
  147. # [10:31] <othermaciej> now that's a high degree of self-awareness
  148. # [10:32] * Quits: sid0 (n=sid0@unaffiliated/sid0) (Read error: 104 (Connection reset by peer))
  149. # [10:33] * Joins: sid0 (n=sid0@unaffiliated/sid0)
  150. # [10:47] * Joins: ROBOd (n=robod@89.122.216.38)
  151. # [10:53] * Quits: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  152. # [11:03] * Joins: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  153. # [11:11] <mhausenblas> (just FYI, the discussion here earlier motivated me to do a quick write-up for starting to collect RDF anti-patterns)
  154. # [11:11] <mhausenblas> see http://chatlogs.planetrdf.com/swig/2009-05-24.html#T09-00-52
  155. # [11:11] <mhausenblas> (back to hacking now, really ;)
  156. # [11:12] * Quits: sid0 (n=sid0@unaffiliated/sid0) (Remote closed the connection)
  157. # [11:16] * Joins: wakaba_ (n=wakaba@EM114-51-174-37.pool.e-mobile.ne.jp)
  158. # [11:34] * Quits: wakaba (n=wakaba@EM114-51-23-205.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  159. # [12:23] * Joins: akamike (n=mikerobi@92.2.117.242)
  160. # [12:32] * Quits: akamike (n=mikerobi@92.2.117.242)
  161. # [12:59] * Joins: tndH (n=Rob@james-baillie-pc083-229.student-halls.leeds.ac.uk)
  162. # [13:00] <annevk42> othermaciej, am now
  163. # [13:01] <othermaciej> annevk42: I was going to ask you to remind me how to check out and generate the Design Principles draft
  164. # [13:01] <othermaciej> I don't think I have a checkout of the spec here
  165. # [13:05] <annevk42> http://dev.w3.org/cvsweb/
  166. # [13:06] <annevk42> it's in html5/html-design-principles
  167. # [13:06] <annevk42> you want to edit Overview.src.html
  168. # [13:07] <annevk42> mhausenblas, nofollow is defined in the HTML5 spec itself
  169. # [13:07] <annevk42> mhausenblas, so it doesn't need to be on RelExtensions
  170. # [13:07] <mhausenblas> ok
  171. # [13:12] * Joins: annevk4 (n=annevk@5ED2D22C.cable.ziggo.nl)
  172. # [13:15] <othermaciej> what's the right place to send EventSource feedback?
  173. # [13:15] <annevk42> public-webapps@w3.org
  174. # [13:36] <othermaciej> hmm I can't seem to remember my w3c cvs password
  175. # [13:37] <othermaciej> guess I'll have to ask a cvs admin for help
  176. # [13:40] <annevk42> it works with an ssh keypair or whatever that's called
  177. # [13:43] * Joins: shepazutoo (n=schepers@adsl-144-163-109.rmo.bellsouth.net)
  178. # [14:00] * Quits: shepazu (n=schepers@adsl-144-137-232.rmo.bellsouth.net) (Read error: 113 (No route to host))
  179. # [14:01] * Quits: gsnedders (n=gsnedder@host86-165-92-13.range86-165.btcentralplus.com)
  180. # [14:04] * Joins: hdh (n=hdh@58.187.200.79)
  181. # [14:16] * Quits: zdobersek1 (n=zan@cpe-92-37-69-40.dynamic.amis.net) (Remote closed the connection)
  182. # [14:16] * Joins: maikmerten (n=maikmert@BAB9417.bab.pppool.de)
  183. # [14:21] * Joins: zdobersek (n=zan@cpe-92-37-69-40.dynamic.amis.net)
  184. # [14:35] * Joins: gsnedders (n=gsnedder@host86-165-92-13.range86-165.btcentralplus.com)
  185. # [14:39] * Quits: gsnedders (n=gsnedder@host86-165-92-13.range86-165.btcentralplus.com) (Client Quit)
  186. # [14:54] * Joins: gsnedders (n=gsnedder@host86-139-222-254.range86-139.btcentralplus.com)
  187. # [14:56] * gsnedders wonders why the wifi has been so slow
  188. # [14:56] <gsnedders> Suddenly it jumped just as I said that from 10 to 200 KB/s
  189. # [14:56] <gsnedders> And back down
  190. # [14:57] * Joins: riven` (n=colin@53525B67.cable.casema.nl)
  191. # [14:57] * gsnedders is trying to download the spec :P
  192. # [14:58] * Quits: riven (n=colin@pdpc/supporter/professional/riven) (Nick collision from services.)
  193. # [14:58] * riven` is now known as riven
  194. # [15:01] <hsivonen> whoa Anolis adds more bytes than the split-out sections take away
  195. # [15:02] <gsnedders> Back down to a number of bytes per second
  196. # [15:04] * Quits: hdh (n=hdh@58.187.200.79) (Remote closed the connection)
  197. # [15:05] * Joins: hdh (n=hdh@58.187.200.79)
  198. # [15:06] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  199. # [15:10] * Joins: gsnedders_ (n=gsnedder@host86-164-130-180.range86-164.btcentralplus.com)
  200. # [15:10] * Quits: gsnedders (n=gsnedder@host86-139-222-254.range86-139.btcentralplus.com) (Nick collision from services.)
  201. # [15:10] * gsnedders_ is now known as gsnedders
  202. # [15:17] * Joins: myakura (n=myakura@p3087-ipbf6705marunouchi.tokyo.ocn.ne.jp)
  203. # [15:36] <hsivonen> Hixie: increased the limit to 4 MB
  204. # [15:39] * Quits: Kuruma (n=Kuruman@p2085-ipbf3401hodogaya.kanagawa.ocn.ne.jp) (Read error: 104 (Connection reset by peer))
  205. # [15:41] * Joins: Kuruma (n=Kuruman@p2085-ipbf3401hodogaya.kanagawa.ocn.ne.jp)
  206. # [15:49] <karlcow> [04:06] <othermaciej> it does seem like there is some degree of fanboyism around RDFa
  207. # [15:49] <karlcow> s/RDFa/whatwg|html5|hixie|$fan/ ($fan = pick your own fav topics of a community), which makes the sentence stupid
  208. # [15:49] <karlcow> [04:08] <Philip`> It seems there's some degree of fanboyism around every technology
  209. # [15:49] <karlcow> fully agreed.
  210. # [15:57] * Quits: gsnedders (n=gsnedder@host86-164-130-180.range86-164.btcentralplus.com)
  211. # [15:58] * Quits: karlcow (n=karl@nerval.la-grange.net) ("This computer has gone to sleep")
  212. # [16:01] * Quits: drry (n=drry@dd25.opt2.point.ne.jp) ("Tiarra 0.1+svn-33535: SIGTERM received; exit")
  213. # [16:02] * Joins: drry (n=drry@dd25.opt2.point.ne.jp)
  214. # [16:06] * Joins: gsnedders (n=gsnedder@host86-164-130-180.range86-164.btcentralplus.com)
  215. # [16:18] <Philip`> karlcow: It doesn't make the sentence stupid, it just makes it less general than it perhaps should be
  216. # [16:19] * Joins: mpt_ (n=mpt@80.67.104.102)
  217. # [16:24] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 110 (Connection timed out))
  218. # [16:27] * gsnedders guesses he ought to do school work again
  219. # [16:27] * gsnedders sighs
  220. # [16:33] <annevk4> /whois Hixie
  221. # [16:34] * annevk4 tries to figure out why HTTP is no longer functioning
  222. # [16:35] * Joins: weinig (n=weinig@cpe-76-173-121-31.socal.res.rr.com)
  223. # [16:37] * Quits: weinig (n=weinig@cpe-76-173-121-31.socal.res.rr.com) (Read error: 60 (Operation timed out))
  224. # [16:39] * gsnedders wonders what IRI to use for atom:category@scheme in a spec
  225. # [16:40] * Joins: zcorpan_ (n=zcorpan@c83-252-196-43.bredband.comhem.se)
  226. # [16:40] <zcorpan_> ... he refers to a note from Simon Pieters
  227. # [16:40] <zcorpan_> ... I am sure we addressed that."
  228. # [16:41] <zcorpan_> i have not received a reply to the email that björn cited
  229. # [16:47] * Joins: wakaba (n=wakaba@EM114-51-16-148.pool.e-mobile.ne.jp)
  230. # [16:49] * Quits: wakaba_ (n=wakaba@EM114-51-174-37.pool.e-mobile.ne.jp) (Read error: 60 (Operation timed out))
  231. # [16:53] * Joins: karlcow (n=karl@nerval.la-grange.net)
  232. # [16:56] * Quits: mpt_ (n=mpt@canonical/launchpad/mpt) (Read error: 110 (Connection timed out))
  233. # [16:59] * Joins: mpilgrim_ (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com)
  234. # [17:00] * Joins: itpastorn1 (n=itpastor@139.57.227.87.static.th.siw.siwnet.net)
  235. # [17:18] * Quits: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com) (Read error: 110 (Connection timed out))
  236. # [17:18] * Quits: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net) (Read error: 110 (Connection timed out))
  237. # [17:18] <gsnedders> Nice. Back down to 50% test cases failing.
  238. # [17:23] * Joins: mlpug (n=mlpug@a88-115-171-214.elisa-laajakaista.fi)
  239. # [17:25] * Joins: mpt_ (n=mpt@canonical/launchpad/mpt)
  240. # [17:26] * mpt_ is now known as mpt
  241. # [17:30] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Client Quit)
  242. # [17:30] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  243. # [17:34] * Joins: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  244. # [17:50] * Parts: zcorpan_ (n=zcorpan@c83-252-196-43.bredband.comhem.se)
  245. # [17:52] * jgraham wonders if he has missed anything, sees a depressing amount of email
  246. # [17:54] * Quits: annevk42 (n=annevk@5ED2D22C.cable.ziggo.nl) (Read error: 104 (Connection reset by peer))
  247. # [17:54] * Quits: annevk4 (n=annevk@5ED2D22C.cable.ziggo.nl) (Read error: 104 (Connection reset by peer))
  248. # [17:55] * Joins: annevk42 (n=annevk@5ED2D22C.cable.ziggo.nl)
  249. # [17:56] * Joins: shepazu (n=schepers@adsl-144-163-109.rmo.bellsouth.net)
  250. # [18:10] * Joins: annevk4 (n=annevk@5ED2D22C.cable.ziggo.nl)
  251. # [18:14] * Quits: shepazutoo (n=schepers@adsl-144-163-109.rmo.bellsouth.net) (Read error: 110 (Connection timed out))
  252. # [18:19] * gsnedders is thankful html5lib has so many test cases with how much he's broken it
  253. # [18:26] <jgraham> gsnedders: Did anyone ever tell you that the order of the errors isn't significant in the tokenizer tests
  254. # [18:26] <gsnedders> jgraham: No
  255. # [18:26] <jgraham> Oh well they should have done
  256. # [18:26] <jgraham> At least I think that is true
  257. # [18:26] <gsnedders> This doesn't account for 500 test cases failing, though :D
  258. # [18:27] <jgraham> No. But It might account for some ailing sonce you fix the major issues
  259. # [18:27] <gsnedders> I think it fixed one, the order of errors.
  260. # [18:33] <jgraham> Philip`: I plan to implement microdata-to-*
  261. # [18:34] * gsnedders gets down to 61 errors
  262. # [18:35] <gsnedders> Huh. Somehow it goes from afterAttributeValueQuoted to attributeName
  263. # [18:37] <gsnedders> Oh, wait. I hadn't re-run the tests since I fixed that illogic.
  264. # [18:40] <gsnedders> And down to 25…
  265. # [18:57] <Philip`> jgraham: I told him that the order of errors isn't significant when the test case has ignoreErrorOrder:true or whatever it is
  266. # [19:04] <gsnedders> Which is different to what jgraham asked.
  267. # [19:05] * Quits: hdh (n=hdh@58.187.200.79) (Remote closed the connection)
  268. # [19:09] <Philip`> gsnedders: Indeed
  269. # [19:09] <Philip`> The idea is that the tests which don't have ignoreErrorOrder ought to have predictable error order in any sane implementation, so you should test the order in order to detect bugs, though technically it's not required by the spec
  270. # [19:14] <gsnedders> 2000 line diff. Fun.
  271. # [19:15] * jgraham notes that a PHP implementation might not be considered sane :)
  272. # [19:16] * gsnedders agrees
  273. # [19:17] * gsnedders has been adding things to his post entitled "PHP Grievances" while working on html5lib over the past few days :)
  274. # [19:22] <gsnedders> Philip`: Oh, and re: yesterday, there is look-behind in the data-state.
  275. # [19:23] * Quits: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  276. # [19:25] <takkaria> gsnedders: there doesn't have to be
  277. # [19:25] <gsnedders> There isn't in Python or PHP implementations, dunno about Ruby…
  278. # [19:25] <gsnedders> takkaria: And seeming I just changed the PHP impl. to be like that… :D
  279. # [19:25] <gsnedders> http://code.google.com/p/html5lib/source/detail?r=2aa8163f5b86662263bd609f81e40c324d574e42
  280. # [19:26] <takkaria> I wonder what we did in hubbub for that
  281. # [19:27] * Quits: karlcow (n=karl@nerval.la-grange.net) ("This computer has gone to sleep")
  282. # [19:28] <takkaria> oh yeah
  283. # [19:29] <takkaria> basically, hubbub uses an inputstream which doesn't support ungetting or peeking backward
  284. # [19:30] <gsnedders> Ow.
  285. # [19:30] <takkaria> acutally it's a highly efficient implementation
  286. # [19:30] <takkaria> we have a current position in the inputstream and then we have an offset number of bytes we are into the buffer
  287. # [19:31] <gsnedders> Oh, sure. But it's not going to be fun to implement parts of the spec with :)
  288. # [19:31] <takkaria> indeed not
  289. # [19:31] <takkaria> but it's not much pain really
  290. # [19:32] * Joins: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  291. # [19:32] * Quits: myakura (n=myakura@p3087-ipbf6705marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  292. # [19:36] * Quits: mhausenblas (n=mhausenb@wg1-nat.fwgal01.deri.ie)
  293. # [19:39] * Joins: wakaba_ (n=wakaba@EM114-51-129-12.pool.e-mobile.ne.jp)
  294. # [19:43] <gsnedders> So splitting out the input stream was around a 0.1s hit when tokenizing the spec
  295. # [19:43] <gsnedders> (Now around 6.1s)
  296. # [19:45] * Quits: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  297. # [19:48] * Quits: wakaba (n=wakaba@EM114-51-16-148.pool.e-mobile.ne.jp) (Read error: 60 (Operation timed out))
  298. # [20:09] <takkaria> that's not terrible
  299. # [20:12] <Philip`> gsnedders: Oh, I forgot about that bit
  300. # [20:12] <Philip`> but it's only four characters, and only needed in rare circumstances, so it's not much of a problem to add a special look-behind buffer
  301. # [20:13] * Philip` supposes it'd be possible to optimise it to a single int keeping track of the state, instead of keeping all the characters
  302. # [20:13] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 110 (Connection timed out))
  303. # [20:16] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
  304. # [20:18] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  305. # [20:25] * Joins: cgriego (n=cgriego@cpe-72-181-202-225.tx.res.rr.com)
  306. # [20:29] <takkaria> it largely depends on how performant string manipulation is in PHP
  307. # [20:31] * hsivonen notes that the tokenizer can be implemented without lookagead or lookbehind
  308. # [20:31] <hsivonen> *lookahead
  309. # [20:31] <takkaria> at some point I should really look at the v.nu parser and see how you remove lookahead
  310. # [20:32] <takkaria> because I can imagine it being a fairly decent performance benefit
  311. # [20:46] * Quits: maikmerten (n=maikmert@BAB9417.bab.pppool.de) ("Leaving")
  312. # [21:03] <gsnedders> takkaria: Basically, I think the biggest limit when dealing with the data state is going to be function call overhead.
  313. # [21:03] <gsnedders> takkaria: Function call overhead is a non-negilable amount of time when tokenizing the spec, so basically have to rely as much as possible on language constructs and not functions.
  314. # [21:05] <Philip`> Write the whole parser as a single giant regular expression, then you won't have any non-native function calls
  315. # [21:10] <gsnedders> Philip`: "The maximum length of a compiled pattern is 65539 (sic) bytes if PCRE
  316. # [21:10] <gsnedders> is compiled with the default internal linkage size of 2."
  317. # [21:10] <gsnedders> Philip`: Also: "All values in repeating quantifiers must be less than 65536."
  318. # [21:14] <takkaria> gsnedders: I'm sure that the function call overhead is a pretty big portion, but string use will be a factor
  319. # [21:14] <takkaria> hubbub tries to delay string handling to as late as possible by using counters and indexes into buffers instead of doing string ops
  320. # [21:14] <takkaria> and then does the string ops when tokens are emitted
  321. # [21:15] <takkaria> I dunno, it just might be an avenue you could look at if you're intending on optimising further
  322. # [21:15] <gsnedders> http://stuff.gsnedders.com/phphtml5lib.pdf
  323. # [21:15] <gsnedders> takkaria: We work one byte at a time
  324. # [21:15] <gsnedders> takkaria: (Basically, we use a single byte long string)
  325. # [21:15] <Philip`> Do you have anything like charsUntil?
  326. # [21:16] <Philip`> (from Python's html5lib)
  327. # [21:16] <gsnedders> Philip`: Yes
  328. # [21:16] <Philip`> Does that work one byte at a time?
  329. # [21:16] <gsnedders> No
  330. # [21:16] <gsnedders> Well, I guess within PHP it does :P
  331. # [21:16] <gsnedders> (Actually, I think PHP just uses libc for strspn, so within libc it does)
  332. # [21:17] <Philip`> Okay, so when you say you work one byte at a time I should ignore you :-)
  333. # [21:17] <gsnedders> Look at that graph: the big drop was when I added that.
  334. # [21:17] <gsnedders> Apart from when we grab a lot of stuff at once, we work one byte at a time :D
  335. # [21:33] * Joins: ap (n=ap@194.154.88.39)
  336. # [21:42] * Joins: weinig (n=weinig@cpe-76-173-121-31.socal.res.rr.com)
  337. # [21:57] * Quits: itpastorn1 (n=itpastor@139.57.227.87.static.th.siw.siwnet.net) ("Leaving.")
  338. # [22:00] * Quits: mlpug (n=mlpug@a88-115-171-214.elisa-laajakaista.fi) (Remote closed the connection)
  339. # [22:00] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  340. # [22:05] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  341. # [22:07] * Joins: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  342. # [22:23] * Quits: weinig (n=weinig@cpe-76-173-121-31.socal.res.rr.com)
  343. # [22:27] * Joins: jacobolus (i=8cf71733@gateway/web/ajax/mibbit.com/x-15a423e7ec0da0e8)
  344. # [22:44] * Quits: jacobolus (i=8cf71733@gateway/web/ajax/mibbit.com/x-15a423e7ec0da0e8) ("http://www.mibbit.com ajax IRC Client")
  345. # [22:45] * Quits: zdobersek (n=zan@cpe-92-37-69-40.dynamic.amis.net) (Read error: 104 (Connection reset by peer))
  346. # [22:54] * Quits: ap (n=ap@194.154.88.39)
  347. # [22:59] * Joins: wakaba (n=wakaba@EM114-51-0-255.pool.e-mobile.ne.jp)
  348. # [23:12] * Joins: remysharp (n=remyshar@static-88.131.106.162.addr.tdcsong.se)
  349. # [23:13] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Ex-Chat")
  350. # [23:13] <Philip`> Does SGML precisely define some concept like case-insensitivity?
  351. # [23:19] * Quits: remysharp (n=remyshar@static-88.131.106.162.addr.tdcsong.se) ("Gotta shoot - peeyaow!")
  352. # [23:19] * Quits: wakaba_ (n=wakaba@EM114-51-129-12.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  353. # [23:21] * Joins: karlcow (n=karl@nerval.la-grange.net)
  354. # [23:22] * Quits: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  355. # [23:26] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
  356. # [23:28] * Joins: Rik` (n=Rik@pha75-2-81-57-187-57.fbx.proxad.net)
  357. # [23:54] * Quits: fakeolliej (n=oliver@17.246.17.145)
  358. # Session Close: Mon May 25 00:00:00 2009

The end :)