Garrett Smith wrote:
I can appreciate the desire to make the task of implementing the spec
in an automated fashion. That is a desire, however, not a need.
So is everything else. This particular desire has great benefits,
however, so it needs to have great drawbacks as well to not be done, right?
What I opposed is calling null a string. Null is not a string by the
definition in the DOM 3 spec[1]
(You linked to the DOM2 spec, but DOM3 says the same thing.)
That definition does not necessarily preclude null being considered a
DOMString, and in fact parts of the spec consider it so. I'm honestly a
little confused why you care so much about what something is "called" as
opposed to what it "does". The latter is what really matters.
However, WebIDL does lump null into domstring.
Yes, because de-facto DOM does this already.
What WebIDL does creates compatibility issues in an attempt to standardize bugs.
It doesn't create any issues that were not there.
Moving forward, if null is allowed, it should not be called a string.
Moving forward doesn't help with the existing DOM interfaces, which
certainly allow passing null for a DOMString.
However, if only a DOMString is allowed, and null is passed, it should
not require a one-off mapping.
Ideally, yes. That's why there should be a default mapping, with
one-offs flagged as needed (ideally rarely).
-Boris
