Re: [whatwg] WebIDL and HTML5

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

How so?  Anything that specifies interoperable behavior would have this 
problem in some cases, as testing indicates.  In cases when the behavior 
is already interoperable there is no inconsistency.

> and with the behavior that developers might naturally expect.

That's an issue even if it's just the spec text that says that null is 
treated in a special way.

Again, what is your specific problem with the specific approach of 
annotating null/undefined conversions as opposed to just describing them 
in the spec text?

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

Then how do you account for all the places in the same spec that talk 
about passing null to DOMString arguments?

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

That's fine.  How is it compatible with the existing specs?

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

I don't see what that has to do with my statement above, that de-facto 
DOM method specifications assume that null can be passed for a DOMString 
and that a number of DOM methods specify what should be done in that case.

Honestly, you can stop copy/pasting the same examples in.  We've seen them.

> That is true. There are methods that discuss what happens when you
> pass null to a method that accepts a domstring.

Right.  That discussion is what should be moved into IDL annotations.

-Boris

Received on Wednesday, 27 August 2008 23:39:58 UTC