Skip to content

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

KurtCattiSchmidt
Copy link
Contributor

This change updates both the LRLR and Declarative CSS Modules explainers to cover differences between them in preparation for a TAG discussion.

@@ -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>` |

Copy link
Contributor

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?

Copy link
Contributor Author

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.) |
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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 |
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants