Add Declarative Shadow DOM strawman proposal

[tomalec]

I'm not sure if it's the right process, but I'd like to publish Declarative Shadow DOM proposal. To move forward the discussions from whatwg/dom#510 and https://discourse.wicg.io/t/declarative-shadow-dom/1904/15

The single list is definitely not the best way to describe behavior specifications, but:

• I'm not sure what would be the best format of the actual normative document,
• I'd like to keep the high-level characteristics and implications readable for humans, not to get into precise strict algorithms
• Once we will reach consensus about some high-level behavior, I'd be happy to write something more detailed.

[hayatoito]

I think it's fine to put a proposal in proposals directory.

BTW, it looks that the proposal's high-level behavior matches my expectation well.

[caridy]

@tomalec thanks for putting this together, it looks very promising. Even though you mentioned a couple of times in the proposal, the fact that this solves the server side rendering and successive rehydration on the client side is a big big plus. It is one of the biggest practical problems to be solved before WC can be used by many apps today. Sending markup that can be rendered and show structural content to users right away without waiting for all the JS to be loaded is a primary use-case today, and we should probably highlight that in the proposal since it is not possible to achieve today with the current WC APIs.

[matthewp]

I don't think it's true that certain types of apps can't use WC because of there not being a declarative form, yet. You can send essential content as light dom and use WC for non-essential content (for ex, send a <select multiple> in light dom and replace it with <better-select> as a WC). Having a declarative form so that you could use shadow dom for essential content would be a nice addition, but I don't think the status quo is holding anyone back.

[caridy]

@matthewp just to be clear, you have only few options:

1. get your server to produce the formal composition, e.g.:

<fancy-content>
     <p>some content that goes inside the default slot</p>
</fancy-content>

in which case the output will be incomplete until those elements are upgraded, they will be missing the styles, and it will exhibit a very weird flickering effect once those elements get upgraded and new stuff become visible.

2. get your server to produce something equivalent to the real output:

<fancy-content>
     ... style and stuff... from the shadow, plus slotted content! 
     <div class="fancy-border"> <!-- from shadow -->
         <p>some content that goes inside the default slot</p> <!-- slotted -->
     </div>
</fancy-content>

in which case, you will have big problems to solve: no real style isolation until the host is upgraded. no way to intercept the upgrade process to pick the slotted pieces right before the upgrade happens so the real slotting can occur. A variation of this is what you just mentioned, send <fake-fancy-content> instead of <fancy-content> and do some work before making that a <fancy-content> after you can guarantee that it is registered, but it happens to suffer from the same kind of problems.

either way you have to do a lot of work just to use web components. I'm not questioning whether or not someone has figured this one out, I'm sure there are folks trying, but the reality is that we should provide them the tools so this process is not as painful as it is today.

[matthewp]

I believe you are saying that <fancy-content> might exhibit a FOUC. The solution is the same as what you do for CSS; you inline essential code into the head.

[tomalec]

@matthewp

I believe you are saying that <fancy-content> might exhibit a FOUC.

I'd say FOUC is a result of the post-creation upgrade of <fancy-content> from either incomplete or leaky HTML&CSS.

In the JS-enabled environment, with custom element definition already loaded there is no FOUC - see http://jsbin.com/rivoyiz/edit?html,output. Could you make this element be rendered without a FOUC in JS-free environment, and still use same id attributes and scoped styles?

I was not able to do so, that's why I propose <shadowroot> that could be used like that http://jsbin.com/gequvih/2/edit?html,output Please note, that light and shadow DOM are exactly 1:1.

Currently, you cannot server-side render it without side effects:

• FOUC,
• leaky styles,
• avoiding actual Shadow DOM features.

The solution is the same as what you do for CSS; you inline essential code into the head.

But in that case, the code we need to inline into the head is the JavaScript, what is against the requirements.

[trusktr]

In older browsers, some JS would be needed anyways, to distribute the content.