[Bug 21888] New: [Custom]: #dfn-custom-element-definition should be defined, and maybe registering a type extension of a custom tag should become an error?

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

            Bug ID: 21888
           Summary: [Custom]: #dfn-custom-element-definition should be
                    defined, and maybe registering a type extension of a
                    custom tag should become an error?
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Component Model
          Assignee: dglazkov@chromium.org
          Reporter: dominicc@chromium.org
        QA Contact: public-webapps-bugzilla@w3.org
            Blocks: 14968

This bookmark "#dfn-custom-element-definition" is referred to from Step 1 of
the element initialization algorithm but does not seem to be defined anywhere.

What I'm trying to close in on is a simplification of the spec. Specifically,
there's an asymmetry between document.register, which seems to admit setting up
a type extension of a custom tag, for example:

XA = document.register('x-a');
XB = document.register('x-b', {prototype: XA.prototype});

and createElement/parsing which says that:

"After a custom element is instantiated, changing the value of the is attribute
must not affect this element's custom element name.

If both types of custom element names are provided at the time of element's
instantiation, the custom tag must win over the type extension."

I'm specifically worried about the difference in meaning between parsing <x-a
is="x-b"></x-a> and simply calling new XB().

For example, could this create a constructor XB that is almost an alias of XA,
but has subtly different lifecycle callbacks?

p = Object.create(HTMLElement.prototype, {
  readyCallback: {value: t}
});
XA = document.register('x-a', {prototype: p});
XA.prototype.readyCallback = u;
XB = document.register('x-b', {prototype: XA.prototype});

Then:

  document.body.innerHTML = '<x-a></x-a>'

will call t. This is unsurprising.

  document.createElement('x-a', 'x-b')

will call t (because "If both types of custom element names are provided at the
time of element's instantiation, the custom tag must win over the type
extension.")

  new XB()

may call u, or t, depending on what the meaning of "Let DEFINITION be ELEMENT's
definition" (from the element initialization algorithm) is.

It seems extending a custom tag with another custom tag is reasonably well
defined. Similarly, extending a type extension with another type extension
squirrels up the prototype chain past the parent type extension to a built-in
interface which isn't complicated with lifecycle callbacks. 

But extending a custom tag with a type extension begets ambiguity. I think it
should be disallowed. I think that is what the intent of "If both types of
custom element names are provided at the time of element's instantiation, the
custom tag must win over the type extension" is, but the generated constructor
is a loophole.

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

Received on Wednesday, 1 May 2013 04:42:52 UTC