Re: [whatwg/dom] Should attachShadow throw or override when an existing declarative shadow root doesn't match? (Issue #1235)

> I don't know, that makes code like this potentially fail in a very action-at-a-distance way, and with no pointer to the root cause of the issue (a `shadowrootmode=closed` template):

That's true. But typically this (DSD) is already "action at a distance" by definition, since it's rendered on the server.

 
> I guess we could add a console warning or so... Maybe it's worth a note in the spec?

This makes a lot of sense - the console warning. I think I'll add that to Chromium. Do we add notes about console warnings to the spec?


> Why did we not throw again?

Not throwing is an important backwards-compatibility behavior, which is the entire point for this whole "empty and return the root" behavior. If a component was built without SSR/DSD knowledge, and then some server code decides to SSR that component, we didn't want to break the component. The only real way to do that is to keep `attachShadow()` working roughly as intended.

Importantly, if the server is taking a component that calls `attachShadow({mode:'open'})` and converting that into a `<template shadowrootmode=closed>`, then that server is already very broken. So I don't think the "change the parameters" issue is really an issue in practice. Plus, components that understand SSD/DSD will check for a `.shadowRoot` and won't ever call `attachShadow()`.

> Okay, but those are not necessarily declarative shadow roots. Only one of them can be. Might just be a matter of using more precise wording then.

I agree that the wording is kind of hard to understand here. Perhaps instead of "declarative shadow roots" in that sentence, we should just use "`<template shadowrootmode>`'s" or something?

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

Message ID: <whatwg/dom/issues/1235/1830313167@github.com>