Re: [whatwg] WebIDL and HTML5

On Wed, Aug 27, 2008 at 9:44 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> Garrett Smith wrote:

>
> So it says to first remove all children, and then do nothing more. Do you
> share this interpretation for this one attribute?
>

Yes.

>
> So at this point I want to ask though: What is your proposal?
>

Walk away from the argument.

I contend that the textContent example is not designed in a useful
manner and that having null -> "" sometimes and null -> "null" others
introduces complexity. I see this influence in "Pro JavaScript
Techniques":

| In JavaScript, null, 0, '', false, and undefined are all equal (==)
| to each other...

(though slightly out of context, it is in similar vain)

Of course IDL is language-agnostic. It was a proposal to leave the
serializing of null to a language, so that languages that treat null
as "" can do so.


> What do you propose should happen when an attribute like
>
>  attribute DOMString nodeValue;
>
> is set using the following ECMAScript code:
>
>  myNode.nodeValue = "hello";
>  myNode.nodeValue = "";
>  myNode.nodeValue = 0;
>  myNode.nodeValue = 10.2;
>  myNode.nodeValue = { toString: function() { return "str"; } };
>  myNode.nodeValue = new Date();
>  myNode.nodeValue = null;
>  myNode.nodeValue = undefined;
>  myNode.nodeValue = myNode;
>
> where myNode points to a textnode. Note that 'throw an exception' is a valid
> answer. In that case ideally also specify the exception to be thrown if you
> have an opinion.
>

No specification is needed for "' or "hello".

Should the others be implementation-dependent, or should they be
standardized/specified to throw/handle?

Andrew Oakley seemed to be of the opinion that WebIDL should specify
what type conversions may or may not happen.

In IE throws an error with - style.color = obj - which might seem
surprising, but does not pose a serious problem. Easy to notice and
very easy to code around.

Conversion of numbers where a string is expected works in the browsers
I've tried.

If there were serialization plans for each value type, and they varied
across methods, it would be confusing and complex. However, if there
were a string conversion function that could be applied, and it would
not break sites, and would meet reasonable expectations, and not
create browser compatibility issues, that would be good.

Using EcmaScript's ToString, the result would be:-

myNode.nodeValue = "hello"; // "hello" (already specified)
 myNode.nodeValue = ""; // "" (already specified)
 myNode.nodeValue = 0; // "0"
 myNode.nodeValue = 10.2; // "10.2"
 myNode.nodeValue = { toString: function() { return "str"; } }; //  "str"
 myNode.nodeValue = new Date(); //  result (new Date).toString()
 myNode.nodeValue = null; // "null"
 myNode.nodeValue = undefined; // "undefined"
 myNode.nodeValue = myNode; // result String( myNode );

Does this behavior seem reasonable? Consider that the setting of
myNode.nodeValue = null has the result:

Opera:
 "null"
Firefox, Webkit,
 ""
and for  myNode.nodeValue = undefined
 IE:
 ""
FF, Op, Safari,
 "undefined"

The following example demonstrates a comparison between a command
above, and calling String() for a command above. The intent is to
observe the difference between the string conversion handled by the
dom setter and the string conversion performed by calling String on
that same argument.

<!DOCTYPE HTML>
<html lang="en">
<head>
	<title>nodeValue -&gt, ToString</title>
</head>
<body>
<button onclick='next()'>next()</button>
<div>actual: <span id="out">xxx<span></div>
<div>ToString: <span id='ToString'>xxx</span></div>

<script>
var d = document,
    o = { toString: function() { return "str" } },
    myNode = d.getElementById('out').firstChild,
    ToString = d.getElementById('ToString').firstChild;

var i = 0,
    cmds = ["hello", "", 0, 10.2, o, new Date, null, undefined, myNode ];
function next() {
  if(i == cmds.length-1) return;
    myNode.nodeValue = cmds[i];
    ToString.nodeValue = String(cmds[i]);
    i++;
}
</script>
</body>
</html>

The result of setting nodeValue is the same as setting
String(nodeValue), except for the case null.

For null
Firefox, Webkit:
 ""
Opera, MSIE:
 "null"

for undefined:
Firefox, Webkit, Opera
 "undefined"
MSIE
 ""

I keep having problems starting windows. "Insufficient system
resources for the API." "Not enough virtual memory." Errors.

Garrett

> Note that the lines should be considered separate from each other. So if for
> example the second line throws I am still interested to hear what the third
> line does etc.
>

Nothing throws in any browser, but the test is far from exhaustive to
make a standard.

> Extra interesting would be to hear motivation on why you think the behavior
> you describe is the appropriate one.
>

Well they're all non-standard.

It seems to be an expectation among some that object would be
converted to a string:
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/788d0d6e130d51a4/7ccea2f5a7226d65?lnk=gst&q=new+color+library+tostring#7ccea2f5a7226d65

I experienced the same thing Jeff did - setting a color to an object
causes an error in IE. IE's behavior is valid and is not a problem to
code around.

Standardizing conversion of number to string seems reasonable and
there is code that depends on that working. OTOH, I can't say I feel
very strongly on this issue, it's trivial to code around once you're
aware that domstring arguments don't convert the argument to a string.

I'd rather hear more input.

Garrett

> Best Regards,
> Jonas
>

Received on Wednesday, 27 August 2008 18:52:01 UTC