Re: [whatwg] WebIDL and HTML5

On Tue, Aug 26, 2008 at 6:52 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Aug 26, 2008, at 5:22 PM, Garrett Smith wrote:
>
>>
>> On Tue, Aug 26, 2008 at 4:47 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>
>>> So let me repeat the question with
>>> the grammatical error fixed. Please do excuse any other grammar errors I
>>> introduce as English is a second language to me.
>>>
>>> 3)  The behavior of the function when null is passed as value for an
>>>  argument is almost always either that of "" or that of "null".
>>>  Which one depends on the exact DOM method.
>>>
>>> Do you agree with this?
>>>
>>
>> No, I do not agree. If the parameter type is domstring, and null is
>> not allowed, and the caller passes null, then the current behavior is
>> implementation-dependent.
>
> 1) What DOM methods or attributes are specified to take a DOMString but
> disallow null? At least some DOM methods clearly specify how null should be
> treated when passed as the value for a DOMString parameter. There are also
> many DOM methods and attributes that are not specified anywhere (except
> perhaps in the unstable HTML5 Working Draft), which thus currently have
> implementation-defined behavior. And many other methods do not specifically
> say null is either allowed or disallowed, which would lead to the
> presumption that it is allowed, since the specification of other methods
> assumes it matches the DOMString type.
>
>> I did not agree ever that "" should be used
>> when null is passed as a value to an object that expects a string (or
>> dom method that expects a domstring). I believe that in the
>> following:-
>>
>>
>> el.textContent = null;
>>
>> - with the options:-
>> a) raise exception
>> b) textContent is set to "null"
>> c) textContent is set to ""
>>
>> Option (c) is wrong.
>> Option (b) would be marginally useful in a few cases
>> Option (a) would be helpful in some cases (finding bugs)
>
> Option (a) is unacceptable for the following reasons:
>
> 1) It does not match existing implementations and thus would likely break
> compatibility with existing content.
>
> 2) It violates the DOM Level 3 Core specification, which says: "On setting,
> any possible children this node may have are removed and, if it the new
> string is not empty or null, replaced by a single Text node containing the
> string this attribute is set to." Thus, clearly assigning null to
> textContent must remove all children of the node.
> <http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent>
>
> In fact your option (c) appears to be mandated by the spec. Can you explain
> why you stated that it is "wrong"?
>

No, option (c) is not mandated by the spec. That is clearly not true.

| When it is defined to be null, setting it has no effect.

I don't agree that that is a good way to handle null, but it is clear
that these two:

document.body.textContent=null;
document.body.textContent='';

Are specified as being different from each other. They are different
because "" is the empty string and null is null. Agreed?

el.textContent = null won't work consistently across browsers. I would
argue that it ought to just set the textContent to "null", since it
would make finding the bug easier. I say this because most programmers
who set textContent to null are doing so by accident, or are trying to
debug something, e.g.

var nodeRef = document.getElementById('invalid_id');
logger.log( nodeRef, INFO  ), where log() sets the textContent
property of a node.

- where nodeRef could easily be null from the call to getElementById,
and would then create a problem with the logger where nothing was
logged. It would be possible to change the Recommendation. Setting
textContent = null is not something that has seen widespread use yet
and changing Firefox and Webkit implementations would be cumbersome.

It is probably at least as likely, if not more likely, that undefined
would end up as a value passed:-

var undef;
document.body.textContent=undef;

It would be somewhat useful if this were printed out as:-

"undefined"

being printed in the document.body.

Other considerations:-

el.textContent = new Date(); // Should it be calling toString()?

>
> Can you explain the reasoning behind your strongly held views on null used
> as a string parameter, since they do not seem to line up with either the DOM
> specifications or with existing implementations? I can sympathize with a
> desire for the handling for null to be clean and elegant, but unfortunately
> existing implementations, content and specs do not allow for such a
> possibility.
>

The spec you mention makes a misfortunate mistake, however, it is not
the mistake that I am concerned with at the moment. The mistakes that
I am more strongly opposed to is the creating of a serialize mapping
of null -> "".

As I have previously stated, it would be inconsistent to serialize
null to something other than "null".

It would be OK for the method or setter to raise on null, or to have
specified behavior if null were passed in.

The mistake is the conversion of null to the empty string.

My view on passing null to DOM methods is inconsistent with the spec,
I must disagree again. In fact, the specifications we've discussed
don't say how to map null to domstring.
http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-C74D1578

It is my opinion that it is wrong to map null -> "" where domstring is
required. The method should either raise a domexception, (and/) or
should convert the argument to a string. Since the compiler can't
check the argument, it is necessary, as stated in numerous examples
such as:-

// Nonstandard*. Works in FF3.1, Safari, Op9.
document.body.style.fontWeight = 800;

var colorObject = {
 r : 16, g: 255, b: 16,
 toString : function() {
   return "rgb(" + this.r + "," + this.g + "," + this.b+")"; }
}
document.body.style.color = colorObject;

(bookmarklet);
javascript:void(document.body.style.background={toString:function(){return"#0f0"}});

* zIndex is of type DOMString
http://www.w3.org/TR/DOM-Level-2-Style/ecma-script-binding.html

Garrett
>
> Regards,
> Maciej
>
>
>

Received on Wednesday, 27 August 2008 02:31:55 UTC