Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Shadow]: Define the behavior of *closed* shadow trees. (bugzilla: 27775) #85

Closed
hayatoito opened this issue May 25, 2015 · 2 comments
Closed

[Shadow]: Define the behavior of *closed* shadow trees. (bugzilla: 27775) #85

hayatoito opened this issue May 25, 2015 · 2 comments
Assignees
@hayatoito
Labels
shadow-dom v1

Comments

@hayatoito
Copy link
Contributor

Title: [Shadow]: Define the behavior of closed shadow trees. (bugzilla: 27775)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c0
Hayato Ito wrote on 2015-01-07 01:12:32 +0000.

The current spec uses a term of 'UA-provided shadow trees'. The spec assumes that built-in elements, such as

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

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.

  • 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.

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c1
Olli Pettay wrote on 2015-01-07 11:22:20 +0000.

(In reply to Hayato Ito from comment #0)

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.
Do we really want that? Wouldn't it bound implementations to use similar structures for
form elements.

In Blink, as some of you might know, ShadowRoot object has an enum
internally, UserAgentShadowRoot or AuthorShadowRoot. Some builtin elements,
such as

But why do we need to spec browser specific behavior? Maybe I'm missing what you're proposing here.

One good thing though is that if 'closed shadow tree' is spec'ed, it might force us to spec
how proper encapsulation and information hiding works.
So maybe we do want it after all, but just not spec what kind of closed shadow tree various elements may have.
That would be up to the UA.
Or... maybe we shouldn't define 'closed shadow tree', but something like
'domain specific shadow tree', and UA would just happen to form a 'system' domain itself.
Assuming 'dsst' would hide information by default, and could opt-in to not-hide, UA shadow DOM would just work
by default. So, I think we want this, and no special 'closed shadow tree'

  • 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:
    I think the end goal should be to allow it. There shouldn't be special cases or inconsistencies.

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c2
Hayato Ito wrote on 2015-01-08 07:48:46 +0000.

(In reply to Olli Pettay from comment #1)

(In reply to Hayato Ito from comment #0)

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.
Do we really want that? Wouldn't it bound implementations to use similar
structures for
form elements.

Yeah, I thought that "we don't want this" because such a shadow tree has been used as an implementation detail of some of builtin elements. No one should take care of such an implementation detail, basically.
However, the recent movement, 'HTML as Custom Element', made me reconsider this topic again. I feel uncomfortable in the current Shadow DOM spec because the spec can't explain an existence of such an internally-used shadow tree in a well-defined manner, even though the spec mentions it as a UA-provided shadow tree, especially in the Section 8, "HTML Elements and Their Shadow Trees".

In Blink, as some of you might know, ShadowRoot object has an enum
internally, UserAgentShadowRoot or AuthorShadowRoot. Some builtin elements,
such as

But why do we need to spec browser specific behavior? Maybe I'm missing what
you're proposing here.

My bad. It's not a goal to define how a builtin element should be implemented in the spec. That's up to UA.
My intention of filing this issue is just to define the behavior of closed shadow trees clearly. It's up to UA how UA makes use of it. UA doesn't have to use shadow trees if a shadow tree doesn't fit.

But, wait,,, it's against "the Section 8, HTML Elements and Their Shadow Trees".
I think the original goal of Section 8 is to define how some of builtin elements should behave if Web Developers call element.createShadowRoot() for that. That's one of tough issues.

One good thing though is that if 'closed shadow tree' is spec'ed, it might
force us to spec
how proper encapsulation and information hiding works.

Good point. So far, we've succeeded to hide the implementation detail of

So maybe we do want it after all, but just not spec what kind of closed
shadow tree various elements may have.
That would be up to the UA.
Or... maybe we shouldn't define 'closed shadow tree', but something like
'domain specific shadow tree', and UA would just happen to form a 'system'
domain itself.
Assuming 'dsst' would hide information by default, and could opt-in to
not-hide, UA shadow DOM would just work
by default. So, I think we want this, and no special 'closed shadow tree'

An Interesting idea. From the view of such a domain specific shadow tree, I am feeling that the current shadow tree might be considered as one of domain specific shadow tree, where the domain is 'Author'.

We might want to define the default behavior of two instances of domain specific shadow trees, 'System and Author', at least. Any other better interpretation of your idea?

Anyway, I don't have a plan to work on this task soon because I'm not confident about how we should prioritize this task. I've not heard any urgent requests for spec-cing closed shadow trees so far.

  • 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:
    I think the end goal should be to allow it. There shouldn't be special cases
    or inconsistencies.

Agreed. That's exactly the original goal of "Section 8".

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c3
Philip Jägenstedt wrote on 2015-01-30 06:09:18 +0000.

It would be nice to have closed shadow trees, which the the shadow-piercing combinator '>>>' cannot reach into and whose internal structure is otherwise entirely opaque to the containing document. Things like

We could perhaps also allow script-created shadow trees to be closed, although defaulting to open.

comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c4
Olli Pettay wrote on 2015-01-30 23:28:20 +0000.

Why default open in that case?

comment: 5
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c5
Ryosuke Niwa wrote on 2015-01-30 23:47:07 +0000.

All the arguments I've heard for default open have been bogus at best. If authors can pierce through shadow boundaries, any hope for encapsulating your components' implementation details is lost.

comment: 6
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c6
Hayato Ito wrote on 2015-02-06 01:40:36 +0000.

As I mentioned in comment #0, what 'default' should be orthogonal to the problem which this bug is trying to resolve.

Whatever the default would be, 'open' or 'closed, I don't see any effect of that on the behavior of closed shadow trees. Do you think the current behavior of UA shadow trees will be affected by the default? I don't think so.

I appreciate if you guys give us comments about the concrete behavior of closed shadow trees in this bug, if you have, as Philip did about '>>>'.

As for '>>>', yeah, I agree that '>>>' shouldn't piece closed shadow trees.

comment: 7
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c7
Philip Jägenstedt wrote on 2015-02-10 04:41:55 +0000.

(In reply to Olli Pettay from comment #4)

Why default open in that case?

Hmm, I actually don't know, closed is probably a more sane default.

comment: 8
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c8
Hayato Ito wrote on 2015-02-10 05:29:15 +0000.

Started to introduce an isolation mode, which is either 'open' or 'closed', at:

babf9a3

comment: 9
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c9
Anne wrote on 2015-02-10 14:28:51 +0000.

Can we call this encapsulation mode and reserve the word isolation for a mode where not even globals are shared?

comment: 10
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c10
Hayato Ito wrote on 2015-02-12 04:16:43 +0000.

(In reply to Anne from comment #9)

Can we call this encapsulation mode and reserve the word isolation for a
mode where not even globals are shared?

I think we can. Done at d0de816.

comment: 11
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c11
Dylan Barrell wrote on 2015-03-10 21:44:16 +0000.

(In reply to Philip Jägenstedt from comment #3)

It would be nice to have closed shadow trees, which the the shadow-piercing
combinator '>>>' cannot reach into and whose internal structure is otherwise
entirely opaque to the containing document. Things like

We could perhaps also allow script-created shadow trees to be closed,
although defaulting to open.

I would strongly caution to not allow scripts to create closed trees from two perspectives:

  1. How do you do testing into a closed tree in an end-to-end testing environment like Webdriver? I have already encountered occasions where Angular 2 end-to-end testing is complicated by the shadow DOM. Making the shadow DOM totally opaque would further complicate this unless you provide a testing API - in which case what is to stop someone from mis-using the testing API to reach inside the shadow DOM.

  2. How do you do custom validations of entire documents for things like accessibility when the dependencies of ARIA roles and attributes can cross shadow root boundaries. One way to do this would be to expose the composed tree through an API but failure to expose the composed tree with the ability to create non-standard components that are 100% opaque make this sort of validation impossible.

comment: 12
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c12
Dimitri Glazkov wrote on 2015-03-10 22:17:04 +0000.

(In reply to Dylan Barrell from comment #11)

(In reply to Philip Jägenstedt from comment #3)

It would be nice to have closed shadow trees, which the the shadow-piercing
combinator '>>>' cannot reach into and whose internal structure is otherwise
entirely opaque to the containing document. Things like

We could perhaps also allow script-created shadow trees to be closed,
although defaulting to open.

I would strongly caution to not allow scripts to create closed trees from
two perspectives:

  1. How do you do testing into a closed tree in an end-to-end testing
    environment like Webdriver? I have already encountered occasions where
    Angular 2 end-to-end testing is complicated by the shadow DOM. Making the
    shadow DOM totally opaque would further complicate this unless you provide a
    testing API - in which case what is to stop someone from mis-using the
    testing API to reach inside the shadow DOM.

  2. How do you do custom validations of entire documents for things like
    accessibility when the dependencies of ARIA roles and attributes can cross
    shadow root boundaries. One way to do this would be to expose the composed
    tree through an API but failure to expose the composed tree with the ability
    to create non-standard components that are 100% opaque make this sort of
    validation impossible.

This is one of the Closed-by-default Cons in the "contentious bits" document: https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits#b-the-default-value-of-closed-shadow-tree-flag. If you have specific examples, please contribute them there.

comment: 13
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c13
Hayato Ito wrote on 2015-04-23 16:06:46 +0000.

Status update about spec-ing the closed mode.

Mostly done about low-hanging fruits. However, there are still remaining tasks:

  1. event.path(): We should filter out a node in closed shadow tree.
    In addition to that, should we filter out a node in a open shadow tree if it is descendant tree of a closed tree?
    In general, we can't determine the open/closed-ness in the local context. We should consider the relationship between the current tree and the target tree, e.g There is a closed shadow tree in the middle.
  2. event retargeting
    Now we have a closed shadow tree. Should we continue an event retargeting even in for open shadow trees?
    How about opt-in?
  3. Other issues for mixing open/closed shadow trees.
    I guess no one has investigated how this mixture of open/closed should work seriously. We have to investigate further.

Anything else? If you notice something, please update this thread.

comment: 14
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c14
Hayato Ito wrote on 2015-04-23 16:25:29 +0000.

Let me paste quote mail here, since it's related.

https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0225.html

D. Event Retargeting
1. We agree with making it optional (opt-in or opt-out). We don’t feel that strongly, but many web developers have asked for this. The default should likely match the default for open vs. closed (no retargeting by default if open by default). <https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444>

comment: 15
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c15
Dylan Barrell wrote on 2015-04-23 17:40:45 +0000.

(In reply to Dimitri Glazkov from comment #12)

This is one of the Closed-by-default Cons in the "contentious bits"
document:
https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits#b-the-
default-value-of-closed-shadow-tree-flag. If you have specific examples,
please contribute them there.

How do I comment in the wiki when I cannot edit it?

comment: 16
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c16
Dimitri Glazkov wrote on 2015-04-23 19:03:52 +0000.

(In reply to Dylan Barrell from comment #15)

(In reply to Dimitri Glazkov from comment #12)

This is one of the Closed-by-default Cons in the "contentious bits"
document:
https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits#b-the-
default-value-of-closed-shadow-tree-flag. If you have specific examples,
please contribute them there.

How do I comment in the wiki when I cannot edit it?

Doh. Good point. My apologies for directing you there. I will incorporate your feedback.
@hayatoito hayatoito added the v1 label May 25, 2015
@hayatoito hayatoito self-assigned this May 29, 2015
hayatoito added a commit that referenced this issue Jun 1, 2015
@hayatoito
[shadow-dom] [issue #85] Remove a note section about a closed mode.
26c798f
@hayatoito
Copy link
Contributor Author

I've updated the spec so that closed mode is well defined. I think I can close this issue.
If you find any issue, please file a new issue for each case.

@hayatoito
Copy link
Contributor Author

Note the API for creating a closed shadow tree is still in the air. See #100.

@hayatoito hayatoito mentioned this issue Jul 22, 2015
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hayatoito hayatoito

Labels
shadow-dom v1
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@hayatoito @AFBarstow