/irc-logs / freenode / #whatwg / 2007-12-29 / end

Options:

  1. # Session Start: Sat Dec 29 00:00:01 2007
  2. # Session Ident: #whatwg
  3. # [00:06] * Joins: jdandrea (n=jdandrea@ool-44c0a1fe.dyn.optonline.net)
  4. # [00:16] * Joins: weinig (n=weinig@17.203.15.140)
  5. # [00:32] * Quits: gsnedders (n=gsnedder@host86-138-198-209.range86-138.btcentralplus.com) ("Partying in teh intarwebs")
  6. # [00:55] * Quits: jdandrea (n=jdandrea@ool-44c0a1fe.dyn.optonline.net)
  7. # [00:57] * Joins: psa (n=yomode@71.93.19.66)
  8. # [01:09] * Quits: nickshanks (n=nickshan@cpc2-clif1-0-0-cust535.nott.cable.ntl.com)
  9. # [01:19] * Joins: jdandrea (n=jdandrea@ool-44c0a1fe.dyn.optonline.net)
  10. # [01:39] * Quits: dbaron (n=dbaron@pool-72-94-185-124.phlapa.fios.verizon.net) ("8403864 bytes have been tenured, next gc will be global.")
  11. # [01:47] * Quits: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  12. # [01:49] * Joins: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  13. # [01:58] <heycam> hi people. are there ecmascript objects that stringify in non-default ways, apart from window.location and window.getSelection()?
  14. # [01:59] <MacDome> one can always override toString...
  15. # [02:00] <heycam> yeah. i'm wondering what other (host) objects do that. (or perhaps stringify in a different way, e.g. by having a different [[DefaultValue]] method.)
  16. # [02:14] <othermaciej> heycam: in WebKit, Range and HTMLAnchorElement also have custom toString methods (though not sure if that is necessary or correct)
  17. # [02:15] <othermaciej> javascript:alert(document.links[0]) on most pages will show the result
  18. # [02:15] <heycam> ok, thanks
  19. # [02:18] <othermaciej> heycam: looks like Mozilla does at least the HTMLAnchorElement one as well (serializing as its own href)
  20. # [02:18] <heycam> yeah i just noticed. maybe the spec should say something?
  21. # [02:18] <othermaciej> heycam: it's also possible that there are more classes in WebKit which serialize in a custom way, but do it too obscurely for my simple search to find
  22. # [02:19] <othermaciej> (I found Selection, Location, Range and HTMLAnchorElement)
  23. # [02:19] <heycam> (ie7 also does the HTMLAnchorElement thing)
  24. # [02:20] <othermaciej> I suspect serializing anchors that way is needed for compatibility, so yes, HTML5 should probably say something
  25. # [02:24] * Quits: jdandrea (n=jdandrea@ool-44c0a1fe.dyn.optonline.net)
  26. # [02:26] <gavin__> Gecko appears to have custom toStrings for HTMLAnchorElements and HTMLAreaElements, Range, Selection
  27. # [02:27] <gavin__> and some CSSOM related objects that I don't really know about
  28. # [02:27] <gavin__> othermaciej's caveat applies
  29. # [02:28] <heycam> thanks gavin__
  30. # [02:28] <gavin__> I didn't find Location because its magical, for example
  31. # [02:28] <heycam> how's the magic implemented there?
  32. # [02:28] * weinig is now known as weinig|away
  33. # [02:28] <gavin__> well it's magic for reasons other than having a custom tostring
  34. # [02:29] <heycam> ah
  35. # [02:29] <gavin__> oh, actually I'm wrong
  36. # [02:29] <gavin__> I just missed it
  37. # [02:29] <gavin__> http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsLocation.cpp#979
  38. # [02:30] * heycam wonders if [[DefaultValue]] is ever overridden in imlementations
  39. # [02:31] * gavin__ is now known as gavin_
  40. # [02:31] * gavin_ is now known as gavin
  41. # [02:32] * gavins is now known as gavin_
  42. # [02:37] * Quits: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  43. # [02:40] * Joins: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  44. # [02:40] * Quits: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net) (Remote closed the connection)
  45. # [02:47] * weinig|away is now known as weinig
  46. # [02:52] * Joins: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  47. # [03:13] * MacDome is now known as MacDomeAFK
  48. # [03:24] * Quits: webben (n=benh@82.152.123.69)
  49. # [03:34] * Quits: jgraham (n=james@cpc1-flee2-0-0-cust327.glfd.cable.ntl.com) (Read error: 110 (Connection timed out))
  50. # [03:38] * MacDomeAFK is now known as MacDome
  51. # [03:41] * Quits: tndH (i=Rob@83.100.183.125) ("ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  52. # [04:13] * Joins: jdandrea (n=jdandrea@ool-44c0a1fe.dyn.optonline.net)
  53. # [04:26] * Quits: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  54. # [04:30] <Hixie> ok now IE is just TRYING to fail these tests
  55. # [04:30] <Hixie> i finally found something that EVERY BROWSER EXCEPT IE failed
  56. # [04:31] <Hixie> and i added it to acid3
  57. # [04:31] <Hixie> and now it fails in IE, because IE handles code in eval() differently from code in a js block
  58. # [04:31] <Hixie> so IE still fails every test
  59. # [04:31] <Hixie> EVEN THE ONES I ADDED SPECIFICALLY TO GIVE IT A NON-ZERO STARTING SCORE
  60. # [04:32] <hober> heh
  61. # [04:38] * Joins: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  62. # [04:42] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) ("CHOCOA")
  63. # [04:47] * Quits: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  64. # [04:48] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  65. # [04:51] * Joins: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  66. # [04:53] * Parts: jdandrea (n=jdandrea@ool-44c0a1fe.dyn.optonline.net)
  67. # [04:59] * Quits: weinig (n=weinig@17.203.15.140)
  68. # [05:30] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  69. # [05:34] <othermaciej> Hixie: code in eval() is supposed to be treated differently from code in a JS block in some ways
  70. # [05:34] <MacDome> sadly Acid3 seems to have borked again... oh well
  71. # [05:34] <MacDome> and we're now 92%!
  72. # [05:34] <MacDome> huaazh
  73. # [05:53] <Hixie> othermaciej: different how?
  74. # [06:02] * Joins: weinig_ (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  75. # [06:02] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  76. # [06:06] * weinig_ is now known as weinig
  77. # [06:42] * Joins: doublec (n=Chris_Do@203-97-173-6.cable.telstraclear.net)
  78. # [07:01] <MacDome> Hixie: sadly the HMTL5 spec does not support your form.elements.length == form.elements testcase. http://bugs.webkit.org/show_bug.cgi?id=16656
  79. # [07:01] <MacDome> unless I missed something in my reading thereof
  80. # [07:02] <Hixie> FIXED
  81. # [07:02] <Hixie> er
  82. # [07:02] <Hixie> fixed
  83. # [07:02] <Hixie> that was a typo
  84. # [07:02] <Hixie> i meant to test form.elements.length against form.length
  85. # [07:20] * Quits: digx (n=rick@c-76-109-201-140.hsd1.fl.comcast.net)
  86. # [07:37] <MacDome> Hixie: oh good. well, I just sent an email about it :)
  87. # [07:37] <MacDome> Hixie: said email contained a list of all WebKit bugs re: Acid3
  88. # [07:37] <MacDome> which I imagine you will find interesting :)
  89. # [07:37] <Hixie> cool
  90. # [07:38] * MacDome goes to look at why the latest Acid3 file causes webkit to fail completely
  91. # [07:38] <MacDome> ah, it's fixed again, good
  92. # [07:38] <MacDome> except now we're 88% instead of 91% :(
  93. # [07:40] <Hixie> teehee
  94. # [07:40] <Hixie> do you know of any bugs in safari or mozilla that i should test?
  95. # [07:41] <MacDome> well, XHTML support is riddled w/ bugs :)
  96. # [07:41] <MacDome> embedding bugs are a big deal for me
  97. # [07:41] <MacDome> Hixie: I really think the test could benefit from using something like these: http://trac.webkit.org/projects/webkit/browser/trunk/LayoutTests/fast/js/resources/js-test-pre.js
  98. # [07:41] <Hixie> i mean DOM or JS things
  99. # [07:41] <MacDome> for making it easier to debug
  100. # [07:42] <MacDome> Hixie: I'll think about it next time I'm sorting through old bugs
  101. # [07:42] <Hixie> you mean reporting something more than the test number?
  102. # [07:42] <Hixie> i'm not sure exactly what one would need to report
  103. # [07:42] <MacDome> Hixie: breaking the ifs down into single tests
  104. # [07:43] <MacDome> instead of if (foo || bar || baz) fail!
  105. # [07:43] <MacDome> it could be
  106. # [07:43] <MacDome> assert(!foo);
  107. # [07:43] <MacDome> assert(!bar)
  108. # [07:43] <MacDome> etc
  109. # [07:43] <Hixie> and have assert thrown an exception or something?
  110. # [07:43] <Hixie> i could i guess
  111. # [07:43] <MacDome> sure
  112. # [07:43] <MacDome> and then the wrapper could catch it
  113. # [07:43] <Hixie> seems tdious
  114. # [07:43] <MacDome> it would certainly make debugging easier. to have things be single-line. but maybe it's not worth it
  115. # [07:44] <MacDome> it could throw an exception containing the assertion text.
  116. # [07:44] <MacDome> which would allow you to report things better
  117. # [07:44] <Hixie> then only the first bit that fails would be run
  118. # [07:44] <MacDome> but again, maybe not worth it
  119. # [07:44] <Hixie> but i guess that's ok
  120. # [07:45] <Hixie> (of each test)
  121. # [07:45] <MacDome> well, you obviously have lots of time to play with differnet methods for differnet tests
  122. # [07:46] <MacDome> perhaps you'll find one you like better than the current
  123. # [07:46] <MacDome> from a debugging standpoint, watching for when "ok" turns false, and then checking each part of an if () clause can be a bit tedius
  124. # [07:46] <Hixie> true
  125. # [07:46] * MacDome goes back to debugging the latest build
  126. # [07:49] <Hixie> how do i distinguish a DOMException object from a string thrown by 'throw' in a spec-compliant way that works in IE?
  127. # [07:50] <MacDome> Hixie: ha! it looks like test 56 is impossible to pass. You never set ok to true! :)
  128. # [07:51] * MacDome assumes he meant to initialize ok to true
  129. # [07:51] <Hixie> fixed
  130. # [07:51] <MacDome> Hixie++ # for testing reserved words!
  131. # [07:51] <MacDome> Hixie: that was one thing I *really* wanted to see moz fix
  132. # [07:52] <Hixie> any others?
  133. # [07:52] <MacDome> or rather.. to see all browsers agree on
  134. # [07:52] <Hixie> i have no idea how to handle this exception thing
  135. # [07:52] <MacDome> Hixie: can't you grab the prototype off of an object in IE?
  136. # [07:52] <MacDome> Hixie: or maybe .toNumber() the exception?
  137. # [07:53] <Hixie> is there a spec that guarantees either of those do anything sane for DOMException? (specifically, a spec that was in CR or better in 2004)
  138. # [07:54] <Hixie> i'll just throw an object with a 'message' property
  139. # [07:54] <Hixie> that works everywhere
  140. # [07:55] <Hixie> i'm amused that test 85 is the only test ie can pass
  141. # [07:55] <Hixie> i'm not especially targetting IE either
  142. # [07:55] <Hixie> i'm really only worrying about mozilla and safari bugs, by and large
  143. # [07:56] <Hixie> (except for things other people have told me to test)
  144. # [07:56] <Hixie> (like ie's attribute mess)
  145. # [07:56] <MacDome> Hixie: it woudl appear that the 30s are misnumbered in comment
  146. # [07:56] <MacDome> it says we fail "39" but according to the comments there is no 39 :)
  147. # [07:57] * MacDome goes to look at the DOMException spec
  148. # [07:58] <MacDome> what the hell is an "exception" instead of an "interface" in idl
  149. # [07:59] <Hixie> how is there no 39
  150. # [08:00] * MacDome reads http://www.w3.org/TR/DOM-Bindings/#idl-exceptions
  151. # [08:01] <MacDome> Hixie: so is e.code accessible within IE?
  152. # [08:02] <othermaciej> Hixie: maybe not the difference you noticed, but there are some intended behavior differences for eval code, for example "var" declarations create bindings that are *not* DontDelete under eval
  153. # [08:02] <Hixie> MacDome: that's one of the things i test i believe
  154. # [08:02] <Hixie> othermaciej: ah
  155. # [08:02] <Hixie> othermaciej: is that in the spec?
  156. # [08:03] <MacDome> Hixie: you were just asking for ways to identify DOMExceptions, I had assumed you were looking to replace the e.HIERARCHY_.... check
  157. # [08:03] <MacDome> which fails in Safari and seems to disagree w/ the spec
  158. # [08:03] <othermaciej> Hixie: some differences are spec'd here: http://bclary.com/2004/11/07/#a-10.2.2
  159. # [08:04] <MacDome> interesting. IE always makes .constructor DontEnum
  160. # [08:05] <MacDome> even if it might be
  161. # [08:05] <othermaciej> Hixie: ah, in fact that section includes the difference I mentioned
  162. # [08:05] <Hixie> MacDome: no, i was looking for ways to change the framework to handle custom exceptions. i cheated instead.
  163. # [08:05] <Hixie> othermaciej: cool
  164. # [08:05] <MacDome> Hixie: I wonder if you can grab at e.constructor and check to see if it's a DOMException that way... I'm not actually sure what e.constructor will get you, othermaciej would probably know
  165. # [08:06] <Hixie> i can only rely on things that either work 100% reliably from DOM Level 0, or things that were in specs at CR or later in 2004
  166. # [08:06] <Hixie> DOM Bindings wasn't even close to either
  167. # [08:07] <MacDome> november 2000: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-17189187 ?
  168. # [08:07] <Hixie> MacDome: where's the ".constructor" part of that?
  169. # [08:07] <MacDome> I was thinking .constructor was on Object
  170. # [08:08] <Hixie> exceptions aren't necessarily Objects
  171. # [08:08] <Hixie> they're host objects
  172. # [08:08] <Hixie> which basically (as of 2004) had no defined behaviour
  173. # [08:08] <Hixie> insofar as .constructor goes
  174. # [08:08] <Hixie> as far as i can tell
  175. # [08:08] * MacDome wonders what an exception can be if not an "Object" in JS. I guess it could be another primitive type...
  176. # [08:09] <Hixie> host objects don't have to be any primitive type as i understand it
  177. # [08:17] <MacDome> Er r or Obj e c t s
  178. # [08:17] <MacDome> I nst ances of Er r or obj ect s ar e t hr own as except i ons when r unt i me er r or s occur . The Er r or obj ect s may al so
  179. # [08:17] <MacDome> ser ve as base obj ect s f or user - def i ned except i on cl asses.
  180. # [08:18] <MacDome> Hixie: according to ECMA e.constructor.prototype.name == "Error" for all runtime exceptions
  181. # [08:19] <MacDome> Hixie: assuming I'm reading 15.11 correctly
  182. # [08:19] <Hixie> sure, but user-thrown exceptions and DOM-thrown exceptions aren't runtime exceptions
  183. # [08:19] <MacDome> correct, they are not required to be based from Error
  184. # [08:19] <MacDome> Hixie: user exceptions at least
  185. # [08:19] <MacDome> Hixie: I'm not sure about DOM exceptions
  186. # [08:19] <Hixie> DOM exceptions are effectively user-defined
  187. # [08:19] <Hixie> or rather, host-defined
  188. # [08:19] <Hixie> (which is even less useful to us)
  189. # [08:19] <Hixie> dom bindings addresses all this, luckily
  190. # [08:21] <MacDome> well, throw can throw any arbitrary value, so that's no hel
  191. # [08:21] <MacDome> p
  192. # [08:22] <Hixie> yeah, i just settled on throwing a { message: "" } object
  193. # [08:22] <MacDome> nice new error messages!
  194. # [08:22] <MacDome> I just reloaded and saw them
  195. # [08:22] <Hixie> i'm up to test 36
  196. # [08:23] <MacDome> bah. once again you check e.NAMESPACE_ERR which isn't supported by any spec I've seen
  197. # [08:24] * MacDome bitches instead of fixing the "bug"
  198. # [08:24] <Hixie> DOM2 Core, appendix E
  199. # [08:26] <MacDome> nice new tests, btw.
  200. # [08:27] <MacDome> Hixie: sure, and javascript:alert(DOMException.HIERARCHY_REQUEST_ERR) is valid in Safari
  201. # [08:27] <MacDome> Hixie: but just because it's a property on the constructor funtion doesn't mean it's a property on the prototype
  202. # [08:28] <Hixie> do you agree that instances of Node have the node type constants on their objects?
  203. # [08:29] <MacDome> sure. it's defined for any object conforming to the Node interface: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-1950641247
  204. # [08:29] <MacDome> http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-17189187 DOMException seems to have no such requirement
  205. # [08:29] <Hixie> the text defining that for JSis exactly the same as the text defining the constants should be on all exception objects
  206. # [08:30] <MacDome> I don't follow
  207. # [08:30] <MacDome> Foo.bar != (new Foo).bar
  208. # [08:30] <Hixie> the only reason Node objects have those constants is the text in appendix E that says that Node.ELEMENT_NODE on the "Prototype Object Node" is present
  209. # [08:31] <MacDome> (the easy solution is obviously for us to implement these constants as part of the DOMException interface), I'm just not sure I understand how that's implied form the spec yet
  210. # [08:31] <Hixie> which is the same text as the text that says that DOMException.INDEX_SIZE_ERR on the "Prototype Object DOMException" is present
  211. # [08:31] <MacDome> ah...
  212. # [08:31] <Hixie> so either the constants should be present in both cases, or in neither cae
  213. # [08:32] <Hixie> case
  214. # [08:32] <MacDome> Prototype Object DOMException
  215. # [08:32] <Hixie> now i agree that the text in the spec sucks, which is why we need the DOM Bindigns spec
  216. # [08:32] <MacDome> I can see how that could be used to mean that the prototype for the object DOMException shoudl have those constants
  217. # [08:32] <MacDome> ok, I'll concede Prototype Object DOMException saves your case
  218. # [08:32] <Hixie> but i can't see any way to interpret that spec which leads to exceptions being different from nodes in this regard
  219. # [08:33] <MacDome> Hixie: well, ignoring appendix E, I think my point is valid
  220. # [08:33] <Hixie> appendix E is the only reason we have anything in JS at all
  221. # [08:33] <MacDome> Hixie: the rest of the spec clearly demands that (new Node).ELEMENT_NODE be valid.
  222. # [08:33] <MacDome> and demands that HIERARCHY_REQUEST_ERR be defined
  223. # [08:33] <MacDome> but makes no such demand on (new DOMException).HIERARCHY_REQUEST_ERR
  224. # [08:33] <Hixie> i disagree; i don't see anything that says how to interpret that idl other than appendix E
  225. # [08:34] * MacDome shrugs
  226. # [08:34] * MacDome goes to prepare the fix
  227. # [08:35] <Hixie> hehe
  228. # [08:35] <Hixie> i've done half the tests with error messages
  229. # [08:35] <Hixie> i'll do the other half in a bit
  230. # [08:36] * MacDome enjoys having such a formidable spec opponent. :)
  231. # [08:36] <Hixie> :-)
  232. # [08:39] * MacDome sighs. DOMException.idl appears non-autogenerated :(
  233. # [09:11] <MacDome> sigh. Hixie's got webkit down to 85% :(
  234. # [09:13] <MacDome> actually 85% for 3.04, 88% for TOT
  235. # [09:14] <MacDome> Hixie: soooo much easier to debug, btw. thanks.
  236. # [09:21] * Quits: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  237. # [09:45] * Joins: kfish (n=conrad@61.194.21.25)
  238. # [09:54] <othermaciej> I think MacDome doesn't realize that the test will not seem legit if WebKit passes out of the box
  239. # [09:56] * Quits: doublec (n=Chris_Do@203-97-173-6.cable.telstraclear.net) ("ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  240. # [09:57] <Hixie> i'm far more interested in seeing compliant browsers than in having my life be easy in making the test seem legit
  241. # [09:58] <othermaciej> yeah, but if he keeps fixing bugs, you'll have to keep adding tests
  242. # [09:58] <Hixie> that is a problem i welcome with open arms
  243. # [09:58] <othermaciej> I mean, not that I'm against people fixing more bugs
  244. # [10:12] * Joins: annevk (n=annevk@ip91350cb4.speed.planet.nl)
  245. # [10:14] <hsivonen> Hixie: you could test that XHTML docs implement HTMLDocument and check that document.body and stuff works
  246. # [10:14] <Hixie> is there a way to do that purely from DOM?
  247. # [10:15] <Hixie> (i'm trying to avoid external files)
  248. # [10:17] <hsivonen> Hixie: I'm not sure if it is possible with 2004 specs. with HTML 5 it should be. :-)
  249. # [10:17] <hsivonen> Hixie: unless there's a spec for DOMParser
  250. # [10:18] <Hixie> testing html5 in an acid test will be for acid4, maybe :-)
  251. # [10:18] <hsivonen> which I doubt
  252. # [10:18] <Hixie> there's dom3 load and save, but i'm pretending that doesn't exist
  253. # [10:18] <hsivonen> (I doubt DOMParser has a spec that is)
  254. # [10:19] <hsivonen> Hixie: anyway, document.body would be a test that'd help acid3 look legitimate by WebKit not passing :-)
  255. # [10:19] <hsivonen> in XHTML that is
  256. # [10:19] <Hixie> heh
  257. # [10:20] <Hixie> i could createDocument() an XHTML doc
  258. # [10:22] * Joins: ROBOd (n=robod@89.122.216.38)
  259. # [10:26] <othermaciej> hsivonen: XHTML documents implementing HTMLDocument is not required by any spec but HTML5 afaik
  260. # [10:26] <Hixie> and dom2 html
  261. # [10:26] <othermaciej> I thought it was allowed but not required by dom2 html
  262. # [10:26] * othermaciej checks his references
  263. # [10:27] <Hixie> it's required as much as HTMLDocument is required for text/html, as far as i can tell
  264. # [10:27] <Hixie> of course back in those days specs were so vague...
  265. # [10:28] <othermaciej> yeah, it seems to be required for XHTML 1.0 as much as for HTML 4.01, which is to say, not very clearly required at all
  266. # [10:28] <othermaciej> wow, so many statements in DOM 2 HTML are just outright factually false
  267. # [10:28] <Hixie> do paste them here
  268. # [10:29] <othermaciej> "In many cases, these enhancements are not applicable to a general DOM because they rely on the presence of a predefined DTD."
  269. # [10:29] <krijnh> http://www.digg.com/software/Ian_Hickson_s_having_a_bit_of_trouble_writing_ACID3 :P
  270. # [10:30] <othermaciej> Hixie: I do know of one DOM Level 1 Core thing that I think every browser gets wrong per spec (but which probably can't be fixed)
  271. # [10:30] <Hixie> yeah i'm avoiding those
  272. # [10:31] <Hixie> and yeah, the DTD stuff is funny
  273. # [10:31] <othermaciej> elt.getAttribute("nonexistentAttribute") is supposed to return empty string instead of null
  274. # [10:31] <Hixie> back in those days people believed it
  275. # [10:31] <hsivonen> DTDs have the questionable honor of being the second most misunderstood part of XML right after namespaces
  276. # [10:34] * Quits: annevk (n=annevk@ip91350cb4.speed.planet.nl) (Read error: 110 (Connection timed out))
  277. # [10:35] <othermaciej> out of the official w3c DOM tests, WebKit fails 6 of the DOM1 Core ones, 1 of the DOM2 Core, 1 of the DOM2 Events, and 5 of the DOM2 HTML
  278. # [10:35] <othermaciej> (in some cases a few more than that in xhtml instead of html, not sure why)
  279. # [10:36] * Joins: jgraham (n=james@cpc1-flee2-0-0-cust327.glfd.cable.ntl.com)
  280. # [10:37] <Hixie> othermaciej: is there a summary of those failures somewhere?
  281. # [10:37] <Hixie> e.g. bugzilla query?
  282. # [10:38] <othermaciej> not in bugzilla
  283. # [10:39] <othermaciej> if you have a WebKit tree checked out, WebKitTools/Scripts/check-dom-results gives counts of tests that appear to succeed, and you can search for "fail" in .txt files in LayoutTests/dom/* to find which specific tests fail
  284. # [10:39] <othermaciej> a lot of the DOM3 Core ones fail due to unimplemented useless features
  285. # [10:39] <Hixie> i do not have a checkout right now
  286. # [10:39] <othermaciej> most of the others are deliberate failures for web compatibility I think
  287. # [10:39] <Hixie> k
  288. # [10:39] <othermaciej> but not sure
  289. # [10:39] <othermaciej> I looked at the DOM 1 Core failures
  290. # [10:40] <othermaciej> 3 are because we allow implicit adoption when inserting a node from another document
  291. # [10:40] <othermaciej> which we added because Gecko allowed it and some sites started to depend on it
  292. # [10:40] <othermaciej> (or maybe it was intranet "enterprise" products w/ a web interface)
  293. # [10:41] <othermaciej> one is due to returning null for getAttribute of a nonexistent attribute
  294. # [10:41] <Hixie> yeah we should just allow that
  295. # [10:41] <Hixie> i don't understand why implicit adoption wasn't allowed
  296. # [10:41] <Hixie> and getAttribute's null thing needs fixing
  297. # [10:41] <Hixie> in the spec
  298. # [10:41] <othermaciej> yes, yes it does
  299. # [10:42] <Hixie> Web DOM Core 4
  300. # [10:42] <othermaciej> asking for that to be fixed was one of my first unpleasant experiences with the w3c
  301. # [10:42] <Hixie> or 5 i guess :-)
  302. # [10:42] <othermaciej> many years ago
  303. # [10:42] <Hixie> oh?
  304. # [10:42] <othermaciej> let me see if I can find the thread in the archives
  305. # [10:43] <othermaciej> ah, the two other failures are also due to not throwing WRONG_DOCUMENT_ERR
  306. # [10:43] <othermaciej> so 5 failures for allowing implicit adoption, one for returning null from getAttribute
  307. # [10:43] <othermaciej> I can tell you that last time I tested, every other browser failed a lot more of these
  308. # [10:43] <othermaciej> even the DOM1 Core tests
  309. # [10:44] <othermaciej> I think the DOM2EV test we fail is due to dispatching events in both capture and bubble phases to the target node
  310. # [10:44] <othermaciej> (technically they should only bubble, but that causes web compat issues due to Gecko's longstanding behavior in this regard)
  311. # [10:45] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 110 (Connection timed out))
  312. # [10:45] <Hixie> yeah, i'm not testing that one either
  313. # [10:45] <Hixie> i'm not testing anything that we want to change
  314. # [10:46] <othermaciej> http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0024.html
  315. # [10:46] <othermaciej> http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0025.html
  316. # [10:46] <othermaciej> both had floods of angry responses
  317. # [10:47] <othermaciej> here's another interesting message from around the same time: http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0076.html
  318. # [10:47] <othermaciej> (incompatibility between DOM 2 Core and DOM 3 Core)
  319. # [10:48] <othermaciej> (on a minor extremely boring edge case issue though)
  320. # [10:49] * Joins: doublec (n=Chris_Do@203-97-173-6.cable.telstraclear.net)
  321. # [10:54] <othermaciej> hey, proof that I'm stubbornly consistent in my beliefs: http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0047.html
  322. # [11:00] <Hixie> proof that i am: http://lists.w3.org/Archives/Public/www-html/1998Dec/0003.html
  323. # [11:05] <Hixie> heh, i found that html4 had no real conformance criteria back in 1999: http://lists.w3.org/Archives/Public/www-html/1999Feb/0010.html
  324. # [11:07] <othermaciej> heh
  325. # [11:07] <othermaciej> well, we have higher standards now
  326. # [11:08] <Hixie> it's sad that from 1998 to 2004 we basically made no progress
  327. # [11:08] <Hixie> i'm glad we have finally shaken ourselves free of the old guard
  328. # [11:08] <othermaciej> well, some of that was the state of affairs in the browser market during that period
  329. # [11:31] <Hixie> i need more tests
  330. # [11:31] <Hixie> let me know if you come up with any
  331. # [11:31] <Hixie> bed time now
  332. # [11:41] * Joins: maikmerten (n=maikmert@La2b7.l.pppool.de)
  333. # [11:56] * Quits: doublec (n=Chris_Do@203-97-173-6.cable.telstraclear.net) ("ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  334. # [11:56] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  335. # [12:08] * Joins: tndH_ (i=Rob@83.100.183.125)
  336. # [12:08] * tndH_ is now known as tndH
  337. # [12:26] * Joins: hdh (n=hdh@58.187.90.38)
  338. # [13:09] * Joins: gsnedders (n=gsnedder@host86-138-198-209.range86-138.btcentralplus.com)
  339. # [13:10] * Joins: doublec (n=Chris_Do@203-97-173-6.cable.telstraclear.net)
  340. # [13:15] * Quits: kfish (n=conrad@61.194.21.25) ("Pike!")
  341. # [13:17] * Quits: doublec (n=Chris_Do@203-97-173-6.cable.telstraclear.net) ("ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  342. # [13:52] * Joins: webben (n=benh@82.152.123.69)
  343. # [14:02] * Parts: hdh (n=hdh@58.187.90.38)
  344. # [14:32] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  345. # [14:32] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  346. # [14:34] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  347. # [14:34] * Joins: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  348. # [14:40] * Quits: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  349. # [14:40] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  350. # [14:44] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  351. # [14:44] * Joins: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  352. # [14:45] * Quits: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  353. # [14:45] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  354. # [14:50] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) ("Leaving")
  355. # [14:50] <Philip`> http://www.natural-innovations.com/wa/xhtml.html - hmm, XHTML was sometimes referred to as HTML 5.0?
  356. # [14:54] <webben> Philip`: http://groups.google.com/group/mail.www-html/browse_thread/thread/140306dc90e21ce3/a0bef1d6fde4d332?lnk=st&q=voyager+w3c+%22html+5.0%22#a0bef1d6fde4d332 perhaps
  357. # [14:56] * Joins: Lachy (n=Lachlan@ti200710a340-2416.bb.online.no)
  358. # [15:04] * Joins: nickshanks (n=nickshan@cpc2-clif1-0-0-cust535.nott.cable.ntl.com)
  359. # [15:05] <Philip`> webben: Ah, thanks
  360. # [15:06] <Philip`> http://www.w3.org/TR/1998/WD-html-in-xml-19981205/ talks about Voyager, but I can't find any 'official' references to an HTML 5.0 so I guess that term just fell out of favour before catching on
  361. # [15:08] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  362. # [15:13] * Joins: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  363. # [15:13] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  364. # [15:15] * Quits: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Client Quit)
  365. # [15:17] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  366. # [15:19] * Quits: Lachy (n=Lachlan@ti200710a340-2416.bb.online.no) (Read error: 110 (Connection timed out))
  367. # [15:22] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  368. # [15:22] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  369. # [16:02] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  370. # [16:05] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  371. # [16:06] * Joins: ROBOd (n=robod@89.122.216.38)
  372. # [17:55] * Quits: webben (n=benh@82.152.123.69)
  373. # [17:56] * Joins: tantek (n=tantek@70-13-191-180.area2.spcsdns.net)
  374. # [18:38] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  375. # [18:39] * Joins: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  376. # [19:19] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  377. # [19:54] * Joins: digx (n=rick@c-76-109-201-140.hsd1.fl.comcast.net)
  378. # [20:29] * Joins: grimboy (n=grimboy@85-211-242-220.dsl.pipex.com)
  379. # [20:49] * Quits: maikmerten (n=maikmert@La2b7.l.pppool.de) ("Leaving")
  380. # [20:57] * Joins: grimeboy (n=grimboy@85-211-242-2.dsl.pipex.com)
  381. # [20:59] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  382. # [21:00] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  383. # [21:13] * Quits: grimboy (n=grimboy@85-211-242-220.dsl.pipex.com) (Read error: 110 (Connection timed out))
  384. # [21:38] * Joins: dolphinling (n=chatzill@rbpool4-69.shoreham.net)
  385. # [21:48] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (devel) (IRC client for Emacs)")
  386. # [22:00] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  387. # [23:06] * Joins: doublec (n=doublec@203-97-173-6.cable.telstraclear.net)
  388. # [23:12] * weinig is now known as weinig_
  389. # [23:12] * weinig_ is now known as weinig
  390. # [23:19] * Quits: grimeboy (n=grimboy@85-211-242-2.dsl.pipex.com) (Read error: 104 (Connection reset by peer))
  391. # [23:19] * Joins: grimboy_uk (n=grimboy@85-211-248-31.dsl.pipex.com)
  392. # [23:29] <Philip`> http://intertwingly.net/blog/?q=%00 - yay for XML
  393. # [23:33] * Quits: gsnedders (n=gsnedder@host86-138-198-209.range86-138.btcentralplus.com) ("Partying in teh intarwebs")
  394. # [23:33] <Philip`> (Also http://golem.ph.utexas.edu/instiki/search?query=%00 etc)
  395. # [23:34] <Philip`> (Also http://golem.ph.utexas.edu/instiki/save/HomePage etc)
  396. # [23:34] <Philip`> Are there any non-trivial dynamically-generated XHTML sites that successfully ensure well-formedness?
  397. # [23:40] <hsivonen> Philip`: Validator.nu used to be a dynamically-generated app (even if not site) that ensured well-formedness, but now it may have holes like that--I have not tested properly for forbidden characters after I did some major rework in the front end
  398. # [23:41] <hsivonen> bullet-proofing it against \0, etc. is one of the many items I should take care of
  399. # [23:42] <hsivonen> actually, I could find out right now
  400. # [23:43] <hsivonen> yep, Validator.nu is broken after the major rework :-(
  401. # [23:43] <hsivonen> my options are:
  402. # [23:43] <hsivonen> 1) Hacking the Xalan serializer (hard)
  403. # [23:43] <hsivonen> 2) Writing a SAX filter (easy but potentially inefficient)
  404. # [23:43] <hsivonen> and
  405. # [23:44] <hsivonen> 3) Writing my own XML serializer (tedious with namespaces)
  406. # [23:46] <hsivonen> hmm. and 4) filtering in a Writer after the serializer
  407. # [23:47] <Philip`> Those all sound like great fun
  408. # [23:48] * Quits: grimboy_uk (n=grimboy@85-211-248-31.dsl.pipex.com) (Read error: 110 (Connection timed out))
  409. # [23:48] * Joins: grimboy_uk (n=grimboy@85-211-244-93.dsl.pipex.com)
  410. # Session Close: Sun Dec 30 00:00:00 2007

The end :)