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

From WHATWG Wiki
Revision as of 01:58, 21 October 2011 by Rolandsteiner (talk | contribs) (→‎[F] host element not rendered, rendered shadow root: Fix incorrect statement about DOM positions)
Jump to navigation Jump to search

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 set display 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 set display 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.

[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].