[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 #49 from brian kardell <bkardell@gmail.com> ---
(In reply to comment #48)
> 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.


This is exectly where I thought we were in dimitri/hixie compromise until I
clarrified with them on irc that that was not the case.  This addresses the
concerns I brought up there and I think seems reasoanble.  I'm good with it. 
Wish I had been able to be in the room to hear what it took to get there - good
job guys.

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

Received on Thursday, 17 January 2013 12:59:29 UTC