Re: Shadow DOM Encapsulation

On Thu, Feb 6, 2014 at 4:40 PM, Peter Linss <peter.linss@hp.com> wrote:
> Please note that this was not the only proposal, and each of the problems you point out below were addressed by my proposal.
>
> To reiterate for the new thread, I proposed two mechanisms for exporting pieces of a shadow component. Either or both could be implemented.
>
> The first would be to allow exporting pieces by a simple flag, rather than a part='' attribute you could simple specify <piece export>...</piece>. The piece would be exported by its tag name and the export would also apply to all nested pieces, unless there was another flag to turn it off, such as: ''no-export' (or maybe 'public' and 'private' for the attribute names). If you want to set the exported name as something other than the tag name you could specify that as export='name'. This would allow the creation of a fully public component by simply adding a single attribute to the shadow root node and addresses your problem #1.

This could work, and it's similar to the simple notion of "hidden, and
semi-closed" that shadow DOM considered for JS.

Note, though, that you can reverse the meaning too - rather than
closing by default and opening with a flag, you could be open by
default and hide things with a flag.  That's compatible with an
evolution of our current approach, and compatible with the JS API,
which is "hidden, and open" by default.

Note also that this isn't quite as easy as it sounds.  When you expose
things, where are they relative to everything else?  CSS syntax needs
to see a tree, or at least trees of trees.  Are all the exported
pieces independent islands that you can only reach by ::part(), and
*then* you can use normal CSS syntax on the subtree rooted there?

> The second proposal was to provide an optional style map for the component. We could create a simple syntax to define an arbitrary 'style node' tree and map it to component pieces via selectors. I don't have a specific syntax at hand, but if folks are interested I'm sure I could come up with something reasonable fairly quickly.

This sounds potentially cool, and a good thing to pursue for the
future, but I can't help but get a huge "over-engineering" vibe from
any though of doing this in V1.

> The other part of my proposal was to simply use pseudo-elements to directly select the exported component pieces by name, and to relax the restrictions on pseudo-element selectors to allow pseudo-classes, attribute selectors, and descendants (with combinators).
>
> With those restrictions relaxed, it's not necessary to flatten the pseudo-element space, so the internal structure of exported pieces could be maintained.
>
> So a piece could be selected as:
> component ::piece { ... }
> it's child could be selected as:
> component ::piece ::child-peice { ... }
> etc, with the full expressiveness of selectors. This addresses your points #2 & #3.

Well, no, not quite.  You're using spaces where they're not allowing.
It'd have to be at least:

  component::piece::child-piece

Or something else for the child-piece part that allowed combinators.

> While allowing a component to simply opt-in to exposing it's internals to selectors, this also allows components to expose only a subset (or nothing). The style map solution would allow the component to describe an arbitrary structure to the selector system and map it to an arbitrary internal structure. Allowing the internals of the component to change without breaking external references.

Ultimately, there's a strong argument against *any* attempt to lock
down by default and only expose some pieces: because the JS side is
hidden-but-open, the page's JS can just walk down the tree and open
everything up by itself.  Any *default* restrictions we put in place
are thus mere suggestions; we're not actually helping anyone lock down
their components, which is the entire argument for being more
restrictive in the first place.  This isn't a weird hack, either -
it's very trivial to do.

The current CSS mechanism of hidden-but-open with cat/hat combinators
doesn't suffer from this problem, because it's an exact analog of the
capabilities offered by JS.  It doesn't pretend to offer more safety
than it really does.

When we *do* offer more restrictive CSS shadow-piercing, we'll
probably want to do it in conjuction with more restrictive JS shadow
piercing, when we actually provide a way to hide a shadow DOM.  (This
doesn't have to be a strong security boundary, just something
sufficiently difficult to remove that you're clearly attacking things
rather than just hacking around.)

~TJ

Received on Friday, 7 February 2014 01:24:19 UTC