[whatwg] DOM Storage feedback

[Cameron McCormack]

Jonas Sicking:
> So it behaves different from passing in an empty string? For some
> functions this surprises me, such as for the namespace parameter for
> getAttributeNS, I would think that we there treat "" the same as null.

Not necessarily, but I agree that would be a better thing to report.
I’ll rejig the tests to get that information.

Cameron McCormack:
> > OK.  So what is more important for choosing the default: fewer
> > exceptions (and thus fewer [Null=…] things polluting the IDL),
> > consistency with the default stringification behaviour of ECMAScript,
> > or avoiding the somewhat counterintuitive default behaviour of
> > converting a valid value of the type to a different value of that type?

> "converting a valid value of the type to a different value of that
> type", which values exactly?

null.  It feels slightly strange to me to treat null as a “second class
value” by default.  But I’ll get over it. :-)

It may actually be indicative of a need for two distinct types: strings
(i.e., possibly empty sequences of characters) and strings-or-null.  But
I don’t know if it’s worth rewriting everything in this way.

> I think another factor, that you haven't mentioned, that is very
> important is web compatibility. But beyond that I think I would rate
> fewer exceptions highest.

Well, I assume that writers of specs that document already-implemented
interfaces will choose the appropriate [Null] annotation (or lack of it)
for web compatibility.  Which to choose as the default is orthogonal, I
think.

-- 
Cameron McCormack ≝ http://mcc.id.au/