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

Options:

  1. # Session Start: Sun May 31 00:00:00 2009
  2. # Session Ident: #whatwg
  3. # [00:01] * Joins: archtech (n=stanv@83.228.56.37)
  4. # [00:03] * Joins: riven`` (n=colin@53525B67.cable.casema.nl)
  5. # [00:04] <Dashiva> jgraham: I made the same mistake yesterday, when the fix was discussed
  6. # [00:04] <Dashiva> You end up in "in head", but the stack has body. Sneaky!
  7. # [00:08] * jgraham thinks he has done his merge the wrong way around
  8. # [00:09] <jgraham> So I have ended up with the tip on a branch called svgmathml
  9. # [00:14] * Joins: sayrer (n=chatzill@66.28.50.6)
  10. # [00:18] * Joins: gsnedders (n=gsnedder@host86-164-130-180.range86-164.btcentralplus.com)
  11. # [00:20] <gsnedders> Oh, if only HTML were logical…
  12. # [00:20] * Quits: riven` (n=colin@53525B67.cable.casema.nl) (Read error: 110 (Connection timed out))
  13. # [00:22] * Quits: Maurice (n=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
  14. # [00:23] <Hixie> > For example, perhaps the document should advised following
  15. # [00:23] <Hixie> > the algorithms only when it is clearly necessary
  16. # [00:23] <Hixie> > (SHOULD NOT perform content sniffing EXCEPT when
  17. # [00:23] <Hixie> > necessary because of continued misconfiguration of
  18. # [00:23] <Hixie> > HTTP servers),
  19. # [00:23] * Hixie wonders how that would work
  20. # [00:23] * Joins: riven` (n=colin@53525B67.cable.casema.nl)
  21. # [00:24] <Philip`> You could add a X-Not-Misconfigured header to servers that aren't misconfigured
  22. # [00:24] <takkaria> ha
  23. # [00:25] <Hixie> lol
  24. # [00:26] * Quits: riven`` (n=colin@53525B67.cable.casema.nl) (Read error: 60 (Operation timed out))
  25. # [00:31] * Quits: archtech (n=stanv@83.228.56.37) (Client Quit)
  26. # [00:34] <gsnedders> Content-Type-But-I-Really-Mean-It-This-Time?
  27. # [00:35] * Joins: archtech (n=stanv@83.228.56.37)
  28. # [00:36] <Philip`> Quite a few people use X-Content-Type-Options: nosniff already
  29. # [00:36] <Dashiva> Recreate the universe so that all http servers ship with an automatic legacy: true header? :)
  30. # [00:36] <Philip`> (including most Google sites)
  31. # [00:39] <Philip`> You don't need to recreate the universe, you just need to shift into a worldtrack in which that's already true
  32. # [00:44] * Joins: riven`` (n=colin@53525B67.cable.casema.nl)
  33. # [00:45] <Hixie> hsivonen! curse you for filing bug 6766!
  34. # [00:46] <Hixie> ok which browser should i base document.all on
  35. # [00:46] <Hixie> any browser vendors here want to bribe me to make theirs the compliant one? :-P
  36. # [00:54] <annevk42> I'm not sure I'm in favor of Opera's one. Can I get money from you for the reverse favor?
  37. # [01:01] * Quits: riven` (n=colin@53525B67.cable.casema.nl) (Read error: 110 (Connection timed out))
  38. # [01:02] <Hixie> who should i use instead?
  39. # [01:02] * Quits: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  40. # [01:04] * Joins: riven` (n=colin@53525B67.cable.casema.nl)
  41. # [01:05] <annevk42> It seems best to be informed by all crappy impl of it
  42. # [01:06] <Hixie> heycam: yt?
  43. # [01:13] * Joins: dglazkov (n=dglazkov@69.181.143.54)
  44. # [01:18] * Joins: jacobolus_ (n=jacobolu@pool-71-104-172-183.lsanca.dsl-w.verizon.net)
  45. # [01:18] * jacobolus_ is now known as jacobolus
  46. # [01:22] * Quits: riven`` (n=colin@53525B67.cable.casema.nl) (Read error: 110 (Connection timed out))
  47. # [01:30] * Quits: jruderman (n=jruderma@c-98-248-40-206.hsd1.ca.comcast.net)
  48. # [01:32] * Joins: riven`` (n=colin@53525B67.cable.casema.nl)
  49. # [01:34] * Joins: jruderman (n=jruderma@c-98-248-40-206.hsd1.ca.comcast.net)
  50. # [01:35] * Quits: jruderman (n=jruderma@c-98-248-40-206.hsd1.ca.comcast.net) (Client Quit)
  51. # [01:35] * Joins: jruderman (n=jruderma@c-98-248-40-206.hsd1.ca.comcast.net)
  52. # [01:40] * Quits: kangax (n=kangax@ool-182f8118.dyn.optonline.net)
  53. # [01:43] * Quits: riven` (n=colin@53525B67.cable.casema.nl) (Read error: 110 (Connection timed out))
  54. # [01:46] * Joins: riven` (n=colin@53525B67.cable.casema.nl)
  55. # [01:47] * Joins: syp__ (n=syp@lasigpc9.epfl.ch)
  56. # [01:48] * Quits: riven`` (n=colin@53525B67.cable.casema.nl) (Read error: 60 (Operation timed out))
  57. # [01:51] * Quits: syp_ (n=syp@lasigpc9.epfl.ch) (Read error: 104 (Connection reset by peer))
  58. # [02:01] * Quits: cying (n=cying@adsl-75-41-114-136.dsl.pltn13.sbcglobal.net)
  59. # [02:10] * Joins: wakaba (n=wakaba@EM114-51-30-120.pool.e-mobile.ne.jp)
  60. # [02:16] * Quits: jruderman (n=jruderma@c-98-248-40-206.hsd1.ca.comcast.net) (Remote closed the connection)
  61. # [02:16] * Joins: jruderman (n=jruderma@c-98-248-40-206.hsd1.ca.comcast.net)
  62. # [02:22] * Joins: hdh (n=hdh@58.187.204.77)
  63. # [02:23] * Joins: riven`` (n=colin@53525B67.cable.casema.nl)
  64. # [02:24] * Quits: riven` (n=colin@53525B67.cable.casema.nl) (Read error: 110 (Connection timed out))
  65. # [02:25] * riven`` is now known as riven
  66. # [02:29] * Quits: wakaba_ (n=wakaba@EM114-51-130-21.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  67. # [02:33] * Joins: jacobolus_ (n=jacobolu@pool-71-104-172-183.lsanca.dsl-w.verizon.net)
  68. # [02:33] * Quits: jacobolus (n=jacobolu@pool-71-104-172-183.lsanca.dsl-w.verizon.net) (Read error: 104 (Connection reset by peer))
  69. # [02:34] * jacobolus_ is now known as jacobolus
  70. # [02:44] * Quits: riven (n=colin@pdpc/supporter/professional/riven) (Read error: 110 (Connection timed out))
  71. # [02:52] * Joins: nessy (n=nessy@124-168-245-234.dyn.iinet.net.au)
  72. # [02:55] <Hixie> document.all seems to be a pretty normal collection, with all the elements in it; calling it is the same as dereferencing it
  73. # [02:55] * Quits: dglazkov (n=dglazkov@69.181.143.54)
  74. # [02:55] <Hixie> and in IE all collections seem to have .tags() method that returns a filtered collection with just the members of that tag name
  75. # [02:56] <Hixie> after lowercasing
  76. # [03:00] <heycam> Hixie, here now
  77. # [03:01] <Hixie> heycam: any chance we can get magic in WebIDL that defines document.all's wacko behavior? :-)
  78. # [03:01] <Hixie> i may have asked this before
  79. # [03:01] * Quits: sayrer (n=chatzill@66.28.50.6) (Read error: 110 (Connection timed out))
  80. # [03:01] <Hixie> interesting, IE8's namedItem() method broke compatibility with earlier versions
  81. # [03:02] <Hixie> i wonder if they did that because of trying to be compatible with the specs or something
  82. # [03:02] <heycam> what's the wacko behaviour?
  83. # [03:05] <Hixie> if (document.all) { throw 0; } doesn't throw
  84. # [03:05] <gavin_> in non-IE browsers only, right?
  85. # [03:06] * Joins: kangax (n=kangax@ool-182f8118.dyn.optonline.net)
  86. # [03:06] <Hixie> typeof document.all === undefined
  87. # [03:06] <gavin_> Mozilla had to make it "undetectable" when we implemented it, because sites used that to check for IE
  88. # [03:06] * Quits: kangax (n=kangax@ool-182f8118.dyn.optonline.net) (Client Quit)
  89. # [03:06] <Hixie> document.all.toString() is something like "[object HTMLCollection]"
  90. # [03:06] <Hixie> (will probably be [object HTMLAllCollection] in HTML5)
  91. # [03:07] <Hixie> document.all instanceof HTMLCollection === false
  92. # [03:07] * Joins: olliej (n=oliver@76.14.73.3)
  93. # [03:07] <heycam> such wackoness seems like it shouldn't be in webidl
  94. # [03:07] <Hixie> document.all.length == document.getElementsByTagName('*').length
  95. # [03:08] <Hixie> the object returned by document.all is callable and needs WebIDL's property indexing stuff
  96. # [03:08] <heycam> ok so that bit should be supported already
  97. # [03:08] <Hixie> the main reason i was hoping you'd be ok with adding that to webidl is i have no idea what i should be saying in html5 :-)
  98. # [03:08] <heycam> aha :)
  99. # [03:09] <heycam> there's no way in ecma-262 to legally have an object that is "undetectable" like that
  100. # [03:10] <Hixie> yeah well we already violate e262 for one thing, what's one more!
  101. # [03:10] * Joins: wakaba_ (n=wakaba@EM114-51-159-43.pool.e-mobile.ne.jp)
  102. # [03:10] <heycam> i don't though, my hands are clean thus far =)
  103. # [03:11] <Hixie> hah
  104. # [03:12] <heycam> do people really do if (document.all instanceof HTMLCollection) to test for IE?
  105. # [03:12] <Hixie> no
  106. # [03:13] <Hixie> they probably do do typeof
  107. # [03:13] <Hixie> but most just do if (document.all)
  108. # [03:13] <Hixie> so that would probably be enough
  109. # [03:13] <heycam> so why the need for that wacko requirement?
  110. # [03:14] <Hixie> trying to be as close as possible to existing implementations
  111. # [03:15] <heycam> just wonder if it's really necessary
  112. # [03:16] <heycam> anyway
  113. # [03:16] * Quits: tndH (n=Rob@james-baillie-pc083-229.student-halls.leeds.ac.uk) ("ChatZilla 0.9.84-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  114. # [03:16] <heycam> i'm not sure what the best way is to describe the "undetectable" requirements is
  115. # [03:17] <heycam> requirements on how certain productions from the ecmascript grammar are evaluated maybe?
  116. # [03:18] * heycam goes out for some shopping
  117. # [03:29] * Quits: wakaba (n=wakaba@EM114-51-30-120.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  118. # [03:30] * Quits: nessy (n=nessy@124-168-245-234.dyn.iinet.net.au) ("This computer has gone to sleep")
  119. # [03:31] * Quits: grimboy (n=grimboy@78-86-152-156.zone2.bethere.co.uk) (Read error: 110 (Connection timed out))
  120. # [03:32] * Joins: dglazkov (n=dglazkov@69.181.143.54)
  121. # [03:42] * Joins: nessy (n=nessy@124-168-245-234.dyn.iinet.net.au)
  122. # [03:43] * Quits: nessy (n=nessy@124-168-245-234.dyn.iinet.net.au) (Client Quit)
  123. # [03:49] * Joins: jacobolus_ (n=jacobolu@pool-71-104-172-183.lsanca.dsl-w.verizon.net)
  124. # [03:49] * Quits: jacobolus (n=jacobolu@pool-71-104-172-183.lsanca.dsl-w.verizon.net) (Read error: 104 (Connection reset by peer))
  125. # [03:53] * Quits: olliej (n=oliver@76.14.73.3)
  126. # [04:00] * Quits: mgrdcm (n=mgrdcm@69.246.244.191)
  127. # [04:01] * Quits: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net) (Read error: 54 (Connection reset by peer))
  128. # [04:02] * Joins: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net)
  129. # [04:07] <Hixie> heycam: i have bad news. It looks like document.all is not the only feature that uses this in webkit -- style.filter does too :-)
  130. # [04:08] <jwalden> yeah, it's something ghastly where it converts to a boolean false
  131. # [04:08] <jwalden> dunno why it's necessary, gecko doesn't have the same to not trigger MS filter-property detection tests
  132. # [04:08] <jwalden> or at least it doesn't as far as I know
  133. # [04:08] <Hixie> gecko doesn't have style.filter at all does it?
  134. # [04:09] <jwalden> via SVG maybe?
  135. # [04:09] * jwalden isn't sure
  136. # [04:09] <Hixie> document.body.filter is undefined in gecko
  137. # [04:09] <Hixie> er
  138. # [04:09] <Hixie> document.body.style.filter is undefined in gecko
  139. # [04:09] <jwalden> k
  140. # [04:13] * Joins: jacobolus (n=jacobolu@pool-71-104-172-183.lsanca.dsl-w.verizon.net)
  141. # [04:13] * Quits: jacobolus_ (n=jacobolu@pool-71-104-172-183.lsanca.dsl-w.verizon.net) (Read error: 104 (Connection reset by peer))
  142. # [04:15] * weinig is now known as weinig|foods
  143. # [04:19] * Quits: archtech (n=stanv@83.228.56.37)
  144. # [04:25] * Joins: dimich (n=dimich@98.125.164.248)
  145. # [04:34] * Quits: jacobolus (n=jacobolu@pool-71-104-172-183.lsanca.dsl-w.verizon.net) (Read error: 104 (Connection reset by peer))
  146. # [04:34] * Joins: jacobolus_ (n=jacobolu@pool-71-104-172-183.lsanca.dsl-w.verizon.net)
  147. # [04:58] * Quits: dglazkov (n=dglazkov@69.181.143.54) (Read error: 104 (Connection reset by peer))
  148. # [05:15] <Hixie> i really think we should number the design principles instead of naming them
  149. # [05:15] <Hixie> people are only reading their names
  150. # [05:24] * Joins: dglazkov (n=dglazkov@72.14.224.1)
  151. # [05:28] * Quits: jacobolus_ (n=jacobolu@pool-71-104-172-183.lsanca.dsl-w.verizon.net)
  152. # [05:34] * Quits: dglazkov (n=dglazkov@72.14.224.1)
  153. # [05:38] * Joins: dglazkov (n=dglazkov@69.181.143.54)
  154. # [05:52] * weinig|foods is now known as weinig
  155. # [05:57] * Quits: dimich (n=dimich@98.125.164.248)
  156. # [06:01] * Joins: dimich (n=dimich@98.125.164.248)
  157. # [06:02] * Quits: dimich (n=dimich@98.125.164.248) (Client Quit)
  158. # [06:11] * Joins: grimboy (n=grimboy@78-86-152-156.zone2.bethere.co.uk)
  159. # [06:13] * Joins: olliej (n=oliver@76.14.73.3)
  160. # [06:28] * Joins: hobo (n=hobo@aboutnerd.com)
  161. # [06:44] * Joins: archtech (n=stanv@83.228.56.37)
  162. # [06:50] * Quits: wakaba_ (n=wakaba@EM114-51-159-43.pool.e-mobile.ne.jp) (Read error: 104 (Connection reset by peer))
  163. # [06:50] * Joins: wakaba (n=wakaba@EM114-51-169-174.pool.e-mobile.ne.jp)
  164. # [06:57] * Joins: doublec (n=doublec@118-93-171-25.dsl.dyn.ihug.co.nz)
  165. # [07:03] * Joins: shepazu (n=schepers@adsl-144-163-109.rmo.bellsouth.net)
  166. # [07:22] * Quits: dglazkov (n=dglazkov@69.181.143.54)
  167. # [07:40] * Quits: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net) (Remote closed the connection)
  168. # [07:59] * Joins: mlpug (n=mlpug@a88-115-171-214.elisa-laajakaista.fi)
  169. # [08:07] * Quits: doublec (n=doublec@118-93-171-25.dsl.dyn.ihug.co.nz) (Read error: 113 (No route to host))
  170. # [08:11] <ezyang> Anyone around to answer a question about fragment processing?
  171. # [08:12] <Hixie> fragment processing?
  172. # [08:12] <ezyang> Parsing html fragments
  173. # [08:12] <ezyang> Although... it looks like I just fixed it :-)
  174. # [08:13] <ezyang> Perhaps "and set node to the context element." is a little ambiguous (step 3 of reset insertion mode algorithm)
  175. # [08:16] * Hixie looks
  176. # [08:16] <ezyang> The algorithm works if I replace the actual entry in the stack of open elements
  177. # [08:17] <Hixie> i don't understand why it's ambiguous or why you would mutate the stack
  178. # [08:18] <ezyang> Ah. Then I've implemented it wrong
  179. # [08:18] <Hixie> how do you interpret it?
  180. # [08:19] <ezyang> Oh, I see where I've gone wrong. I'm assuming things actually get inserted into the context element.
  181. # [08:19] <ezyang> User error! Boink
  182. # [08:19] <Hixie> the reset the insertion mode thing does nothing but reset the insertion mode :-)
  183. # [08:20] <ezyang> Yep
  184. # [08:22] <ezyang> I always forget if the "last" node on a stack is the most recently added one or the oldest one
  185. # [08:23] <hobo> you'd think it would be the most recent one
  186. # [08:23] <hobo> as you add them it increases the stack so the last one would be the most recently added
  187. # [08:24] <ezyang> For step three, "If node is the first node in the stack of open elements, then set last to true and set node to the context element.", do I set node to the context element if there is no context element?
  188. # [08:24] <Hixie> yeah i apologise for the mess around the stack
  189. # [08:24] * Joins: nessy (n=nessy@124-168-245-234.dyn.iinet.net.au)
  190. # [08:24] <Hixie> ezyang: how can there be no context element?
  191. # [08:25] <ezyang> Umm, when I'm not parsing a fragment?
  192. # [08:26] <Hixie> when you're not passing a fragment, /node/ will never be the first node in the stack
  193. # [08:26] <ezyang> OK.
  194. # [08:26] <Hixie> so you can assert(context is not null) in that condition, if you like -- you should never hit it unless you or the spec has a bug
  195. # [08:27] <ezyang> Looking at "reset insertion mode" more closely, I can see that would be the case.
  196. # [08:30] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  197. # [08:31] <ezyang> FIFTEEN!
  198. # [08:31] <ezyang> (failures)
  199. # [08:31] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  200. # [08:32] <Hixie> heycam: yt?
  201. # [08:33] * Quits: olliej (n=oliver@76.14.73.3)
  202. # [08:39] <ezyang> Ugh. Now I need to incorporate a list of doctypes in the library
  203. # [09:01] * Quits: myakura (n=myakura@p4050-ipbf3009marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  204. # [09:13] * Quits: mlpug (n=mlpug@a88-115-171-214.elisa-laajakaista.fi) (Remote closed the connection)
  205. # [09:29] * Joins: sayrer (n=chatzill@66.28.50.6)
  206. # [09:31] * Joins: pauld (n=pauld@host86-144-251-8.range86-144.btcentralplus.com)
  207. # [09:38] * Joins: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  208. # [09:40] * Quits: uriel (n=uriel@li43-28.members.linode.com) (Remote closed the connection)
  209. # [09:48] * Joins: pauld_ (n=pauld@host86-144-251-8.range86-144.btcentralplus.com)
  210. # [09:51] * Joins: zdobersek (n=zan@cpe-92-37-70-70.dynamic.amis.net)
  211. # [09:54] <ezyang> Are there any tests in the test-suite for quirks mode specific behavior?
  212. # [09:54] * Quits: pauld (n=pauld@host86-144-251-8.range86-144.btcentralplus.com) (Read error: 110 (Connection timed out))
  213. # [09:55] * Joins: pauld (n=pauld@host86-144-251-8.range86-144.btcentralplus.com)
  214. # [09:57] <ezyang> Also, I'm pretty sure this is a bogus test: <!doctype html></html> <head>
  215. # [09:58] <ezyang> since </html> puts the mode to "After After Body", then the whitespace gets handled as if it was "In Body" and should get placed in <body>
  216. # [10:01] <Hixie> </html> doesn't do anything before head iirc
  217. # [10:01] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  218. # [10:02] * Quits: pauld_ (n=pauld@host86-144-251-8.range86-144.btcentralplus.com) (Read error: 60 (Operation timed out))
  219. # [10:03] <ezyang> "before head" causes </html> to be reprocessed as if an implicit <head> tag was seen
  220. # [10:03] <ezyang> Which further reprocesses as if an end </head> was seen
  221. # [10:03] <ezyang> and so forth
  222. # [10:04] <Hixie> really? i thought we changed that
  223. # [10:04] <ezyang> Oh I see, we're in "before html", not "before head"
  224. # [10:04] <Hixie> huh go figure, i am wrong
  225. # [10:04] <Hixie> oh well
  226. # [10:05] <ezyang> Ehh, the behavior is the same
  227. # [10:05] <ezyang> Yeah.
  228. # [10:05] <ezyang> So what's supposed to happen?
  229. # [10:05] <Hixie> what the spec says is what the rule is at the moment
  230. # [10:05] <Hixie> no idea if it'll change
  231. # [10:06] <ezyang> Ok. I guess I should hg blame the relevant test-case and yell at hsivonen if it's one of his nudge nudge things (more realistically, stick the test-case in test99)
  232. # [10:08] <ezyang> Ick. hg blame doesn't show deletions. So I *can't* find out
  233. # [10:09] <ezyang> Someone must have changed it to not result in whitespace at some point, though, so it will get punted to 99
  234. # [10:10] * Quits: pauld (n=pauld@host86-144-251-8.range86-144.btcentralplus.com) (Read error: 104 (Connection reset by peer))
  235. # [10:10] * Quits: zdobersek (n=zan@cpe-92-37-70-70.dynamic.amis.net) ("Leaving.")
  236. # [10:12] * Joins: pauld (n=pauld@host86-144-251-8.range86-144.btcentralplus.com)
  237. # [10:13] <ezyang> Wow. Most of these are bogus
  238. # [10:13] * Quits: pauld (n=pauld@host86-144-251-8.range86-144.btcentralplus.com) (Read error: 104 (Connection reset by peer))
  239. # [10:14] * Joins: pauld (n=pauld@host86-144-251-8.range86-144.btcentralplus.com)
  240. # [10:14] <ezyang> Ok. The spec needs to be changed to handle <html></html><!-- comment -->
  241. # [10:18] <Hixie> send mail or file a bug if you need changes
  242. # [10:19] <Hixie> (i can't track irc comments so otherwise i'll just forget)
  243. # [10:20] <ezyang> Ok.
  244. # [10:21] <ezyang> It's also kind of debatable whether or not these changes are correct or not
  245. # [10:26] <Hixie> it basically boils down to "are there pages that break if we do it the other way"
  246. # [10:26] <ezyang> Since <title> isn't going into <head>, probably.
  247. # [10:28] * Joins: pauld_ (n=pauld@host86-144-251-8.range86-144.btcentralplus.com)
  248. # [10:29] * Quits: pauld (n=pauld@host86-144-251-8.range86-144.btcentralplus.com) (Read error: 104 (Connection reset by peer))
  249. # [10:35] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  250. # [10:35] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  251. # [10:37] * Joins: othermaciej_ (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  252. # [10:37] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 54 (Connection reset by peer))
  253. # [10:37] <ezyang> For <a><div><p></a>, is the div supposed to be a child of <a>?
  254. # [10:39] <ezyang> Oh, it's a foster parented case.
  255. # [10:40] * Quits: nessy (n=nessy@124-168-245-234.dyn.iinet.net.au) ("This computer has gone to sleep")
  256. # [10:42] * Quits: othermaciej_ (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  257. # [10:43] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  258. # [10:45] * Joins: mlpug (n=mlpug@a88-115-171-214.elisa-laajakaista.fi)
  259. # [10:49] * Joins: ROBOd (n=robod@89.122.216.38)
  260. # [10:55] <heycam> Hixie, you were after me before?
  261. # [11:10] * Quits: hdh (n=hdh@58.187.204.77) (Remote closed the connection)
  262. # [11:12] * Quits: pauld_ (n=pauld@host86-144-251-8.range86-144.btcentralplus.com) (Read error: 104 (Connection reset by peer))
  263. # [11:12] * Joins: pauld (n=pauld@host86-144-251-8.range86-144.btcentralplus.com)
  264. # [11:16] <ezyang> PHP implementation of html5lib has ~100% coverage (there is one error where we can't actually express a doctype with no qualified name with libxml, but whatever)
  265. # [11:17] <ezyang> Time to sleep
  266. # [11:23] * Joins: zdobersek (n=zan@cpe-92-37-70-70.dynamic.amis.net)
  267. # [11:27] * Quits: pauld (n=pauld@host86-144-251-8.range86-144.btcentralplus.com)
  268. # [11:40] * Joins: sverrej (n=sverrej@59.94.252.42)
  269. # [11:56] * Joins: hdh (n=hdh@58.187.204.203)
  270. # [11:57] * Quits: bgalbraith (n=bgalbrai@71.202.109.116)
  271. # [12:04] * Joins: annevk2 (n=annevk@5ED2D22C.cable.ziggo.nl)
  272. # [12:08] * Joins: doublec (n=doublec@118-93-171-25.dsl.dyn.ihug.co.nz)
  273. # [12:08] * Quits: sayrer (n=chatzill@66.28.50.6) (Read error: 110 (Connection timed out))
  274. # [12:52] * Joins: wakaba_ (n=wakaba@EM114-51-136-71.pool.e-mobile.ne.jp)
  275. # [13:11] * Quits: wakaba (n=wakaba@EM114-51-169-174.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  276. # [13:14] <annevk42> heycam, style.filter is the same as document.all due to the SVG WG not renaming it to avoid conflicts with IE
  277. # [13:17] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  278. # [13:18] * Joins: tndH (n=Rob@james-baillie-pc083-229.student-halls.leeds.ac.uk)
  279. # [13:20] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  280. # [13:21] <othermaciej> well, WebKit does style.filter that way
  281. # [13:21] <othermaciej> though it's even weirder, since the return is normally a string
  282. # [13:22] <othermaciej> we have to make it a special string-like thing that masquerades as undefined
  283. # [13:22] <othermaciej> dunno what other browsers do
  284. # [13:35] <annevk42> I think we do something else but it is causing issues
  285. # [13:36] * Quits: doublec (n=doublec@118-93-171-25.dsl.dyn.ihug.co.nz) ("Leaving")
  286. # [13:45] * Joins: virtuelv (n=virtuelv@084202133045.customer.alfanett.no)
  287. # [13:49] * Philip` is saved by semicolon insertion
  288. # [13:50] <Philip`> For some inexplicable reason I was accidentally printing a date in the middle of a <script> generated by some code, so there was a spurious line saying "2009-05-31"
  289. # [13:51] <Philip`> and it must have been interpreted as a statement computing 1973 with an implicit semicolon at the end, so it didn't cause a syntax error
  290. # [13:51] <Philip`> and it's been like that for about six months
  291. # [14:54] * Joins: riven (n=colin@53525B67.cable.casema.nl)
  292. # [14:58] <gsnedders> So, hmm…
  293. # [14:59] * gsnedders realizes what he was going to ask
  294. # [15:00] * Joins: thomaslee (n=tom@210-84-40-214.dyn.iinet.net.au)
  295. # [15:01] * Quits: sverrej (n=sverrej@59.94.252.42) (Read error: 104 (Connection reset by peer))
  296. # [15:01] <thomaslee> hi all -- am working with the canvas element in the firefox 3.5 beta -- is this an appropriate place to ask questions about the behaviour of the API?
  297. # [15:06] * Quits: zdobersek (n=zan@cpe-92-37-70-70.dynamic.amis.net) ("Leaving.")
  298. # [15:11] <gsnedders> thomaslee: Yes.
  299. # [15:11] <thomaslee> cool
  300. # [15:11] * gsnedders can't actually answer any questions on the canvas API himself, but can say that this is the right place to ask :P
  301. # [15:12] <thomaslee> haha great :)
  302. # [15:12] <thomaslee> that's fine
  303. # [15:12] <thomaslee> question is:
  304. # [15:12] <thomaslee> ctx.moveTo(canvas.width, 0); ctx.lineTo(canvas.width, canvas.height);
  305. # [15:14] <thomaslee> once you ctx.stroke(), firefox's implementation of canvas, only draws half of the line -- the other half presumably "off-canvas".
  306. # [15:14] <thomaslee> oops, trigger happy with the commas
  307. # [15:14] * gsnedders grumbles about ezyang having made php html5lib really slow
  308. # [15:14] <thomaslee> anyway, the question is -- is this expected behaviour?
  309. # [15:15] <annevk42> I think so
  310. # [15:15] <thomaslee> the other thing that's confusing me is for a lineWidth = 1.0, I'm seeing what looks like two pixel lines -- although I'm assuming this has something to do with coordinate space and firefox's internal representation of the canvas.
  311. # [15:16] <Philip`> thomaslee: Integer coordinates refer to the positions *between* pixels
  312. # [15:16] <thomaslee> annevk42: so assuming I want a line down the right hand side, I should be drawing this line for x=canvas.width-1 ?
  313. # [15:16] <gsnedders> ezyang: You've made it go from taking < 6s to tokenize the spec to taking > 131s
  314. # [15:17] <thomaslee> Philip`: come again? :)
  315. # [15:17] <Philip`> thomaslee: so if you stroke a line with integer coordinates, it goes between two columns of pixels and ends up shading pixels in both columns
  316. # [15:17] <gsnedders> Oh, wait, I ran that with XDebug on.
  317. # [15:17] <thomaslee> Philip`: oh okay, wow. why's that?
  318. # [15:17] <Philip`> thomaslee: If you want to draw a line through just a single column of pixels, you have to shift the coordinates by 0.5
  319. # [15:18] <Philip`> thomaslee: i.e. ctx.moveTo(canvas.width-0.5, 0); ctx.lineTo(canvas.width-0.5, canvas.height)
  320. # [15:18] <annevk42> unless the line has a width of 2n, presumably?
  321. # [15:18] <gsnedders> ezyang: Let me try that again: you've made it go from < 6s to > 11s
  322. # [15:18] <Philip`> annevk42: If it has width 2n and you're trying to draw a single column of pixels, that's never going to work :-)
  323. # [15:19] <annevk42> meh
  324. # [15:20] <thomaslee> Philip`: right, so that would explain why I'm still seeing two pixel lines when reducing line width. But why on earth do integer coordinates refer to the space in between pixels?
  325. # [15:20] <Philip`> thomaslee: It's that way so that fills work like you would expect (with sharp edges), but it has the consequence that strokes don't quite work like you expect (so you have to shift them by 0.5 to the centers of pixels)
  326. # [15:21] <Philip`> thomaslee: e.g. fillRect(10, 10, 1, 1) fills between the corners of pixels, instead of filling a rectangle between the centers of four pixels
  327. # [15:21] <Philip`> (...assuming you imagine pixels as being squares)
  328. # [15:22] <thomaslee> Philip`: okay, I think I understand. Going to have to remember that one!
  329. # [15:24] <Philip`> thomaslee: It's not the most intuitive thing in the world :-)
  330. # [15:24] <Philip`> but I can't imagine any way to make it better without making other things worse
  331. # [15:24] <thomaslee> Philip`: my brain hurts already :)
  332. # [15:25] <thomaslee> fair enough ... I only started messing with canvas yesterday, maybe it'll make sense when I've got a better understanding of it all.
  333. # [15:25] <thomaslee> anyway, thanks very much for your help
  334. # [15:27] * Joins: zdobersek (n=zan@cpe-92-37-70-70.dynamic.amis.net)
  335. # [15:28] <heycam> annevk42, we did consider renaming it recently
  336. # [15:28] <heycam> not sure it's worth it
  337. # [15:32] * gsnedders has a brief wish PHP did lazy evaluation
  338. # [15:33] <thomaslee> Philip`: just to be clear, the 0.5 coordinate offset is expected behaviour as per the spec, right? (as in, I'm assuming this isn't a firefox-specific thing)
  339. # [15:35] <Philip`> thomaslee: The spec doesn't really define the mapping between rendering concepts and physical pixels, e.g. it doesn't talk about antialiasing and it doesn't limit implementations to one device pixel per canvas pixel
  340. # [15:35] <Philip`> thomaslee: but all current implementations do the same as Firefox here
  341. # [15:35] <Philip`> thomaslee: so in reality it's the behaviour you should expect
  342. # [15:39] <thomaslee> Philip`: great, thanks.
  343. # [15:50] <gsnedders> Does "reconstruct the active formatting elements" step 7 need to have after it a check that it isn't a marker?
  344. # [16:06] * Quits: hdh (n=hdh@58.187.204.203) (Remote closed the connection)
  345. # [16:18] * Joins: mgrdcm (n=mgrdcm@69.246.244.191)
  346. # [16:25] <annevk42> someone is asking me to be added to html5lib team members so he write documentation? no need for vetting right?
  347. # [16:26] <gsnedders> annevk2: I think generally we've had at least one person agreeing to it
  348. # [16:27] <annevk42> so one in total or two?
  349. # [16:27] <gsnedders> One in total.
  350. # [16:28] <annevk42> i guess that'd be me then
  351. # [16:29] <annevk42> for reference: juguang
  352. # [16:31] * Joins: myakura (n=myakura@p4050-ipbf3009marunouchi.tokyo.ocn.ne.jp)
  353. # [16:38] * Joins: doublec (n=doublec@118-93-189-3.dsl.dyn.ihug.co.nz)
  354. # [16:38] * Quits: zdobersek (n=zan@cpe-92-37-70-70.dynamic.amis.net) ("Leaving.")
  355. # [17:21] * Quits: drostie (n=hopkins@5ED17066.cable.ziggo.nl) (Remote closed the connection)
  356. # [17:27] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  357. # [17:44] * Quits: doublec (n=doublec@118-93-189-3.dsl.dyn.ihug.co.nz) ("Leaving")
  358. # [17:45] * Joins: dglazkov (n=dglazkov@69.181.143.54)
  359. # [17:55] * Joins: sayrer (n=chatzill@ma80f36d0.tmodns.net)
  360. # [18:02] <ezyang> gsnedders: Test cases pass first. Profiling (and not until that) and then optimization later.
  361. # [18:04] * Joins: mat_t (n=mattomas@ppp-0-216.leed-b-2.access.uk.tiscali.com)
  362. # [18:07] * Quits: Wolfman2000 (n=Wolfman2@cpe-065-184-176-090.ec.res.rr.com) ("Leaving")
  363. # [18:16] <gsnedders> ezyang: Peh. I was just taking the same solution as Python for this :)
  364. # [18:16] <gsnedders> ezyang: Also: parsing the spec fails.
  365. # [18:16] <ezyang> It... errors?
  366. # [18:16] <ezyang> Wow.
  367. # [18:17] <ezyang> That means our test-coverage is not good enough.
  368. # [18:17] <gsnedders> Fatal error: Call to a member function cloneNode() on a non-object in /Users/gsnedders/Documents/Stuff I'm Working On/html5lib/php/library/HTML5/TreeConstructer.php on line 3037
  369. # [18:17] <gsnedders> The non-object is int(300)
  370. # [18:17] <ezyang> Huh. That should never happen.
  371. # [18:17] <gsnedders> Well it does. :D
  372. # [18:18] <ezyang> Oh, hey, that's the marker
  373. # [18:18] <ezyang> Ok, so we need to figure out why that algorithm is failing
  374. # [18:18] <ezyang> Do you have a minimal test-case?
  375. # [18:18] <gsnedders> No.
  376. # [18:18] <Philip`> curl http://www.whatwg.org/specs/web-apps/current-work/ -o html5lib/testdata/treeconstruction/tests13.dat
  377. # [18:18] <Philip`> That'll encourage people to optimise their implementations
  378. # [18:18] <gsnedders> ezyang: that.
  379. # [18:18] <ezyang> Heh
  380. # [18:18] * Joins: webben (n=benh@79-67-185-18.dynamic.dsl.as9105.com)
  381. # [18:18] <ezyang> Will do.
  382. # [18:19] * gsnedders wonders if we should actually do that…
  383. # [18:19] <ezyang> I wish we had better names for our test-cases
  384. # [18:19] <gsnedders> What could be better than a number? :P
  385. # [18:19] * Joins: MartinNebe (n=martin_n@189.234.120.88)
  386. # [18:20] <Philip`> I wouldn't object to regrouping and renaming the tests
  387. # [18:20] <ezyang> It's just that, some of the test-cases make assumptions about the naming of the tests
  388. # [18:21] <ezyang> gsnedders: It would be super-uber-awesome if you could find a minimal test-case that tickles the bug.
  389. # [18:21] <gsnedders> No, it would be super-über-awesome.
  390. # [18:21] <gsnedders> uber isn't a word, damnit!
  391. # [18:25] * Quits: mat_t (n=mattomas@ppp-0-216.leed-b-2.access.uk.tiscali.com) ("This computer has gone to sleep")
  392. # [18:25] <gsnedders> Last token emitted is with stream at Line 4667, column 5
  393. # [18:26] * jgraham would positivly welcome renaming the tests but doesn't want to actually spend time doing it
  394. # [18:26] <gsnedders> <dfn title="dom-uda-protocol">
  395. # [18:31] * Quits: sayrer (n=chatzill@ma80f36d0.tmodns.net) (Read error: 110 (Connection timed out))
  396. # [18:31] <ezyang> Is it conceptually clean for me to refer to elements in the SVG namespace as 'svg:foo'? I know that prefixes can change, but this is the most convenient representation
  397. # [18:33] <gsnedders> ezyang: <table><tr><td><code>protocol</code> </table>
  398. # [18:34] <ezyang> Awesome
  399. # [18:35] * Quits: myakura (n=myakura@p4050-ipbf3009marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  400. # [18:35] * Quits: dglazkov (n=dglazkov@69.181.143.54)
  401. # [18:37] <gsnedders> ezyang: s/protocol//
  402. # [18:39] * gsnedders has no idea which test file to put the test in
  403. # [18:40] <ezyang> There's a bunch of foster parenting tests in... erm... 7, I think
  404. # [18:40] <ezyang> (this is why we need better names)
  405. # [18:41] <gsnedders> Yeah, I think 7 is best.
  406. # [18:41] * Joins: mat_t (n=mattomas@ppp-0-216.leed-b-2.access.uk.tiscali.com)
  407. # [18:42] * gsnedders runs it against Python to make sure something agrees with the parse tree
  408. # [18:43] * gsnedders gets auth failed :\
  409. # [18:43] <gsnedders> ezyang: Pushed
  410. # [18:44] * Joins: allanmac_ (n=allanmac@dsl092-075-022.bos1.dsl.speakeasy.net)
  411. # [18:44] <ezyang> Awesome
  412. # [18:45] <gsnedders> Have fun with your test suite which throws a fatal error :P
  413. # [18:45] * Parts: allanmac_ (n=allanmac@dsl092-075-022.bos1.dsl.speakeasy.net)
  414. # [18:45] * Joins: allanmac_ (n=allanmac@dsl092-075-022.bos1.dsl.speakeasy.net)
  415. # [18:45] * Parts: allanmac_ (n=allanmac@dsl092-075-022.bos1.dsl.speakeasy.net)
  416. # [18:45] <ezyang> I'm finishing XForeign support first
  417. # [18:45] * gsnedders notes the spec is a good test document because it is so huge and does so much
  418. # [18:46] * Philip` notes the spec is a bad test document because it's very repetitive and is valid
  419. # [18:46] * Joins: allanmac_ (n=allanmac@dsl092-075-022.bos1.dsl.speakeasy.net)
  420. # [18:46] <gsnedders> ezyang: I take it you're fixing the fact that HTML elements should go into the HTML namespace?
  421. # [18:46] <gsnedders> Philip`: But it does everything that's valid, more or less :P
  422. # [18:47] <Philip`> gsnedders: That seems unlikely :-p
  423. # [18:47] <ezyang> gsnedders: I assume that's the default behavior. I suppose I could fix that trivially though
  424. # [18:47] <gsnedders> Well, it's almost infinitely long :P
  425. # [18:47] <Philip`> gsnedders: Why is that relevant?
  426. # [18:47] * Parts: allanmac_ (n=allanmac@dsl092-075-022.bos1.dsl.speakeasy.net)
  427. # [18:48] * Parts: annevk2 (n=annevk@5ED2D22C.cable.ziggo.nl)
  428. # [18:48] * Joins: zdobersek (n=zan@cpe-92-37-70-70.dynamic.amis.net)
  429. # [18:48] * Joins: allanmac_ (n=allanmac@dsl092-075-022.bos1.dsl.speakeasy.net)
  430. # [18:48] <Philip`> gsnedders: I could make a document that's infinitely long and consists entirely of whitespace, and it wouldn't test much behaviour
  431. # [18:48] * Parts: allanmac_ (n=allanmac@dsl092-075-022.bos1.dsl.speakeasy.net)
  432. # [18:48] <gsnedders> Philip`: Indeed
  433. # [18:48] <gsnedders> Philip`: But you'd need an infinitely long document to try every possible valid character stream
  434. # [18:49] * Parts: zdobersek (n=zan@cpe-92-37-70-70.dynamic.amis.net)
  435. # [18:49] <Philip`> gsnedders: An infinitely long document could only test precisely one character stream
  436. # [18:49] <gsnedders> ezyang: It _should_ just mean changing to createElementNS
  437. # [18:49] <ezyang> Right, but because the tokenizer+parser are finite state machines
  438. # [18:49] <Philip`> gsnedders: You'd need infinitely many documents if you want to test infinitely many character streams
  439. # [18:49] <ezyang> We don't need an infinite input stream to test all state combinations
  440. # [18:50] <gsnedders> Philip`: Indeed.
  441. # [18:50] <gsnedders> ezyang: If we implement both as finite state machines exactly to spec, yes :P
  442. # [18:50] <Philip`> gsnedders: But the interesting state in an implementation is finite, so a finite set of finite test cases could test all the interesting cases
  443. # [18:50] * Joins: allanmac (n=allanmac@dsl092-075-022.bos1.dsl.speakeasy.net)
  444. # [18:51] <jgraham> Philip`: And your're going to autogenreate tests to cover them all, right? ;)
  445. # [18:51] <Philip`> (By "interesting", I mean that e.g. "<br><br>" might be interesting but "<br><br><br>" is very unlikely to be)
  446. # [18:51] <gsnedders> ezyang: Though it may well make <foo:bar> throw an error
  447. # [18:51] * gsnedders sighs
  448. # [18:51] <Philip`> jgraham: That's what I did for the tokeniser :-)
  449. # [18:51] <Philip`> (or at least attempted to)
  450. # [18:51] <Philip`> jgraham: and if I ever got around to finishing my tree-constructor implementation, I suppose I could generate tests for that too
  451. # [18:51] <ezyang> I think it would be possible to programatically generate tree-constructer tests
  452. # [18:52] <gsnedders> Philip`: It's OCaml, right?
  453. # [18:52] <jgraham> Philip`: I know and I know, respectively
  454. # [18:52] <Philip`> gsnedders: Yes
  455. # [18:54] * Joins: wakaba (n=wakaba@EM114-51-141-13.pool.e-mobile.ne.jp)
  456. # [18:59] * Quits: wakaba_ (n=wakaba@EM114-51-136-71.pool.e-mobile.ne.jp) (Read error: 60 (Operation timed out))
  457. # [19:06] * Quits: mat_t (n=mattomas@ppp-0-216.leed-b-2.access.uk.tiscali.com) ("This computer has gone to sleep")
  458. # [19:08] * Parts: MartinNebe (n=martin_n@189.234.120.88)
  459. # [19:08] * Quits: tndH (n=Rob@james-baillie-pc083-229.student-halls.leeds.ac.uk) (Remote closed the connection)
  460. # [19:11] * Quits: annevk42 (n=annevk@5ED2D22C.cable.ziggo.nl) (Read error: 104 (Connection reset by peer))
  461. # [19:11] * Joins: annevk42 (n=annevk@5ED2D22C.cable.ziggo.nl)
  462. # [19:16] <ezyang> gsnedders: I'm looking at your new SPACECHARACTERS token type, and I'm thinking that's not actually a good idea.
  463. # [19:16] <gsnedders> ezyang: It's what Python does.
  464. # [19:16] <ezyang> It diverges from spec, and anywhere we matched just CHARACTERS, we have to match against both
  465. # [19:16] <ezyang> Sure.
  466. # [19:17] <ezyang> The way I would personally implement it, though, would be as an advisory extra flag placed in the token
  467. # [19:17] <gsnedders> ezyang: Diverging from spec is not a problem.
  468. # [19:17] <ezyang> Adding a new token type is a fairly large divergence
  469. # [19:20] <Hixie> heycam: what i was going to say is that it looks like style.filter also needs this magic (specifically it needs to return a string that masquerades as undefined)
  470. # [19:20] <Hixie> othermaciej: the way i specced document.all was to say it ToBoolean()s to false, but is otherwise a normal HTMLCollection
  471. # [19:21] <Hixie> othermaciej: is that not enough? I couldn't work out how to make it masquerade as 'undefined' for the purposes of the JS spec
  472. # [19:21] <jgraham> Hixie: So instanceof and typeof will work like any other HTMLCollection?
  473. # [19:21] * jgraham has no idea if that is a problem
  474. # [19:22] <Hixie> yeh
  475. # [19:22] * Joins: dbloom-work (n=futurama@c-67-180-87-16.hsd1.ca.comcast.net)
  476. # [19:22] * Parts: dbloom-work (n=futurama@c-67-180-87-16.hsd1.ca.comcast.net)
  477. # [19:26] * Joins: tndH (n=Rob@james-baillie-pc083-229.student-halls.leeds.ac.uk)
  478. # [19:40] * Joins: mat_t (n=mattomas@ppp-0-216.leed-b-2.access.uk.tiscali.com)
  479. # [19:43] * Joins: annevk2 (n=annevk@5ED2D22C.cable.ziggo.nl)
  480. # [19:47] * Quits: mat_t (n=mattomas@ppp-0-216.leed-b-2.access.uk.tiscali.com) (Read error: 60 (Operation timed out))
  481. # [19:50] <gsnedders> Hmm, abath isn't around
  482. # [19:50] <gsnedders> *abarth
  483. # [19:59] * Joins: bgalbraith (n=bgalbrai@71.202.109.116)
  484. # [20:06] <Hixie> christ i wish larry would follow the process the chairs set out and file bugs instead of sending all these e-mails where i have to carefully parse each line to see if there's a change request there
  485. # [20:20] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
  486. # [20:21] <jgraham> Hixie: What would "masqurading as undefined" imply for document.all?
  487. # [20:22] <Hixie> doing whatever it is webkit or gecko do
  488. # [20:22] <Hixie> but i don't know how to express that in terms of the js spec
  489. # [20:22] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  490. # [20:23] <Dashiva> That's a tall order
  491. # [20:25] <hsivonen> Hixie: wouldn't another "willful violation" be less work for Gecko and WebKit developers?
  492. # [20:26] <Hixie> i mean i don't know how to phrase the willful violation
  493. # [20:26] <jgraham> Hixie: so document.all === undefined or more?
  494. # [20:26] * Joins: kangax (n=kangax@ool-182f8118.dyn.optonline.net)
  495. # [20:26] <Hixie> more
  496. # [20:26] <Hixie> try it
  497. # [20:26] <Hixie> i can't describe it
  498. # [20:26] <jgraham> I am trying it. I want to know what to try :)
  499. # [20:26] <Hixie> typeof does weird things, instanceof does weird things, it matters if you're in with() or not, all kinds of weird things
  500. # [20:26] <Hixie> depends on webkit vs gecko vs opera, too
  501. # [20:27] <jgraham> typeof and instanceof seem easy to deal with, === seems hard to deal with
  502. # [20:27] <Dashiva> Yeah, I remember the bug discussion in Opera's BTS
  503. # [20:28] <jgraham> Breaking document.all in 'with' seems like it shouldn't be a big deal
  504. # [20:28] * Joins: mat_t (n=mattomas@ppp-0-216.leed-b-2.access.uk.tiscali.com)
  505. # [20:29] <annevk2> I recall discussions about it requiring fairly low-level changes to the ECMAScript engine
  506. # [20:30] <hsivonen> perhaps ES5 should provide a spec hook for this
  507. # [20:31] <annevk2> I don't think they're too interested in things like that
  508. # [20:31] * Quits: kangax (n=kangax@ool-182f8118.dyn.optonline.net)
  509. # [20:31] <Dashiva> Boolean value false, typeof undefined.
  510. # [20:31] <annevk2> http://wiki.whatwg.org/wiki/Web_ECMAScript
  511. # [20:32] <Hixie> jgraham: it's actually harder to break it than not
  512. # [20:32] <Hixie> right now the html5 spec just says it ToBoolean()s to fdalse
  513. # [20:32] <Hixie> false
  514. # [20:33] <Hixie> anyway, i'm outta here
  515. # [20:33] <Dashiva> Should probably mention a typeof override too?
  516. # [20:35] <jgraham> Hixie: I meant that making it work or not in with seems like it shouldn't be too big a deal
  517. # [20:35] <jgraham> But I guess I could be wrong about that
  518. # [20:35] * jgraham wishes for the death of "with"
  519. # [20:37] <Dashiva> There's that reshaping the universe to your whims thing again
  520. # [21:01] * Quits: mat_t (n=mattomas@ppp-0-216.leed-b-2.access.uk.tiscali.com) ("This computer has gone to sleep")
  521. # [21:20] * Quits: mgrdcm (n=mgrdcm@69.246.244.191)
  522. # [21:20] * Joins: mgrdcm (n=mgrdcm@69.246.244.191)
  523. # [21:23] * Joins: dave_levin (n=dave_lev@72.14.224.1)
  524. # [22:22] * Quits: mlpug (n=mlpug@a88-115-171-214.elisa-laajakaista.fi) (Remote closed the connection)
  525. # [22:25] * Joins: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net)
  526. # [22:56] * Joins: drostie (n=hopkins@5ED17066.cable.ziggo.nl)
  527. # [23:06] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  528. # [23:11] * Quits: Rik` (n=Rik@pha75-2-81-57-187-57.fbx.proxad.net)
  529. # [23:12] * Joins: Rik` (n=Rik@pha75-2-81-57-187-57.fbx.proxad.net)
  530. # [23:13] * syp__ is now known as syp_
  531. # [23:21] * Quits: virtuelv (n=virtuelv@084202133045.customer.alfanett.no) ("Ex-Chat")
  532. # [23:24] * Joins: nessy (n=nessy@124-168-245-234.dyn.iinet.net.au)
  533. # [23:36] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  534. # [23:40] * annevk42 has the feeling Larry and Roy are both making issues appear more easily than they are; maybe even intentionally
  535. # [23:41] * Joins: hdh (n=hdh@118.71.96.231)
  536. # [23:41] <annevk42> e.g. Larry ignores most of the comments against having versioning for character encoding sniffing and tries to convince people to look at the general idea and Roy somehow believes the URL issue is restricted to HTML src/href attributes
  537. # [23:51] * Quits: drostie (n=hopkins@5ED17066.cable.ziggo.nl) (Remote closed the connection)
  538. # [23:53] * Joins: drostie (n=hopkins@5ED17066.cable.ziggo.nl)
  539. # [23:56] <annevk42> takkaria, <canvas> is perfectly safe
  540. # [23:56] <annevk42> takkaria, even some amount of scripting can be safe
  541. # [23:57] <annevk42> just has to be sandboxed
  542. # [23:58] <takkaria> browsers don't currently do any kind of sandboxing though
  543. # [23:58] <takkaria> and until they all do, a preparse and whitelist will be required
  544. # [23:59] * Quits: heycam (n=cam@203-217-67-148.dyn.iinet.net.au) ("bye")
  545. # Session Close: Mon Jun 01 00:00:00 2009

The end :)