Re: [w3c/webcomponents] Serialize shadow DOM for use in javascript disabled user agents (#788)

That's an interesting proposal, but I have to say I'm not really a fan of it.  I don't like that it is declared as an element but does not appear in the resulting child nodes, I find most of the defined behaviour pretty surprising.  The resulting DOM structure could have any of:

 - Nothing
 - HTMLUnknownElement
 - HTMLShadowRootElement

CSS interactions aren't mentioned, `nth-child`, `shadowroot + span`, etc.  I assume that, because the element isn't treated as a real element after parsing then they wouldn't be counted in `nth-child` and the combinators would not apply.  That is (potentially) a breaking change on current behaviour, although it's unlikely that websites would be currently using an element called `<shadowroot>`.

Fragments and unconnected documents aren't mentioned anywhere either,

```javascript
let frag = (new Range()).createContextualFragment(`
    <shadowroot mode="closed"></shadowroot>
    <span>Hello</span>
`);
console.log(frag.childNodes);
```

What happens in this case? I guess it would be the same as when it's found inside a template element, where it is a `HTMLShadowRootElement`, but the proposal should make that explicitly clear.

> host.appendChild(document.createElement('shadowroot')) does append HTMLUnknownElement

This means `<shadowroot>` is not really an element tag, even though it looks like one.  No other element tag works this way, and event `<!DOCTYPE>` and comments result in traversable DOM nodes.  I think it would be a mistake to use a normal element tag notation but adopt this behaviour.

> It should have mode attribute equal to open or closed, otherwise it is processed as HTMLUnknownElement

In addition to the previous point, this is a surprising rule that means a small mistake, e.g. typo in the attribute name or value, can result in a drastic change the style and behaviours associated sibling elements.  See above regarding the CSS rules, do those combinators and `nth-child` selectors now count the element? Now there's more children, so JS code relying on a specific structure or node sequence could break.  In this case, it may be better to default to one mode or the other.

I'm aware of the immutable nature of the parser, which is most likely the main reason this is proposed as a new element rather than a new node type. However, I think that the resulting DOM tree needs to be consistent in all cases.

The suggestion of extending the `<template>` element fits this scenario perfectly because its contents aren't parsed as its children, which is entirely the goal here too.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/788#issuecomment-459985329