If I may briefly summarize the pros and cons of every approach discussed: <X-MYWIDGET>
Pros: - element name is inherently immutable - can provide arbitrary API, can (but does not have to) derive from arbitrary HTML element - best performance (in instantiation, CSS selector matching) Cons: - accessibility only for shadow tree contents, no accessibility for host element unless ARIA roles are specified - parsing issues in special circumstances (<table>, auto-closing <p>, etc.) - no/limited fallback (limited: user provides fallback as content of <X-MYWIDGET>, won't work in special places like within tables) - makes it easy to conflate semantics and representation <button IS=MYWIDGET> Pros: - fallback behavior as per HTML element - accessibility as per HTML element + shadow tree contents - binding only at creation, or immediately thereafter - API is that of host element, +alpha Cons: - add'l APIs ignored for accessibility - harder to implement: there's a window during parsing (before reading the button) where it's still an ordinary button, requiring binding to be added afterwards - immutability of 'is' attribute not immediately obvious to authors - unclear what happens if a HTML element with intrinsic shadow DOM is assigned a CSS binding button { BINDING: MYWIDGET; } Pros: - fallback behavior as if un-styled - accessibility - mutability depending on medium, etc. - host element stays unchanged Cons: - dynamic binding is hard to implement - shadow DOM dependent on rendering tree (something we explicitly wanted to avoid) - API immutable that of host element - unclear what happens if a HTML element with (intrinsic or explicit) shadow DOM is assigned a CSS binding as well Does the above look about right? - Roland