https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775
Bug ID: 27775
Summary: [Shadow]: Define the behavior of *closed* shadow
trees.
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Component Model
Assignee: dglaz...@chromium.org
Reporter: hay...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14978
The current spec uses a term of 'UA-provided shadow trees'. The spec assumes
that built-in elements, such as <video> elements, might be implemented with
shadow trees.
However, the behavior of UA-provided shadow trees isn't well defined in the
spec yet.
For example, in Blink, event.path API returns an array, however, it excludes
nodes in UA-provided shadow trees. Unfortunately, the spec doesn't mention this
behavior at all. That doesn't look good to me from the view of compatibility if
browser vendors would like to use shadow trees to implement their built-in
elements.
I am wondering whether it is worth or not to expose this *hidden* concept, UA
shadow trees, clearly in the spec, as a *closed shadow tree*, a tentative name
borrowed from the another thread, so that we can explain the behavior of
builtin elements in terms of Shadow DOM. I think this would fill one of missing
pieces for 'HTML as Custom Elements' concept.
In Blink, as some of you might know, ShadowRoot object has an enum internally,
UserAgentShadowRoot or AuthorShadowRoot. Some builtin elements, such as <video>
or <input>, use UserAgentShadowRoot in their implementation as you imagine.
Currently, the behavior of this kind of shadow trees is only explained by
Blink's C++ code.
It'd be nice that I could write down a well-defined behavior of a closed shadow
tree somewhere. That should be in the spec. I don't want other browser vendors
to do a kind of *reverse-engineering*.
The spec should mention the followings, but not limited to:
- Element.shadowRoot - If the youngest shadow tree is closed, return null. That
matches the current Blink's implementation.
- Element.getDestinationInsertionPoints - must filter out insertion points if
they are in a closed shadow tree. That matches the current Blink's
implementation. e.g. <detail><summary>
- Event.path - must filter out event targets if it is in a closed shadow tree.
(The exact condition is more complex than you imagine).
- Needs to discuss:
Whether or not to allow calling Element.createShadowRoot() for the shadow
host which has the closed youngest shadow tree.
If we allow it, we might have to consider the followings also:
- InsertinonPoint.getDistributedNodes - Filter out nodes in a closed older
shadow tree. In Blink, we don't need this because there is not such UA and
author shadow trees, I think.
- ShadowRoot.olderShadowRoot - If the older shadow tree is closed, return
null.
- The behavior of CSS selector which *crosses* shadow trees.
'::shadow', '/deep/' - See
https://code.google.com/p/chromium/issues/detail?id=433977 also. This should be
mentioned in css-scoping spec.
What makes things complex is the case when a closed shadow tree and an open
shadow tree are mixed together within one shadow host:
e.g.
A). ShadowHost => the oldest shadow tree (open) => older shadow tree (open) =>
youngest shadow tree (closed)
B). ShadowHost => the oldest shadow tree (closed) => older shadow tree
(closed) => youngest shadow tree (open)
In Blink, there isn't a pattern A so far. We might need to consider this case
in the future.
Here, I'm not aiming to expose an API for creating a closed shadow tree to Web
developers.
Although this issue might resolve one of pre-requirements for that, as a
result, I don't have any idea about how we should prioritize exposing such a
API.
If we were to expose the API, the API might be:
- Element.createShadowRoot take an optional dictionary, such as ({'mode':
'closed'}).
I don't care which the *default* should be, `closed` or `open`. That sounds
non-essential to me. That's a domain of API. For compatibility, the default
should be 'open', I think.
Please use bug 20144 for this kind of topic.
--
You are receiving this mail because:
You are on the CC list for the bug.
