Shadow DOM: Contentious Bits

A. Multiple Shadow Roots per Element

Current state: removal being discussed

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 (examples: http://blog.quickui.org/2013/11/08/filling-slots-in-shadow/ 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.

B. The default value of "closed shadow tree" flag

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

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.

C. The imperative distribution API

Current state: needs working proposal

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:

• ?

Alternative Ideas:

• The component could achieve nearly the same result by explicitly setting classes on children that need to be selected. Prototype. The problem with this proposal is that it does not satisfy the web components gold standard's content reprojection requirement.

D. Separate Event Retargeting from of Style Composition

Current state: being considered

Discussion:

Pros:

• Smaller primitives make implementation easier

Cons:

• Event retargeting is still necessary for closed shadow trees.

E. Shadow boundary-piercing combinators

Current state: being considered for removal

Discussion: Sep 2013, Feb 2014, Jan 2015

Pros: *

Cons: *

Research:

• Shadow-piercing Combinators in the Wild