Re: [csswg-drafts] Multiple stylesheets per file (#5629)

> > Right now nothing is exported from a style sheet to JS except for the sheet itself in the default export. `@sheet` as proposed would be the first thing to create a named export.
> 
> > I have been concerned about needing to know which things create named exports as that set expands in the future. How would we export class name, and would that use something like `@export` or a new at-rule for declaring a class name or selector, and that new rule creates a named export?
> 
> I am unsure if this is the correct framing/perspective.
> 
> I am not in favor CSS syntax that only exists so that it makes something work on the JS side. So it doesn't make sense to me to have to add extra syntax in a stylesheet to make things accessible from JS.

I have to disagree here, or at least advocate that CSS _should_ consider good JS integration as a goal on it's own.

There is a fundamental line in the dependency graph of many web projects from JS to CSS. JS modules require CSS to function properly, cause CSS to load, read values from CSS, and use those values to dynamically update HTML to trigger styling. So CSS adding features to make those types of things natively available and standard is a good thing. If `@sheet` (or `@export`) is initially used from JS, that's not bad, it's CSS offering one of it's main dependents a useful feature.

> I am not really in favor of this syntax:
> 
> import {sheet1, sheet2} from './styles1and2.css' assert {type: 'css'};
> I would prefer something less magical:
> 
> import sheet from './styles1and2.css' assert {type: 'css'};
> 
> const sheet1 = sheet.getSheet('sheet1'); // or any similar API to get the sheets from the `CSSStyleSheet` object.

I'm definitely not opposed to `.getSheet()` if it gets this feature off the ground. One reason that tooling prefers imports is to make tree-shaking easier. Analyzing imperative calls to see what's used is difficult-to-impossible. That probably doesn't apply so much to `@sheet` which is more likely to be the output of a bundler, not the input.

> Some issues that come to mind with named exports/imports:
> 
> * dashed idents aren't valid names in JS (`@sheet --foo {}`, `@property --foo{}`)

JS can import names that aren't valid JS identifiers now, so developers can write

```ts
import {'--foo' as foo} from './foo.css' with {type: 'css'}`;
```

> * multiple things in CSS can share the same name (`@sheet --foo {}`, `@keyframes --foo {}`, `@property --foo`)

This is the biggest problem, and why I'd like to see some explicit export modifier. Then there can simply be ab error if you export the same name multiple times without renaming.

> In a way `import {sheet1, sheet2} from` is syntactic sugar that isn't actually needed for what the `@sheet` feature is trying to solve?
> 
> Convenient access to named things from a stylesheet seems generally useful. Can we have homogenous API that works for `@sheet` but also other named things?

Only with some kind of renaming support (ie export as), so `.getSheet()` seems like a good incremental solution for now that solves the core problem.

-- 
GitHub Notification of comment by justinfagnani
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5629#issuecomment-3804926875 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 27 January 2026 12:23:30 UTC