On Mon, 20 Mar 2006 16:14:38 +0100, Ian Davis <[EMAIL PROTECTED]> wrote:
And what exactly do I have to implement? I think the specification
should remain unchanged as what is currently specified is a sane thing
to do. Unless of course there is some interoperability between the
majority of browsers that is different from that what is specified.
You're right, it's the sane thing, but it doesn't reflect reality. One
major browser throws an exception where we say it shouldn't. That means
that content authors can't rely on the behaviour we're specifying which
I believe lowers the utility of the text.
If we want down that road we might as well specify nothing, imho. The
features we specify should be testable and it should be clear how they
should be implemented. I think that authors reading specifications are
well aware that what's in there is not always reflected by implementations.
The above text could be used for the authoring guidelines though, I
guess. It seems important to tell people you can't currently rely on
what responseText its getter will do when readyState is not 3 or 4.
I'd rather we wrote down what is reliable now and marked
incompatibilities as likely to be tightened up in the next version. I
think it's better to have a smaller spec that is accurate and released
early.
Leaving all kinds of things undefined doesn't make a specification more
accurate and I doubt it makes the specification any smaller. As an author
I would much rather read a tutorial anyway, especially when there are
differences between implementations. Things like "This method, when
invoked without arguments, SHOULD do the same as invoked with its only
argument being null" don't really tell me, as an author, that
implementations might do otherwise. I don't think I'd really be able to
distinguish SHOULD and MUST and on top of that see what kind of
implications they might have on implementations...
Therefore I leave this text as is.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
