Shadow DOM: Contentious Bits
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:
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 workarounds, but they do not satisfy the web components gold standard's 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: