What if we used an attribute instead of a shadow-root element?

[treshugart]

This would replace #17.

<div shadow-root="open">
  <template undistributed>
    <span slot="name">not distributed</span>
  </template>
  <slot>Light DOM</slot>
</div>

Would rehydrate to:

<div shadow-root="open">
  #shadow-root
    <slot></slot>
  Light DOM
  <span slot="name">not distributed</span>
</div>

To make it compatible with the current imperative API:

• It can only be set once. Subsequent sets do nothing.
• It must accept a value. I guess we could do the right thing and default to open but that's not really spec compliant. Thanks Apple.

[bedeoverend]

Interested in this syntax, so if this attribute was set on an element, it would expect a template which represents the undistributed light DOM of the element, correct?

After the insertion of the Shadow Root, would it then remove the innerHTML and stamp the undistributed template into the Light DOM? I guess this would be safe as attaching a Shadow DOM can't be reversed, so it doesn't matter that the original DOM was lost?

Then, after the Shadow Root is attached, you'd update the Shadow DOM via through it's imperative API?

I'm just trying to get my head around this, not only from this lib's perspective, but also as something to potentially influence spec in future.

[treshugart]

Interested in this syntax, so if this attribute was set on an element, it would expect a template which represents the undistributed light DOM of the element, correct?

Yes. I think we need to have an answer for this, but we don't need to implement it for a first iteration.

After the insertion of the Shadow Root, would it then remove the innerHTML and stamp the undistributed template into the Light DOM? I guess this would be safe as attaching a Shadow DOM can't be reversed, so it doesn't matter that the original DOM was lost?

Then, after the Shadow Root is attached, you'd update the Shadow DOM via through it's imperative API?

This is the problem I'm thinking about. I have no idea how to get around this yet, unfortunately.

[bedeoverend]

So I was mucking around with a demo of this. Syntax feels really nice - it uses the <template undistributed> element, but only optionally, defaulting to just rehydrating the slots in order. It also puts unused default information in the template so should resolve #10 and it'll also fix #16

The rehydration script isn't very specific to the attribute syntax proposed here, it's more to deal with the <template undistributed> stuff, but that code means it's a lot heavier than the current rehydration script, but to be fair it's dealing with a lot more information - default content, undistributed nodes, restoring proper light DOM structure.

There's also a few quirks which make it feel a bit clunky e.g. the way I've done default inside the placeholder nodes feels pretty unintuitive when writing it out, but not sure on a better syntax...? Plus also the need to write out <slot name="description"><span slot="description"/></slot> doesn't feel so nice.

[treshugart]

This sounds awesome! I wouldn't worry too much about ergonomics or perf at this point. Having something that covers the spec means we can iterate on the niceness.

Plus also the need to write out doesn't feel so nice.

Is this pointing out the fact that the spec has opted for verbosity over a possibly more ergonomic approach, or does this have to do something with the algorithm here?

[bedeoverend]

Is this pointing out the fact that the spec...

More to do with the algorithm I believe i.e. it would be nice to be able to just write:

<h3><span slot="name">John Doe</span></h3>

and when splitting in light + shadow you can infer that the existence and position of <slot name="name" /> But, this won't work once you've got nodes that'll get assigned to <slot>, as there's no differentiation between them and what's in shadow. Getting around this you could ask users to write out <span slot></span> which would be assigned to a nameless slot. Anyway this is just a niggle, not worth much time.

[bedeoverend]

@treshugart what're your thoughts on this? I feel like this is a better position than what we've got now, do you want me to chuck it into a PR?

Also, thoughts on using composed rather than shadow-dom="open"?

[treshugart]

Agree. Go for it!

Also, thoughts on using composed rather than shadow-dom="open"?

This is a tough one. If we think that by having a composed shadow root that it should always be open then we don't need an argument and composed is probably best. However, if we think closed needs to be available to the declarative approach then shadow-root feels better.

If we go with composed, it fits the naming convention of the flag on Event.

[bedeoverend]

Agree. Go for it!

Nice! I'll put one together.

IMO composed is the better one here, as I can't see how you could ever have a declarative Shadow Root - how would you restrict access? But, perhaps we'd want to open the door for more options down the track i.e. not just open / closed. But, I think it's much of a muchness.

[bedeoverend]

FYI haven't forgotten about this, just haven't had a change to make a PR. Should have some time early next week though

[treshugart]

So given the recent discussions and what we've lightly proposed in whatwg/dom#510 (comment), I think composed is the best solution here.

However, I want to implement that proposal in full. Meaning, I want composed not to do anything with the DOM; it should be compatible with React et al. Maybe we can use an attribute handler of some sort (mutation observers?) to "upgrade" the css encapsulation. And then observe the content of that node, so when it changes, we can rescope.

For the dom encapsulation aspect, I think we might be able to do similar to what we're doing now because it's currently only rehydrating if attachShadow() is called, which is intentional.

I think what I'm getting at (still fleshing out) is that we add another mode (CSS only) via composed shadow dom encapsulation can happen via our current method.

[bedeoverend]

@treshugart given it looks like Declarative Shadow DOM is looking like <shadowroot> which is quite different to composed and what is discussed in your last comment, would you like to see this lib go more towards a polyfill of the potential Decl. Shadow DOM standard, or as a polyfill for the composed approach you've proposed?

I think the composed approach is more practical and useful, however I think if a standard syntax is agreed on for Decl. SD, then it would be useful to have a polyfill for it - perhaps they should be two different libs? Also will know more end of next week after TPAC summit

[treshugart]

I reckon go with a pf for the standards approach. As much as it sucks, alignment with that is better than divergence without a native approach. We'll know more after TPAC. I know someone is planning on bringing up our proposal (https://gist.github.com/treshugart/dafb15f613bb7664d451f582da512f63) at TPAC. Not sure if it will have much effect, though. 🤞

[treshugart]

I'm going to close this now in favour of the current node approach.