On 2011-05-06 15:45, Boris Zbarsky wrote:
On 5/6/11 6:10 AM, Lachlan Hunt wrote:
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.
Sorry, I should have said most. We were aware of a few exceptions.
document.write(null) will write "null" in Chrome and Gecko (but not
Safari). You may want to check IE as well.
For document.write(), Gecko, Webkit (including Safari 5), Opera and IE
write "null" on both Windows and Mac. I don't know which version of
Safari you were using that gave you a different result.
alert(null) outputs "null" in all browsers. Both confirm(null) and
prompt(null, null) output "" in Gecko and "null" in all others.
It's possible that alert() and .write() might need to be defined as
exceptions for compatibility, especially since both are commonly used
for quick debugging purposes and it's useful to clearly see when a
variable is null using alert(foo); I don't really have a strong opinion
either way for the confirm() and prompt() methods, though consistency
with alert seems sensible.
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.
Is there any reason to believe that any or all of those are
intentionally done that way for this handling of null, or are they
merely a result of the way the programmers arbitrarily decided to
implement them?
Furthermore, some IDL in Gecko explicitly treats null as "null". In
addition to the selector API, there's createHTMLDocument,
Opera throws an exception when invoking createHTMLDocument(null). Is
there any evidence that stringifying to "null" is required for
compatibility at all?
all sorts of stuff on DOMTokenList,
It seems unlikely that DOMTokenList would have any compatibility issues
with either approach, considering it's a relatively new feature with
limited support and limited deployment.
.text on HTMLAnchorElement,
a.text is defined as an alias for a.textContent in HTML, which does
stringify null to "" in all implementations. Opera 11 stringifies .text
to "null". WebKit and IE don't support a.text, but do support
.textContent. Is there any reason why .text and .textContent need to be
handled differently? If so, then that will require HTML to be updated.
Otherwise, I don't see why that isn't just regarded as a bug in Gecko.
.wrap on HTMLTextAreaElement.
Wrap is an enumerated property and the strings "" and "null" are both
interpreted as the missing value default state, "soft". It only affects
the way the way the value is reflected in the content attribute. So
changing that shouldn't have any compatibility issues.
I also found HTMLOutputElement.defaultValue stringifies to "null" in Gecko.
In all other cases I've checked, including 99% of all DOMString
properties on HTMLFooElement interfaces documented in HTML, Gecko
stringifies to "".
WebKit instead just removes an attribute from the DOM when the
corresponding property is assigned null, and this means the default
value (usually "") is returned when getting those properties. So, while
not technically the same as stringifying to "", it is compatible with it.
Opera 11 stringified the following to "":
* [A, AREA, LINK, BASE] .href
* SCRIPT .text
* INPUT .type, .value
* BUTTON .type
* KEYGEN .keytype
* .textContent on everything
All other properties stringified to "null", which caused site compat
problems in some cases.
(I haven't checked these properties yet: protocol, host, hostname, port,
pathname, search, hash on A and AREA, selectionDirection on INPUT and
TEXTAREA, value on SELECT, and outerHTML on everything.)
(I don't have results for IE yet because the testharness script I used
to write the tests doesn't work in IE.)
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'm not sure where it's been mentioned publicly. That's just what Anne
has claimed internally.
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.
I think it's safe since Firefox 3.6 has that behaviour and there doesn't
seem to be any known issues caused by that.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
