- From: Ray Whitmer <ray@personallegal.net>
- Date: Thu, 1 Dec 2005 06:20:11 -0700
- To: Kasimier Buchcik <K.Buchcik@4commerce.de>
- Cc: Anne van Kesteren <annevk@opera.com>, ML-www-dom <www-dom@w3.org>
On Dec 1, 2005, at 4:16 AM, Kasimier Buchcik wrote: > But maybe the damage is really already done, and DOM implementations > of browsers will differ from other DOM implementations; not exactly > the intention of a DOM API, is it? I don't think there is sufficient wiggle room to explain it as a binding difference, but I could be wrong. I don't remember well now. I know we revisited it any number of times and if we had had early consensus to change it, we would have. If anyone was arguing against this empty string return initially, I would be sure that it was the Java camp (which I was part of in DOM level 1), who now appear to be the only ones conforming. I believe that this is what the DOM test suite is for, and that a test should be submitted, if one does not exist, to identify this incompatibility of some browsers with the DOM level 1 standard (which in many cases their representatives clearly drafted and approved). Just because there is a compliance test they fail doesn't mean they have to care, and some obviously will not, but it clearly identifies the issue of contention and just go back and look at the names of the participants on the DOM Level 1 standard, level 2, etc. Perceived compliance of browsers is a shallow illusion, and the test suite will never prove compliance. It should be possible in theory to at least convince those who drafted it to comply, which would seem to be its value, and the issue here is such a simple one, they should fall in to line and tell people to fix their web pages. If not, well what did we ever need a W3C DOM WG for if the implementers are just going to fight it out anyway by their dominance. We could suggest other simple level 1 tests that Java implementations would generally pass and recent browser implementations would fail but few web pages use the functionality precisely because major browsers fail to implement it and the test suite fails to implement it, so it is not at issue here, i.e.: <p id='foo'>Test</p> <script> alert(document.getElementById('foo').getAttributeNode('id').firstChild); </script> Try it on Safari, and returns null. Try it on Firefox and it actually works (I don't believe it always did on Mozilla, good work Johnny) and gives you a text node. Of course, in Firefox, if I change it to: <p id='foo'></p> <script> alert(document.getElementById('foo')); </script> it produces a null, which seems wrong, too, because I often want Javascript to change the text of a paragraph that starts empty, not that I can't put something there to work around the error (Safari works correctly in this case). Of course, if I change it to... then Firefox works and Safari does not... Let me know if you want more examples... Ray
Received on Thursday, 1 December 2005 14:45:47 UTC