search

embroider-build / content-tag

A rust program that uses my swc fork to parse GJS
MIT License
7 stars 7 forks source link

Add failing test for declarative shadow-dom #66

Open NullVoxPopuli opened 5 months ago

NullVoxPopuli commented 5 months ago

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

ef4 commented 5 months ago

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 commented 5 months ago

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 :shrug:

ef4 commented 4 months ago

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 commented 4 months ago

do we have a means to escape?

ef4 commented 4 months ago

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 https://github.com/embroider-build/content-tag/pull/66#issuecomment-1954999736, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACN6MQKQ33NOT3LT2ZJXTDYUUAWHAVCNFSM6AAAAABCVKCR32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJUHE4TSNZTGY . You are receiving this because you commented.Message ID: @.***>

NullVoxPopuli commented 4 months ago

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 :sweat_smile: (Currently, that's just Glint and template-lint, afaik))