-
Notifications
You must be signed in to change notification settings - Fork 707
[css-cascade-7] @sheet proposal #11509 #11980
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
base: main
Are you sure you want to change the base?
Conversation
css-cascade-7/Overview.bs
Outdated
Such ''@sheet'' block rules have the same restrictions and processing | ||
as a [=conditional group rule=] [[CSS-CONDITIONAL-3]] | ||
with a true condition. |
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'm unclear on why this sentence is in the spec - can you explain what it's intended to do beyond what's implied by the grammar for @sheet
above? (Explanatory text of this sort would be a good use case for a "Note".)
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.
Good call out. This essentially means "the rules within this block apply", which is what you'd want for @layer
(which I copied it from), but crucially not what we want for @sheet
.
I switched the 'true condition' to 'false condition' and added an example.
<pre class='idl' export> | ||
partial interface CSSImportRule { | ||
[SameObject] readonly attribute SheetNameList sheetNames; | ||
[SameObject] readonly attribute StyleSheetList namedStyleSheets; |
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.
The value of namedStyleSheets
should be manually available by iterating the existing styleSheet
attribute and pulling out each CSSSheetBlockRules
in order. Given that, is there a reason we should be exposing it as part of the standard? (Possibly an expected common use case?)
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.
You can manually access the individual rules that way, but not the actual CSSStyleSheet
object.
The CSSStyleSheet
has more options than the individual rules - https://drafts.csswg.org/cssom/#the-cssstylesheet-interface
This could potentially be plugged into adoptedStyleSheets
in Shadow DOM as well - https://drafts.csswg.org/cssom/#dom-documentorshadowroot-adoptedstylesheets
(note that it currently says it must be a Constructable Stylesheet, but that was lifted recently and the specs/implementations haven't caught up - #10013 (comment))
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.
Also, the CSSImportRule
already has a single-value accessor for styleSheet
- https://www.w3.org/TR/cssom-1/#cssimportrule
That won't work for named stylesheets, but separating them isn't too bad - the existing API will return the stylesheet containing the global, unnamed sheet and the new namedStylesheets
list contains the @sheet
nested sheets.
with a false condition. | ||
|
||
Note: This means that rules within an ''@sheet'' block are not applied | ||
until their [=named stylesheet=] is explicitly embedded into a document. |
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'm not sure if "embedded into a document" is the right condition here. In the example below, the @sheet
rule is part of the document; its contents are accessible via CSSOM. Maybe "imported into another context" 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.
Yeah this one is tricky to phrase. I think "imported into another context" is more correct, so I'm going with that for now, but this might change in the future.
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 drop into another context
?
Because you can also import it into the same context, right?
I meant "Comment" rather than "Request changes"
<<media-query-list>>?</pre> | ||
|
||
where: | ||
* the optional <<sheet-name-list>> imports only the named sheet(s) |
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 it be stated how to handle named sheets that don't exist in the provided url?
@import one, two from url('foo.css')
where 'foo.css':
@sheet one {}
Does it fail entirely or does it still import one
?
Initial version, still needs lots of work