Re: [WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties

On 5/6/11 6:10 AM, Lachlan Hunt wrote:
> This definition matches current selectors-api implementations, which do
> this conversion for the selectors parameter and this is also the result
> expected by the current selectors api test suite. However, according to
> information I got from Anne, and from my own limited testing, this does
> not seem to be true of other DOMString attributes or properties in other
> implementations.

It really depends on the case, actually.  There has been a good bit of 
past discussion on this topic that you may want to read.  Unfortunately, 
I don't remember whether that discussion was here, on public-html, on 
whatwg, or public-webapi, or public-script-coord.

> Recently, in order to resolve a site compatibility issue caused by us
> stringifying to "null" for some properties, we made all DOMString APIs
> consistent in their handling of null, such that they now stringify to an
> empty string. We believe this is compatible with other implementations
> for all other attributes and properties that we are aware of.

document.write(null) will write "null" in Chrome and Gecko (but not 
Safari).  You may want to check IE as well.

There are various other cases that have this behavior.  In Gecko, 
anything that goes through JS_ValueToString (instead of default 
XPConnect argument conversion that converts null to a void empt) will do 
this.  This is unfortunately not particularly consistent.

Furthermore, some IDL in Gecko explicitly treats null as "null".  In 
addition to the selector API, there's createHTMLDocument, all sorts of 
stuff on DOMTokenList, .text on HTMLAnchorElement, 
document.write/writeln, .wrap on HTMLTextAreaElement.

So now you're aware of some properties where this is not the case... ;)

> I've been informed that Cameron has plans to update WebIDL to make this
> the default too, but hasn't yet done so.

Oh, interesting.  I'd either missed that or forgotten it...  I don't 
have a problem with this change per se, but note that it will change 
querySelector(null) from silently doing probably the wrong thing to 
throwing.  I do think it should be safe, though.

-Boris

Received on Friday, 6 May 2011 13:45:36 UTC