Declarative Shadow DOM for XML Syntax

[mossblaser]

What is the issue with the HTML Standard?

Currently the declarative shadow DOM feature appears to be defined entirely within the HTML syntax parser. As a consequence if you're using the XML syntax for HTML (formerly called "XHTML" -- for the benefit of those like me who use that term sloppily) this feature is unavailable.

This feature (declarative shadow DOMs) is very useful when embedding, for example, SVGs who use their own IDs, CSS etc. which would otherwise conflict with the rest of the document (or other SVGs). In this example, the XML syntax is also especially useful since SVGs emitted by other tools often employ namespaces liberally.

It seems to me that not supporting declarative shadow DOM in the XML syntax is a mistake and that something ought to be done to enable this valuable feature to be used and to avoid what feels like a surprising non-syntactic difference between HTML syntax and XML syntax. (Alternatively, if this is intentional , I'd welcome more information in the non-normative introduction about this kind of difference between the syntaxes).

Thanks all for your help!

For future reference, this was spotted during the reporting of a bug in Chrome where I ran into this difference.

[domenic]

I don't think we should be adding new features to the XML syntax. Maintaining only one syntax for HTML is a better use of resources for specifiers and implementers, and it's a small switching cost for authors to move to the modern HTML syntax.

For example, since there is no specification for how XML parsers behave, modifying that nonexistent specification to add support for declarative shadow DOM is quite difficult.

We should consider making it clearer in the spec that the XML syntax is unmaintained and disrecommended, though.

[mossblaser]

Oh, crikey, I didn't realise that was the situation at all! Are there other non-syntactical differences between the HTML and XML syntaxes I might not be aware of or is this the first of what may become many?

As noted above, the interoperability with other XML based things (like SVG and mathml) is very valuable and losing this feels like a serious misstep.

I do realise there is non-xml SVG-like language supported in the HTML syntax but this is not really SVG. In particular, support for XML namespaces disappears in the HTML look-a-like SVG.

As an example of the value of this, many SVG authoring tools and generators make use of their own namespaces for adding rich annotations to SVGs which you otherwise lose. Drawing tools like Inkscape represent some of their higher level drawing operations as more primative elements (eg paths) with higher level details in another namespace. This makes the SVG universally renderable but allows smarter applications to interpret or manipulate the higher level shape (eg a star). You can also imagine the value of this kind of thing for data visualisation tools. Access to this information in a browser environment has a multitude of uses ranging from providing hints to animation tweeners to interacting with data visualisations.

An analogous (though more limited) feature in HTML is of course data attributes. Unfortunately these are not intended to be used by independent software systems (there is no namespacing, except by convention) and in any case are not supported outside of HTML.

In summary, I feel that the intersection between HTML and SVG (in particular) is an extraordinary environment for developing rich visual experiences. Formally deprecating the XML syntax or HTML, or causing it to diverge from HTML in non-trivial non-syntactic ways, would substantively lessen the HTML platform.

(Unless, of course, I'm barking up the wrong tree here and there is an alternative mechanism for interoperability I've not realised/understood?)

[sideshowbarker]

Are there other non-syntactical differences between the HTML and XML syntaxes I might not be aware of or is this the first of what may become many?

https://wiki.whatwg.org/wiki/HTML_vs._XHTML has some details

[mossblaser]

Thanks for that. I've had a good reread of that page and as far as I can see this generally relates to resolving syntactic differences between XML and HTML, e.g. explaining case sensitivity, namespace handling etc. In particular, none of the differences related to fundamental semantic differences.

The case of declarative shadow DOM would stand out as something with substantive semantic behaviour which has no equivalent expression within XML.

Perhaps I'm ignorant of broader context but it seems very surprising to me that this feature is a component of the parser and not some subsequent (if early) processing stage. The consequences of this implementation detail certainly surprises me in any case.

Even if this is necessarily a parsing issue, templates appear to be one of the very few special cased features explicitly marked out for the XML syntax so it feels odd to omit this related feature.

Thanks again for helping me better understand this issue!

[gsnedders]

Perhaps I'm ignorant of broader context but it seems very surprising to me that this feature is a component of the parser and not some subsequent (if early) processing stage.

Essentially you want to build a different DOM, to put things in the shadow tree and not in the light tree.

Note that doing this as post-processing is slightly difficult, because when should that post-processing happen.

For example, it would be surprising if this (HTML syntax) logged two different things:

<!doctype html>
<div><template shadowrootmode="open">OpenDeclarativeShadowDOMsupported</template></div>
<script>
var div = document.getElementsByTagName("div")[0];
console.log(`${div.childNodes.length} ${div.shadowRoot.childNodes.length}`);
window.onload = () => console.log(`${div.childNodes.length} ${div.shadowRoot.childNodes.length}`);
</script>

…which would happen if you only did the post-processing at the point at the parser completing.

I suppose you could try and define it somewhere such that it happened prior to any script execution or any layout occurring, but practically browsers aren't going to want to actually implement it as a DOM mutation (which would also be observable, via MutationObserver), given that is considerably more expensive than just creating the shadow DOM in the first place.

The other big problem with defining it in XML is there's simply a much larger number of XML parser libraries all over the place (than there are HTML parsers), and having some parse into the shadow DOM and some into the light DOM opens things up to differential parsing attacks.

[mossblaser]

Thanks, I'd not considered the complexity of scripts executing during parsing.

That said, it still feels quite awkward that the result is that the behaviour ends up specified as part of the parser (even if that is a sensible implementation decision). But I am probably sufficiently an outsider that I don't think it is helpful for me to try and push for otherwise.

The other big problem with defining it in XML is there's simply a much larger number of XML parser libraries all over the place (than there are HTML parsers), and having some parse into the shadow DOM and some into the light DOM opens things up to differential parsing attacks.

Isn't this the same kind of situation as already exists with <template> which XML-for-HTML parsers are expected to treat specially? (Pure XML parsers will already parse these differently) Likewise isn't this problem just as relevant to HTML parsers?

In any case, as I said earlier, it does appear that this feature is a "watershed" moment where the XML syntax first meaningfully loses feature parity with the HTML syntax. (Since you can't replicate the shadow DOM functionality in some other way without resorting to JavaScript).

This thread is the first place I can recall hearing about the XML syntax being unmaintained: it is not clear that this is the case from the spec, wiki or elsewhere. If this is not yet formal consensus I'd like to lend a voice as a supporter of the XML syntax. If this is a long formalised decision, aside from better documentation, from my specific uses it would be good to see working support for XML namespaces in embedded SVG (or mathml etc.). This would revert the (currently impassable for my use) regression which comes with migration to the HTML syntax.

[TUSF]

I know this is closed, and I'm not too knowledgeable on the subject, but wouldn't one solution be to put this functionality into a separate XML namespace spec? Something like so:

<html xmlns="http://www.w3.org/1999/xhtml"
  xmlns:shadow="https://www.w3.org/2025/shadow-root" >
  <body>
    <div shadow:mode="open"><span>This is in the shadow DOM.</span></div>
  </body>
</html>

Granted, this wouldn't allow for polyglot documents, but it would maintain feature parity. This way only XML Parsers that would be expected to read the XML syntax for HTML would be affected by the new syntax. Those presumably already have to understand stuff like xlink, svg, mathml, etc… what's one more?

[domenic]

There are many possible technical solutions. None of them overcome the more foundational issues mentioned in #10237 (comment).