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

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.

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.

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.

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.

(In reply to comment #5)
>  And it is what's most
> consistent with other JS APIs. 

Could you explain this a bit?

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.

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.

It's less about user code than about what ECMAScript defines in their "ToString()" internal API used throughout the specification to handle conversions.

(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".

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 ;)

(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

(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

(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+''".

(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.

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.

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".

I've reverted the change.

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.

>> "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.

It would be good to hear from WebKit developers about this.

> 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.

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

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.

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.