/irc-logs / freenode / #whatwg / 2008-02-10 / end

Options:

  1. # Session Start: Sun Feb 10 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:00] <kig> aah, perl html parser
  4. # [00:00] <kig> nm
  5. # [00:01] <gsnedders> kig: no, a perl parser that creates an OCaml HTML parser
  6. # [00:01] <gsnedders> (the perl parser uses regex to parse the HTML5 spec, IIRC)
  7. # [00:03] <Philip`> It's a Perl script that parses the HTML5 spec to generate an OCaml representation of the script, which can be executed directly in OCaml or can (soon) be compiled down into Perl code to implement an HTML5 parser (and also C++ and JS etc)
  8. # [00:03] <Philip`> s/of the script/of the parser algorithm/
  9. # [00:04] <Philip`> It's basically just http://lists.w3.org/Archives/Public/public-html/2007Jul/1103.html but for the tree construction stage too
  10. # [00:30] * Quits: Ketsuban (n=ketsuban@cpc2-oxfd8-0-0-cust335.oxfd.cable.ntl.com) ("all I want to do is be a full time online furry")
  11. # [00:32] * Joins: webben (n=benh@82.152.229.45)
  12. # [00:56] * Quits: psa (n=yomode@71.93.19.66) (Remote closed the connection)
  13. # [01:03] * Quits: virtuelv_ (n=virtuelv@ti132110a341-0704.bb.online.no) ("Leaving")
  14. # [01:11] <Philip`> Hmm, is html5.org dead?
  15. # [01:14] <Philip`> http://canvex.lazyilluminati.com/misc/insertion_modes.svg (red = error transition; blue = non-error reprocess-as-if transition; black = non-error permanent transition)
  16. # [01:14] <Philip`> with only a small number of known bugs in there
  17. # [01:14] <Hixie> i love anne's comment on <canvas>:
  18. # [01:15] <Hixie> "The section should be more clear what it means by image. ..."
  19. # [01:15] <Hixie> which section?
  20. # [01:15] <Hixie> that's how the e-mail starts. which fricking section???
  21. # [01:15] <Philip`> The canvas section? :-)
  22. # [01:16] <Hixie> that doesn't help much :-P
  23. # [01:16] <Hixie> maybe he means 3.14.11.3. Security with canvas elements
  24. # [01:16] <Hixie> i think i must have fixed this comment already
  25. # [01:18] <Hixie> maybe he means the origin section itself?
  26. # [01:19] <Philip`> (Aha, html5.org is back, hence http://philip.html5.org/misc/insertion-modes.svg )
  27. # [01:20] <Hixie> safari fails at that image.
  28. # [01:20] <Hixie> hat's red?
  29. # [01:20] <Hixie> parse error?
  30. # [01:20] <Hixie> how abotu blue?
  31. # [01:20] <Philip`> red = error transition; blue = non-error reprocess-as-if transition; black = non-error permanent transition
  32. # [01:21] <Hixie> brb, intermission shift.
  33. # [01:34] * Joins: jgraham (n=james@81-86-208-197.dsl.pipex.com)
  34. # [01:38] * Quits: jgraham (n=james@81-86-208-197.dsl.pipex.com) (Client Quit)
  35. # [01:39] * Joins: tantek (n=tantek@pool-71-105-213-62.lsanca.dsl-w.verizon.net)
  36. # [01:40] <Hixie> Philip`: cool
  37. # [01:41] <Hixie> Philip`: looks like you have some missing. e.g. EOF in a number of the main phase cases
  38. # [01:41] <Hixie> in fact _BeforeHead has only one exiting arrow
  39. # [01:41] <Hixie> which seems unlikely
  40. # [01:42] <Philip`> EOF doesn't explicitly transition to any insertion mode, which is why it isn't shown
  41. # [01:42] <Hixie> ah ok
  42. # [01:43] <Philip`> It might do transitions while generating implied end tags, but those will be a subset of the transitions that are already shown
  43. # [01:43] <Hixie> the transitions for a single character "X" seem wrong
  44. # [01:43] <Hixie> initial phase -> root element -> _beforehead -> ?
  45. # [01:44] <Philip`> ...and it might do transitions when acting as if there were new start/end tags
  46. # [01:44] <Hixie> aaah
  47. # [01:44] <Hixie> you should show those too :-)
  48. # [01:45] <Philip`> In BeforeHead it does some internal magic (like pretending there's a <head>) and then performs the only possible transition to InHead
  49. # [01:46] <Hixie> makes sense
  50. # [01:46] <Philip`> Duplicate the "Start tag [head]" arrow and call it "Character not [...]" etc for each act-as-if-a-start-tag-named-head bit?
  51. # [01:48] <Hixie> or just put an asterisk next to the transitions that happen due to other cases
  52. # [01:48] <Hixie> labelled "* Also happens due to other tokens" or something
  53. # [01:48] <Hixie> or "* May be implied"
  54. # [01:49] * Joins: othermaciej (n=mjs@mbc0f36d0.tmodns.net)
  55. # [01:52] <Philip`> http://philip.html5.org/misc/insertion-modes-2.svg handles act-as-if-start-tag
  56. # [01:54] <Philip`> Hmm, stack overflow if I try it with end tags
  57. # [01:57] <Philip`> ...because </p> can create a <p>, and <p> can create a </p>
  58. # [01:57] <Philip`> (in body)
  59. # [01:59] <Hixie> heh
  60. # [02:07] <Philip`> http://philip.html5.org/misc/insertion-modes-3.svg handles act-as-if-(start|end)-tag
  61. # [02:07] <Philip`> and is getting a little ugly :-(
  62. # [02:08] <Philip`> (It's intentional that <noscript> isn't handled, because I haven't translated that bit yet)
  63. # [02:09] * Quits: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  64. # [02:09] <Hixie> i think my asterisk idea wins :-P
  65. # [02:10] <Hixie> found any errors in the spec yet? :-D
  66. # [02:10] <othermaciej> so the "please don't dereference these http URIs" post from the w3c made it to reddit
  67. # [02:10] <Philip`> If I added asterisks, I'd have to add some way to delete duplicates, and that would require lines of code :-(
  68. # [02:10] <othermaciej> I am amazed how many people support the concept of using http URIs as opaque identifiers not meant to be dereferenced
  69. # [02:10] <Hixie> i think we clearly should learn from this that using URIs for things that are opaque identifiers not meant to be dereferenced is dumb
  70. # [02:10] <othermaciej> barely a moment's thought given to whether that might be a dumb idea in the first place
  71. # [02:11] <Hixie> Philip`: heh
  72. # [02:12] <Philip`> You can just look at http://philip.html5.org/misc/insertion-modes.svg and imagine a "..., or may be implied" beside each transition
  73. # [02:15] <Philip`> Hixie: There's a few things that don't entirely seem sensible in there (so I've sent mail to public-html), but I haven't tried looking hard for errors yet :-)
  74. # [02:16] * Philip` wants to create hundreds of thousands of test cases to see if all the parsers interoperate
  75. # [02:16] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  76. # [02:17] <Hixie> k
  77. # [02:25] <tantek> FWIW I'm quite firmly on the other side re: http URIs, in strong support of dereferenceable URLs (not a typo), e.g. for XMDP profiles.
  78. # [02:26] <othermaciej> a dereferencable URL for something meant to be dereferenced is fine
  79. # [02:26] <othermaciej> but an allegedly opaque identifier starting with "http:" and having the format of a URL is just dumb
  80. # [02:27] <tantek> IMHO a URI using the "http" protocol implies dereferencability.
  81. # [02:29] <othermaciej> that's certainly how it seems to most people
  82. # [02:30] <Dashiva> Any transfer protocol would be an odd choice for non-transfer, really
  83. # [02:32] <Philip`> <html xmlns="data:,w3.org XHTML"> - still a URI, still uses DNS for 'guaranteed' uniqueness and allows many distinct values for the same domain
  84. # [02:32] <tantek> agreed Dashiva. Any URI using a transfer protocol implies dereferenceability, and specs SHOULD NOT discourage dereferenceability of such URIs.
  85. # [02:33] <tantek> in fact, one might even say that specs which use URIs MUST NOT place additional such restrictions on the URIs, as that would be a layer violation.
  86. # [02:35] * Quits: tantek (n=tantek@pool-71-105-213-62.lsanca.dsl-w.verizon.net)
  87. # [02:58] * Quits: othermaciej (n=mjs@mbc0f36d0.tmodns.net)
  88. # [03:03] * Quits: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  89. # [03:30] * Quits: tndH (i=Rob@87.102.19.44) ("ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  90. # [03:51] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  91. # [04:41] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  92. # [05:06] <jruderman> will <video> work well for streaming formats?
  93. # [05:06] * Quits: Kuruma (n=Kuruman@h123-176-107-050.catv01.catv-yokohama.ne.jp) (Read error: 104 (Connection reset by peer))
  94. # [05:06] <jruderman> such as real-time porn cams
  95. # [05:07] * Joins: Kuruma (n=Kuruman@h123-176-107-050.catv01.catv-yokohama.ne.jp)
  96. # [05:07] * Quits: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  97. # [05:10] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net) ("durr...")
  98. # [05:11] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  99. # [05:11] * Joins: heycam (n=cam@ppp232-187.static.internode.on.net)
  100. # [05:11] * heycam is now known as heycam|sydney
  101. # [05:16] * Joins: roc (n=roc@121-72-11-14.dsl.telstraclear.net)
  102. # [06:43] * Quits: roc (n=roc@121-72-11-14.dsl.telstraclear.net)
  103. # [07:09] * Quits: enn (i=eli@dsl253-036-017.chi1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  104. # [07:10] * Joins: enn (i=eli@dsl253-036-017.chi1.dsl.speakeasy.net)
  105. # [08:13] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  106. # [09:08] * Joins: roc (n=roc@121-72-16-46.dsl.telstraclear.net)
  107. # [09:08] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  108. # [09:08] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  109. # [09:26] * Quits: DxSadEagle (n=maksim@kde/orlovich) (Remote closed the connection)
  110. # [09:26] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  111. # [09:38] * Joins: virtuelv (n=virtuelv@ti132110a341-2025.bb.online.no)
  112. # [09:40] * Quits: jwalden (n=waldo@RANDOM-THREE-O-EIGHT.MIT.EDU) (Remote closed the connection)
  113. # [09:42] * Joins: heycam (n=cam@ppp232-187.static.internode.on.net)
  114. # [09:54] * Quits: heycam|sydney (n=cam@ppp232-187.static.internode.on.net) (Read error: 110 (Connection timed out))
  115. # [09:54] * heycam is now known as heycam|sydney
  116. # [09:55] * Joins: mpt (n=mpt@222-155-10-198.jetstream.xtra.co.nz)
  117. # [10:17] <hsivonen> the idea of using URIs as identifiers rather than locators ignores the main affordance of URIs
  118. # [10:18] <hsivonen> in that sense, we should have stayed with URLs and the URI thing was a mistake
  119. # [10:19] * Joins: peepo (n=Jay@host86-129-186-34.range86-129.btcentralplus.com)
  120. # [10:22] * Quits: peepo (n=Jay@host86-129-186-34.range86-129.btcentralplus.com) (Client Quit)
  121. # [10:28] * Joins: ROBOd (n=robod@89.122.216.38)
  122. # [10:53] * Joins: jgraham (n=james@81-86-208-197.dsl.pipex.com)
  123. # [10:57] * Quits: jgraham (n=james@81-86-208-197.dsl.pipex.com) (Client Quit)
  124. # [11:31] * Quits: mpt (n=mpt@222-155-10-198.jetstream.xtra.co.nz) ("Leaving")
  125. # [12:01] * Quits: bzed (n=bzed@devel.recluse.de) (Remote closed the connection)
  126. # [12:23] * Joins: maikmerten (n=maikmert@Lba69.l.pppool.de)
  127. # [12:36] * Joins: bzed (n=bzed@devel.recluse.de)
  128. # [12:43] * Joins: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  129. # [12:48] * Joins: tndH_ (i=Rob@87.102.19.44)
  130. # [12:48] * tndH_ is now known as tndH
  131. # [13:44] <annevk> Philip`, is your parser faster than the Java parser?
  132. # [13:45] <Philip`> annevk: My C++ tokeniser was faster than the Java tokeniser (at least in the particular case that I was testing)
  133. # [13:46] <annevk> you haven't converted the OCaml parser to C++ yet?
  134. # [13:48] <Philip`> No, and the tree constructor part doesn't quite work in OCaml yet either
  135. # [13:51] <annevk> k
  136. # [14:17] * Quits: bzed (n=bzed@devel.recluse.de) ("leaving")
  137. # [14:17] * Joins: bzed (n=bzed@devel.recluse.de)
  138. # [14:46] * Quits: virtuelv (n=virtuelv@ti132110a341-2025.bb.online.no) ("Leaving")
  139. # [14:59] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  140. # [15:00] <zcorpan_> http://www.sitepoint.com/forums/showthread.php?t=531009
  141. # [15:28] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  142. # [15:46] * Joins: myakura (n=myakura@p2098-ipbf4207marunouchi.tokyo.ocn.ne.jp)
  143. # [15:51] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  144. # [15:53] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  145. # [16:08] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  146. # [16:09] * met_ just testing postMessage http://ejohn.org/apps/message/
  147. # [16:09] <gsnedders> the spec gen truly is bizarre.
  148. # [16:09] <met_> anyone knows why it doesn't work in opera?
  149. # [16:09] * met_ thougt Opera implemented postMessage already
  150. # [16:10] * Quits: maikmerten (n=maikmert@Lba69.l.pppool.de) (Remote closed the connection)
  151. # [16:12] <annevk> Opera implemented it on document instead of window
  152. # [16:12] <met_> oh
  153. # [16:12] <annevk> (this is changing)
  154. # [16:12] <met_> ok, I have missed thaht
  155. # [16:24] <gsnedders> Hixie: playing around with various concepts I have for implementing the spec-gen clone, it's gonna be quick. really quick.
  156. # [16:24] <gsnedders> (and by playing around I mean playing around with a DOM tree of the HTML 5 spec, so a really large doc)
  157. # [16:36] * Joins: myakura_ (n=myakura@p2098-ipbf4207marunouchi.tokyo.ocn.ne.jp)
  158. # [16:40] * Joins: jgraham (n=james@81-86-208-197.dsl.pipex.com)
  159. # [16:47] * Quits: myakura (n=myakura@p2098-ipbf4207marunouchi.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
  160. # [17:04] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  161. # [17:06] <annevk> Hixie, in http://lists.w3.org/Archives/Public/www-archive/2008Jan/0078.html you said you changed test 43 but it seems that you did not do that
  162. # [17:14] * Joins: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  163. # [17:46] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  164. # [18:15] * Joins: DxSadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  165. # [18:15] * Quits: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com) (Read error: 104 (Connection reset by peer))
  166. # [18:20] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  167. # [18:22] * Parts: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  168. # [18:31] * Joins: D2xSadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  169. # [18:37] * Quits: DxSadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com) (Read error: 110 (Connection timed out))
  170. # [18:47] * Joins: tndH_ (i=Rob@adsl-77-86-99-71.karoo.KCOM.COM)
  171. # [18:51] * Joins: maikmerten (n=maikmert@T76c0.t.pppool.de)
  172. # [18:59] * Joins: roc_ (n=roc@121-72-16-46.dsl.telstraclear.net)
  173. # [19:00] * Quits: roc (n=roc@121-72-16-46.dsl.telstraclear.net) (Read error: 104 (Connection reset by peer))
  174. # [19:06] * Quits: tndH (i=Rob@87.102.19.44) (Read error: 110 (Connection timed out))
  175. # [19:10] * Quits: maikmerten (n=maikmert@T76c0.t.pppool.de) (Remote closed the connection)
  176. # [19:11] * Joins: grimboy (n=grimboy@78-105-162-250.zone3.bethere.co.uk)
  177. # [19:17] * Joins: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net)
  178. # [19:21] * Joins: csarven- (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  179. # [19:37] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  180. # [19:38] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  181. # [19:39] * Quits: csarven- (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  182. # [20:06] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  183. # [20:12] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  184. # [20:19] * Quits: roc_ (n=roc@121-72-16-46.dsl.telstraclear.net)
  185. # [20:25] * Quits: gsnedders (n=gsnedder@host86-151-228-75.range86-151.btcentralplus.com) ("Partying in teh intarwebs")
  186. # [20:26] * Quits: jgraham (n=james@81-86-208-197.dsl.pipex.com) ("I get eaten by the worms")
  187. # [20:28] * Joins: jgraham (n=james@81-86-208-197.dsl.pipex.com)
  188. # [20:30] * Quits: jgraham (n=james@81-86-208-197.dsl.pipex.com) (Client Quit)
  189. # [20:31] <Hixie> annevk: as far as i can tell i did; what's not fixed?
  190. # [20:35] <Philip`> Hmm... Opera has a feature to import bookmarks from Firefox
  191. # [20:36] <Philip`> Firefox 3 stores bookmarks in an SQLite database
  192. # [20:36] <Philip`> Hence, Opera will have to include SQLite so that it can continue to import from Firefox
  193. # [20:36] * D2xSadEagle can't say he blames FF people for using something like SQLite.
  194. # [20:36] <D2xSadEagle> though don't they always run only one process? Cheaters :p
  195. # [20:37] <Philip`> Since it already has to pay the code-size and integration cost of SQLite, it will cost approximately nothing extra to support client-side database storage in a way that's compatible with Firefox
  196. # [20:37] <Philip`> And so the world will be happy and interoperable, which is good
  197. # [20:38] <Hixie> it frightens me that Julian is arguing that servers don't assume that a missing Referer means that the request should be allowed
  198. # [20:38] <Philip`> (And any other browser that wants to attract Firefox users will have to offer a similar import feature, and so will have to have SQLite too)
  199. # [20:39] <Dashiva> Philip`: Well, that all assumes FF3 will be released before DNF :)
  200. # [20:40] * Hixie wonders how to respond to someone who has such a feeble grasp of the realities of deployed content
  201. # [20:41] <Philip`> Hixie: If they do assume that, it should be easy to give some examples of open source code with that assumption
  202. # [20:42] <Philip`> It seems the much more common situation (mainly to avoid image hot-linking) is for servers to assume a non-missing different-origin Referer means the request should be denied
  203. # [20:42] <Philip`> (which isn't the same as assuming a missing Referer means the request should be trusted)
  204. # [20:43] <Hixie> right
  205. # [20:43] <Philip`> (because nothing particularly bad happens when someone hot-links an image and 1% of users don't send Referer and therefore don't get redirected to a rude message)
  206. # [20:44] <Hixie> feel free to point him to code doing this if you know of any
  207. # [20:44] <Philip`> I don't know of any
  208. # [20:44] <Hixie> yeah me either
  209. # [20:44] <Hixie> i just know it's very common :-)
  210. # [20:44] <Philip`> You're the one arguing that servers do make assumptions :-p
  211. # [20:45] <hsivonen> b.m.o at least used to block slashdot referers but allows no referer
  212. # [20:45] <Philip`> and arguing without evidence is not very convincing :-)
  213. # [20:45] <webben> What does Apache do by default?
  214. # [20:45] <hsivonen> webben: just logs the referer
  215. # [20:46] <webben> IIS?
  216. # [20:46] <Hixie> Philip`: indeed
  217. # [20:46] <Dashiva> Philip`: My image leech prevention script assumes a missing referer is local
  218. # [20:46] <Hixie> guess i'll have to do more research
  219. # [20:46] <Dashiva> It's not open source, though
  220. # [20:47] <Hixie> time to go to the rehearsal though
  221. # [20:47] <Hixie> bbl
  222. # [20:47] <Philip`> hsivonen: b.m.o isn't blocking certain referrers in order to avoid CSRF, so it's not really relevant to the argument about no-referrer pings being bad for security
  223. # [20:47] <Philip`> and the same for all the image leech prevention scripts
  224. # [20:48] <hsivonen> Philip`: using Referer for security purposes seems like a very brittle and RFC 2616-incompliant idea to me
  225. # [20:49] <Philip`> hsivonen: If we assumed people were sensible, then that would mean people wouldn't use Referer for security purposes, and so there's no danger in sending pings with no Referer
  226. # [20:50] <hsivonen> which one of Julian's messages are we talking about?
  227. # [20:50] <Philip`> I think the first paragraph of http://lists.w3.org/Archives/Public/public-html/2008Feb/0164.html
  228. # [20:57] <Philip`> http://google.com/codesearch?q=show:J2QBLfV3jjo:NRV5Vj3R4SI:1curwdNzfbk&cs_p=ftp://t3domains.de/pub/TYPO3-complete-package/current-version/yamlt3-V4.5.0.zip&cs_f=yamlt3/typo3/sysext/cms/tslib/class.tslib_fe.php#l2106
  229. # [20:57] <hsivonen> hmm. using Referer as an anti-CSRF mechanism still seems like a very bad idea unless it is merely used as an optimization in a mechanism that actuallly works
  230. # [20:57] <Philip`> That's something that prevents email form submission if the Referer is wrong or missing
  231. # [20:59] * tndH_ is now known as tndH
  232. # [21:00] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  233. # [21:01] <tndH> Philip`: lucky for them, fx3 exports its bookmarks to an html file on shutdown ;)
  234. # [21:03] <Philip`> http://google.com/codesearch?q=show:H3ulLINfCo0:QkWYPi2-xVM:o8NYFfBdVkY&cs_p=http://freshmeat.net/redir/punbb/46741/url_tgz/punbb-1.2.15.tar.gz&cs_f=punbb-1.2.15/upload/include/functions.php#l671
  235. # [21:03] <Philip`> That also prevents things if Referer is wrong or missing
  236. # [21:08] <Philip`> http://google.com/codesearch?q=show:BILmTBaOV7w:J2LE5gqHQ64:eBTzqE7cT8s&cs_p=http://wphooks.flatearth.org&cs_f=hooks/check_admin_referer/-001#first
  237. # [21:08] <Philip`> There's another one
  238. # [21:08] <Philip`> So I still haven't seen one that thinks missing referer means the request can be trusted...
  239. # [21:11] <Philip`> tndH: Oh :-(
  240. # [21:12] <Philip`> http://google.com/codesearch?q=show:cFRMv4O2bGI:eriQ8VkTUd4:dQQ6OTNA-Bs&cs_p=https://svn.radicaldesigns.org/amp/trunk&cs_f=punbb/admin_options.php#l41
  241. # [21:12] <Philip`> That also rejects missing referer
  242. # [21:13] * Quits: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  243. # [21:14] <Philip`> http://google.com/codesearch?q=show:2v0x4p249hg:NM4BWguMEFY:lqNJFi-SHlc&cs_p=http://scoop.kuro5hin.org/dist/releases/scoop_1.1.7.tar.gz&cs_f=scoop-1.1.7/lib/Scoop/Admin.pm#l8
  244. # [21:17] * Joins: roc (n=roc@202.0.36.64)
  245. # [21:20] <Philip`> http://google.com/codesearch?q=show:aVoQhiwqoGk:-V6ZnWGm9lc:vBMeJnZMb1M&cs_p=http://www.dcscripts.com/localFTP/gdcf625.tar.gz&cs_f=./dcf625/cgi-bin/dcforum/dcboard.cgi#l344
  246. # [21:21] * Philip` gives up looking
  247. # [21:21] <Philip`> So, I still don't have any evidence that sending requests with a missing Referer is going to introduce security issues in existing software
  248. # [21:22] <Philip`> (though obviously I also don't have any evidence that it isn't)
  249. # [21:25] <Philip`> hsivonen: Do you know of some specific anti-CSRF mechanisms that do work?
  250. # [21:26] * Philip` is currently unable to think of any
  251. # [21:29] <Philip`> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3Evar%20xhr%3Dnew%20XMLHttpRequest()%3Bxhr.open(%27GET%27%2C%20%27https%3A%2F%2Fmail.google.com%2Fmail%2F%3Flogout%26hl%3Den-GB%27)%3Bxhr.send(null)%3C%2Fscript%3E
  252. # [21:29] <Philip`> In Firefox 3, that doesn't work very happily
  253. # [21:30] <Philip`> presumably because of the Access-Control stuff introducing new CSRF vulnerabilities
  254. # [21:31] <Philip`> annevk: Is that a known problem or a bug in Firefox or something?
  255. # [21:32] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  256. # [21:33] <Philip`> Oh, maybe not
  257. # [21:33] <Philip`> It's not anything new, because <script src="https://mail.google.com/mail/?logout&hl=en-GB"></script> has the same effect
  258. # [21:33] <Philip`> Is it a bug in Gmail, or is the web just fundamentally broken?
  259. # [21:33] <zcorpan_> hsivonen: apparently some people use transitional because the software they use emit stuff that only validates as transitional
  260. # [21:35] <zcorpan_> hsivonen: and so it might be worth to look into the default templates of popular CMSs and blogs and which errors they get when validating as html5
  261. # [21:35] <zcorpan_> (but i guess the results would be pretty much the same as what you've already got)
  262. # [21:35] <hsivonen> zcorpan_: good idea
  263. # [21:36] <hsivonen> zcorpan_: altough the generated stuff in CMSs is harder to change than the templates, so it would be even more interesting to isolate the template parts somehow
  264. # [21:37] <zcorpan_> yeah
  265. # [21:42] <hsivonen> I see <a name> and target=_blank in what I think is the Blogger default
  266. # [21:43] <hsivonen> additionally, the blogger navbar has every presentational iframe attribute
  267. # [21:43] <zcorpan_> "SMF and WordPress both output target="_blank"." -- http://www.sitepoint.com/forums/showthread.php?p=3718885
  268. # [21:44] <hsivonen> what's SMF?
  269. # [21:44] <zcorpan_> probably http://www.simplemachines.org/
  270. # [21:44] <hsivonen> never heard
  271. # [21:45] <zcorpan_> i hadn't, either
  272. # [21:45] <Philip`> SMF seems to be fairly popular
  273. # [21:45] * Joins: jgraham (n=james@81-86-208-197.dsl.pipex.com)
  274. # [21:45] <Philip`> https://labs.mozilla.com/forum/ uses it
  275. # [21:48] <hsivonen> Can't validate that one with Validator.nu
  276. # [21:48] <hsivonen> the SSL cert is not supported by Sun JDK
  277. # [21:50] <Philip`> http://html5.validator.nu/?doc=http%3A%2F%2Fwww.simplemachines.org%2Fcommunity%2Findex.php looks unhappy
  278. # [21:50] <hsivonen> zcorpan_: WordPress default has profile at least: http://html5.validator.nu/?doc=http%3A%2F%2Fthemes.wordpress.net%2Ftestrun%2F
  279. # [21:51] <Philip`> and http://html5.validator.nu/?doc=http://www.cyberscoreforums.com/ (SMF 1.x, whereas the other one was 2.x) looks similar
  280. # [21:51] <hsivonen> ah. language="JavaScript" all over the place
  281. # [21:58] <hsivonen> Sun's certificate management docs aren't as obvious as I'd like :-(
  282. # [22:01] <hsivonen> I wonder if there's a way to ask HttpClient to accept any cert and only use TLS for encryption--not for verifying the idintity of the other party
  283. # [22:01] <zcorpan_> <link rel="help" href="http://www.cyberscoreforums.com/index.php?action=help" target="_blank" /> (from cyberscoreforums.com)
  284. # [22:09] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  285. # [22:18] * Joins: starjive (i=beos@81-233-18-73-no30.tbcn.telia.com)
  286. # [22:20] * Joins: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net)
  287. # [22:24] * Quits: heycam|sydney (n=cam@ppp232-187.static.internode.on.net) ("bye")
  288. # [22:28] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  289. # [22:31] * Joins: gsnedders (n=gsnedder@host86-151-228-75.range86-151.btcentralplus.com)
  290. # [22:31] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  291. # [22:33] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  292. # [22:33] * D2xSadEagle is now known as SadEagle
  293. # [22:34] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  294. # [22:40] <zcorpan_> wonder if we should allow <img with=0 height=0>
  295. # [22:40] <zcorpan_> er
  296. # [22:40] <zcorpan_> width
  297. # [22:45] <annevk> Philip`, Google doing actions on the user's behalf based on a GET request seems to be broken
  298. # [22:48] <gsnedders> annevk: seeming you said you'd explain to me anything I didn't get from the DOM specs, what does compareDocumentPosition() return?
  299. # [22:48] <Philip`> I suppose doing actions on a POST request would be broken too, because anyone could set up a form and submit it via JS
  300. # [22:49] <Philip`> so it's basically impossible to safely allow actions
  301. # [22:49] <SadEagle> gsnedders: it's an untranslatable string of curses in the direction of whoever thought up of this function
  302. # [22:49] <gsnedders> :D
  303. # [22:49] <SadEagle> Philip`: check out some stuff in http rfc about pipelining and idempotency, for extra fun.
  304. # [22:49] <gsnedders> at a really basic level, how can I tell if something occurs before something else?
  305. # [22:50] <annevk> yes
  306. # [22:50] <annevk> though not all browsers might support it
  307. # [22:51] <annevk> also, iirc it returns an integer that maps to some constant
  308. # [22:51] <gsnedders> oh yuk.
  309. # [22:51] <SadEagle> hmm, it's actually not so expensive to implement as I first thought.
  310. # [22:51] <kig> the usual solution to ajax api is to trust the browser to not leak cookies outside SOP and use the cookie secret for authenticating requests by adding the secret as a var to the post req
  311. # [22:51] <SadEagle> gsnedders: this seems to explain it: http://www.quirksmode.org/blog/archives/2006/01/contains_for_mo.html
  312. # [22:52] <gsnedders> SadEagle: thx
  313. # [22:52] <kig> s/usual/what i've been using/
  314. # [22:53] <SadEagle> np
  315. # [22:53] <SadEagle> there is a separate section in DOM3 core explaining it too, just search for DocumentPosition... For some reason the method specs don't refer to it..
  316. # [22:54] <gsnedders> that'll be why I didn't find it.
  317. # [22:54] * SadEagle loves DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC
  318. # [22:54] <gsnedders> yeah, I just noticed that
  319. # [22:54] <Philip`> kig: Hmm, that sounds quite reasonable
  320. # [22:54] <gsnedders> SadEagle: sadly, too often order isn't defined in DOM
  321. # [22:56] <SadEagle> they have a disconnected flag, though
  322. # [22:56] <annevk> wow, someone should clean that up and remove that constant
  323. # [22:57] <gsnedders> DOM5!
  324. # [22:57] <gsnedders> next year of school will suck. No longer in Secondary 5 :(
  325. # [22:59] <zcorpan_> dom5 core is on my list of things to do...
  326. # [22:59] <annevk> Hixie, "input2.setAttribute("checked", "checked"); // sets defaultChecked, doesn't change actual state" does change the state in deployed browsers
  327. # [22:59] <gsnedders> zcorpan_: you can use me a test subject as someone who doesn't know much about DOM :P
  328. # [23:00] <zcorpan_> gsnedders: i don't follow
  329. # [23:01] <gsnedders> zcorpan_: To make sure DOM5 Core actually makes sense to those who don't know much about DOM
  330. # [23:01] <zcorpan_> gsnedders: ah
  331. # [23:01] <zcorpan_> gsnedders: not sure that should be a goal though
  332. # [23:01] <SadEagle> gsnedders: coincidentally, DOM* Core is probably the best-specified part of DOM.
  333. # [23:02] <gsnedders> SadEagle: I'm aware.
  334. # [23:02] <Hixie> annevk: oh, in the radio button tests. i thought you were talking about the checkbox tests.
  335. # [23:03] * SadEagle wonders whether someone will be tackling saneification of DOM2 HTML... I guess some parts of WF2 overlap, though.
  336. # [23:03] <gsnedders> SadEagle: HTML 5 is, AFAIK
  337. # [23:03] <zcorpan_> yeah
  338. # [23:03] <SadEagle> poor Hixie :-)
  339. # [23:05] <Hixie> annevk: wow, that's a big bug in the spec. i'd better make sure i fix that in html5.
  340. # [23:06] <annevk> i doubt that's possible
  341. # [23:07] <annevk> HTML5 fixed most of DOM2 HTML
  342. # [23:07] <Hixie> i mean a big bug in the dom2 html spec
  343. # [23:08] <annevk> ok
  344. # [23:08] <Hixie> i haven't checked wf2
  345. # [23:08] * Hixie mails himself
  346. # [23:15] <Hixie> annevk: k, fixed the test
  347. # [23:17] <annevk> how can input1 still be checked?
  348. # [23:18] <annevk> .defaultChecked is exactly equivalent to setAttribute("checked", "checked") ...
  349. # [23:18] <annevk> or did you change other things, too?
  350. # [23:19] <Hixie> wait i thought you said that setting setAttribute("checked", "checked") was specifically _not_ equivalent to setting defaultChecked?
  351. # [23:19] <Hixie> so you're saying that setting defaultChecked also changes checked???
  352. # [23:20] <annevk> yes
  353. # [23:20] <annevk> sorry for not being more specific initially
  354. # [23:21] <annevk> maybe I'm wrong
  355. # [23:23] * Joins: heycam (n=cam@b4F38.static.pacific.net.au)
  356. # [23:24] <Dashiva> Wouldn't it be nice if there was a website that would screenshot a given page in IE6+7, FF2+3, Safari2+3 and Opera9.2+9.5 and display the results?
  357. # [23:24] * Hixie puts it back to what it used to be
  358. # [23:24] <Hixie> Dashiva: there is
  359. # [23:24] <Dashiva> really?
  360. # [23:24] <Dashiva> And not a paid service?
  361. # [23:24] <Hixie> yes
  362. # [23:24] <Hixie> i forget the url
  363. # [23:24] <Hixie> but there are some
  364. # [23:24] * heycam is now known as heycam|sydney
  365. # [23:24] <Dashiva> Hmm... guess it's google time
  366. # [23:25] <annevk> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3Ex%3Cinput%20name%3Dradio%20type%3Dradio%3E%3Cinput%20name%3Dradio%20type%3Dradio%3E%3Cscript%3Evar%20i%20%3D%20document.getElementsByTagName(%22input%22)%3B%20i[0].defaultChecked%20%3D%20true%3B%20i[1].defaultChecked%20%3D%20true%20%3C%2Fscript%3E
  367. # [23:25] <annevk> Firefox seems inconsistent
  368. # [23:26] <Hixie> well i've put it back to what the spec says
  369. # [23:26] <annevk> but given how inconsistent Firefox is I'm not sure we can fix it
  370. # [23:30] <Philip`> Dashiva: http://browsershots.org/ ?
  371. # [23:30] <Dashiva> Yeah, looking at that now
  372. # [23:31] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  373. # [23:42] * Quits: jgraham (n=james@81-86-208-197.dsl.pipex.com) ("I get eaten by the worms")
  374. # [23:51] <annevk> Hixie, because of "iframe { float: left; height: 0; width: 0; }" some of the media query tests are invalid
  375. # [23:51] <annevk> specifically, y1, y2, y3, and y4 will not function as expected
  376. # [23:51] <annevk> (if I uncomment that CSS line the media query tests pass in Opera as expected)
  377. # [23:54] <Hixie> oh the media queries depend on the iframe dimensions?
  378. # [23:55] <annevk> y1, y2, y3, y4 test the width and height media features
  379. # [23:55] <Hixie> yes
  380. # [23:55] <Hixie> i didn't realise that those heights and widths were the viewport dimensions
  381. # [23:55] <Hixie> of the inner viewport
  382. # [23:56] <annevk> they are
  383. # [23:56] <Hixie> but indeed it is
  384. # [23:56] <annevk> you could change them to min-device-width etc. I suppose
  385. # [23:56] <Hixie> fixed
  386. # [23:58] <Hixie> there, let me know if that works
  387. # [23:58] <annevk> that works, but you should update the comment to say that the tests assume a 0x0 window
  388. # [23:58] <annevk> "// the next four assume that the window is bigger than 1em by 1em at the time the test is run"
  389. # [23:59] * Joins: jgraham (n=james@81-86-208-197.dsl.pipex.com)
  390. # [23:59] <Hixie> fixed
  391. # [23:59] <annevk> great
  392. # Session Close: Mon Feb 11 00:00:00 2008

The end :)