[Bug 21886] [Custom]: Define or link to what it means for a local name to be associated with an interface

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21886

--- Comment #4 from Dominic Cooney <dominicc@chromium.org> ---
Proposal A: Any type extension needs to name a tag when it is registered, even
if it is redundant based on the prototype.

This has some nice aspects:

- It's clearer when you're registering a type extension and when you're
registering a custom tag, which is a plus.

- Maybe we could not bother doing prototype chain walking on register. If the
author wants to mess up prototype chains, let them.

(In reply to comment #3)
> I'm tempted to suggest that for unambiguous prototypes (e.g.
> HTMLVideoElement) that we do the magic "divine the localName from the
> prototype" (which would be option 2, I guess) but do we have to worry about
> new elements breaking existing document.register calls by adding a new
> built-in element that would make a previously-unambiguous call to
> document.register ambiguous?

There's also the question of whether doing something ambiguous like extending
HTMLModElement, HTMLHeadingElement. Is that an error?

Proposal B: 

1. Each HTML element has an associated tag name. Those are per the HTML spec,
except in the case of HTMLModElement, HTMLHeadingElement (others?) which are
defined to be "ins" and "h1" respectively. (Yes, it is arbitrary.) This future
proofs existing kinds of elements that gain a new tag name; we can just define
their associated tag name post-hoc to be whatever the historical name was.

2. document.register's dictionary argument has another optional entry (what
should we call it?) that specifies the tag name the element should have *when
created by the constructor*.

3. createElement, createElementNS aren't changed. The author can use any
matching tag name for those calls.

Some code to illustrate this suggestion:

var A = document.register('x-a', {prototype:
Object.create(HTMLHeadingElement.prototype)});

var h3 = document.createElement('h3', 'x-a');
Object.getPrototypeOf(h3) === A.prototype  // true per #3 above

(new A).outerHTML // "<h1 is="x-a"></h1> per #1 above

var B = document.register('x-b', {prototype:
Object.create(HTMLHeadingElement.prototype}, localName: 'h4'});

(new B).outerHTML // "<h4 is="x-b"></h4> per #2 above

var h2 = document.createElement('h2', 'x-b');
Object.getPrototypeOf(h2) === B.prototype  // true per #3 above

Making this go would require rework to DEFINITION which only has one name in
it. Not sure how much behavior is hooked off that.

I think both Proposal A and Proposal B are consistent. I like Proposal A; it
looks simpler and more predictable.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 17 May 2013 00:00:13 UTC