Re: Shadow DOM Encapsulation

So, the major proposal people have in opposition to the above is to
lock down shadow dom completely in CSS, and allow components to
surface individual pieces via a part='' attribute.  You can then
access those elements from the outside document via a ::part()
pseudo-element hanging off of the component, like "x-foo::part(bar)".

This has a few problems:

1. You have to explicitly tag each element that you want to surface.
Some types of components want to expose their entire selves, because
they're being used just as API surface, etc.  Some just want to expose
a *lot*; they don't need to literally expose everything, but it's
still annoying to spam a part='' attribute everywhere.

2. ::part effectively flattens the structure of the internals.  It's
very similar to allowing only a simple selector on the tree, no
combinators.  This is obviously rather limiting, for the same reasons
it would be limiting to disallow combinators from the outside page.
Hopefully I don't need to illustrate use-cases for combinators.  ^_^

3. ::part, at least as naively defined above, doesn't handle nesting
of components, either.  This breaks down in two ways:

  3a. If you want to style a particular component, regardless of where
it's used in the page, you can't do it with ::part.  For example, if
you're using the jQuery UI WC library, and you want every use of the
<jq-button> to be styled in a particular way, you can't do it.

  3b. When building a component, it often makes sense to factor out
some bits into their own components.  This is just an internal detail,
for code elegance; it shouldn't matter for the outside world.  Does
this mean that you need some way to surface the parts of nested
components as your parts?  Do you need to list all the exposed parts
explicitly, or do you just send them all up by default?

Let's be clear - these probably could be fixed. However, it would take
quite a bit more time to develop, and "fixing" them would be done by
relaxing the very containment that people are asking for.  By the time
you're done, you have something almost as wide-open as ^/^^ already,
but with a clumsier syntax.

This is the problem with trying to address all the problems at once,
with a single mechanism.  There are use-cases for higher restrictions,
but there are plenty of use-cases in lots of directions for more
general uses, too, and you can't solve all of them without losing the
restrictiveness that the first use-cases wanted, or ending up with
awkward and hard-to-understand syntax/data model.

This is why we ended up with a "hidden, but open if you want" model
for JS Shadow DOM, and why we ended up with the exact same model for
CSS.

~TJ

Received on Thursday, 6 February 2014 23:36:31 UTC