A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Component Model Decorator Brainstorming: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
(Considerations)
(→‎Overview: Triggers)
Line 2: Line 2:


== Considerations ==
== 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 ===
=== Interface ===
Line 18: Line 22:


Decorators therefore should be rendered "around" the element or component. Cases where a tighter coupling is required are probably better handled by composition.
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.

Revision as of 17:17, 26 October 2011

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.