12798 2011-05-27 12:13:01 +0000 Default to [TreatNullAs=EmptyString] 2013-10-28 05:54:23 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified All All RESOLVED WONTFIX P2 normal --- 1 Ms2ger cam adrianba allen annevk brendan bugs jonas kennyluck lachlan.hunt mike public-script-coord travil w3c public-webapps-bugzilla oldest_to_newest 48868 0 Ms2ger 2011-05-27 12:13:01 +0000 Just to make sure you don't forget. 48899 1 cam 2011-05-29 22:30:53 +0000 Thanks, done now. I called the old behaviour "[TreatNullAs=String]", for want of a better identifier to use after the "=". http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.279;r2=1.280;f=h 49511 2 travil 2011-06-13 19:44:18 +0000 I'm a little concerned about this change; what was the justification for this change? In IE9, we now use WebIDL syntax to drive the code-generation for our legacy DOM APIs. I just checked, and 443+ of our legacy APIs are using null->"null" conversions, while only 2 needed the [TreatNullAs=EmptyString] annotations. There are some additional APIs I'd have to test to validate (as the signatures don't 100% align with those speced in the latest W3C WebIDL-converted specs)--however it's doubtful that those would change the tide. Given IE's wide deployment and large compatibility history, I'd guess that null->"null" conversions are more typically expected by the web. Additionally, by flipping the default, you are moving away from ECMAScript default conversions (ToString(x)) which seems backwards and not a direction we should be going. 49513 3 jonas 2011-06-13 19:58:02 +0000 I agree. I'd prefer to see this go the other direction despite the fact that Gecko's default is to do what the spec now says. 49514 4 bugs 2011-06-13 20:04:43 +0000 null -> "null" has always felt very strange to me. And based on experience with Gecko, the Web doesn't expect it more than handling null as a null or empty string. 49516 5 jonas 2011-06-13 20:08:21 +0000 I agree that null -> "null is strange (which is why I originally argued against it), but no stranger than undefined -> "undefined". And it is what's most consistent with other JS APIs. I think that is more important. 49517 6 bugs 2011-06-13 20:14:16 +0000 (In reply to comment #5) > And it is what's most > consistent with other JS APIs. Could you explain this a bit? 49518 7 jonas 2011-06-13 20:24:43 +0000 Any JS APIs which operate on strings will convert null to "null". For example a = "foo" + null; // a = "foonull" People that are more familiar with the standard JS API can probably come up with many more examples. 49520 8 bugs 2011-06-13 20:40:05 +0000 But this kind of common API doesn't magically convert null to "null". var o = { _a : "foo", setA: function(v) { this._a = v; }, getA: function(v) { return this._a; } } var value = null; o.setA(value); alert(value == o.getA()); So, I'm not sure "And it is what's most consistent with other JS APIs. " argument really holds. 49521 9 travil 2011-06-13 20:52:35 +0000 It's less about user code than about what ECMAScript defines in their "ToString()" internal API used throughout the specification to handle conversions. 49522 10 allen 2011-06-13 21:14:20 +0000 (In reply to comment #8) > But this kind of common API doesn't magically convert null to "null". > > var o = { > _a : "foo", > setA: function(v) { > this._a = v; > }, > getA: function(v) { > return this._a; > } > } > > var value = null; > o.setA(value); > alert(value == o.getA()); > > So, I'm not sure "And it is what's most consistent with other JS APIs. " > argument really holds. The above setA method doesn't do any conversion so it simply stores whatever was passed as the v argument. If a JavaScript programmer wanted to enforce that _a was a string they would most likely code it as: setA: function(v) { this._a = String(v); }, This String conversion is defined by ECMAScript in terms of ToString (section 9.8) which converts null to "null" and undefined to "undefined". 49523 11 bugs 2011-06-13 21:16:20 +0000 That example was just a counter example to "And it is what's most consistent with other JS APIs. " Nothing to do with string conversion ;) 49524 12 brendan 2011-06-13 21:18:20 +0000 (In reply to comment #8) > But this kind of common API doesn't magically convert null to "null". > > var o = { > _a : "foo", > setA: function(v) { > this._a = v; > }, > getA: function(v) { > return this._a; > } > } > > var value = null; > o.setA(value); > alert(value == o.getA()); There is no conversion here at all! I don't see how this argue for null -> "" or null -> "null". OTOH, the + operator with string on left or right, String called as function, parseInt/parseFloat convering their argument to string, all use ECMA-262's ToString, which does null -> "null". /be 49525 13 allen 2011-06-13 21:46:07 +0000 (In reply to comment #11) > That example was just a counter example to > "And it is what's most consistent with other JS APIs. " > Nothing to do with string conversion ;) It's all about string conversion. This issue is about what to do when null is passed as an argument corresponding to a parameter that is supposed to be a DOMString. In general, JS code that wants to ensure that a value is a string will use the String() function to do the conversion. That function is defined in terms of ToString. ToString is also specified as the default conversion algorithm for DOMString parameters in Web IDL 4.1.14 49530 14 cam 2011-06-13 22:20:17 +0000 (In reply to comment #13) > ToString is also specified as the default conversion algorithm for DOMString > parameters in Web IDL 4.1.14 Not after the recent change that prompted Jonas to reopen this bug. http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString I had written myself a note from a fair while ago to make this change, but I didn't write down the arguments for doing so. :o In trying to come up with arguments to support this post facto, I can't come up with anything super strong. We do of course have [TreatNullAs] to handle cases where the default isn't compatible with content. There are many operation/attributes in the HTML5 spec that take a string where passing in null seems like it should do the same thing as the empty string. null to me seems more "do nothing-ish" than the string "null". So for example doing inputElement.value = null; on the face of it looks much more like it would clear the value rather than set it to the string "null". OTOH this could encourage two different, valid ways of getting the same behaviour, when perhaps we should just be encouraging authors to use "". The previous behaviour is easier to explain. "When you pass a value to a DOMString parameter, it's always converted to a string like String(value) or value+''". 49534 15 allen 2011-06-13 22:33:45 +0000 (In reply to comment #14) > (In reply to comment #13) > > ToString is also specified as the default conversion algorithm for DOMString > > parameters in Web IDL 4.1.14 > > Not after the recent change that prompted Jonas to reopen this bug. > http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString > Actually, what I meant is that the default (step 3) after the special cases are found not to apply is ToString. 49675 16 Ms2ger 2011-06-16 08:45:29 +0000 I'm okay with reverting this; I filed the bug because I understood the consensus to be that null -> "null" wasn't web-compatible (at least, for non-IE browsers). I'd be rather happy if we could get away with changing the default. 49781 17 lachlan.hunt 2011-06-17 12:14:10 +0000 There are cases like document.write(null) and alert(null), where stringifying to "null" is better, particularly where those methods are used for quick debugging to check what the value of a variable is. If they stringify to "", then the output would be misleading for developers which, based on existing widespread behaviour, is to expect "null". 49820 18 cam 2011-06-18 05:41:29 +0000 I've reverted the change. 49825 19 annevk 2011-06-18 07:54:04 +0000 Pretty much every method and attribute setter relies on the Gecko behavior of null -> "" I think and there is quite some content out there that relies on this too. Enough that Opera recently switched from null -> "null" to null -> "". I believe WebKit has had similar experience. Now if Gecko is changed and they can ship with that change null -> "null" might be the right thing to do, but otherwise the more sensible default is null -> "". Both for existing methods and attribute setters and for future ones, so we have at least some consistency. 49842 20 travil 2011-06-18 19:17:59 +0000 >> "I *think* and there is quite some content out there that relies on this too" >> "I *believe* WebKit has had similar experience." Anne, can you provide some examples that motivated the change in Opera? As I sighted before, the IE behavior defatul is null->"null", so I'm wondering what sites are broken in IE due to this behavior (and not some other side-effect)? In addition to the compatibility argument, there's also the argument around consistency _with ECMAScript_ default behavior. We should be very careful about changing to a default that is inconsistent with ECMAScript null converstions in [[ToString]]. Now, if ECMAScript is willing to change their defaults, then I think we may have something to discuss. >> Now if Gecko is changed and they can ship with that change null -> "null" might be the right thing to do, but otherwise the more sensible default is null -> "". Both for existing methods and attribute setters and for future ones, so we have at least some consistency. Indeed I am arguing for consistency, but consistency between the DOM and ECMAScript. This is one of my goals for the WebIDL binding. 49885 21 zcorpan 2011-06-20 05:53:19 +0000 It would be good to hear from WebKit developers about this. 49898 22 w3c 2011-06-20 07:06:55 +0000 > It would be good to hear from WebKit developers about this. I don't have much to add. You all can test WebKit's behavior just as well as I can. I don't know of any particular requirements one way or another. 49929 23 brendan 2011-06-20 17:48:10 +0000 Need to survey some Gecko/WebKit/Presto forks of content that might care. I wrote in public-script-coord: Could someone cite some examples on the web? I'm prepared to believe they are Out There. We might have to cater to them with some quirks mode or other. But we need a survey to study the de-facto standard requirements. BTW, I'm sympathetic to the idea that WebIDL, for historical or even just-so ahistorical reasons, might want a "nullable DOMString" type. This is not that JS-friendly, and JS matters a lot more than Java, C#, etc. But it still could be that WebIDL and users, even users of the JS APIs, want null -> "" (a falsy value). So ignoring compatibility constraints, and ignoring the separate falsy-might-be-better argument, I'd prefer "ECMAScript ToString" semantics. But we can't ignore those two issues, I agree. We need to study some JS on the web that cares. --- The breaking change could be bad: falsy value becomes truthy, changing control flow. Also, less bad but still pretty bad: you see "null" instead of "" in data that is presented to the user. /be 49944 24 annevk 2011-06-20 21:41:58 +0000 It seems my recollection about this affecting a lot was wrong (thankfully I guess). This affected two or three sites of which I cannot give the URL and given that both Gecko and WebKit were consistent we decided to follow them. In particular innerHTML and setAttribute() are affected. If both Gecko and WebKit change we can change as well. 50086 25 cam 2011-06-22 00:02:16 +0000 Per http://www.w3.org/mid/op.vxfg9dxp64w2qv@anne-van-kesterens-macbook-pro.local I'm marking this RESOLVED WONTFIX. Remember that this would have been only a change in defaults -- individual attributes and operation arguments can be marked with [TreatNullAs] to override the default, in case of compatibility problems. If in the future we have some concrete data on whether DOM APIs overwhelmingly prefer "" or "null", we can just select the default appropriately and update specifications.