Skip to content

Shadow DOM: Contentious Bits

Dimitri Glazkov edited this page Feb 6, 2015 · 26 revisions

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:

Alternative ideas:

  • add imperative equivalent, the ability to transfer a shadow tree from one host to another.

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:

The imperative distribution API

Current state: needs solid proposal