Current state: removal being discussed

Spec Bug: Consider removal of multiple shadow roots

Discussion: Aug 2011, Feb 2015

Pros:

• enables consistent story for adding shadow trees to builtins
• provides reasoning about subclassing DOM trees

Cons:

• complexity: (link to trac.webkit.org patch removing the code?)
• performance: may result in "submerged" trees that aren't rendered but still participate in style/layout

Cost/benefit of change:

• Disables the use case for general inheritance-based component composition and Firefox UI in XBL)
• Makes implementing Shadow DOM easier

Alternative ideas:

• add imperative equivalent, the ability to transfer a shadow tree from one host to another.
• Ryosuke/Ted/Jan Proposal

Current state: in need of consensus, currently spec'd as open-by-default, with strong opposition to flip to closed-by-default.

Spec bug: The default value of open/closed flag

Discussion: June 2011, Feb 2012, Oct 2012, Mar 2013, Feb 2014, Feb 2014, Feb 2015

Open-by-default Pros:

• offers enough of a doorstep to avoid unintentional wandering across composition boundaries.
• compatible with most of today's tooling/testing/introspection techniques in the wild

Open-by-default Cons:

• developers are likely to ignore the doorstep in cases where they "just need stuff done", and thus negatively affect component's composition qualities (robustness, maintainability, reuse).

Closed-by-default Pros:

• provides a more explicit barrier to prevent deliberate access (though not actively hostile attempts at gaining entry)
• ensures that the internal structure of the component is never part of the contract between component user and component developer

Closed-by-default Cons:

• forces component testing to use different code from what is shipping (no way to test the inside of the component instance)
• disables a class of introspection tooling (example: design-mode introspection in a drag/drop designer) and checkers (example: accessibility checker)
• breaks event delegation

Alternative Ideas:

• Don't have the default value. Make developer choose their mode when creating a shadow root.

Feedback from Web Developers:

• 1

Current state: needs working proposal

Spec bug: Specify imperative API for node distribution

Discussion: Spec bug, Feb 2014, Apr 2014

Pros:

• Enables more flexible ways to select content into insertion points.
• Imperative API that explains the declarative <content> element's magic is good for the platform.

Cons:

• There are several proposals, each with its own weaknesses, with no clear winner.

Alternative Ideas:

• There are several possible content reprojection criteria.

Current state: being considered

Spec bug: Make event retargeting optional

Discussion:

Pros:

• Smaller primitives make implementation easier

Cons:

• Event retargeting is still necessary for closed shadow trees.

Current state: being considered for removal

Discussion: Sep 2013, Feb 2014, Jan 2015

Pros:

• Provides somewhat mechanical workaround for existing CSS theming frameworks
• Empowers widget consumers to tweak pre-developed widgets
• Provides UA stylesheet equivalent.

Cons:

• Third-party theming anti-pattern
• Developers are tempted to put everything into their "UA stylesheet equivalent"
• Contributes negatively to potential performance opportunities.

Research:

• Shadow-piercing Combinators in the Wild