[Bug 18669] Switch from is= to <tag if a decision has been reached among implementers

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

--- Comment #48 from Daniel Buchner <danieljb2@gmail.com> ---
After discussing the alternate proposal presented by Ian and Dimitri, we (Alex
Russell, Dimitri Galzkov, Elliott Sprehn, Ian, Matt McNulty, Scott Miles, Tab
Atkins, and myself) have arrived at a slightly modified proposal that we feel
balances the various concerns raised by those who have participated in the
discussion thus far. Please provide commentary and feedback to ensure this
proposal accounts for the necessary requirements and use-cases:

--- Custom Element Instantiation ---

Custom elements can be instantiated using either a custom tag, or the
application of a custom element name using the is="" attribute. Using the is=""
attribute to apply a custom element definition to a native element _will not_
affect proto inheritance of the custom element.

--- Custom Element Declaration ---

Custom elements will continue to be defined via the <element> tag or the
document.register DOM interface. Extension of native element prototypes will
occur only by way of the HTMLElementElement's extends attribute or the
document.register interface's prototype option.

Custom element names must include a dash somewhere in the string - this is a
modification to the current spec draft which forced a more specific "x-"
prefix.

--- Extension of Native Elements ---

There will be no prohibition on the extension of native elements regardless of
which of the two supported custom element instantiation methods the developer
uses.

--- Reasons for Two Instantiation Methods ---

There are many valid use-cases that highlight the need for both custom
instantiation options, some are technical, others are semantic in nature - here
are a couple examples:

- Extension of elements such as <td>, that heavily depend on a delicate
technical dance between various parts of the browser's implementation stack and
the HTML parser.

- Semantic fallback support for developers/applications that require content be
evaluated and understood by all manner of parsing agent.

The spec editor will provide an explanation for each of the custom element
declaration options that details what each option was designed to allow for,
and includes examples that highlight where the use of one is advisable over the
other.

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

Received on Thursday, 17 January 2013 00:53:34 UTC