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

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/

Received on Saturday, 7 May 2011 14:04:21 UTC