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
Re: [File API: FileSystem] Path restrictions and case-sensitivity
On Fri, May 6, 2011 at 8:22 PM, Glenn Maynard gl...@zewt.org wrote: This can be solved at the application layer in applications that want it, without baking it into the filesystem API. I wasn't talking about baking it into the api, i meant that the application using it could write such code. I don't know what you're talking about. We're not talking about serializing to FAT, we're talking about case-sensitivity within virtualized filenames. you raised an issue involving if something were serialized, and i noted that the serialized case is already unhappy with eric's proposal. Again, if filenames are case-insensitive, then the API will work differently on a Turkish system than other systems, as I described, in a way that's guaranteed to cause interop failures. This point stands. someone generating the content is likely to generate the file name references directly too (as i noted), as such it's unlikely that problems will happen. case 1: file is 'dotless-i', file reference is 'dotted-i', the generated content does *not* work on your *average* system. someone notices relatively quickly. case 2: file is 'dotted-i', file reference is 'dotless-i', the generated content does *not* work on your *average* system. someone notices relatively quickly. case 3: file is 'dotted-i', file reference is 'dotted-i', the generated content should work everywhere. case 4: file is 'dotless-i', file reference is 'dotless-i', the generated content will work or not depending on the user agent's ability to safely serialize the content (file and referencing file) to the host platform. this case is no different than with any other rule set.
Re: [File API: FileSystem] Path restrictions and case-sensitivity
On Sat, May 7, 2011 at 9:24 PM, timeless timel...@gmail.com wrote: On Fri, May 6, 2011 at 8:22 PM, Glenn Maynard gl...@zewt.org wrote: This can be solved at the application layer in applications that want it, without baking it into the filesystem API. I wasn't talking about baking it into the api, i meant that the application using it could write such code. You're talking about baking case-insensitivity into the API. I'm saying applications can implement case-sensitivity if it's desired for their use case, instead of forcing it on everything despite the problems it causes. you raised an issue involving if something were serialized, and i noted that the serialized case is already unhappy with eric's proposal. I didn't say anything about serializing to FAT--I didn't mention FAT at all. I said: It's a serious problem if this isn't interoperable. If filenames are case-insensitive and honor the locale, then people are going to save files as IMAGE.JPG and access them as image.jpg, and it'll work everywhere except on Turkish systems. If *this API's* concept of filenames is case-insensitive, then IMAGE.JPG and image.jpg represent the same file on English systems and two different files on Turkish systems, which is an interop problem. case 1: file is 'dotless-i', file reference is 'dotted-i', the generated content does *not* work on your *average* system. someone notices relatively quickly. If you create IMAGE.JPG (dotless-I) in one part of your code and then refer to it elsewhere as image.jpg (dotted-i), it *does* work on an average (non-Turkish) system if filenames are case-insensitive. Only when someone tries to use this same code on a Turkish system will it fail, where I and i are different characters. -- Glenn Maynard
