Re: [whatwg] WebIDL and HTML5

On Wed, Aug 27, 2008 at 11:58 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
> Garrett Smith wrote:
>>
>> I contend that the textContent example is not designed in a useful
>> manner and that having null -> "" sometimes and null -> "null" others
>> introduces complexity.
>
> Sure.  And we're stuck with this complexity.  Now where do we go from here?
>

Having specifications that mention null's special behavior, but having
that behavior vary has caused problems.

Given that, I suggest moving forward:
  Test, then document those methods as having special behavior. Do
this not by a null->value mapping, but by documenting the method's
algorithm in simple terms. e.g. "if X is not a string, throw an error"
  Make a decision for either (1) null and other non-string values are
handled or (2) leave the behavior implementation-dependent.

I would say (1) is somewhat desirable. Sites that rely on things like
input.value = 12; style.height = 0.

If it is decided that handling non-string values for dynamic languages
(EcmaScript) should be standardized, then methods that handle
non-string values should be tested using non-string values (in
EcmaScript, that includes an Object and 4 other primitives). For
exampe:-

input.value = null;

Firefox:
 ""
Opera
 "null"
Safari:
 depending on the type of input, use defaultValue or remove the attribute.
IE:
  Windows won't start (Opera often has the same result as IE)

Testing would indicate where handling of some values, especially null,
is not consistent. Edge cases with null will usually be a programmer
accident.

<spec-correction>
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent

The textContent documentation seems a bit off.
| 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.

This would be the following pseudocode:
If newString !== "" || newString === null Then
 // replace by a Text node containing newString

I now realize that this is interpreted as:
If not newString === "" and not newString === null Then
 // replace by a Text node containing newString

Could be written as:
| Setting:
| Remove all children of this node.
| If inputString is null or empty, return.
| append a single Text node containing the inputString.

Aside from that, there is the error: "if it the new string". The
sentence would be more clearly broken into two sentences using
positive, not negative conditions.
</spec-correction>

Garrett

> -Boris
>
>

Received on Wednesday, 27 August 2008 20:43:45 UTC