[Bug 22344] [Shadow]: projecting into <shadow>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22344

Dominic Cooney <dominicc@chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bzbarsky@mit.edu,
                   |                            |mrbkap@gmail.com

--- Comment #4 from Dominic Cooney <dominicc@chromium.org> ---
I would love to hear from someone with XBL experience what they think of this.

I think this feature will put more pressure on running content distribution in
something more flexible than document order.

In thinking more about the effect on the spec, this means the definition of
active and inert insertion points needs to be tweaked; content elements with
exactly one shadow element ancestor and no intervening content element
ancestors is active now.

In Blink we apparently allow the dubious feature of adding a ShadowRoot to an
insertion point, and render it if the insertion point is inert. I'm not sure if
that is enshrined in the spec but I would be keen to restrict that to
simplifying the implementation now that <shadow> can both be parent of
distributed nodes and get nodes distributed to it.

Do you think that we can now make all content elements without content element
ancestors active? For example, could you nest a content element in a *second*
shadow element for the purpose of "deleting" those nodes?

(In reply to comment #3)
> One note: I would propose that, if <shadow>stuff</shadow> appears in a
> shadow subtree with no older subtree (that is, there is no older shadow to
> fill in), then "stuff" should get rendered as default content. This is the
> current behavior in which <shadow> renders default content when no older
> subtree exists.

Yes. I think the spec should address this by specifying that all elements have
a ShadowRoot. (It is probably <content></content>, but now that <shadow> is
sane, that detail is irrelevant.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 13 June 2013 23:54:37 UTC