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

Options:

  1. # Session Start: Tue Jun 17 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:02] * Quits: aaronlev (n=chatzill@g227079101.adsl.alicedsl.de) ("ChatZilla 0.9.82.1 [Firefox 3.0/2008052906]")
  4. # [00:05] * Quits: othermaciej (n=mjs@17.255.69.132)
  5. # [00:11] <heycam> Dashiva, if that's the case that's a bug :)
  6. # [00:11] <heycam> i'll have a look once i'm at uni
  7. # [00:14] * Quits: heycam (n=cam@203-217-69-250.dyn.iinet.net.au) ("bye")
  8. # [00:16] * Joins: MangoFusion (n=jamesu@host86-145-164-229.range86-145.btcentralplus.com)
  9. # [00:19] * Quits: virtuelv (n=virtuelv@192.80-203-77.nextgentel.com) ("Ex-Chat")
  10. # [00:19] * Joins: jgraham (n=james@81-86-219-217.dsl.pipex.com)
  11. # [00:20] <jgraham__> gsnedders: I copied the latest version of outline.py to james.html5.org/temp/outline/outline.py
  12. # [00:32] * Quits: hasather (n=hasather@cm-84.215.63.253.getinternet.no) (Read error: 110 (Connection timed out))
  13. # [00:34] * Quits: aroben (n=aroben@unaffiliated/aroben)
  14. # [00:39] * Joins: mcarter (n=mcarter@ip-12-22-56-126.hqglobal.net)
  15. # [00:43] * Joins: othermaciej (n=mjs@17.255.96.158)
  16. # [00:44] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  17. # [00:44] <Dashiva> Just to see if I got the terminology right... HTMLDivElement is an 'interface object', HTMLDivElement.prototype (also somediv.[[prototype]]) is an 'interface prototype object' and somediv is a 'host object implementing an interface'.
  18. # [00:44] <heycam> Dashiva, i see the bug (the "go to step 23")
  19. # [00:44] <heycam> (in web idl's [[Put]])
  20. # [00:45] <heycam> Dashiva, yeah that's the terminology i used
  21. # [00:45] <Dashiva> heycam: That's half of it
  22. # [00:45] <Dashiva> The other half is step 14
  23. # [00:46] <Dashiva> If the property doesn't exist, it continues to 15 and from there you can't get anywhere beyond 19
  24. # [00:46] <heycam> hmm
  25. # [00:47] <heycam> ok i'll take a look at it
  26. # [00:47] <Dashiva> Actually, probably step 15 is the problem
  27. # [00:47] <Dashiva> Since it has to check PutForwards before going on to create
  28. # [00:47] <Dashiva> So instead of throwing an exception, it should jump to 24
  29. # [00:48] <Dashiva> *19
  30. # [00:48] * Quits: MangoFusion (n=jamesu@host86-145-164-229.range86-145.btcentralplus.com) ("Not here")
  31. # [00:48] <Dashiva> You know what, it's too late for this. Don't listen to me. Zzz :)
  32. # [00:49] <heycam> yeah that step 15 is assuming the property already exists
  33. # [00:49] <heycam> which it shouldn't
  34. # [00:53] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (IRC client for Emacs)")
  35. # [00:57] * Joins: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca)
  36. # [01:00] * Quits: tndH (i=Rob@87.102.5.204) ("ChatZilla 0.9.82.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  37. # [01:01] * Quits: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca) (Client Quit)
  38. # [01:04] * Quits: qwert666 (n=qwert666@day221.neoplus.adsl.tpnet.pl) ("Leaving")
  39. # [01:07] * Quits: smedero (n=smedero@mdp-nat251.mdp.com)
  40. # [01:30] * Joins: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca)
  41. # [01:40] * Joins: jruderman (n=jruderma@ip68-5-179-249.oc.oc.cox.net)
  42. # [01:42] * Joins: tantek (n=tantek@c-98-210-12-23.hsd1.ca.comcast.net)
  43. # [02:06] * Joins: aa__ (n=aa@nat/google/x-169c754896fed4db)
  44. # [02:07] * Quits: tantek (n=tantek@c-98-210-12-23.hsd1.ca.comcast.net)
  45. # [02:09] * Quits: grimboy (n=grimboy@78-105-162-250.zone3.bethere.co.uk) ("Lost terminal")
  46. # [02:12] <takkaria> could anyone confirm my reading of the tokenisation part of the spec, that '<h a="&not">' should result in an 'a' attribute containing the not symbol?
  47. # [02:13] <takkaria> oh, wait, I think I see my problem
  48. # [02:23] * Joins: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  49. # [02:25] * Parts: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  50. # [02:26] * Joins: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  51. # [02:34] * Joins: deane (n=dean@121.98.128.155)
  52. # [02:39] * Quits: eseidel (n=eseidel@nat/google/x-05285c5b20294e95)
  53. # [02:39] * Parts: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  54. # [03:00] * Quits: billmason (n=billmaso@ip232.unival.com) (Read error: 104 (Connection reset by peer))
  55. # [03:07] * Quits: gavin (n=gavin@firefox/developer/gavin) (Read error: 104 (Connection reset by peer))
  56. # [03:07] * Joins: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  57. # [03:19] * Quits: jruderman (n=jruderma@ip68-5-179-249.oc.oc.cox.net)
  58. # [03:21] * Joins: jruderman (n=jruderma@ip68-5-179-249.oc.oc.cox.net)
  59. # [03:51] * Joins: othermaciej_ (n=mjs@17.203.15.234)
  60. # [03:51] * Quits: KevinMarks (n=KevinMar@60.sub-75-208-225.myvzw.com) ("The computer fell asleep")
  61. # [03:59] * Quits: othermaciej (n=mjs@17.255.96.158) (Nick collision from services.)
  62. # [03:59] * othermaciej_ is now known as othermaciej
  63. # [04:01] * Joins: eseidel (n=eseidel@adsl-75-36-129-130.dsl.pltn13.sbcglobal.net)
  64. # [04:04] * Quits: deane (n=dean@121.98.128.155) (Remote closed the connection)
  65. # [04:09] * Joins: mcarter_ (n=mcarter@ip-12-22-56-126.hqglobal.net)
  66. # [04:11] * Quits: mcarter (n=mcarter@ip-12-22-56-126.hqglobal.net) (Read error: 110 (Connection timed out))
  67. # [04:23] * Quits: jgraham (n=james@81-86-219-217.dsl.pipex.com) ("I get eaten by the worms")
  68. # [04:30] * Quits: eseidel (n=eseidel@adsl-75-36-129-130.dsl.pltn13.sbcglobal.net)
  69. # [04:50] * Quits: mcarter_ (n=mcarter@ip-12-22-56-126.hqglobal.net) (Read error: 110 (Connection timed out))
  70. # [05:17] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  71. # [05:18] * Quits: othermaciej (n=mjs@17.203.15.234) (Read error: 104 (Connection reset by peer))
  72. # [05:44] * Quits: Dashiva (i=Dashiva@wikia/Dashiva) (Read error: 113 (No route to host))
  73. # [05:56] * Quits: weinig (n=weinig@17.203.15.145)
  74. # [06:11] * Joins: eseidel (n=eseidel@c-67-180-49-110.hsd1.ca.comcast.net)
  75. # [06:23] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  76. # [06:39] * Quits: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  77. # [06:42] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  78. # [06:44] * Joins: othermaciej_ (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  79. # [06:44] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  80. # [06:48] * Joins: deane (n=dean@121-72-175-170.dsl.telstraclear.net)
  81. # [06:48] * othermaciej_ is now known as othermaciej
  82. # [07:36] * Quits: sverrej (n=sverrej@89.10.27.86) (Read error: 60 (Operation timed out))
  83. # [07:45] * Quits: roc (n=roc@202.0.36.64)
  84. # [07:57] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
  85. # [07:59] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  86. # [08:04] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  87. # [08:05] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  88. # [08:08] <heycam> Dashiiva, fixed the thing you mentioned earlier
  89. # [08:14] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  90. # [08:17] * Joins: Dashiva (n=noone@wikia/Dashiva)
  91. # [08:18] * Joins: sverrej_ (n=sverrej@pat-tdc.opera.com)
  92. # [08:22] <othermaciej> Hixie: sicking said almost everything I would have said in his reply to Microsoft's feedback
  93. # [08:22] <othermaciej> I am tempted to +1
  94. # [08:23] <Hixie> heh
  95. # [08:23] <Hixie> i haven't read it yet
  96. # [08:23] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  97. # [08:23] <Hixie> i can't believe they stuffed so much filler crap into that feedback
  98. # [08:24] <Hixie> on another note, the htmlwg bugzilla hasn't had any activity for at least 6 hours
  99. # [08:24] <othermaciej> I was dismayed that many of their quotes were clearly out of context
  100. # [08:25] <othermaciej> or at least, they turned them towards ends that I am pretty sure the authors of said comments did not intend
  101. # [08:25] <othermaciej> this cast doubt on the contextual validity of their other quotes for me
  102. # [08:26] <Hixie> hence the version i provded that just has their actual feedback
  103. # [08:26] <Hixie> stripping out the stuff that doesn't actually contibute
  104. # [08:39] * Quits: sverrej_ (n=sverrej@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  105. # [08:41] * Joins: sverrej_ (n=sverrej@213.236.208.247)
  106. # [09:02] * Joins: hsivonen (n=hsivonen@kekkonen.cs.hut.fi)
  107. # [09:02] * Joins: heycam (n=cam@203-217-69-250.dyn.iinet.net.au)
  108. # [09:13] <heycam> Dashiva, in your mail you said s14 of the [[Put]] can be removed. why's that?
  109. # [09:16] * Joins: tndH_ (i=Rob@87.102.5.204)
  110. # [09:16] * tndH_ is now known as tndH
  111. # [09:21] <Dashiva> heycam: If you would jump in s14 there's no such property. That means that in s15, there can't be a property with putforwards either (since there's no property)
  112. # [09:22] * Quits: eseidel (n=eseidel@c-67-180-49-110.hsd1.ca.comcast.net)
  113. # [09:23] <heycam> but you jump in s14 if there is no property
  114. # [09:23] * heycam confused
  115. # [09:24] <Dashiva> And you jump in s15 if there is no property (or there is a property, and it's not putforwards)
  116. # [09:24] <Dashiva> Essentially s15 is all of s14 + check putforwards
  117. # [09:26] <heycam> true i could combine s14 and s15 to say "If O does not have a property with name P, or if it does but it does not blah blah [PutForwards] ..."
  118. # [09:27] <heycam> i split them only to avoid a big conditional thing like that
  119. # [09:27] <Dashiva> I just figured 'does not correspond to an attribute' included the case 'there is no such attribute'
  120. # [09:28] <heycam> ah, k
  121. # [09:28] <Dashiva> Also, it seems a bit string to split on attribute exists/not in step 14, and then combine them into step 19, and then split again in step 21
  122. # [09:28] <Dashiva> s/string/strange/
  123. # [09:28] <heycam> or you figured "If the property on O with name P does not correspond ..." could still evaluate to false if there is no such property
  124. # [09:29] <Dashiva> Yeah. I see it might not be spec-level clarity.
  125. # [09:31] <heycam> so with the splitting on 14 / combining on 19 / splitting on 21... could you elaborate?
  126. # [09:32] <Dashiva> If the property does not exist, or if the property exists but is not putforward, in both cases it is necessary to run [[CanPut]].
  127. # [09:32] <Dashiva> (which is step 19)
  128. # [09:34] <heycam> yep...
  129. # [09:34] <Dashiva> And step 19 leads to step 21, where it checks if the property exists. Again.
  130. # [09:38] <heycam> so you'd rather have two branches from s14/s15, and include the [[CanPut]] in both?
  131. # [09:38] * Joins: jgraham (n=james@81-86-219-217.dsl.pipex.com)
  132. # [09:39] <heycam> or i could bring the [[CanPut]] up above s14 (but then it's irrelevant if we get to s16)
  133. # [09:39] <Dashiva> I'd rather not branch on 14, and just send both cases to 19.
  134. # [09:40] <Dashiva> Hmm... actually...
  135. # [09:41] <Dashiva> PutForwards implies a Readonly attribute, so we can't CanPut before it anyhows, I believe
  136. # [09:42] <heycam> right (well, the [[CanPut]] could be done, but not the return based on it)
  137. # [09:43] * heycam wonders if he should write up his algorithms as C code and then run gcc -S -O9 on them to try to minimise them :)
  138. # [09:44] <Dashiva> Would unifying 14 and 15 be easier if the conditional was inverted? e.g. if there is a property with name P and that property has extattr putforwards, jump to steps equivalent to 16-18. And then the canput stuff following instead of in a jump.
  139. # [09:46] <heycam> yeah that probably would
  140. # [09:47] <Dashiva> Oh well. As long as [[CanPut]] happens for both new and old properties, I suppose this is just bikeshedding.
  141. # [09:48] <heycam> i should have a "you can implement these how you want as long as the observable effects are the same" in the spec somewhere (but don't yet)
  142. # [09:49] <Dashiva> By the way, is the special casing of 2^32-1 for integer indexes explained somewhere?
  143. # [09:49] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  144. # [09:50] <heycam> not in the document
  145. # [09:50] <heycam> although now i wonder if it is really necessary
  146. # [09:50] <heycam> since such host objects won't necessarily have a .length property on them
  147. # [09:50] <heycam> (which is the reason it is like that for Array objects)
  148. # [09:52] <Dashiva> Oh, of course. Then it makes perfect sense.
  149. # [09:53] <Dashiva> I didn't think of .length being greater than the max index
  150. # [09:53] <heycam> yeah it makes sense for Array. not sure for IndexSetters...
  151. # [09:53] * heycam adds an ednote
  152. # [09:53] <Dashiva> It's good for consistency, though. :)
  153. # [09:54] <heycam> true
  154. # [10:00] * heycam dinners
  155. # [10:00] * Dashiiva avoids comments about barbies
  156. # [10:01] * Quits: jgraham (n=james@81-86-219-217.dsl.pipex.com) ("I get eaten by the worms")
  157. # [10:03] <virtuelv> Dashiiva: wanna go shopping?
  158. # [10:03] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  159. # [10:07] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) (Remote closed the connection)
  160. # [10:08] * Joins: othermaciej_ (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  161. # [10:08] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  162. # [10:08] * Joins: roc (n=roc@121-72-162-128.dsl.telstraclear.net)
  163. # [10:39] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  164. # [10:46] * Joins: ROBOd (n=robod@89.122.216.38)
  165. # [10:48] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  166. # [10:59] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  167. # [11:09] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  168. # [11:10] * Joins: Dashiiiva (n=noone@195.18.164.170)
  169. # [11:11] * Quits: roc (n=roc@121-72-162-128.dsl.telstraclear.net) (Read error: 104 (Connection reset by peer))
  170. # [11:13] * Joins: roc (n=roc@121-72-162-128.dsl.telstraclear.net)
  171. # [11:13] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
  172. # [11:20] * Joins: webben (n=benh@nat/yahoo/x-b23946d03e2f9faf)
  173. # [11:22] * Quits: sverrej_ (n=sverrej@213.236.208.247) (Read error: 113 (No route to host))
  174. # [11:23] * Quits: Dashiiva (n=noone@195.18.164.170) (Read error: 110 (Connection timed out))
  175. # [11:27] <Hixie> rb is 50% of the html4all traffic too
  176. # [11:27] <Hixie> that's funny
  177. # [11:28] <zcorpan> Hixie: does it make sense for the ratechange event to be cancelable?
  178. # [11:29] <Hixie> does it have a default action?
  179. # [11:29] <zcorpan> not afaict
  180. # [11:29] <Hixie> then it doesn't matter
  181. # [11:29] <zcorpan> fair enough
  182. # [11:31] <Hixie> teehee, on june 6th rb asked gregory to forward many of his comments on html5 to the xhtml2 group
  183. # [11:31] <Hixie> but as far as i can tell, that didn't happen
  184. # [11:34] <zcorpan> "When the defaultPlaybackRate or playbackRate attributes change value", setting to the value it already has means it hasn't changed right
  185. # [11:39] <Hixie> i guess
  186. # [11:40] <Hixie> i can specify it the other way if that's what UAs want
  187. # [11:40] <Hixie> hey does anyone know what the status of the svgwg's work on the svg parsing thing is?
  188. # [11:40] <Hixie> i don't recall ever hearing back from them
  189. # [11:40] <Hixie> and it's been what, two months now?
  190. # [11:42] <hsivonen> ouch. document.write writing a script that document.writes is more complex than I first thought :-(
  191. # [11:43] <hsivonen> Hixie: do you know if Gecko and WebKit really call the parser re-entrantly or whether they interleave parser and script execution using a run queue?
  192. # [11:43] <Hixie> no idea what their implementation does
  193. # [11:43] <Hixie> the net result is basically what the spec says though
  194. # [11:43] <Hixie> though the spec is mildly more complex to handle script async and script defer
  195. # [11:44] <hsivonen> I had happily assumed a run queue model, but now that I try to write it down in the case where document.write document.writes, it starts to get ugly
  196. # [11:44] <virtuelv> hsivonen: document write is evil
  197. # [11:45] <virtuelv> I hacked up a bunch of testcases that indicates that no two browsers behave the same
  198. # [11:45] <Hixie> the browsers are pretty close to each other, most of the differences are obvious bugs
  199. # [11:45] <virtuelv> Hixie: I'll ask if I can release the TC's somewhere
  200. # [11:45] <virtuelv> I'm not sure what are bugs or not
  201. # [11:46] <virtuelv> document.write in setTimeout calls are so much fun
  202. # [11:46] <hsivonen> Hixie: anyway, I have trouble wrapping my head around the spec assertion that the tree builder is re-entrant
  203. # [11:46] <Hixie> they should just blow away the document
  204. # [11:46] <Hixie> hsivonen: oh?
  205. # [11:46] <hsivonen> Hixie: it seems to me that the parser doesn't need to be re-entrant
  206. # [11:47] <virtuelv> Hixie: suffice it to say that browsers in general don't cancel the timeout
  207. # [11:47] <Hixie> hsivonen: just like any thing that you can implement as a recursive function can be implemented with a hand-managed stack? or more so?
  208. # [11:47] <hsivonen> Hixie: right
  209. # [11:47] <Hixie> hsivonen: well sure
  210. # [11:48] <Hixie> hsivonen: recursive algorithms are what the spec uses generally because they're easier to explain and understand, but they're not what i'd recommend implementing
  211. # [11:48] <Hixie> hsivonen: though iirc the parser's re-entrancy is only ever one level deep
  212. # [11:49] <hsivonen> Hixie: instead of recursing, a single-threaded browser engine should be able to put the parser state on the heap and spin through the event loop
  213. # [11:50] <Hixie> well the parser has to be interruptible in a browser anyway
  214. # [11:50] <Hixie> so it would just interrupt itself
  215. # [11:50] <Hixie> returning to the vent loop
  216. # [11:51] <Hixie> event
  217. # [11:51] <hsivonen> Hixie: right. and once you make it interruptible, I don't see why you'd ever want the *tree builder* to be re-entrant
  218. # [11:51] <Hixie> indeed
  219. # [11:51] <hsivonen> So I'm again in a situation where I'm trying to unroll the spec definition into something else but equivalent
  220. # [11:51] <Hixie> that is an expected situation, yes
  221. # [11:52] <Hixie> no spec will ever directly map to all implementations
  222. # [11:55] <hsivonen> Hmm. I can't figure how to make three-level-deep document.write have the right execution order in a GWT context where the browser owns the script execution but the script owns the parser
  223. # [11:55] <hsivonen> too bad. I can't use GWT to fully try stuff out then
  224. # [11:57] <Hixie> heh
  225. # [11:57] <annevk> http://www.p01.org/releases/DHTML_contests/files/20lines_hypno_trip_down_the_fractal_rug/
  226. # [11:58] <roc> Hixie: there was a discussion here with Doug Schepers a while ago about the SVG parsing thing
  227. # [11:58] <Hixie> roc: yeah, i think i saw that
  228. # [11:58] <roc> annevk: wow
  229. # [11:58] <hsivonen> hmm. I'm starting to suspect the "generic [R]CDATA algoritm" and the way Gecko executes document.written scripts doesn't match
  230. # [11:58] <hsivonen> hmm.
  231. # [11:59] <roc> annevk: somewhat abusive use of "20 lines" though
  232. # [11:59] <annevk> Hixie, I don't think there was much progress, though they assigned some actions
  233. # [11:59] <annevk> roc, "20 lines" is a dubious concept anyway :)
  234. # [11:59] <hsivonen> roc: I seriously think the same tokenizer should handle both HTML and SVG islands
  235. # [12:00] <Hixie> hsivonen: gecko has some thing where adding text to a script that hasn't executed will still execute
  236. # [12:00] <Hixie> hsivonen: i'm not sure if we need to put that in html5 or if gecko can change, it's something i should probably look at
  237. # [12:00] <roc> it seemed clear that a) the SVG group has a requirement that parsing of SVG fragments should impose XML-esque validation with strict error handling and that b) you have a requirement that parsing SVG fragments should not impose strict error handling
  238. # [12:01] <Hixie> that appears to be the case, yes
  239. # [12:01] <hsivonen> roc: in addition to requiring non-strict error handling for SVG fragments, I also want to require avoiding complexity in the parser
  240. # [12:01] <roc> so it doesn't really matter what the proposed solution is, since those two requirements are irreconcilable
  241. # [12:02] <hsivonen> roc: I'm OK with complexity imposed by the legacy Web
  242. # [12:02] <hsivonen> roc: I'm not OK with introducing new complexity for XML purity
  243. # [12:02] <hsivonen> we have to define what document.write does inside an SVG fragment
  244. # [12:03] <hsivonen> if the same tokenizer is used, document.write inside SVG doesn't cause new complexity
  245. # [12:03] <Hixie> roc: they're not completely irreconcilable, you could come up with some schemes where you fall from one to the other (and the remainder is treated as html, not svg)
  246. # [12:03] <Hixie> roc: but it does seem unlikely that such a scheme would fit into the various constraints we have
  247. # [12:03] <Hixie> anyway
  248. # [12:03] <hsivonen> if we'd change to an XML parser mid-stream, we'd have to figure out what exactly document.write does and how it can be implemented sanely
  249. # [12:03] <annevk> that's what they're looking at, but it's not really clear to me how that works with tokenizing etc.
  250. # [12:03] <roc> that's what Doug wanted to do actually
  251. # [12:04] <Hixie> i was just wondering if there was anything i needed to work on
  252. # [12:04] <Hixie> apparently there isn't yet
  253. # [12:04] <annevk> <keygen>
  254. # [12:04] <Hixie> <keygen>?
  255. # [12:04] <roc> okay, so if you would accept strict SVG parsing with errors falling back to HTML parsing, then progress is possible
  256. # [12:04] <roc> in theory
  257. # [12:05] <Hixie> potentially
  258. # [12:05] <hsivonen> I'd much rather spend my time delivering an additional serializer to address the copy-paste requirements of the SVG WG than to spend my time writing two tokenizers that can be switched mid-stream
  259. # [12:05] <Hixie> i'm not convinced such a scheme would work, but we'll find out in due course
  260. # [12:05] <annevk> Hixie, I guess that's part of WF2, but it'd be nice if it was in a spec so it becomes easier to advocate Koreans for instance into using it
  261. # [12:05] <roc> someone should ping them
  262. # [12:06] <roc> hsivonen: it's clear that having browsers reserialize as XML when copy/pasting is the right thing, but the SVG WG insists that copy-pasting in a text editor is a requirement
  263. # [12:06] <hsivonen> I'm not convinced the complexity imposed by additional strictness is a good use of anyone's limited resources
  264. # [12:06] <hsivonen> roc: I'd prefer to go with the right thing
  265. # [12:06] <roc> they want both
  266. # [12:07] <Dashiiiva> <pony/>
  267. # [12:08] <hsivonen> roc: it's easy to want it if writing the parser is Someone Else's Problem
  268. # [12:08] <roc> such is the life of the implementor
  269. # [12:09] <annevk> it doesn't really make sense to just accept that roc, imo
  270. # [12:09] <roc> I'm just the messenger
  271. # [12:09] <Hixie> annevk: send me a spec
  272. # [12:10] <annevk> if we just implemented whatever the W3C came up with we'd never beat Flash
  273. # [12:10] <Philip`> I think it wasn't clear whether they'd be unhappy with using the current SVG-in-HTML parsing rules and just defining conformance so that the content must be well-formed XML, so that conforming HTML5 SVG could always be copied into a real XML document, which seems to me kind of nicer than actual XML parsing since it wouldn't affect the parser at all
  274. # [12:10] <annevk> Hixie, I can't really get anything better than the old Netscape one, I guess I should try harder
  275. # [12:10] <annevk> :/
  276. # [12:10] <roc> Philip`: what do you mean "conforming"? They want browsers to check for well-formed XML of the SVG fragment before rendering it.
  277. # [12:11] * Philip` suggests black-box reverse engineering of <keygen>
  278. # [12:11] <hsivonen> Philip`: it does affect at least *a* parser if you expect that level of conformange to be checked in software
  279. # [12:11] <Hixie> annevk: neither could i, and that was basically useless
  280. # [12:12] <Hixie> right well. bed time. nn.
  281. # [12:12] <hsivonen> Hixie: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3E%0Adocument.write(%27a%27)%3B%0Adocument.write(%27%3Cscript%3Edocument.write(%22c%22)%3C\%2Fscript%3E%27)%3B%0Adocument.write(%27b%27)%3B%0A%3C%2Fscript%3E%0A has the same result in Gecko and WebKit
  282. # [12:12] * Joins: myakura (n=myakura@p1216-ipbf601marunouchi.tokyo.ocn.ne.jp)
  283. # [12:12] <Philip`> roc: I don't think all of 'they' considers that as an absolute requirement, so they could perhaps be convinced away from that
  284. # [12:13] <roc> I tried
  285. # [12:14] <roc> with Doug at least. The WG as a whole hasn't been all that responsive to my other issues
  286. # [12:14] <roc> I wonder what heycam's position is on all this
  287. # [12:23] * Parts: annevk (n=annevk@pat-tdc.opera.com)
  288. # [12:23] * Joins: annevk (n=annevk@pat-tdc.opera.com)
  289. # [12:24] * othermaciej_ is now known as othermaciej
  290. # [12:27] <hsivonen> I guess I should go read some browser source on how document.write is implemented
  291. # [12:29] <othermaciej> document.write writes at the current insertion point
  292. # [12:29] <othermaciej> which might be beyond the end of the current script element
  293. # [12:30] <othermaciej> if it document.wrote something already
  294. # [12:31] <hsivonen> othermaciej: in WebKit, does the script engine call into the parser on document.write or schedule stuff for running and return to the main loop?
  295. # [12:31] <othermaciej> actually the insertion point starts right after the script, per-script, so when you document.write a script and then document.write something else, and that script document.writes, I think the content gets inserted before whatever was written after the second script
  296. # [12:31] <othermaciej> it just inserts stuff into the queue of characters to process
  297. # [12:31] <othermaciej> it does not return to the main loop at all
  298. # [12:31] <othermaciej> script execution during parsing is synchronous and blocks the parser
  299. # [12:32] <hsivonen> but when document.written data gets parsed, are there script engine stack frames on the call stack?
  300. # [12:33] <hsivonen> so if document.write document.writes, will the script engine be entered re-entrantly?
  301. # [12:33] <othermaciej> the script engine can be re-entered via the parser using innerHTML
  302. # [12:33] <othermaciej> but not document.write, I don't think
  303. # [12:33] <othermaciej> since nothing that document.write writes (to the current, parsing document) is processed until after the script completes execution
  304. # [12:34] <hsivonen> othermaciej: that doesn't seem to be the case
  305. # [12:34] <hsivonen> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3E%0Adocument.write('a')%3B%0Adocument.write('%3Cscript%3Edocument.write(%22b%22)%3C%5C%2Fscript%3E')%3B%0Adocument.write('c')%3B%0A%3C%2Fscript%3E
  306. # [12:34] <othermaciej> well I could be misremembering it, this is a very confusing area
  307. # [12:35] <hsivonen> the document.written script runs before the script that wrote it finishes
  308. # [12:35] <othermaciej> is that true?
  309. # [12:35] <othermaciej> the live dom viewer does not prove that
  310. # [12:35] <othermaciej> the output ("abc") is consistent with what I described
  311. # [12:36] <Lachy> hsivonen, no, othermaciej is right.
  312. # [12:36] <othermaciej> first 'a<script>document.write("b")<\/script>c' is injected into the character stream right after the first script
  313. # [12:36] <othermaciej> then a is parsed
  314. # [12:36] <othermaciej> then the second script
  315. # [12:36] <othermaciej> which causes b to be injected into the token stream right after the second script
  316. # [12:37] <othermaciej> then c is parsed
  317. # [12:37] <othermaciej> each script starts with an insertion point right after its end tag
  318. # [12:37] <hsivonen> ah. excellent. That's what I thought at first, and then I got tangled in confusion
  319. # [12:37] <othermaciej> which may not be the same as the end of all currently inserted content
  320. # [12:37] <annevk> I wonder why Opera has two separate text nodes for bc
  321. # [12:38] <hsivonen> so why does the spec talk about re-entrant calls to the tree builder?
  322. # [12:38] <Lachy> hmm, maybe not.
  323. # [12:38] <Lachy> document.write('a');
  324. # [12:38] <Lachy> w(1);
  325. # [12:38] <Lachy> document.write('<script>document.write("b");w(3);<\/script>');
  326. # [12:38] <Lachy> w(2);
  327. # [12:38] <Lachy> document.write('c');
  328. # [12:38] <Lachy> that doesn't work as I'd expect it to.
  329. # [12:39] <Lachy> at least in Firefox.
  330. # [12:40] <Lachy> or in WebKit.
  331. # [12:40] <Lachy> w(3) is executing before w(2), so it seems it's not waiting until the first script is finished.
  332. # [12:46] <othermaciej> yeah that didn't do what I expected either
  333. # [12:47] <othermaciej> seems like it can re-enter to arbitrary levels
  334. # [12:47] <othermaciej> <script>
  335. # [12:47] <othermaciej> document.write('a');
  336. # [12:47] <othermaciej> alert(1);
  337. # [12:47] <othermaciej> document.write('<script>document.write("b<script>document.write(\'c\'); alert(4);<\\/script>"); alert(3);<\/script>');
  338. # [12:47] <othermaciej> alert(2);
  339. # [12:47] <othermaciej> document.write('d');
  340. # [12:47] <othermaciej> </script>
  341. # [12:50] <hsivonen> alert requires UI to be responsive
  342. # [12:50] <hsivonen> does alert establish a nested event loop or does alert cause the call stack to unwind to the main event loop?
  343. # [12:51] <hsivonen> document.write is hard
  344. # [13:03] <othermaciej> alert makes a modal event loop
  345. # [13:03] <othermaciej> it does not cause all UI to be responsive
  346. # [13:04] <hsivonen> in Firefox 3, alert is window-modal, although, as I understand it, the windows have their UI run on one thread
  347. # [13:05] <hsivonen> alert seems app-modal is Safari
  348. # [13:08] * Joins: htmlfivedotne1 (n=dcostali@c-67-162-99-121.hsd1.il.comcast.net)
  349. # [13:08] * Parts: htmlfivedotne1 (n=dcostali@c-67-162-99-121.hsd1.il.comcast.net)
  350. # [13:15] <heycam> roc, sorry for the delay on your www-svg issues
  351. # [13:15] <heycam> (note that a couple of them are on the agenda for today's telcon (which i won't be at))
  352. # [13:16] <hsivonen> I'm getting curious about support for incremental rendering of document.written content
  353. # [13:17] <annevk> <script> without async is not so good for incremental rendering
  354. # [13:19] <heycam> as for html in svg, i have to say that i (persionally) haven't had time to look into it. i believe the others did something on it at the F2F recently, and are writing up some text, but i haven't seen it.
  355. # [13:19] * heycam tv ⇒ afk
  356. # [13:23] <hsivonen> annevk: <script> without async *could* be good for incremental rendering, if a) layout runs on a different thread or b) the script engine stack is really on the heap, so that the C++ stack can unwind without breaking script state
  357. # [13:24] <hsivonen> however, I just saw some Gecko code that makes me want to write a test case to see if incremental layout works from document.written content
  358. # [13:25] <hsivonen> it seems safe to assume that Presto and Trident have concurrency models that differ significantly from Gecko and WebKit, which I gather are more alike
  359. # [13:42] * Quits: webben (n=benh@nat/yahoo/x-b23946d03e2f9faf)
  360. # [13:53] * Joins: ROBOd2 (n=robod@89.122.216.38)
  361. # [13:54] * Quits: ROBOd (n=robod@89.122.216.38) (Read error: 60 (Operation timed out))
  362. # [13:58] <Lachy> hey, I just realised that <iframe sandbox=""> could potentially create a false sense of security. If a website author uses it to embed user comments and hosts the comment file on the same domain as the parent page, it only protects the user as long as the comment page isn't viewed outside of the iframe.
  363. # [14:00] <Lachy> so websites would still need to filter out as much as possible, and keep sandbox="" only as a last line of defence.
  364. # [14:02] <Philip`> That would matter if you used <iframe sandbox src=...>, but you can't use that because it's unsafe in UAs that don't support sandboxing
  365. # [14:02] <Lachy> at the moment, that's the only way to do it, since there isn't yet a way to embed the markup inline.
  366. # [14:02] <Philip`> so you'd have to use <iframe sandbox doc="user's raw comment" src="some-file-with-user's-sanitised-comment.html"> and then it's alright anyway
  367. # [14:03] <Lachy> doc="" isn't specced yet.
  368. # [14:04] <Lachy> if you were going to sanitise the comment, then why embed the raw comment inline?
  369. # [14:05] * Joins: qwert666 (n=qwert666@acai2.neoplus.adsl.tpnet.pl)
  370. # [14:05] <Lachy> I'm just not convinced sandox is a good solution for sandboxing user contribued content. It could be good for embedding content from 3rd party sites though.
  371. # [14:06] <Philip`> The sanitised comment might strip out lots of safe content and styles that aren't in the whitelist, so it's uglier for users than the original unsanitised (sandboxed) comment
  372. # [14:07] <Philip`> so if their UA supports sandboxing then they can benefit from getting the unsanitised version
  373. # [14:07] <Lachy> if your sanitiser code is that bad, it's time to rewrite it.
  374. # [14:08] * Quits: myakura (n=myakura@p1216-ipbf601marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  375. # [14:08] * Joins: aaronlev (n=chatzill@f051105064.adsl.alicedsl.de)
  376. # [14:09] <Philip`> If it was possible to write a sanitiser that wasn't bad, why would anyone want client-side sandboxing?
  377. # [14:09] <Lachy> I just don't think it's a good idea to ever send unsanitised code to browsers. Imagine if there was a browser bug that inadvertently allowed something it shouldn't, and there were sites that published fully unsanitised comments, then you can bet there would be exploits pretty quickly.
  378. # [14:10] <Lachy> incase their sanitiser missed something by mistake, not because it could accidently remove something it shouldn't.
  379. # [14:12] <othermaciej> having both sanitization and client-side sandboxing is safer
  380. # [14:12] <othermaciej> to get an exploit through, you'd need matching mistakes on both ends
  381. # [14:12] * othermaciej is failing to sleep
  382. # [14:13] <Lachy> othermaciej, right. But if the server didn't sanitise, then the browser is the only line of defence, and you'd better hope there's no bug in it.
  383. # [14:13] <othermaciej> why is that a "but"?
  384. # [14:14] <Lachy> because I'm concerned that sandbox="" could create a false sense of security, where silly developers don't bother sanitising the code, and then it really doesn't depend on there being matching mistakes on both ends.
  385. # [14:15] <Lachy> it's just one really big mistake on the server side and whatever small mistake in the browser is enough.
  386. # [14:16] <Lachy> and if even Philip` is suggesting sending unsanitised code to browsers, I'm sure there will be developers in the wild crazy enough to do so as well.
  387. # [14:18] <othermaciej> one obviously shouldn't even remotely consider sending unsanitized code to browsers until sandbox="" is widely implemented, which won't be for a while
  388. # [14:19] <othermaciej> but even then it's probably not a good idea
  389. # [14:19] <othermaciej> defense in depth and all
  390. # [14:19] <Philip`> You could send unsanitised code in doc="" even if sandbox="" isn't implemented yet, as long as nobody implements doc="" before implementing sandbox=""
  391. # [14:20] <othermaciej> I'm willing to entertain the notion that adding sandbox="" could in some cases hurt security through second-order effects like you describe
  392. # [14:21] <othermaciej> but I think it is likely not the case, because the vast number of sites currently doing blacklist-based instead of whitelist-based sanitization may well be better off with sandbox="" and no server-side sanitization at all
  393. # [14:27] <Lachy> why? Blacklist sanitation is better than nothing, even though it's clearly a flawed approach.
  394. # [14:28] <virtuelv> blacklists do not scale
  395. # [14:28] <Lachy> virtuelv, yeah, I know that.
  396. # [14:28] <virtuelv> and especially if it's about cleaning markup
  397. # [14:28] <othermaciej> I would expect every blacklist-based filter to have holes, while browsers could plausibly implement sandbox="" close to correctly
  398. # [14:29] <othermaciej> nontheless, I think it is best to both filter on the server and use client-side restrictions
  399. # [14:34] * Joins: webben (n=benh@nat/yahoo/x-486bd7c0a10669ed)
  400. # [14:35] <Lachy> jgraham__, yt?
  401. # [14:36] <Lachy> jgraham__, are you ever intending to finish and publish that @media blog post on the whatwg blog?
  402. # [14:38] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  403. # [14:38] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  404. # [14:49] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Remote closed the connection)
  405. # [14:50] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  406. # [14:51] * Quits: tommorris (n=tommorri@i-83-67-98-32.freedom2surf.net)
  407. # [14:57] <zcorpan> Hixie: shouldn't currentLoop be readonly?
  408. # [15:16] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  409. # [15:22] * Quits: deane (n=dean@121-72-175-170.dsl.telstraclear.net)
  410. # [15:24] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  411. # [15:28] * Joins: Lachy (n=Lachlan@85.196.122.246)
  412. # [15:32] * Joins: itpastorn (n=itpastor@ne.keryx.se)
  413. # [15:38] * Joins: aroben (n=aroben@c-71-58-56-76.hsd1.pa.comcast.net)
  414. # [15:58] * Quits: mpt (n=mpt@canonical/launchpad/mpt) ("Ex-Chat")
  415. # [15:58] * Parts: Dashiiiva (n=noone@195.18.164.170)
  416. # [16:02] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  417. # [16:05] * Joins: Dashiiiva (n=noone@195.18.164.170)
  418. # [16:15] * Quits: itpastorn (n=itpastor@ne.keryx.se) ("Leaving.")
  419. # [16:20] * Joins: billmason (n=billmaso@ip232.unival.com)
  420. # [16:45] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) (Remote closed the connection)
  421. # [16:47] * Quits: roc (n=roc@121-72-162-128.dsl.telstraclear.net)
  422. # [16:58] * Joins: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  423. # [16:58] * Quits: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 104 (Connection reset by peer))
  424. # [16:59] * Joins: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  425. # [17:03] <annevk> If someone else wants to reply again to the sandboxing thread, be my guest. It seems obvious to me that his solution is flawed, but I can't really put it in words.
  426. # [17:05] <annevk> <applet> use case: http://wordle.net/gallery/Faux_Columns
  427. # [17:05] * Joins: smedero (n=smedero@mdp-nat251.mdp.com)
  428. # [17:05] * annevk can't see the outcome
  429. # [17:05] * Quits: zcorpan (n=zcorpan@pat.se.opera.com)
  430. # [17:06] * annevk isn't sure whether that justifies <applet> or whether it's a sign that plugins are harmful
  431. # [17:06] <Philip`> <applet ... /> ... </applet>
  432. # [17:07] <Philip`> Oh wait
  433. # [17:07] <Philip`> Ignore me, I can't read
  434. # [17:07] <Philip`> (I missed the '><param' in the middle)
  435. # [17:07] <annevk> quirks mode :/
  436. # [17:08] <Philip`> That seems like an unnecessarily fancy way to display a static image
  437. # [17:09] <annevk> <applet> has a print() method?
  438. # [17:09] <Philip`> Oh, apparently that is actually necessary, in order to put the computation load on the clients instead of the server
  439. # [17:12] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 110 (Connection timed out))
  440. # [17:12] <Philip`> (and it's not possible to do on the client even with the not-yet-implemented canvas text support, since it needs to analyse the shape of the characters)
  441. # [17:13] * Joins: csarven (n=csarven@on-irc.csarven.ca)
  442. # [17:22] * Joins: jgraham_ (n=james@81-86-219-217.dsl.pipex.com)
  443. # [17:34] * Joins: BenMillard (n=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  444. # [17:43] <csarven> Is Safari treating it properly if <object type="text/html" data="#foo"></object> includes the current document? Firefox2, Opera9.5 and IE7 doesn't.
  445. # [17:44] <annevk> per HTML5, yes
  446. # [17:45] <annevk> per HTML4, probably also yes
  447. # [17:48] <csarven> Good to here that.
  448. # [17:51] <csarven> Except that Safari includes the whole document and not just the contents of the element with id "foo"
  449. # [17:51] <gsnedders> csarven: that's right
  450. # [17:51] <annevk> csarven, that would be correct, actually
  451. # [17:51] <gsnedders> csarven: It should load the same as what loading a URI with a fragment would do normally
  452. # [17:51] <annevk> csarven, there's no special treatment specified
  453. # [17:52] <csarven> Is there a user for the fragment identifier then?
  454. # [17:52] <csarven> s/user/use
  455. # [18:00] <annevk> it will show that within the <object>
  456. # [18:00] <annevk> http://simon.html5.org/html5-elements uses that for instance
  457. # [18:09] <csarven> annevk I see an <iframe> instead of <object>
  458. # [18:09] <annevk> it would work the same way
  459. # [18:10] * Quits: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  460. # [18:15] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  461. # [18:26] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  462. # [18:28] <csarven> annevk If data value is a fragment identifier of the current page, is it expected for the UA to not request the current page seperately?
  463. # [18:30] <annevk> they're not handled specifically so I'd expect an additional request
  464. # [18:30] <annevk> though given that three browsers disagree with WebKit it might be worth noting somewhere to see whether Opera/Firefox are planning on fixing this
  465. # [18:34] * Quits: JohnResig (n=jresig@c-76-118-158-44.hsd1.ma.comcast.net)
  466. # [18:38] * Joins: Dashimon (i=Dashiva@199.84-48-51.nextgentel.com)
  467. # [18:44] * Joins: eseidel (n=eseidel@c-67-180-49-110.hsd1.ca.comcast.net)
  468. # [18:48] * Quits: Dashiva (n=noone@wikia/Dashiva) (Read error: 110 (Connection timed out))
  469. # [18:48] * Dashimon is now known as Dashiva
  470. # [18:48] * Quits: eseidel (n=eseidel@c-67-180-49-110.hsd1.ca.comcast.net) (Client Quit)
  471. # [18:49] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 113 (No route to host))
  472. # [18:49] * Joins: hasather (n=hasather@ti0034a380-3359.bb.online.no)
  473. # [18:52] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  474. # [18:57] * Joins: JohnResig (n=jresig@c-76-118-158-44.hsd1.ma.comcast.net)
  475. # [18:58] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  476. # [18:59] * Parts: BenMillard (n=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  477. # [19:05] * Joins: csarven- (n=csarven@on-irc.csarven.ca)
  478. # [19:11] * Quits: hasather (n=hasather@ti0034a380-3359.bb.online.no) (Read error: 110 (Connection timed out))
  479. # [19:15] * Quits: csarven (n=csarven@on-irc.csarven.ca) (Read error: 110 (Connection timed out))
  480. # [19:25] * csarven- is now known as csarven
  481. # [19:26] * Joins: tantek (n=tantek@137.164.255.6)
  482. # [19:41] * Joins: mpt_ (n=mpt@canonical/launchpad/mpt)
  483. # [19:49] * Joins: tantek_ (n=tantek@137.164.255.6)
  484. # [19:49] * Quits: tantek (n=tantek@137.164.255.6) (Read error: 104 (Connection reset by peer))
  485. # [19:57] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 113 (No route to host))
  486. # [20:03] * Joins: roc (n=roc@121-72-162-128.dsl.telstraclear.net)
  487. # [20:12] * Joins: virtuelv (n=virtuelv@192.80-203-77.nextgentel.com)
  488. # [20:12] * Quits: aaronlev (n=chatzill@f051105064.adsl.alicedsl.de) ("ChatZilla 0.9.82.1 [Firefox 3.0/2008052906]")
  489. # [20:12] * Joins: aaronlev (n=chatzill@f051105064.adsl.alicedsl.de)
  490. # [20:19] * Joins: hober (n=ted@unaffiliated/hober)
  491. # [20:20] * Joins: csarven- (n=csarven@on-irc.csarven.ca)
  492. # [20:21] * Quits: csarven (n=csarven@on-irc.csarven.ca) (Nick collision from services.)
  493. # [20:21] * csarven- is now known as csarven
  494. # [20:23] <Hixie> hsivonen: as far as i can tell, all the examples you posted and what othermaciej was saying are consistent with the spec
  495. # [20:24] <hsivonen> Hixie: yeah, they are. my understanding of document.write was flawed. sorry.
  496. # [20:25] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  497. # [20:25] * Joins: KevinMarks (n=KevinMar@137.164.255.6)
  498. # [20:27] <Hixie> np
  499. # [20:28] * Joins: eseidel (n=eseidel@nat/google/x-07c60711a668ab9c)
  500. # [20:31] * Joins: sverrej (n=sverrej@84.38.144.42)
  501. # [21:03] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  502. # [21:05] * Quits: KevinMarks (n=KevinMar@137.164.255.6) ("The computer fell asleep")
  503. # [21:12] <hsivonen> I could use a more detailed diagram of how document.write is supposed to work
  504. # [21:13] <hsivonen> I'm having doubts about whether the "insertion point" is the most intuitive concept
  505. # [21:14] <hsivonen> and if treating document.written data as separate buffers that get pushed to the tokenizer would be easier to grasp
  506. # [21:17] * Quits: tantek_ (n=tantek@137.164.255.6)
  507. # [21:25] * Joins: othermaciej_ (n=mjs@nat/apple/x-d83e54a4c6c105d8)
  508. # [21:27] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  509. # [21:27] <zcorpan_> googling for "acid3" shows a link "FAIL" to http://acid3.acidtests.org/empty.txt , that's pretty funny
  510. # [21:28] <zcorpan_> Hixie: clearly, google isn't standards compliant
  511. # [21:30] <Lachy> is anyone here actually able to load getfirefox.com and download FF3 now? I can't connect.
  512. # [21:30] <webben> Lachy: That's a common experience.
  513. # [21:31] <Lachy> it's not good enough. How do they expect to break a world record like this?
  514. # [21:31] <webben> are they trying to?
  515. # [21:31] <Lachy> yes, haven't you heard?
  516. # [21:31] <zcorpan_> Lachy: wfm
  517. # [21:31] <didymos> Lachy, John Gruber at Daring Fireball is saying the same thing
  518. # [21:32] <Lachy> http://weblogs.mozillazine.org/asa/archives/2008/06/download_day_st.html
  519. # [21:32] <webben> nah, I've studiously avoided all the hypes and just kept downloading latest prereleases ;)
  520. # [21:32] <didymos> personally, I got there at first attempt (just now)
  521. # [21:32] <Lachy> the link to the world record page won't work either.
  522. # [21:32] <webben> yeah, was just gonna say ;)
  523. # [21:33] <Hixie> google fails acid2 as well iirc
  524. # [21:34] <zcorpan_> Hixie: that clearly shows google's commitment to standards ;)
  525. # [21:34] <Lachy> google is a non-visual UA with little, if any, support for JS. So it doesn't really have much hope of fully passing the tests.
  526. # [21:37] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  527. # [21:39] * Quits: othermaciej_ (n=mjs@nat/apple/x-d83e54a4c6c105d8) (Read error: 104 (Connection reset by peer))
  528. # [21:40] * Joins: othermaciej_ (n=mjs@nat/apple/x-39ce087fe668d5b1)
  529. # [21:40] * zcorpan_ finds registerProtocolHandler() in the firefox advanced tips
  530. # [21:45] * zcorpan_ finds that http://www.mozilla.com/js/firefox-video-launch.js is text/html
  531. # [21:46] <gsnedders> zcorpan_: Who needs correct MIME types?
  532. # [21:46] <zcorpan_> gsnedders: indeed
  533. # [21:55] * Quits: roc (n=roc@121-72-162-128.dsl.telstraclear.net)
  534. # [21:56] * Joins: csarven- (n=csarven@on-irc.csarven.ca)
  535. # [21:58] * Quits: sverrej (n=sverrej@84.38.144.42) (Remote closed the connection)
  536. # [21:58] * Quits: csarven- (n=csarven@on-irc.csarven.ca) (Read error: 104 (Connection reset by peer))
  537. # [22:00] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Remote closed the connection)
  538. # [22:01] <hsivonen> Hixie: I'm reading https://bugzilla.mozilla.org/show_bug.cgi?id=95487#c39
  539. # [22:01] * Hixie learns his backup system has been broken since february
  540. # [22:01] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  541. # [22:01] <Hixie> "oops"
  542. # [22:02] <hsivonen> Hixie: which seems to confirm my guess that document.written content is parsed without letting the event loop breathe
  543. # [22:02] <Hixie> sounds plausible
  544. # [22:03] <hsivonen> Hixie: does the spec expect the relationship of normal parsing and the first level of doc.write and the relationship of the first and second levels of doc.write to be different somehow
  545. # [22:03] <hsivonen> ?
  546. # [22:03] <Hixie> yes, you can only recurse once
  547. # [22:03] * Joins: hasather_ (n=hasather@cm-84.215.63.253.getinternet.no)
  548. # [22:04] <hsivonen> Hixie: what takes care of preventing deeper recursion?
  549. # [22:04] * Hixie looks
  550. # [22:05] * hsivonen wonders if document.write was considered a simple feature in the Netscape 2 design phase
  551. # [22:06] <Philip`> I imagine they designed it to be simple to implement in their architecture, and as hard as possible for any competitors to implement in their different architectures :-)
  552. # [22:07] * Joins: othermaciej (n=mjs@17.255.105.164)
  553. # [22:07] * Quits: csarven (n=csarven@on-irc.csarven.ca) (Read error: 110 (Connection timed out))
  554. # [22:08] <Hixie> hsivonen: step 3 of document.write()
  555. # [22:08] <hsivonen> "If there is a script that will execute as soon as the parser resumes, then the method must now return without further processing of the input stream."?
  556. # [22:09] <hsivonen> why does the behavior othermaciej showed earlier follow?
  557. # [22:09] <Hixie> yeah
  558. # [22:09] * Joins: KevinMarks (n=KevinMar@137.164.255.6)
  559. # [22:10] <hsivonen> in that case, the second level of document.write wrote a third level of script that executed similarly relative to the second level as the second level did relative to the first level
  560. # [22:11] <Hixie> give me a concrete example and i'll try to describe how it runs
  561. # [22:11] <hsivonen> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cscript%3E%0D%0Adocument.write('a')%3B%0D%0Aalert(1)%3B%0D%0Adocument.write('%3Cscript%3Edocument.write(%22b%3Cscript%3Edocument.write(%5C'c%5C')%3B%20alert(4)%3B%3C%5C%5C%2Fscript%3E%22)%3B%20alert(3)%3B%3C%5C%2Fscript%3E')%3B%0D%0Aalert(2)%3B%0D%0Adocument.write('d')%3B%0D%0A%3C%2Fscript%3E%0D%0A
  562. # [22:11] <othermaciej> it looks like in Firefox and WebKit at least execute scripts that are document.written while executing another script
  563. # [22:11] <othermaciej> I made this test case:
  564. # [22:11] <othermaciej> <script>
  565. # [22:11] <othermaciej> document.write('a');
  566. # [22:11] <othermaciej> alert(1);
  567. # [22:11] <othermaciej> document.write('<script>document.write("b<script>document.write(\'c\'); alert(4);<\\/script>"); alert(3);<\/scr\
  568. # [22:11] <othermaciej> ipt>');
  569. # [22:11] <othermaciej> alert(2);
  570. # [22:11] <othermaciej> document.write('d');
  571. # [22:11] <othermaciej> </script>
  572. # [22:11] <othermaciej> (sorry for bad line break)
  573. # [22:11] <othermaciej> it alerts 1 4 3 2
  574. # [22:11] <othermaciej> but prints abcd
  575. # [22:13] <Hixie> ok hsivonen
  576. # [22:13] <Hixie> so
  577. # [22:13] <gsnedders> jgraham__: ping
  578. # [22:14] <Hixie> we tokenise up to the bottom of the input
  579. # [22:14] <jgraham_> gsnedders: Here, sorta
  580. # [22:15] <gsnedders> jgraham_: How do you get what's under `elif rank(element) >= rank(self.current_section.heading):` from the spec?
  581. # [22:15] <Hixie> then we create a <Script> element and mark it "parser-inserted"
  582. # [22:16] * Joins: weinig (n=weinig@17.203.15.145)
  583. # [22:16] <Hixie> let "old insertion point" be "uninitialised"
  584. # [22:16] <Hixie> let "insertion point" be just after the </script>
  585. # [22:17] <Hixie> we then insert the element into the DOM and run the script, which goes as follows:
  586. # [22:18] <Hixie> first a call to document.write()
  587. # [22:18] <Hixie> step 1: insertion point is defined, skip this step
  588. # [22:19] <Hixie> step 2: "a" is inserted after </script>
  589. # [22:19] <Hixie> step 3: skip this step
  590. # [22:19] * Joins: tantek (n=tantek@137.164.255.6)
  591. # [22:19] <gsnedders> jgraham_: As far as I can see, you deviate from the spec
  592. # [22:20] <Hixie> step 4: run the tokeniser on the new input (just "a"), which just causes a text node saying "a" to be appended after the <script> in the DOM
  593. # [22:20] <Hixie> step 5: return
  594. # [22:20] <Hixie> next an alert. we alert "1".
  595. # [22:20] <Hixie> next another document.write().
  596. # [22:20] <Hixie> step 1: insertion point is defined, skip this step
  597. # [22:20] <jgraham_> gsnedders: I'll have a look.
  598. # [22:21] <gsnedders> jgraham_: Meaning Hixie's algorithm is broken, and it's not an implementation bug on my behalf
  599. # [22:21] * gsnedders hopes it is Hixie's fault so then he doesn't have to deal with it :P
  600. # [22:21] <Hixie> step 2: just after the "a" (and before the insertion point) we insert |<script>document.write("b<script>document.write('c'); alert(4);<\/script>"); alert(3);</script>|.
  601. # [22:21] <Hixie> step 3: skip this step
  602. # [22:21] * Quits: webben (n=benh@nat/yahoo/x-486bd7c0a10669ed)
  603. # [22:22] <Hixie> step 4: run the tokeniser:
  604. # [22:22] * Quits: othermaciej_ (n=mjs@nat/apple/x-39ce087fe668d5b1) (Read error: 110 (Connection timed out))
  605. # [22:22] <Hixie> we tokenise a <script>
  606. # [22:22] <Hixie> create a <script> element.
  607. # [22:22] <Hixie> mark it as "parser-inserted".
  608. # [22:23] <Hixie> tokenise until we get the </script>, and append that string to the <script>
  609. # [22:23] <Hixie> let "old insertion point" be just after the last inserted piece of text (basically the end of the file)
  610. # [22:24] * Quits: weinig (n=weinig@17.203.15.145)
  611. # [22:24] <gsnedders> jgraham_: I must be blind if it is in the spec :)
  612. # [22:24] <Hixie> we let "insertion point" be the same, actually.
  613. # [22:25] <Hixie> append the <script> to the DOM
  614. # [22:25] <Lachy> hmm, weird. Whenver I'm able to load getfirefox.com, it still links to Firefox 2
  615. # [22:25] <Hixie> this is the script that says |document.write("b<script>document.write('c'); alert(4);<\/script>");alert(3);|
  616. # [22:26] <Hixie> it's inline, so it executes.
  617. # [22:26] <jgraham_> gsnedders: I really should have commented this code more :)
  618. # [22:26] <Hixie> we call document.write() again.
  619. # [22:26] <jgraham_> The relevant part of the spec is "Otherwise, if the element being entered has a rank equal to or greater than the heading of the current section, then create a new section and append it to the outline of the current outlinee element, so that this new section is the new last section of that outline. Let current section be that new section. Let the element being entered be the new heading for the current section."
  620. # [22:26] <jgraham_> But I have no idea if that's the same as my implementation or not
  621. # [22:27] <hsivonen> Hixie: so far, we haven't had "a script that will execute as soon as the parser resumes", right?
  622. # [22:27] <Hixie> correct (in fact i think we won't because in this example you never have <script src="">)
  623. # [22:27] <gsnedders> jgraham_: It's totally different
  624. # [22:28] <gsnedders> jgraham_: the spec needs three lines
  625. # [22:28] <Hixie> so i guess the spec doesn't (and shouldn't) limit it to two deep for inline scripts
  626. # [22:28] <gsnedders> jgraham_: and no loop
  627. # [22:28] <Hixie> do you want me to continue?
  628. # [22:28] <hsivonen> Hixie: no need to. thank you.
  629. # [22:28] <Hixie> k
  630. # [22:29] * Hixie breathes a sigh of relief because this was getting complicated
  631. # [22:29] <hsivonen> Hixie: the concept of "a script that will execute as soon as the parser resumes" could be more clearly named so that the reader wouldn't try to see if an inline script can be it
  632. # [22:29] <Hixie> any suggestions for a better name?
  633. # [22:30] <Hixie> an external script, maybe?
  634. # [22:30] <hsivonen> not before I have figured out what exactly it is
  635. # [22:30] <gsnedders> http://pastebin.com/m7524f744 — that's the rather bogus TOC I'm getting
  636. # [22:30] <jgraham_> gsnedders: http://lists.w3.org/Archives/Public/public-html/2008Mar/0032.html
  637. # [22:30] <hsivonen> if it always an external script, then, yes, "external script" would be good
  638. # [22:30] <gsnedders> Hixie: Fix that!
  639. # [22:30] <hsivonen> no I have to learn why their execution has different steps :-/
  640. # [22:30] * gsnedders runs and hides
  641. # [22:31] * gsnedders implements jgraham_'s prose
  642. # [22:31] <Hixie> hsivonen: external scripts have to be downloaded
  643. # [22:31] <hsivonen> Hixie: did my email "Re-entrant invocation of the tree builder" make sense?
  644. # [22:31] <Hixie> when did you send it?
  645. # [22:31] <hsivonen> public-html
  646. # [22:32] * zcorpan_ wonders if public-html is a moment in time
  647. # [22:32] <Hixie> oh just now
  648. # [22:32] <hsivonen> oops. I misread when as where
  649. # [22:33] <hsivonen> 45 minutes ago
  650. # [22:34] * Hixie works out why his backup wasn't working
  651. # [22:35] <Hixie> it was trying to back up three machines
  652. # [22:35] <Hixie> the first one is one that i turned off in february
  653. # [22:35] <Hixie> so my makefile was failing
  654. # [22:35] <Hixie> oops
  655. # [22:36] <jgraham_> gsnedders: You can always vote in favour of the issue :)
  656. # [22:36] <gsnedders> jgraham_: Coward! Just bully Hixie!
  657. # [22:36] <hsivonen> a <script src> load stops the world until loaded, right?
  658. # [22:37] <Hixie> gsnedders: (will get to your issue momentarily)
  659. # [22:37] <Hixie> hsivonen: not if it's nested deeply enough, iirc
  660. # [22:39] * gsnedders realises he has no way to get at the parent of a section
  661. # [22:40] <hsivonen> Hixie: I guess I should convert othermaciej's example to use external scripts and see how the scripts run
  662. # [22:40] <hsivonen> having them run differently than in the inline case seems counter-intuitive
  663. # [22:41] <gsnedders> jgraham_: self[::-1] — what do two colons do?
  664. # [22:41] <Hixie> hsivonen: oh, no, wait
  665. # [22:41] <Hixie> hsivonen: the problem is this
  666. # [22:41] <Hixie> hsivonen: it's a script the document.write()s multiple things in a row
  667. # [22:41] <Hixie> hsivonen: one of which is external
  668. # [22:41] <Hixie> hsivonen: it doesn't block script execution iirc
  669. # [22:41] <Hixie> hsivonen: only the parser
  670. # [22:42] <hsivonen> like document.write("<script src=foo><\/script><script src=bar><\/script>")
  671. # [22:42] <hsivonen> ?
  672. # [22:43] <Philip`> gsnedders: things[x:y:z] means things[x], things[x+z], things[x+2*z], ... up to things[x+n*z] where n is the maximum number such that x+n*z < y, or something like that
  673. # [22:43] <Philip`> gsnedders: and if x is omitted it means 0, and if y is omitted it means len(things)
  674. # [22:44] <Philip`> gsnedders: oh but my explanation breaks down a bit
  675. # [22:44] <Hixie> hsivonen: more like document.write("<script src=alert2><\/script>");alert(1);
  676. # [22:44] <Philip`> gsnedders: but if you ignore all the details, then that means self[::-1] is just reversed(self)
  677. # [22:44] <hsivonen> Hixie: that seems counter-intuitive
  678. # [22:44] <Philip`> gsnedders: (but compatible with older Pythons that don't have 'reversed')
  679. # [22:45] <gsnedders> Philip`: ah
  680. # [22:45] <Hixie> hsivonen: specifically, <script>document.write("<script src=alert2><\/script>");document.write("this won't be tokenised until after the alert1 and alert2");alert(1);</script>
  681. # [22:45] <Hixie> hsivonen: see the /topic
  682. # [22:45] <hsivonen> Hixie: thanks. I need to study this in detail.
  683. # [22:47] <Hixie> when you test this beware of hitting the cache; in some browsers that changes the behaviour
  684. # [22:47] <Hixie> html5 goes out of its way not to be cache-sensitive here
  685. # [22:47] <hsivonen> fun!
  686. # [22:48] * Quits: ROBOd2 (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  687. # [22:49] <jgraham_> gsnedders: What Philip` said. http://www.python.org/doc/2.3.5/whatsnew/section-slices.html
  688. # [22:49] <Hixie> hsivonen: specifically in the spec this is implemented by having the "pause until the script has completed loading" be only ever executed in the very outer tree construction invokcation
  689. # [22:49] <Hixie> invocation
  690. # [22:53] * Joins: aaronlev_ (n=chatzill@f051105064.adsl.alicedsl.de)
  691. # [22:55] <hsivonen> Hixie: so regarding my email, I could substitute checking if the tree builder is invoked recursively with checking if there's a document.write on the call stack?
  692. # [22:57] <Hixie> i believe that is currently equivalent, yes
  693. # [22:57] <Hixie> be wary of changes that violate that assumption, in case we ever add other ways to be reentrant
  694. # [22:57] <hsivonen> Hixie: thanks
  695. # [22:58] <hsivonen> Hixie: it seems that it's necessary to keep track of document.write nesting level anyway: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/html/document/src/nsHTMLDocument.cpp&rev=3.785&mark=2417-2420#2413
  696. # [22:59] * Quits: othermaciej (n=mjs@17.255.105.164)
  697. # [23:00] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Remote closed the connection)
  698. # [23:01] <Hixie> hsivonen: there are other ways to implement that restriction
  699. # [23:01] <Hixie> replid to your mail btw
  700. # [23:02] <Hixie> replied
  701. # [23:02] <hsivonen> Hixie: restricting recursion depth?
  702. # [23:02] <hsivonen> Hixie: thanks
  703. # [23:02] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  704. # [23:03] <Hixie> well what you really want to make sure is that a document.write() doesn't write a script that does another document.write(), but there's no guarantee that the second will be run while the first is on the call stack
  705. # [23:03] <Hixie> (or rather, you want to block that but only when it's in an infinite loop)
  706. # [23:03] * Quits: jgraham_ (n=james@81-86-219-217.dsl.pipex.com) ("I get eaten by the worms")
  707. # [23:04] <Hixie> another way is just to limit how much cpu/ram a script can use
  708. # [23:04] <gsnedders> Infinite loops are _awesome_!
  709. # [23:05] <gsnedders> I mean, how else are you going to use a modern CPU?
  710. # [23:05] * Joins: othermaciej (n=mjs@17.255.105.164)
  711. # [23:05] <hsivonen> Hixie: I'll have to ponder your point about appending to a buffer on stack tomorrow
  712. # [23:05] <hsivonen> it's past my bed time
  713. # [23:05] <Hixie> nn
  714. # [23:06] <hsivonen> nn.
  715. # [23:06] <Hixie> and thanks for implementing this
  716. # [23:06] <Hixie> it's good to have someone look at it this closely
  717. # [23:10] * Quits: aaronlev (n=chatzill@f051105064.adsl.alicedsl.de) (Connection timed out)
  718. # [23:16] * Quits: qwert666 (n=qwert666@acai2.neoplus.adsl.tpnet.pl) ("Leaving")
  719. # [23:20] * Joins: roc (n=roc@202.0.36.64)
  720. # [23:22] <zcorpan_> Hixie: the spec annotation system gives 500 when trying to log in
  721. # [23:23] <Hixie> yeah
  722. # [23:23] <Hixie> i need to reboot the server
  723. # [23:23] * zcorpan_ was going to add a pointer to http://simon.html5.org/test/html/dom/interfaces/HTMLElement/HTMLMediaElement/ somewhere
  724. # [23:23] <Hixie> for some reason dreamhost have apache set to spawn more processes than the server can handle, and it doesn't reap them
  725. # [23:23] <Hixie> so we run out of ram
  726. # [23:23] <zcorpan_> buy more ram :)
  727. # [23:24] <Hixie> send me money :-)
  728. # [23:24] <zcorpan_> doh :(
  729. # [23:24] <zcorpan_> you should be happy i'm writing tests! :-p
  730. # [23:25] <zcorpan_> though the ones i've got so far are pretty boring
  731. # [23:26] <Hixie> :-)
  732. # [23:26] <Hixie> try now
  733. # [23:27] <zcorpan_> still 500
  734. # [23:27] <Hixie> sigh
  735. # [23:28] <Hixie> try now
  736. # [23:28] <zcorpan_> still
  737. # [23:28] <zcorpan_> i'll try tomorrow
  738. # [23:28] <zcorpan_> bedtime
  739. # [23:28] <Hixie> nn
  740. # [23:29] <zcorpan_> nn
  741. # [23:29] * Parts: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  742. # [23:29] * Joins: manko (n=asdf@ip2-195.thearbours.orl.ygnition.net)
  743. # [23:31] <Lachy> Hixie, how much does dreamhost charge for your private server?
  744. # [23:31] * Joins: weinig (n=weinig@17.203.15.145)
  745. # [23:32] <Hixie> $1 per 10 MHz CPU and 10MB RAM per month
  746. # [23:32] <Lachy> and how much do you pay for?
  747. # [23:33] <Hixie> varies based on load
  748. # [23:33] <Lachy> ok
  749. # [23:33] <Hixie> right now (high load on acid3 for no apparent reason) i'm using just under 1.5GB RAM
  750. # [23:35] <Philip`> The release of Firefox 3 seems like an apparent reason for people to try Acid3
  751. # [23:36] <Lachy> it only scores 51
  752. # [23:36] <Hixie> yeah that was my reasoning too, but the referrers were all over hte place
  753. # [23:36] <roc> Lachy: no way, it should be over 70
  754. # [23:36] <Lachy> oh, 71. It just paused at 51 for some reasonj
  755. # [23:36] <Philip`> You ought to just cache the results based on UA string - there's no point having a hundred million people run the same test with an identical browser, and it's an awful waste of energy
  756. # [23:36] <Hixie> heh
  757. # [23:37] <othermaciej> there's some networking in the middle of the test
  758. # [23:37] <Hixie> yeah run it twice to get real results, otherwise your network will have too much effect on the test
  759. # [23:38] * Lachy just runs his localhost copy of the test so it doesn't suffer from network issues
  760. # [23:38] <othermaciej> I told people to try the Safari 4 Developer Preview on Acid3 at WWDC, but I doubt that generated a whole lot of traffic
  761. # [23:38] <Hixie> ok yeah running the logs through just checking the UA string instead of the referrer does indeed indicate that it's all ff3 users
  762. # [23:38] <Hixie> mostly on xp
  763. # [23:38] * Philip` just looks on Wikipedia to get the Acid3 results
  764. # [23:38] <Hixie> some opera 9.5 users too
  765. # [23:39] <Lachy> othermaciej, how recent is Safari 4 compared to the latest nightly WebKit?
  766. # [23:39] <gsnedders> Hixie: Can you deal with <http://lists.w3.org/Archives/Public/public-html/2008Mar/0032.html> over night?
  767. # [23:39] <othermaciej> Lachy: it's an older WebKit, but a newer Safari (although you can run a nightly with S4DP installed)
  768. # [23:40] <Lachy> is Safari 4 only available to people with ADC accounts?
  769. # [23:40] <othermaciej> the preview is up on ADC, which you need an account to access, but getting an ADC account is free
  770. # [23:41] <Lachy> ok, I have a free account.
  771. # [23:41] <Hixie> gsnedders: ok
  772. # [23:42] <othermaciej> Lachy: you should be able to get it then (though I am not sure how to find the download, probably the search feature will find it)
  773. # [23:43] <Lachy> yeah, found it.
  774. # [23:43] <Lachy> when you log in, there's a link that says downloads and it's the 3rd listed under What's New
  775. # [23:43] * manko is now known as White_Leviathan
  776. # [23:43] <othermaciej> cool
  777. # [23:44] <Lachy> does it have any cool new UI features that weren't in Safari 3?
  778. # [23:45] <smedero> Lachy: It handles what Fluid does nicely http://fluidapp.com/ (creating dedicated "apps" for websites)
  779. # [23:47] <Lachy> ok. Why do I have to restart after installing Safari? It's like a Windows installer! :-(
  780. # [23:47] <Lachy> brb
  781. # [23:47] * Quits: Lachy (n=Lachlan@85.196.122.246) ("Leaving")
  782. # [23:49] * weinig is now known as weinig|coffee
  783. # [23:49] * Joins: Lachy (n=Lachlan@85.196.122.246)
  784. # [23:52] <othermaciej> Lachy: you can actually force quit the installer when it tells you to reboot, as long as you quit all WebKit apps
  785. # [23:52] <othermaciej> Lachy: if you are willing to live on the edge a little
  786. # [23:53] <Lachy> ah, too late. I already restarted.
  787. # [23:53] <othermaciej> anyway, it has "Save as Web Application" which among other things supports HTML5 <link rel="icon" sizes=...> and <meta name="application-name" ...>
  788. # [23:53] <Lachy> oh, nice.
  789. # [23:54] * Quits: eseidel (n=eseidel@nat/google/x-07c60711a668ab9c)
  790. # [23:54] <Hixie> the installer should probably list the applications you have to close instead of just rebooting :-)
  791. # [23:54] <othermaciej> http://webkit.org/blog has the right markup
  792. # [23:54] <othermaciej> if you wanna test it out
  793. # [23:54] <Lachy> better yet, the installer should just tell me which applications it wants to close, ask if it's ok and do it automatically
  794. # [23:55] <othermaciej> (but it will genreate a name and icon if needed)
  795. # [23:55] * Quits: virtuelv (n=virtuelv@192.80-203-77.nextgentel.com) ("Ex-Chat")
  796. # [23:55] <othermaciej> sadly I am not an installer engineer, but I see you rpoint
  797. # [23:57] * Parts: hasather_ (n=hasather@cm-84.215.63.253.getinternet.no)
  798. # [23:59] * Quits: smedero (n=smedero@mdp-nat251.mdp.com) (Read error: 104 (Connection reset by peer))
  799. # [23:59] <Lachy> othermaciej, http://webkit.org/images/surfin-safari.icns is served as text/plain.
  800. # [23:59] <othermaciej> Lachy: I guess I should figure out how to reconfigure the server
  801. # [23:59] <Lachy> and although Firefox sniffed it as binary, Safari didn't and displayed a lot of jibberish.
  802. # Session Close: Wed Jun 18 00:00:00 2008

The end :)