Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

Is x-mywidget necessarily more performant?  Why?

On Oct 3, 2011 5:33 AM, "Roland Steiner" <rolandsteiner@google.com> wrote:
>
> 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