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/
