-
Notifications
You must be signed in to change notification settings - Fork 218
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
Add proposal for @sheet to enable multiple stylesheets per file #931
base: main
Are you sure you want to change the base?
Conversation
[SameObject] readonly attribute StyleSheetList nestedStyleSheets; | ||
}; | ||
``` | ||
*Open issue: The name `nestedStyleSheets` is up for discussion* |
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.
Maybe namedStyleSheets
?
|
||
## Open Issues | ||
|
||
1. Whether rules are applied automatically for `@sheet` definitions, or whether they need to be imported to apply. The CSS Working Group did not have a consensus. |
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.
I expect that we'll want them not to apply, to satisfy the scenario where a page wants to define some styles at the top level that will be shared among components used on the page but not used by the base page.
|
||
1. Whether rules are applied automatically for `@sheet` definitions, or whether they need to be imported to apply. The CSS Working Group did not have a consensus. | ||
2. Fragment-only identifiers (without a URL) should allow inline `@sheet` references on the same document to be included globally (even within shadow roots). This wasn't brought up in the CSSWG discussions at all, but is important for DSD without requiring an external file (to avoid FOUC). | ||
3. Behavior of `@import` - should this be possible within `@sheet` at all, should it be allowed if it's the first/only statement, or should it be blocked? There was discussion of this in the CSSWG, but no conclusion was reached. |
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 any context we can link to for this one?
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 one" being item 3. Behavior of @import
.
Much of this explainer is consolidating and iterating on a CSSWG discussion around [Justin Fagnani](https://github.com/justinfagnani)'s proposal for multiple stylesheets in a single file [here](https://github.com/w3c/csswg-drafts/issues/5629). | ||
|
||
## Participate | ||
- [Issue tracker](https://github.com/w3c/csswg-drafts/issues/5629) |
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.
Seems like these links might be reversed.
|
||
#### Performance | ||
|
||
This will be a performance-neutral feature, and use of it may allow for developers to reduce the number of network requests. We should ensure that multiple imports of different sheets from the same file produce a single network request. |
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 can make the argument that eliminating stylesheet duplication is a performance opportunity. Having a bunch of duplicated <style>
tags has a cost in terms of both memory and parsing time. This is an old doc, and very large numbers of components are used in order to highlight the effect, but the differences are definitely observable: https://dandclark.github.io/json-css-module-notes/#css-module-performancememory-examples
Or a more recent analysis: https://github.com/nolanlawson/declarative-shadow-dom-style-vs-link-benchmark
Both of those are looking at it from the perspective of CSS modules, but I think the performance argument to be made for @sheet
is similar, with the added bonus that it doesn't require JS.
|
||
## Participate | ||
- [Issue tracker](https://github.com/w3c/csswg-drafts/issues/5629) | ||
- [Discussion forum](https://github.com/MicrosoftEdge/MSEdgeExplainers/labels/AtSheet) |
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.
I think these two links might be backwards (i.e. the first is linked to the discussion forum, and the second one is actually linked to the Issue tracker)
* Current version: this document | ||
|
||
## Introduction | ||
When developing web components, web authors often encounter challenges with distributing global styles into shadow roots and sharing styles across different shadow roots. Declarative shadow DOM (DSD) enables creation of shadow DOM without JS, but adding styles to DSD requires the developer to either use JS to put a shared stylesheet into `adoptedStyleSheets`, or to duplicate the styles in a `<style>` element for each component instance. |
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.
I might split the second sentence up into two. i.e. "Declarative shadow DOM (DSD) enables creation of shadow DOM without JS. However, ..."
AtSheet/explainer.md
Outdated
|
||
Additionally, bundling of stylesheets is difficult for developers who are distributing web components. They either need to ship many small stylesheets, or use workarounds like `@import url("data...")` which are suboptimal for performance and don't interact well with other patterns. | ||
|
||
We propose an enhancement to allow declaration of new stylesheets via an `@sheet` CSS block, and using existing mechanisims such as `@import` and `<link>` to apply those shared styles to DSDs without the use of Javascript. |
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.
"allow declaration" -> "allow the declaration"
"block, and using existing" -> "block and the use of existing"
AtSheet/explainer.md
Outdated
|
||
Additionally, bundling of stylesheets is difficult for developers who are distributing web components. They either need to ship many small stylesheets, or use workarounds like `@import url("data...")` which are suboptimal for performance and don't interact well with other patterns. | ||
|
||
We propose an enhancement to allow declaration of new stylesheets via an `@sheet` CSS block, and using existing mechanisims such as `@import` and `<link>` to apply those shared styles to DSDs without the use of Javascript. |
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.
minor nit, but I see we use simply "JS" elsewhere. Should we do the same here (instead of the full "Javascript")?
div { | ||
color: red; | ||
} | ||
} |
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.
nit: inconsistent spacing between the blocks
readonly attribute DOMString? name; | ||
}; | ||
``` | ||
*Open issue: Should this overload the existing `title` attribute instead?* |
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.
Should we leave all open issues for the open issues section?
``` | ||
*Open issue: The name `nestedStyleSheets` is up for discussion* | ||
|
||
## Considered alternatives |
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.
Should we include all those mentioned in https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ShadowDOM/explainer.md#alternate-proposals (minus @sheet
as well?)
## Open Issues | ||
|
||
1. Whether rules are applied automatically for `@sheet` definitions, or whether they need to be imported to apply. The CSS Working Group did not have a consensus. | ||
2. Fragment-only identifiers (without a URL) should allow inline `@sheet` references on the same document to be included globally (even within shadow roots). This wasn't brought up in the CSSWG discussions at all, but is important for DSD without requiring an external file (to avoid FOUC). |
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 this an open issue since this is what we are proposing?
|
||
1. Whether rules are applied automatically for `@sheet` definitions, or whether they need to be imported to apply. The CSS Working Group did not have a consensus. | ||
2. Fragment-only identifiers (without a URL) should allow inline `@sheet` references on the same document to be included globally (even within shadow roots). This wasn't brought up in the CSSWG discussions at all, but is important for DSD without requiring an external file (to avoid FOUC). | ||
3. Behavior of `@import` - should this be possible within `@sheet` at all, should it be allowed if it's the first/only statement, or should it be blocked? There was discussion of this in the CSSWG, but no conclusion was reached. |
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.
I might reword this to be clearer what we mean by "this"
1. Whether rules are applied automatically for `@sheet` definitions, or whether they need to be imported to apply. The CSS Working Group did not have a consensus. | ||
2. Fragment-only identifiers (without a URL) should allow inline `@sheet` references on the same document to be included globally (even within shadow roots). This wasn't brought up in the CSSWG discussions at all, but is important for DSD without requiring an external file (to avoid FOUC). | ||
3. Behavior of `@import` - should this be possible within `@sheet` at all, should it be allowed if it's the first/only statement, or should it be blocked? There was discussion of this in the CSSWG, but no conclusion was reached. | ||
4. What happens with multiple `@sheet` definitions with the same identifier? First-definition wins, or do they get merged like `@layer`? Again, this was brought up in the CSSWG but not resolved. Note that it's possible to have a "Flash of other-styled content" if it's last-defintion-wins, as the first definition may apply, then a later definition may override it. |
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.
Why would this lead to flash of other styled content? Since we apply the full cascade before painting, could that actually happen?
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.
i.e. I would presume if a DSD uses the same name for the sheet, we would want the last to win instead of the first (unless they combine)
```html | ||
<template shadowrootmode="open"> | ||
<style> | ||
@sheet foo { |
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.
Missing indentation
Co-authored-by: Dan Clark <daniec@microsoft.com>
As part of looking at Declarative CSS Modules, TAG has suggested that we should investigate
@sheet
as a possible direction. This explainer summarizes and builds on the CSSWG discussion about this idea to consolidate it into a single location.