Re: Shadow tree style isolation primitive

On Mon, Jan 12, 2015 at 4:45 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> I understand your use case but please also understand that some authors
> don't want to write a few dozen lines of JavaScript to create a shadow DOM,
> and hundreds of lines of code or load a framework to decoratively isolate
> CSS rules in their pages.

I agree that having a *simpler* way to define the shadow boundaries
could potentially make sense.  It wouldn't be a matter of splitting
apart more primitives, but instead of defining new sugar on top of the
existing stuff, to have a simple declarative mechanism for "make this
element push all of its contents into a shadow tree", potentially also
with some simple way to define styles for elements of that type.

I'm not saying the current status quo is 100% ideal, just that I think
the lines it draws are theoretically pretty useful.

Previously I said that it was a problem if the isolation selector
could pierce isolations - I think that's true of *general* selectors,
because, for example, classes are often reused for different meanings
in different parts of the page.  But if we restrict it to *element
names*, it's probably more okay; those are more identity-based, which
is part of why we're using them for components in the first place.
Imagine that the markup could look something like:

```
<head>
  <meta name=component-elements content="x-foo">
  /* Or whatever, just need some declarative mechanism for custom
element names. */
</head>
<x-foo>
  <p class=one>...</p>
</x-foo>
<p class=two>...</p>
<style>
p { color: red; } /* only affects the p.two element, as p.one is
inside the x-foo's isolation */
x-foo::shadow p { color: blue; } /* does target the p.one element,
standard shadow-dom styling rules */
@in-shadow-of x-foo {
  p { color: green; }
  /* treated as a style *inside* the shadow dom, for short selectors
and normal specificity rules */
  /* thus, this targets p.one */
  /* interacts with the previous `x-foo::shadow p` rule in
already-defined shadow-dom way. */
  /* this style is also shared between the various x-foo elements that
may be on the page */
  /* to style a single specific one, append a <style scoped> element
normally. */
}
</style>
```

This is just a quick sketch, but it shows how we can still invoke the
shadow dom primitives with a simple declarative syntax when all we
want is the simple isolation boundary, nothing more complex.  It also
composes properly, just like full-powered script-based web components
do; you can use a bunch of components together on the page, and as
long as their names don't clash, everything just works.

> I would just say that we feel event retargeting should be treated as a
> separate concern from style isolation.  I'm denying that a style isolation
> with event retargeting is a valid use case but there are use cases in which
> style isolation without event retargeting is desirable or retargeting needs
> to be implemented by frameworks.

Yeah, event retargeting seems validly separable.  It used to be a
tighter boundary in shadow DOM, but we loosened the defaults.  That
should be something more controllable.

~TJ

Received on Tuesday, 13 January 2015 01:22:32 UTC