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

On 2011-05-09 22:31, Jonas Sicking wrote:
> On Mon, May 9, 2011 at 9:22 AM, Lachlan Hunt<lachlan.hunt@lachy.id.au>  wrote:
>> Every other tested property on HTML*Element interfaces stringified to
>> "null".
>
> What about namespaceURI, in various APIs (DOM-Core, DOM-XPath).

Node.namespaceURI is readonly according to DOM3 Core, so setting it to 
null has no effect.  But I just tested createElementNS() and got the 
following results:

var el = document.createElementNS(null, "foo");

Firefox, WebKit, Opera, IE:
   el.namespaceURI returns null
   el.prefix returns null
   el.localName returns "foo"; returns "FOO" in Opera

Same result as invoking createElementNS("", "foo");


var el = document.createElementNS(null, null);

Firefox, WebKit, Opera (internal) throw INVALID_CHARACTER_ERR

Same result as invoking createElementNS("", "");

Opera 11, IE 9:
   el.namespaceURI returns null
   el.prefix returns null
   el.localName returns "null" in IE; returns "NULL" in Opera

Same result as invoking createElementNS("", "null");

> In general, my main priority is that we make things as consistent as
> possible. My second priority is that we make things follow JS
> behavior. So I'd be very happy if we can get away with making the just
> the above list stringify to "", and the rest of the DOM stringify to
> "null".

We had a site compatibility bug with at least one property recently, 
(input.max = null), that we were stringifying to "null", but where the 
site is expecting WebKit-compatible behaviour.  We've also had similar 
compat problems in the past with some CSSOM properties, although they 
have since been defined as nullable types in that spec.

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

Received on Tuesday, 10 May 2011 10:51:27 UTC