Should the shadow host element be rendered? (Was: Re: Notes from a component model pow-wow)

Tab: How well is display: transparent received, eg on www-style?

I have a feeling this question—whether to render the host or not—depends on
whether you are using shadow DOM with components, or with existing elements.

When you want to use shadow DOM with components, the current solution seems
OK to me—the author surrounds elements that they want replaced, eg

<x-timezone-picker>
  <select>
    <option>UTC</option>
    ...
  </select>
</x-timezone-picker>

Which  lets the x-timezone-picker have a completely different API to select
if you want, works well in the fallback case, etc.

Not rendering the host element is useful when that <select> is the outermost
element. With the model we proposed, making the host element have minimal
impact on rendering, is tedious: You have to reset its borders, margin,
padding, positioning, zoom, display, etc. Even that is obviously not
perfect.

Not rendering the host element is more expressive, because trivially if you
want to get the behavior proposed to date, you just put another instance of
the same kind as the host in the shadow. This assumes that there is some
convenient way to to control how styles applied to the host element can be
forwarded to the shadow.

On Wed, Sep 21, 2011 at 5:44 PM, Roland Steiner <rolandsteiner@google.com>wrote:

> A neat side effect of not rendering the host element (whether by "display:
> transparent", or implicitly) is that encapsulated styling of a component
> becomes trivial. I.e., one may want a component be isolated (i.e., not be
> able to access the main document by default, and vice versa), but still
> style the host element somehow. At the moment this requires 2 style-sheets:
> one to style the host element, and one to style the contents of the
> component. If the host element doesn't get a render box, only the latter
> remains, which is easy to encapsulate by putting a <style [scoped]> inside
> the component tree.


I think it depends on *who* wants to style it. If the isolated component
wants to style the outermost box, then having that box inside the boundary
is good. If the page wants to style the outermost box, then having that box
outside the boundary is good.

In practice, maybe the answer is both will want to style aspects of the
outermost box. Taking the timezone picker example, the page design might
dictate this is a block it can float and has margins of x; the component
might dictate that it has a map of the world as a background.

I wonder, just like some properties inherit and some don’t, if there are
some properties that matter across component boundaries and some that don’t.

Dominic


>
> - Roland
>
>
> On Wed, Sep 21, 2011 at 3:20 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
>> On 9/20/11 11:15 PM, Tab Atkins Jr. wrote:
>>
>>> I think this is properly a CSS issue.  You want an element to not
>>> exist in the box tree, but to still have its children in the tree,
>>> which should be controllable with a display value, perhaps called
>>> 'transparent'.
>>>
>>
>> I believe that would be an acceptable solution to this use case, yes. If
>> it ever happens.
>>
>> -Boris
>>
>>
>