-
Notifications
You must be signed in to change notification settings - Fork 243
Add comparisons between LRLR and Declarative CSS Modules #1073
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Add comparisons between LRLR and Declarative CSS Modules #1073
Conversation
@@ -325,6 +325,28 @@ CSS Modules are not the only type of module - there are also JavasScript, JSON, | |||
| WASM | `import {foo} from "bar.wasm" with {type: "wasm"};` | `<script type="wasm-module" specifier="/bar.wasm"></script>` | | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of the drawbacks of this approach was the syntax. I think we had discussed an alternative that would feel more natural, although the exact details are escaping me. Do we want to update the syntax or add a section for an alternative syntax as part of this in case it helps when we go to re-review with the TAG?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tricky thing is that we can't really change the syntax of Declarative CSS Modules without diverging from the Imperative version significantly. Let's leave this open until @dandclark returns - he might have some ideas here.
| Integration with @sheet | ✅ Yes | ❌ No | | ||
| Uses existing HTML concepts | ✅ Yes | ❌ No | | ||
| Uses existing module concepts | ❌ No | ✅ Yes | | ||
| Extensibility | Clean @sheet integration, scope expansion could apply to SVG references | More declarative module types (HTML, SVG, etc.) | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a section on extensibility in this explainer and how we envision this applying to SVG?
So essentially this wouldn't apply to other reference types then? That does seem like it could be a drawback. I'd suggest expanding on this in the new extensibility section.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the scoping extensions would apply to any reference type, including SVG, link fragments, etc.
I'd like to keep the scoping extensions as a parallel subject, referenced here but defined elsewhere, so that the proposals don't get muddled together. Right now, I'm just referencing the bug, but it could be a separate explainer eventually. But we can ship LRLR without scoping and deliver that later, so I don't want to get too stuck on it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is how it could look - I'll post it in the bug when I'm back from vacation:
SVG:
<template exportids="foo"><!-- Exports 'foo' to the light DOM -->
<template exportids="foo">
<svg height="100" width="100">
<circle id="foo" r="45" cx="50" cy="50" fill="red" />
</svg>
</template>
<svg height="100" width="100">
<use href="#foo" /><!-- "foo" is in this shadow scope due to the "exportids" attribute above -->
</svg>
</template>
<svg height="100" width="100">
<use href="#foo" /><!-- "foo" is in the Light DOM scope due to the "exportids" attribute above -->
</svg>
Local anchors:
<template exportids="foo">
<a name="foo">Link to foo</a>
</a>
<a href="#foo">Scroll to a shadow root!</a>
| Scope | Standard DOM scoping | Global scope | | ||
| Identifier syntax | Standard HTML IDREF | Module identifier | | ||
| Integration with @sheet | ✅ Yes | ❌ No | | ||
| Uses existing HTML concepts | ✅ Yes | ❌ No | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way CSS Modules could end up being closer to HTML concepts if we adjust the syntax?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could, but then it would diverge from Imperative CSS Modules. Let's sync with @dandclark once he's back.
This change updates both the LRLR and Declarative CSS Modules explainers to cover differences between them in preparation for a TAG discussion.