Re: [whatwg] WebIDL and HTML5

Garrett Smith wrote:
> I do not see where the spec describes the particular effect when
> setting to nul.

Maciej quoted the exact text.  So did I.  I suggest selecting that text, 
copying it, going to your browser, opening up the find dialog or 
equivalent, pasting it, and thus getting to see where it is in the spec.

Or you could actually read the section on textContent in DOM3 Core... 
Whichever.

> I don't see it. Where does it say null is converted to the empty string?

See above.  It doesn't say null is converted to the empty string.  It 
says that the empty string and null behave the same when assigned to 
textContent.

> I do see some discussion of null being differentiated from empty strings:

Yes, indeed.  And that discussion talks about what to do with that case. 
  Again, no one claims that null is "".  But they have to be treated the 
same way in some cases.

> | 1.3.3 XML Namespaces
> | In programming languages where empty strings can be
> | differentiated from null, empty strings, when given as a
> | namespace URI, are converted to null.

Like in this case.

> | Setting the prefix to null makes it unspecified, setting it to
> | an empty string is implementation dependent.

Indeed.  In this case, no mapping is defined by the idl (though ideally 
this would not have the "implementation-dependent" thing and just define 
behavior, period).

> | Note that when using the methods that take a feature and a
> | version as parameters, applications can use null or empty
> | string for the version parameter

Right.  And the behavior must be the same whether null or "" is used.

> I've explained numerous times that null is not a string value.

In the DOM, it is.  This isn't called out explicitly in the DOMString 
definition, but it's assumed de-facto throughout the DOM specs.

Note that I'm not saying this is necessarily a good thing.  It's just a 
fact we have to live with.

> Treating null as the empty string is not consistent with the language.

"The" language?  The DOM is language-agnostic.

> A method that has special behavior for null would be fine.

Indeed.  The DOM is full of such methods.

> The special behavior could be throwing an exception (might help find bugs), or
> creating a string from the argument, in the given language; that would
> be "null" in EcmaScript and Java.

A number of DOM methods define the special behavior to be 'treat the 
argument as ""'.  Why exactly do you have a problem with accepting this 
given the numerous examples in the spec?

Put another way, what do _you_ think createElementNS is saying to do 
with the namespaceURI argument?

> Creating mappings for methods where null=Empty, null="null" is chatty.
 > It's not consistent with what developers would naturally expect in
 > EcmaScript.

Sure.  No one _likes_ having to do this.  But changing the way the DOM 
works is not an option, so we're kind of stuck with it.  And again, 
there's more to the DOM than just ECMAScript (sadly, in some ways, from 
an ECMAScript point of view).

> I would more rather you try to understand the reasoning.

I think we understand your reasoning.  You, on the other hand, seem to 
have trouble understanding... Again, in simple terms:

1)  The DOM defines certain behavior.
2)  Changing this behavior is not an option.
3)  It would be good to express this behavior explicitly in the IDL so
     that it's easy to machine-generate DOM bindings and for improved
     interoperability.

Which part of that doesn't make sense?

> Get some rest. We don't have to come to an agreement right away.

Honestly, I don't see how we can "come to an agreement" when you 
fundamentally won't accept basic premises like "the DOM Core specs are 
not up for change in this discussion".  And honestly, trying to explain 
things to you is starting to look like a total waste of time.

-Boris

Received on Wednesday, 27 August 2008 12:46:03 UTC