Re: [WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties
Lachlan Hunt: WebIDL currently specifies in the ECMAScript to IDL type mapping [1] that null stringifies to null by default, unless otherwise specified with [TreatNullAs=EmptyString]. … 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. FYI, I made that change yesterday. -- Cameron McCormack ≝ http://mcc.id.au/
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 Huntlachlan.h...@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/
Re: [WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties
On 2011-05-07 16:03, Lachlan Hunt wrote: (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 now tested IE9, which did give me results. The following properties are all stringified to . * BODY .text, .bgColor, .link, .vLink, .aLink * HR .size * A, AREA .coords, .shape * IFRAME .width, .height, .marginHeight, .marginWidth * TABLE .bgColor, .width * COLGROUP, COL .width * TR .bgColor, * TD, TH .bgColor, .height, .width * INPUT .height, .width * BUTTON .type * .textContent on everything Every other tested property on HTML*Element interfaces stringified to null. (This is testing non-readonly DOMString properties on HTML*Element interfaces documented in HTML [1], excluding those I mentioned as untested in my previous mail.) [1] http://www.whatwg.org/C -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties
On Mon, May 9, 2011 at 9:22 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2011-05-07 16:03, Lachlan Hunt wrote: (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 now tested IE9, which did give me results. The following properties are all stringified to . * BODY .text, .bgColor, .link, .vLink, .aLink * HR .size * A, AREA .coords, .shape * IFRAME .width, .height, .marginHeight, .marginWidth * TABLE .bgColor, .width * COLGROUP, COL .width * TR .bgColor, * TD, TH .bgColor, .height, .width * INPUT .height, .width * BUTTON .type * .textContent on everything Every other tested property on HTML*Element interfaces stringified to null. What about namespaceURI, in various APIs (DOM-Core, DOM-XPath). 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. / Jonas
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/
Re: [WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties
On 5/7/11 10:03 AM, Lachlan Hunt wrote: 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. I was using Safari 5 on Mac; looks like it does something weird with document.write from a javascript: URI that's unrelated to the handling of null. 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? For the cases I describe above, the latter. 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? No idea. .text on HTMLAnchorElement, a.text is defined as an alias for a.textContent in HTML, which does stringify null to in all implementations. I'm just saying that in Gecko it's not an alias at the moment. Is there any reason why .text and .textContent need to be handled differently? No idea. -Boris
[WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties
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/
Re: [WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties
On 5/6/11 6:10 AM, Lachlan Hunt wrote: 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. It really depends on the case, actually. There has been a good bit of past discussion on this topic that you may want to read. Unfortunately, I don't remember whether that discussion was here, on public-html, on whatwg, or public-webapi, or public-script-coord. 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. document.write(null) will write null in Chrome and Gecko (but not Safari). You may want to check IE as well. 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. Furthermore, some IDL in Gecko explicitly treats null as null. In addition to the selector API, there's createHTMLDocument, all sorts of stuff on DOMTokenList, .text on HTMLAnchorElement, document.write/writeln, .wrap on HTMLTextAreaElement. So now you're aware of some properties where this is not the case... ;) 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 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. -Boris
