Re: [whatwg/dom] Declarative Shadow DOM (#510)

> Sure, I don't have an opinion on this. If removing it makes more sense, let's remove it. That might end up being less confusing for authors too, since the element doesn't do anything if it's sitting there.

Regarding, template overloading (`<template newattribute>`) vs  new element (`<shadowroot>`-ish),

if we can agree on "don't leave `<template>` element in the light tree", I prefer a new element, `<shadowroot>` or something, here  because:

Descendant nodes of declarative shadow dom is effectively **NOT** *inert*, from user's perspective.
 e.g.
```
  <custom-a>
    <template newattribute> (or <shadowroot>)
      <img src='...'></img>
      <script src='...'></script>
    </template newattribute>
  </custom-a>
```

In this case,  `<img>` or `<script>` look inside of `<template>` element, but they would reside in the shadow tree, as the final result, after parsing html. We fetch resources for them. That sounds a big difference to me, as compared to usual `<template>` element's usage pattern. `newattribute` is too weak as a visual sign of this big different semantics.

In addition to that,  as Dominic suggested, the engine (or parser) might want to optimize.

Instead of:
  1. Parse a template element (and its descendants), as usual
  2. Call attachShadow on the parent element of the template
  3. shadowRoot.appendChild(template.content);
  4. Remove template element from the light tree   

We might want to optimize:
  1. Parser encounters opening `<shadowroot>`
  2. Call attachShadow on the parent element of the `<shadowroot>`
  3. Parser continues to parse descendants of `<shadowroot>`, and build a shadow tree *directly*
  4. Parser encounters a closing `</shadowroot>`.
  5. Parser continues to parse html, and continue to build a light tree

I am not sure how these are feasible, but that could be an option.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/510#issuecomment-329672539