Component Model Decorator Brainstorming - Revision history

Rolandsteiner: /* Implementation Approaches */ divide shadow-DOM approaches, add aspect-oriented approach

2011-10-29T01:06:36Z

Implementation Approaches: divide shadow-DOM approaches, add aspect-oriented approach

← Older revision		Revision as of 01:06, 29 October 2011
Line 117:		Line 117:
	* Long standardization to get there.		* Long standardization to get there.

	== Component-like ~~Shadow~~ DOM ==		== Component-like shadow DOM, rendered as overlay ==

			The decorators are declared similar to components and have their own DOM tree. A component is rendered in the specified position separately from the main DOM as an overlay to the "normal" rendering.

			=== Advantages ===

			* Expressiveness and scriptability of DOM
			* Uses tools we already have or develop for components, no interaction between decorator and regular element rendering

			=== Disadvantages ===

			* Creates a inter-dependency between DOM and the triggers (e.g., CSS), but less of an issue than with XBL-inheritance approaches
			* Overlays are quite limited in capabilities

			== Component-like shadow DOM, with inheritance ==

	The decorators are declared similar to components and have their own DOM tree. A component is rendered in the specified position separately from the main DOM.		The decorators are declared similar to components and have their own DOM tree. A component is rendered in the specified position separately from the main DOM.
Line 123:		Line 137:
	=== Advantages ===		=== Advantages ===

	* ~~Greater expressiveness~~		* Expressiveness and scriptability of DOM
	* Uses tools we already have or develop for components.		* Uses tools we already have or develop for components, no interaction between decorator and regular element rendering

	=== Disadvantages ===		=== Disadvantages ===

	* Creates a inter-dependency between DOM and the triggers (e.g., CSS)~~. Potential recursiveness.~~		* Creates a inter-dependency between DOM and the triggers (e.g., CSS)
	* "Heavier" in application.		* "Heavier" in application.
	* (Re-)raises questions about (XBL-like) inheritance, overriding and/or hiding of previously applied shadow trees		* (Re-)raises questions about (explicit or implicit) XBL-like inheritance, overriding and/or hiding of previously applied shadow trees

			== Aspect-oriented components ==

			Components are assembled from parts, which are essentially "micro-templates". Sub-classes and decorators can override any or all of those parts. What is rendered is an auto-flattening of all final parts.

			=== Advantages ===

			* Defines inner structure of components, makes individual parts decoratable/replaceable
			* Parts can serve as pseudo-element targets naturally
			* Individual parts should be responsible for a limited subset of the host element's children, reducing the potential conflict area between multiple parts vying for the same host elements

			=== Disadvantages ===

			* Best trigger mechanism undefined (questionable whether CSS is a good fit)
			* Probably very heavy in application.
			* Requires discipline from authors to set up effectively
			* Scripts may hold references to elements in parts that "go away" on updates (may not be a problem in practice)

	== In-between ==		== In-between ==

Rolandsteiner: /* Implementation Approaches */

2011-10-29T00:31:38Z

Implementation Approaches

← Older revision		Revision as of 00:31, 29 October 2011
Line 130:		Line 130:
	* Creates a inter-dependency between DOM and the triggers (e.g., CSS). Potential recursiveness.		* Creates a inter-dependency between DOM and the triggers (e.g., CSS). Potential recursiveness.
	* "Heavier" in application.		* "Heavier" in application.
			* (Re-)raises questions about (XBL-like) inheritance, overriding and/or hiding of previously applied shadow trees

			== In-between ==

			Determine decorators in terms of CSS layout, but define that layout in terms of a DOM and open it up to scripting - e.g., auto-instantiate the DOM when a content-generating pseudo-element is used.

			=== Advantages ===

			* Simplicity of CSS application, but allowing for scripting
			* Details what is currently "hidden"

			=== Disadvantages ===

			* Performance questions
			* Content-generating pseudo-classes may not fit a single DOM template
			* Defining things in terms of DOM may block future additions to CSS that then would no longer fit that definition (and thus break pages)
			* Performant implementation may require multiple renderers per node

Rolandsteiner at 00:07, 27 October 2011

2011-10-27T00:07:54Z

← Older revision		Revision as of 00:07, 27 October 2011
Line 14:		Line 14:

	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.		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 <tt><inherited></tt> is undesirable. Similarly, collecting decorator's under a component's <tt>ShadowRoot</tt> does not work.

	=== Priority Inversion ===		=== Priority Inversion ===

	An XBL-style <tt><inherited></tt> 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 <tt><inherited></tt> element, hiding the component (and other decorators) entirely.		An XBL-style <tt><inherited></tt> places the decorator(s) on top of the main component, making the decorator the root of the tree. This makes the decorator the "more important" part in the relation. Indeed, a decorator might omit the <tt><inherited></tt> 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.		[[User:Rolandsteiner\|RolandSteiner]] Decorators therefore should be rendered "around" the element or component. Cases where a tighter coupling is required are probably better handled by composition.

	=== Decorating Component Parts ===		=== Decorating Component Parts ===

Rolandsteiner: moved Component Model Strawman: Decorators to Component Model Decorator Brainstorming: Mostly brainstorming ATM, no concrete proposals yet

2011-10-26T20:07:51Z

moved Component Model Strawman: Decorators to Component Model Decorator Brainstorming: Mostly brainstorming ATM, no concrete proposals yet

← Older revision	Revision as of 20:07, 26 October 2011
(No difference)

Rolandsteiner: /* Advantages */

2011-10-26T20:06:33Z

Advantages

← Older revision		Revision as of 20:06, 26 October 2011
Line 94:		Line 94:
	* pseudo-element kinda makes sense, since the decorator can be considered becoming part of the decorated element		* pseudo-element kinda makes sense, since the decorator can be considered becoming part of the decorated element
	* allows further styling of the decorator		* allows further styling of the decorator
			* classification what decorators can be applied to which elements in the realm of the possible (make 'illegal' decorators fail in the CSS selector matching).

	==== Disadvantages ====		==== Disadvantages ====

Rolandsteiner: /* CSS Decorator Properties */

2011-10-26T20:04:51Z

CSS Decorator Properties

← Older revision		Revision as of 20:04, 26 October 2011
Line 73:		Line 73:
	=== CSS Decorator Properties ===		=== CSS Decorator Properties ===

	Allow decorators to specify a CSS <tt>decorator-<xyz></tt> property with the values <tt>none</tt> and <tt>apply</tt>. Rules can then switch individual ~~properties~~ on or off.		Allow decorators to specify a CSS <tt>decorator-<xyz></tt> property with the values <tt>none</tt> and <tt>apply</tt>. Rules can then switch individual decorators on or off.

	==== Advantages ====		==== Advantages ====
Line 83:		Line 83:
	* requires probably controversial CSS extension		* requires probably controversial CSS extension
	* does not define where decorator is rendered		* does not define where decorator is rendered
			* does not allow classification which decorators are applicable to which elements

	=== CSS Decorator Pseudo-elements ===		=== CSS Decorator Pseudo-elements ===

Rolandsteiner: /* CSS Decorator Properties */

2011-10-26T20:04:00Z

CSS Decorator Properties

← Older revision		Revision as of 20:04, 26 October 2011
Line 73:		Line 73:
	=== CSS Decorator Properties ===		=== CSS Decorator Properties ===

	Allow decorators to specify a CSS <tt>decorator-</tt> property with the values <tt>none</tt> and <tt>apply</tt>. Rules can then switch individual properties on or off.		Allow decorators to specify a CSS <tt>decorator-<xyz></tt> property with the values <tt>none</tt> and <tt>apply</tt>. Rules can then switch individual properties on or off.

	==== Advantages ====		==== Advantages ====

Rolandsteiner: Binding approaches

2011-10-26T20:02:29Z

Binding approaches

@@ Line 63: / Line 63: @@
 It seems useful and straight-forward to allow multiple decorators on a single element. However, assigning decorators, e.g., via a CSS <tt>binding</tt> property and using the CSS cascade would leave only the decorator stemming from the most specific rule.
-= Approaches =
+= Binding Approaches =
 == Pure CSS ==

Rolandsteiner: /* Considerations */

2011-10-26T19:45:17Z

Considerations

← Older revision		Revision as of 19:45, 26 October 2011
Line 22:		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.

			=== Decorating Component Parts ===

			In some cases it may be desirable to have the ability to decorate specific parts of a component. E.g., the caps-lock indicator in an <tt><input></tt> field could be considered a decorator.

			However, this clashes with the desire to not make the internals of components public. To reconcile this we'd need a better model of how to declare component parts, whether "aspect-oriented components" or something different.

	== Triggers ==		== Triggers ==

Rolandsteiner: /* Questions */ Styling Q

2011-10-26T19:11:43Z

Questions: Styling Q

← Older revision		Revision as of 19:11, 26 October 2011
Line 39:		Line 39:

	Can a decorator be decorated itself?		Can a decorator be decorated itself?

			=== Styling ===

			Can a decorator affect the styling of the decorated element?

	=== Layout ===		=== Layout ===