Shadow DOM: Contentious Bits

Travis Leithead edited this page Apr 24, 2015 · 26 revisions

A. Multiple Shadow Roots per Element

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:

Alternative ideas:

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.

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:

Alternative Ideas:

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

Feedback from Web Developers:

C. The imperative distribution API

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:

D. Separate Event Retargeting from Style Composition

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.

E. Shadow boundary-piercing combinators

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:

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.