Component Model Decorator Brainstorming

Overview

Considerations

Dynamic

A decorator can be applied and removed dynamically, as opposed to a component, which is applied statically and cannot change. Furthermore, an element can have 0-n decorators, but just 0-1 components.

Interface

A decorator cannot add additional interfaces to the decorated element.

Confinement

A decorator may come from an untrusted source. In case the decorated element is a component, that component may come from an untrusted source as well, which may be different than the decorator's.

Therefore, an approach that merges a decorator with a component's shadow tree, e.g., via <inherited> is undesirable. Similarly, collecting decorator's under a component's ShadowRoot does not work.

Priority Inversion

An XBL-style <inherited> places the decorator(s) on top of the main component, making the decorator the root of the tree. This inverts the priority that should exist between a decorator and the main component. Indeed, a decorator might omit the <inherited> element, hiding the component (and other decorators) entirely.

Decorators therefore should be rendered "around" the element or component. Cases where a tighter coupling is required are probably better handled by composition.

Triggers

We consider the following triggers for the application of decorators:

• element tag names
• attributes
• ARIA roles
• general CSS

If we can achieve decorator-assignment via generic CSS rules, this can handle all cases above.