Shadow DOM Encapsulation

[This'll be rambly.  Sorry.]

[Let me first note that this isn't really the best list for this kind
of discussion.  It's a wider Shadow DOM topic, and should be discussed
in the relevant venue for that - public-webapps.  But Sylvain asked
for some more detail, and Ted has been bringing up old Maciej emails
without mentioning the rest of the relevant threads where we came to
the current conclusions, so it's probably worthwhile to at least have
an informative thread here.]

So, Sylvain and others have asked for some justification of the
current level of Shadow DOM CSS "encapsulation".  I'll start with a
quick summary of how it's currently defined.

Elements inside a shadow subtree ("shadow nodes") can't be targetted
by selectors in the outer document in any way.  They are completely
hidden from any normal selector or combinator.

We introduce a new combinator, which for the purpose of this email
I'll call "^", which lets you pierce a single shadow boundary,
allowing you to style what's inside of a shadow tree when you
explicitly want to.  (We also have a ^^ combinator which pierces an
arbitrary number of shadow boundaries, effectively matching on the
"composed tree" rather than the normal DOM tree.)

First, note that this is almost *precisely* how Shadow DOM works in
JS.  Shadow subtrees are hidden from normal DOM traversal and search
methods, such as .childNodes or .getElementByID().  When you
explicitly want to search into a shadow subtree, though, you just have
to access the .shadow property on an element, which returns the
subtree, at which point you can continue to use normal DOM traversal
inside the subtree.

The decision to do the JS side of Shadow DOM this way was made over a
year ago.  Here's the relevant thread for the decision:
<http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg312>
(it's rather long) and a bug tracking it
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=19562>.

Note that there were good arguments made for adopting either a
private-by-default or private-by-choice model, but we eventually went
with a public-by-default model instead.  This was for several reasons,
but the most important in my eyes is that we gradually came to realize
what the underlying primitive we were trying to expose was, and that
was just "hiding", not "privacy" or "security", which are elaborations
of the basic concept.  While this decision predates the articulation
of the Extensible Web Manifesto, it ends up agreeing with it exactly -
it exposes the most basic underlying primitive, so that the UA can
build more complicated things on top of it, but authors can still use
the base concept without having to reinvent the whole stack for
themselves.

(An almost identical scenario played out in JS regarding privacy, too.
 People have been clamoring for privacy for years.  It turns out,
though, that most cases are just looking for "hidden by default"
and/or collision avoidance (which are two sides of the same coin), and
so JS started by introducing the Symbol.  It's going to build stronger
privacy primitives into the language *as well*, most likely on top of
Symbol, but by exposing the lower-level primitive first they allow
incremental progress and ensure that people whose needs aren't
perfectly served by the eventual "private variables" solution don't
need to reinvent from the ground up - they can just move a little bit
down the stack and start from Symbols instead.)

Following the call of the Extensible Web Manifesto these days is even
more important, because we've come to recognize just how right it is.
In JS Shadow DOM, if we produced something too restrictive, people
wanting something similar but less restrictive are screwed, and have
to continue building things on their own from the ground up.  The same
applies to CSS Shadow DOM - start by defining the most basic boundary,
providing useful functionality without getting in the way of users,
*then* build more elaborate boundaries on top of it.


Okay, that's enough abstract theorizing, and enough text.  Next email
will be more concrete stuff.

~TJ

Received on Thursday, 6 February 2014 22:11:14 UTC