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

Hi,
   WebIDL currently specifies in the ECMAScript to IDL type mapping [1] 
that null stringifies to "null" by default, unless otherwise specified 
with [TreatNullAs=EmptyString].

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.

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.

But this fix also had the result of changing the way we handled null in 
selectors-api, for which we used to stringify as "null".

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

Since Selectors API is defined to use the default behaviour as specified 
by WebIDL, and if and when WebIDL gets updated, then it also means that 
the Selectors API implementations in Gecko, WebKit and IE will also need 
to be updated again and I will need to update the test suite.

In Gecko's case, this means reverting back to the behaviour they had 
shipped in Firefox 3.6, so it's unlikely that reverting this will result 
in any web compatibility issues.

[1] http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Friday, 6 May 2011 10:11:18 UTC