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 Discussion: Rendering: Difference between revisions
No edit summary |
m (→Rendering: fix some copy/paste typos) |
||
(10 intermediate revisions by the same user not shown) | |||
Line 14: | Line 14: | ||
and as a somewhat lesser concern: | and as a somewhat lesser concern: | ||
[3] | [3] Every point between the rectangles should correspond to a valid DOM range. | ||
ad [3]: Note that conversely, in no variant there is a mapping from a DOM range with anchor <x-foo> to a rectangle/screen position, since the children of <x-foo> may be rendered in arbitrary places, depending on <content> elements within the shadow DOM, or even not at all. | |||
== Rendering == | == Rendering == | ||
Line 28: | Line 30: | ||
<A> | <A> | ||
<x-foo> -----> [ShadowRoot] | <x-foo> -----> [ShadowRoot (S)] | ||
<B/> <Y/> | <B/> <Y/> | ||
<C/> <Z/> | <C/> <Z/> | ||
Line 143: | Line 145: | ||
Issues: | Issues: | ||
* Containing document can't style the shadow host. Because of Isolation it also can't style the ShadowRoot, unless styles styles set on | * Containing document can't style the shadow host. Because of Isolation it also can't style the ShadowRoot, unless styles styles set on <x-foo> are forwarded somehow. If so, mechanism of style forwarding needs to be specced. | ||
=== [F2] neither host element nor shadow root rendered, shadow root has single child <R> as root element === | |||
Similar to [F], but the ShadowRoot doesn't have to be an element itself, can be extended towards [G] later on. | |||
A-----------------------------------------------------+ | |||
| R-------------------------------------+ | | |||
| | Y------+ Z------+ | | | |||
| [A,0] | [R,0] | | [R,1] | | [R,2] | [A,1] | | |||
| | +------+ +------+ | | | |||
| +-------------------------------------+ | | |||
+-----------------------------------------------------+ | |||
Issues: | |||
* Containing document can't style the shadow host. Because of Isolation it also can't style the ShadowRoot nor the shadow root element, unless styles styles set on <x-foo> are forwarded somehow. If so, mechanism of style forwarding needs to be specced. | |||
=== [G] neither host element nor shadow root rendered === | === [G] neither host element nor shadow root rendered === | ||
Line 159: | Line 177: | ||
* There is no single rendering rectangle corresponding to <x-foo>. | * There is no single rendering rectangle corresponding to <x-foo>. | ||
* Containing document can't style the host element. Styles set on <x-foo> could be forwarded to ALL children of the shadow root, but it's not clear this is useful. | * Containing document can't style the host element. Styles set on <x-foo> could be forwarded to ALL children of the shadow root, but it's not clear this is useful. | ||
* The potential gaps between the rectangles of the shadow root's children and | * The potential gaps between the rectangles of the shadow root's children and the host element's parent don't directly map to a DOM position. | ||
=== [Z] Other? === | === [Z] Other? === | ||
Line 168: | Line 186: | ||
Currently we implemented variant [D]. | Currently we implemented variant [D]. | ||
We probably want to go towards [F2]. |
Latest revision as of 02:40, 12 January 2012
Overview
The question asked herein is how to best treat the following somewhat mutually exclusive requirements:
[1] The containing document "wants" to naturally style the host element (using <x-foo> notation here - see the Component Registration page for alternatives). E.g.,
x-foo { background-color: yellow; border: 1px solid blue; }
[2] The component "wants" to be able to style its outermost rendering rectangle. Because of Isolation, this rectangle is ideally located within the component, i.e., within the shadow DOM.
and as a somewhat lesser concern:
[3] Every point between the rectangles should correspond to a valid DOM range.
ad [3]: Note that conversely, in no variant there is a mapping from a DOM range with anchor <x-foo> to a rectangle/screen position, since the children of <x-foo> may be rendered in arbitrary places, depending on <content> elements within the shadow DOM, or even not at all.
Rendering
This consists of the following, more or less orthogonal, sub-questions
- is the host element rendered or not?
- is the shadow root rendered or not?
- is the shadow root an element or a separate node type?
- using
display: transparent
?
Almost all combinations of the above have their respective merits and problems. Assume we have the following DOM structure:
<A> <x-foo> -----> [ShadowRoot (S)] <Y/> <C/> <Z/> <D/> </x-foo> </A>
This could conceivably be rendered in the following ways:
[A] rendered host element, rendered shadow root, shadow root is element
A---------------------------------------------------------------------+ | x-foo-------------------------------------------------+ | | | SR------------------------------------+ | | | | | Y------+ Z------+ | | | | [A,0] | ??? | [S,0] | | [S,1] | | [S,2] | ??? | [A,1] | | | | +------+ +------+ | | | | | +-------------------------------------+ | | | +-----------------------------------------------------+ | +---------------------------------------------------------------------+
Consequences:
- Shadow root as element requires separate TreeScope tree and host-element pointer
Issues:
- Styles set on <x-foo> such as
background-color
don't really affect the component's rendering if the component overrides them on the shadow root. - The potential gaps between the shadow root's rectangle and the outer host element's rectangle don't directly map to a DOM position.
[B] rendered host element with default display: transparent
, rendered shadow root, shadow root is element
A-------------------------------------------------------+ | x-foo - - - - - - - - - - - - - - - - - + | | :SR------------------------------------+: | | :| Z------+ +------+ |: | | [A,0] :| [S,0] | | [S,1] | | [S,2] |: [A,1] | | :| Z------+ +------+ |: | | :+-------------------------------------+: | | + - - - - - - - - - - - - - - - - - - - + | +-------------------------------------------------------+
Consequences:
- Shadow root as element requires separate TreeScope tree and host-element pointer
Issues:
- Containing document can't style the shadow host, but this is more apparent because of
display: transparent
. Containing document could setdisplay
to something different if needed. - If
display
is set to something different it becomes variant [A], with the associated issues.
[C] rendered host element, rendered shadow root, shadow root is separate node type, shadow root's rectangle always is the same as the host element's (no gap)
A-------------------------------------------------------+ | x-foo-----------------------------------+ | | |SR------------------------------------+| | | || Z------+ +------+ || | | [A,0] || [S,0] | | [S,1] | | [S,2] || [A,1] | | || Z------+ +------+ || | | |+-------------------------------------+| | | +---------------------------------------+ | +-------------------------------------------------------+
This allows both the document to style <x-foo>, as well as allowing the component to have its own outer rectangle, but prevents any gap from forming between them. However, this raises more questions than it answers:
Issues:
- Need to spec how ShadowRoot node type is styleable
margin
,padding
,position
et al must not apply, so need to define how styles apply to ShadowRoot in detail.
[D] rendered host element, shadow root not rendered
A-----------------------------------------------------+ | x-foo---------------------------------+ | | | Y------+ Z------+ | | | [A,0] | ??? | | ??? | | ??? | [A,1] | | | +------+ +------+ | | | +-------------------------------------+ | +-----------------------------------------------------+
Issues:
- Confinement requires separate style-sheet in order for the component to be able to style the host element.
- The potential gaps between the rectangles of the shadow root's children and the outer host element don't directly map to a DOM position.
[E] host element has display: transparent
by default, shadow root not rendered
A---------------------------------------+ | x-foo - - - - - - - - - + | | :Y------+ Z------+: | | ??? :| | ??? | |: ??? | | :+------+ +------+: | | + - - - - - - - - - - - + | +---------------------------------------+
Issues:
- Containing document can't style the shadow host, but this is more apparent because of
display: transparent
. Containing document could setdisplay
to something different if needed. - If
display
is set to something different it becomes variant [D], with the associated issues. - The potential gaps between the rectangles of the shadow root's children and the outer host element don't directly map to a DOM position.
[F] host element not rendered, rendered shadow root
In this scenario, the ShadowRoot most likely is an element.
A-----------------------------------------------------+ | SR------------------------------------+ | | | Y------+ Z------+ | | | [A,0] | [S,0] | | [S,1] | | [S,2] | [A,1] | | | +------+ +------+ | | | +-------------------------------------+ | +-----------------------------------------------------+
Issues:
- Containing document can't style the shadow host. Because of Isolation it also can't style the ShadowRoot, unless styles styles set on <x-foo> are forwarded somehow. If so, mechanism of style forwarding needs to be specced.
[F2] neither host element nor shadow root rendered, shadow root has single child <R> as root element
Similar to [F], but the ShadowRoot doesn't have to be an element itself, can be extended towards [G] later on.
A-----------------------------------------------------+ | R-------------------------------------+ | | | Y------+ Z------+ | | | [A,0] | [R,0] | | [R,1] | | [R,2] | [A,1] | | | +------+ +------+ | | | +-------------------------------------+ | +-----------------------------------------------------+
Issues:
- Containing document can't style the shadow host. Because of Isolation it also can't style the ShadowRoot nor the shadow root element, unless styles styles set on <x-foo> are forwarded somehow. If so, mechanism of style forwarding needs to be specced.
[G] neither host element nor shadow root rendered
A-------------------------------------+ | Y------+ Z------+ | | ??? | | ??? | | ??? | | +------+ +------+ | +-------------------------------------+
Undoubtedly the most flexible from a layout perspective, as it allows a single element to "create" multiple renderers.
Issues:
- There is no single rendering rectangle corresponding to <x-foo>.
- Containing document can't style the host element. Styles set on <x-foo> could be forwarded to ALL children of the shadow root, but it's not clear this is useful.
- The potential gaps between the rectangles of the shadow root's children and the host element's parent don't directly map to a DOM position.
[Z] Other?
There is a marvelous variant that solves all issues and doesn't suffer any of the above drawbacks which this paragraph is too small to contain.
Current State
Currently we implemented variant [D].
We probably want to go towards [F2].