Is x-mywidget necessarily more performant? Why?
On Oct 3, 2011 5:33 AM, "Roland Steiner" <[email protected]> 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
