On 2011-05-09 22:31, Jonas Sicking wrote:
On Mon, May 9, 2011 at 9:22 AM, Lachlan Hunt<[email protected]> 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/
