Re: [selectors-api] Stringifying undefined

Jonas Sicking wrote:
> On Fri, Feb 13, 2009 at 5:23 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
>> e.g.
>> function nsresolver(ns) {
>>  uri = {xht: "http://www.w3.org/1999/xhtml",
>>        svg: "http://www.w3.org/2000/svg"}
>>  return uri[ns];
>> }
>>
>> For resolving the default namespace, this would return undefined.  And there
>> were similar cases where it made sense for null or "" to be returned
>> instead.
> 
> I'm not sure I agree with this reasoning. This also results in that
> the 'foo' and 'cheesedoodles' prefixes are resolved to the default
> namespace, is that really desired?

When the NSResolver was in the spec, that's not how it worked.  If, when 
resolving a prefix, null or undefined was returned, then they were 
treated the same as the empty string so that an exception would be 
thrown.  It was only for the default namespace (prefix = "") that was 
allowed to have "" (or null or undefined) returned.

> function nsresolver(ns) {
>  uri = {xht: "http://www.w3.org/1999/xhtml",
>        svg: "http://www.w3.org/2000/svg"
>        "": ""};
>  return uri[ns];
> }

If we do add namespace resolving again, it's not yet clear if the 
function is the solution that we will use. But if we did, then that 
makes it incredibly inconvenient for authors since, in most cases, they 
would have to remember to declare {"": ""} every time, along with 
whatever other prefixes they actually wanted to declare.

Anyway, I'd rather postpone this discussion of what NSResolver we use, 
if at all, till later when work on version 2 has begun.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Wednesday, 18 February 2009 22:09:34 UTC