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

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