- From: Romain Menke via GitHub <noreply@w3.org>
- Date: Tue, 27 Jan 2026 12:36:00 +0000
- To: public-css-archive@w3.org
> 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. Just to make sure the nuance isn't lost :) I am not opposed to `@sheet`, I really like it. Most of all because of how useful it is purely in CSS. It makes it so much easier to create a CSS bundler where the input is multiple CSS files and the output is a single CSS file. But I am not in favor of something called `@export` and having a concept in CSS of what is or isn't exposed to JS from inside a CSS file. In CSS it does make sense to be able to define/declare things without applying them. `@sheet` does this, but also `@property`, `@keyframes`, `@custom-media`, `@font-face`, ... As long as these aren't used they are (mostly?) inert. And having a good JS API to import named things from a CSS stylesheet is also obviously a good feature. But I don't think we want to create a new concept of `exported` in CSS stylesheet. `defined but not applied` is a much better fit imo. -- GitHub Notification of comment by romainmenke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5629#issuecomment-3804986495 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:36:01 UTC