[Bug 27775] [Shadow]: Define the behavior of *closed* shadow trees.

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

--- Comment #12 from Dimitri Glazkov <dglazkov@chromium.org> ---
(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 <video controls>
> > would then be closed.
> > 
> > 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.

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

Received on Tuesday, 10 March 2015 22:17:08 UTC