Add failing test for declarative shadow-dom

[NullVoxPopuli]

Support: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template

[ef4]

This is an intentional limitation of the proposed content-tag format. For it to be agnostic about the interior language, it can't allow unescaped </template> inside the content tag. We could devise an escaping mechanism.

[NullVoxPopuli]

intentional limitation

I don't believe this, it doesn't make sense?

At least, with how I understand your words, it forbids folks from ever using The Platform for stuff like this: https://developer.chrome.com/docs/css-ui/declarative-shadow-dom (or whatever else can be done with <template>)

For it to be agnostic about the interior language, it can't allow unescaped inside the content tag.

This seems reasonable to me. We shouldn't be allowing any unescaped tag anyway.
I don't know what this'll mean for tools like Glint, where they want error-tolerance 🤷

[NullVoxPopuli]

<template> is only useful with the shadowrootmode attribute, otherwise <template> isn't rendered at all

[ef4]

I don't believe this, it doesn't make sense?

Read more carefully, I said it's not allowed without escaping. For the same reason that a single-quoted Javascript string literal has an intentional limitation that you can't use unescaped single quotes in them.

The point here is that content-tag is supposed to work regardless of the interior language. For that to be possible, the outside language (content-tag itself) needs to claim some delimiter to mark the end, and if the interior languages wants to use that delimiter it needs to be escaped.

[NullVoxPopuli]

do we have a means to escape?

[ef4]

We have to design it. It could be as simple as `\</template>` means literal `</template>` and `\\</template>` means literal `\</template>`. Alternatively we could make some pragma that defines a custom delimiter, kind of like a Ruby Here Document.

…

On Tue, Feb 20, 2024 at 3:21 PM NullVoxPopuli ***@***.***> wrote: do we have a means to escape? — Reply to this email directly, view it on GitHub <#66 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACN6MQKQ33NOT3LT2ZJXTDYUUAWHAVCNFSM6AAAAABCVKCR32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJUHE4TSNZTGY> . You are receiving this because you commented.Message ID: ***@***.***>

[NullVoxPopuli]

Recapping from the spec meeting, and "having had time to sleep on it", I think supporting a

<glimmer> ... </glimmer> alternate is my preference for "just paste your HTML and have it work".

that would be kind of annoying to switch <template> to <glimmer>, so i think we should support both for a time. It's compiled away, and only really matters for folks not using content-tag for tooling 😅
(Currently, that's just Glint and template-lint, afaik))