[Bug 26365] [Shadow]: Need an equivalent definition of 'in a Document' for shadow trees

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

--- Comment #57 from Hayato Ito <hayato@chromium.org> ---
Thank you, Hixie. I appreciate your proposal.

I've taken a closer look at each case. Let me add inline comments.

(In reply to Ian 'Hixie' Hickson from comment #53)

> In general, I think we want to have as few categories of elements here as
> possible. In particular, I think "being rendered vs not being rendered", "in
> the document deeply vs not", "in the document directly vs not", and "scoped
> to the current subtree" are reasonable categories.

Totally agreed. I'd like to minimize the number of 'primitives' to explain the
Web platform.
That's one of the motivations I tried to introduce categories.

> 
> So it seems to me that for the above we should go as follows:
> 
> "In the document": 

Yeah, "In the document" matches the "category A" in the comment #21.

>   <link> (e.g. you don't want rel=import working from inside a shadow tree)

+1. <link> is also mentioned explicitly in the Shadow DOM spec
(http://w3c.github.io/webcomponents/spec/shadow/#inert-html-elements). We
should upstream it to the HTML standard.


> "Being rendered":

Oh, I am glad to notice that 'Being rendered' is clearly defined in the HTML
standard. I should have used this term in this discussion, instead of 'display:
none'.

Category C, 'An element is in the composed tree (with document as root)', is a
necessary condition for 'Being rendered'. I'd like to mention that "An Element
which is not in Category C doesn't have any associated CSS layout boxes" in the
Shadow DOM spec, though the css-scoping spec implies that
(http://drafts.csswg.org/css-scoping/#inheritance), I think. We might want to
clarify that.


The current Shadow DOM spec, 2.4 Composed Trees
(http://w3c.github.io/webcomponents/spec/shadow/#composed-trees), also says:

> In rendering a document tree, or presenting it visually, the composed tree must be used instead of the document tree.
> The composed tree must be updated before the rendering occurs.

Now I am feeling this is redundant. To be honest, I don't like this paragraph
because it is not well defined (I should be blamed).
Instead of that, I think what we have to say is:

1. CSS inheritance should be resolved based on relationship in the composed
tree, as the current css-scoping spec says.
2. If an element is not in the composed tree (with document as root), the
element doesn't have any associated CSS layout boxes.

This looks enough to me, doesn't that?



>   <embed>
>   <object>
>   focusable
>   <applet>

I don't have strong opinion for these except for *focusable*.

'focusable' is also mentioned in the Shadow DOM spec:

http://w3c.github.io/webcomponents/spec/shadow/#focus-navigation
>  If a node doesn’t participate in the composed tree, the node must be skipped from the navigation order [CSS3UI] sequence.

We can also rewrite this definition by using 'Being Rendered'. We don't have to
use the composed tree here.


> 
> "Scoped to the current subtree":
>   media controllers

+1.
I am not confident about what is desired behavior for media controllers
association. However, limiting the association to the current scope sounds a
good starting point.

>   form control associations

+1.
I think "Scoped to the current subtree" are implicit here unless otherwise
mentioned.
In the past, the Shadow DOM spec mentioned explicitly <form> control
association doesn't cross Shadow DOM boundaries, but it was removed from the
spec because we thought it was implicit because each node tree should be
considered 'separated', unless otherwise mentioned, basically.

> 
> "In the document deeply":
>   <script>
>   <command> exposure
>   accesskey

+1 with a nit.

As for <script>:
We don't have an agreement on what document.currentScript should return. In
other words, currenetScript should be scoped or not.
If we prefer scoped here, we might want to let ShadowRoot to have
ShadowRoot.currentScript.


As for accesskey:
In the current implementation of blink, accesskey is not *scoped*. There is one
global accesskey map which is shared among every node trees which participate
in the same tree of trees.
Is there any spec for the conflict case? I thought that we should define how to
resolve the case where two elements use the same access key. In other words, we
might want to define a *document* order between nodes in the same tree of
trees.


>   <dialog>
>   autofocus
>   <iframe>, <frame>
>   window.length
>   inertness of browsing context container
>   <style>
>   <video> autopause
>   whether autofill is canceled

+1 basically.

Note that we should also mention that {Document,ShadowRoot}.styleSheets
property is *scoped*.

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

Received on Thursday, 11 December 2014 06:43:43 UTC