- 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