Re: [whatwg] WebIDL and HTML5

On Wed, Aug 27, 2008 at 2:49 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Garrett Smith wrote:


> 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?
>

The drawback would be inconsistency with current implementations and
with the behavior that developers might naturally expect. (the
unnatural expectation that null is converted to "" in some default
mapping appendix).

>> 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.
>

I disagree. That the DOM spec does not include null. It is very
verbose on what it does include, so it's not by accident.

I believe that null should be handled based on what it is.

>> However, WebIDL does lump null into domstring.
>
> Yes, because de-facto DOM does this already.
>

My examples clearly show otherwise. null is handled differently in
Firefox, [Opera/IE], Safari, depending on what DOM method /property it
is used for.

<input type="submit" id='xx' value="go">
document.getElementById('xx').value = null

Will result in:
   Opera setting the value to "null"
   Safari removing the attribute
   Firefox sets the attribute to ""
   IE: Windows will not start again :-(

My examples show that there is non-standard behavior that is handled
differently in different browsers. The way to standardize that is not
to call the value null a string with a special value.

>> 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.
>

That is true. There are methods that discuss what happens when you
pass null to a method that accepts 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).
>

I see. Well, I can just avoid the problem by always using strings
where domstring is required.

> -Boris
>

Received on Wednesday, 27 August 2008 22:21:05 UTC