-
Notifications
You must be signed in to change notification settings - Fork 213
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
Updates to Declarative Shadow DOM adopedStyleSheets #905
base: main
Are you sure you want to change the base?
Updates to Declarative Shadow DOM adopedStyleSheets #905
Conversation
This reverts commit 7eab993.
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.
LGTM with some minor feedback, thanks!
| Module type | Script Module | Declarative Module | | ||
| -------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------| | ||
| JavaScript | `import { foo } from "./bar.js";` | TODO | | ||
| CSS | `import foo from "./bar.css" with { type: "css" };` | `<script type="css-module" specifier="/bar.css"> ... </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.
For all of these, the "Script Module" column shows how the module would be consumed, but the "Declarative Module" column demos how the module would be defined.
It might be more consistent to have the "Declarative Module" instead show how the module would be consumed, e.g. <template shadowrootmode="open" adoptedstylesheets="/foo.css">
.
The specification of `@sheet` could be modified to split the *definition* of stylesheets from the *application* of the style rules. With this modification, `@sheet` would *define* a stylesheet with its own set of rules, but not *apply* the rules automatically. This would allow for defining stylesheets in a light DOM context and applying them only to the shadow roots. | ||
With this behavior, the following example would have a a gray background and blue text only within the Shadow DOM: |
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.
With this behavior, the following example would have a a gray background and blue text only within the Shadow DOM: | |
With this behavior, the following example would have a gray background and blue text only within the Shadow DOM: |
</template> | ||
</template> | ||
``` | ||
Text within both shadow roots in the above example should be blue due to the `adoptedstylesheets` at each Shadow DOM layer. Note that it is not currently possible to export stylesheets *out* of shadow roots. |
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.
Something I noticed here is that this approach doesn't separate the action of applying of the sheet to a shadow and of making it available to nested shadows. So, say I have a shadow A
and A
contains a nested shadow B
. If I want to define a style in the light DOM and apply it only to shadow B
, I can't do that; to make it available to B
I have to pass it to A
in adoptedstylesheets
which will also apply it to A
.
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 doesn't need to block sharing this doc but is maybe worth a note; we have more thinking to do 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.
From offline chat - Requiring @import in shadow DOM (same as light DOM) seems like it'd solve this, and make the usage feel more consistent.
@@ -348,7 +425,7 @@ This proposal will add a new markup-based `adoptedstylesheets` property that clo | |||
:host { | |||
color: red | |||
} | |||
</style> | |||
</style> |
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.
</style> | |
</style> |
(nit- stray space)
@@ -362,7 +439,7 @@ Web authors can use the `adoptedstylesheets` property on the `<template>` elemen | |||
<!-- --> | |||
</template> | |||
``` | |||
One requirement of this approach is that the current `adoptedStylesheets` JavaScript property would need to lift the “constructable” requirement for `adoptedStylesheets`. This was recently agreed upon by the CSSWG but has not been implemented yet: [ Can we lift the restriction on constructed flag for adoptedStylesheets?](https://github.com/w3c/csswg-drafts/issues/10013#issuecomment-2165396092) | |||
One requirement of this approach is that the current `adoptedStylesheets` JavaScript property would need to lift the “constructable” requirement for `adoptedStylesheets`. This was recently agreed upon by the CSSWG but has not been implemented yet: [ Can we lift the restriction on constructed flag for adoptedStylesheets?](https://github.com/w3c/csswg-drafts/issues/10013#issuecomment-2165396092) |
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 requirement of this approach is that the current `adoptedStylesheets` JavaScript property would need to lift the “constructable” requirement for `adoptedStylesheets`. This was recently agreed upon by the CSSWG but has not been implemented yet: [ Can we lift the restriction on constructed flag for adoptedStylesheets?](https://github.com/w3c/csswg-drafts/issues/10013#issuecomment-2165396092) | |
One requirement of this approach is that the current `adoptedStylesheets` JavaScript property would need to lift the “constructable” requirement for `adoptedStylesheets`. This was recently agreed upon by the CSSWG but has not been implemented yet: [ Can we lift the restriction on constructed flag for adoptedStylesheets?](https://github.com/w3c/csswg-drafts/issues/10013#issuecomment-2165396092) |
stray space
```html | ||
<script> | ||
function supportsDeclarativeAdoptedStyleSheets() { | ||
return document.createElement('template')["adoptedStyleSheets"] == undefined; |
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.
return document.createElement('template')["adoptedStyleSheets"] == undefined; | |
return document.createElement('template')["adoptedStyleSheets"] != undefined; |
``` | ||
For the Declarative CSS Modules approach, [one suggestion](https://github.com/whatwg/html/issues/10673#issuecomment-2453512552) is to bind the `<link>` tag's `href` attribute value to the CSS module identifier and add a new attribute (`noadoptedstylesheets`) to avoid double-applying stylesheets. |
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.
For the Declarative CSS Modules approach, [one suggestion](https://github.com/whatwg/html/issues/10673#issuecomment-2453512552) is to bind the `<link>` tag's `href` attribute value to the CSS module identifier and add a new attribute (`noadoptedstylesheets`) to avoid double-applying stylesheets. | |
There was also a [suggestion](https://github.com/whatwg/html/issues/10673#issuecomment-2453512552) for adding browser support to enable falling back to a normal `<link>` tag without the use of script, by binding the `<link>` tag's `href` attribute value to the CSS module identifier and adding a new attribute (`noadoptedstylesheets`) to avoid double-applying stylesheets. |
Optional suggestion for clarifying the purpose of this alternative.
This PR updates the Shadow DOM stylesheet Sharing document based on feedback from TAG and WHATWG.
In particular:
@sheet
section is expanded