Skip to content
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

[css-cascade-6] add a :stylesheet selector to match the current stylesheet #7349

Closed
faceless2 opened this issue Jun 11, 2022 · 5 comments
Closed

Comments

@faceless2
Copy link

This is derived from both #3547 and (in particular) #6606, but I've opened a new issue as it's a more specific proposal.

Suggestion is: add a :stylesheet pseudo-class selector which functions like :scope but matches the element that declared the rule - ie the <style> or <link>element that created the stylesheet. For programatically created stylesheets, it would match nothing.

  • I suspect this would be very easy to implement as the rule should already have a reference to the stylesheet that declared it.
  • it would mean the functionality of the old <style scoped> syntax could be reproduced. This has been pretty heavily discussed in 3547, it was clearly popular, and while @scope is good it doesn't(*) provide a direct replacement for that functionality. :stylesheet would do that:
<style>
@scope (* > :stylesheet) {
...
}
</style>

(* you could give the <style> an id and reference that from the @scope rule, so it's technically possible; just not very flexible)

@tabatkins
Copy link
Member

I think you need @scope (:has(> :stylesheet)) {...}, but yeah, that'd work.

Anyway, huh. Slightly funky idea, but I suppose it works and satisfies a need. I'd be fine with it.

@mirisuzanne
Copy link
Contributor

It seems to me like all the use-cases for this actually require selecting the parent of the style sheet, which @tabatkins achieves by using the :has() selector. I don't know any reason to select the stylesheet itself. Is there a reason we would do this, rather than something like :stylesheet-parent or something similar that directly targets the parent?

I suppose this allows you to more generically define which ancestor of the style sheet to select?

@mirisuzanne mirisuzanne added this to In progress in Cascade 6 (Scope) Sep 6, 2022
@faceless2
Copy link
Author

Is there a reason we would do this, rather than something like :stylesheet-parent or something similar that directly targets the parent?

Not really, to be honest. For the use-case I had in mind for this, :stylesheet-parent is fine. Only being able to select the parent would remove the ability to distinguish between two sibling stylesheets, and apply selectors to their siblings (for example) - but I don't have a use-case that would require that

@mirisuzanne
Copy link
Contributor

Yeah, :stylesheet would allow more flexibility around where the stylesheet lives in relation to the scoping element. That might be useful? But it would then require more complex selectors, and flexibility comes with more potential for unclear relationships.

Agenda+ to hopefully resolve on:

  • Add :stylesheet-parent (or :stylesheet)
  • Maybe add a note to bikeshed the name of the selector, if people aren't happy with those names

I think that would also allow us to close #6606

@astearns astearns added this to 3:30-4:45 in TPAC Thursday 2022 Sep 11, 2022
@astearns astearns moved this from 3:30-4:45 to 1:30-3:00 in TPAC Thursday 2022 Sep 11, 2022
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed :stylesheet, and agreed to the following:

  • RESOLVED: @scope without selector scopes to the parent of the owner node, or the containing tree if there's no owner node
The full IRC log of that discussion <emilio> topic: :stylesheet
<emilio> github: https://github.com//issues/7349
<emilio> miriam: this is about stylesheets in the dom and scoping
<emilio> ... idea is to use `:stylesheet` / `:stylesheet-parent` to select stuff inside this scope
<emilio> ... that would allow you to scope the stylesheet
<emilio> ... most usecases prefer the stylesheet parent
<emilio> ... I don't have strong use cases for any
<fremy> huge +1
<emilio> fantasai: is there any use case other than implementing <style scoped>?
<emilio> miriam: no
<emilio> fantasai: then how about doing that?
<emilio> miriam: problem is backwards compat
<heycam> q+
<emilio> ... if scope is not recognized it's applied unscoped
<emilio> fantasai: can we use empty @scope rule for this?
<emilio> miriam: I like it
<emilio> ... we'd be setting aside being able to select the stylesheet's sibling
<Rossen_> ack heycam
<emilio> heycam: 2 things, does @scope nest? What would it mean if you would use @scope without a selector, would it be sensible?
<heycam> emilio: it would have sensible behavior
<heycam> ... the rule wouldn't apply, you would apply both filters
<emilio> heycam: second point is that there are stylesheets without nodes (constructable stylesheets)
<emilio> ... so we'd need to decide what it does
<heycam> emilio: it could also do nothing. just not match.
<heycam> fremy: this is in @scope
<heycam> emilio: so it would always match
<heycam> emilio: is <style scoped> really not possible?
<heycam> ... layers have the same issue
<heycam> ... you use layers
<heycam> miriam: if we get the media attribute extended to support supports(), then the media attribute can fail, and stop the style sheet from being applied
<heycam> ... you could use that along with the new attribute
<heycam> ... that's the proposal for layers and scope attributes
<heycam> emilio: I don't think any engine keeps around the DOM node deep enough, it could be done
<heycam> miriam: it has a bit less flexibility than what Tab was suggesting, where you could still apply a lower boundary
<heycam> ... while letting the upper boundary be applied by the position of the style sheet
<heycam> ... since lower boundaries is a bit part of what scoping provides, that might be a reason to go with the change to the @scope rule
<heycam> emilio: if I had to choose between :stylesheet and @scope, I'd go for @scope
<heycam> chrishtr: for the bottom or the top of the scope?
<emilio> miriam: the top, if you use no selector it'd use the parent of the <style> / <style> element as the scope root
<emilio> fantasai: if your <link> is in your <head> it doesn't accomplish very much
<emilio> chrishtr: what about constructable stylesheets?
<fantasai> s/it does/the stylesheet does/
<emilio> heycam: you need to define it but I think it logically shouldn't scope to anything
<emilio> chrishtr: could you add a `scope` property to the stylesheet to be able to scope a constructable stylesheet?
<emilio> heycam: yeah that should be doable
<dbaron> (leaving meeting now, probably back around 5pm)
<emilio> miriam: do we want links in <head> to also style the whole doc?
<emilio> fantasai: I don't think you want to do that, it'd just end up not styling anything
<fantasai> s/anything/much of anything/
<emilio> RESOLVED: @scope without selector scopes to the parent of the owner node, or the containing tree if there's no owner node

@mirisuzanne mirisuzanne moved this from In progress to Needs Edits in Cascade 6 (Scope) Sep 21, 2022
dfabulich added a commit to dfabulich/css-sandbox that referenced this issue Oct 3, 2022
dfabulich added a commit to dfabulich/css-sandbox that referenced this issue Oct 3, 2022
dfabulich added a commit to dfabulich/css-sandbox that referenced this issue Oct 3, 2022
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 13, 2023
This CL makes it possible to specify a @scope rule without any
prelude, scoping the rules implicitly to the parent of the owner node.

This is implemented by storing a StyleSheetContents in each StyleScope,
and treating each owner-parent-node of the StyleSheetContents as a
scoping root.

The following likely doesn't work, and is postponed for future CLs:

 - Constructed stylesheets
 - An owner node whose parent node is a ShadowRoot

w3c/csswg-drafts#7349

Bug: 1379844
Change-Id: Icbfae88636662e9a16dd11f9c7a371c997447f60
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 16, 2023
This CL makes it possible to specify a @scope rule without any
prelude, scoping the rules implicitly to the parent of the owner node.

This is implemented by storing a StyleSheetContents in each StyleScope,
and treating each owner-parent-node of the StyleSheetContents as a
scoping root.

The following likely doesn't work, and is postponed for future CLs:

 - Constructed stylesheets
 - An owner node whose parent node is a ShadowRoot

w3c/csswg-drafts#7349

Bug: 1379844
Change-Id: Icbfae88636662e9a16dd11f9c7a371c997447f60
aarongable pushed a commit to chromium/chromium that referenced this issue Jan 16, 2023
This CL makes it possible to specify a @scope rule without any
prelude, scoping the rules implicitly to the parent of the owner node.

This is implemented by storing a StyleSheetContents in each StyleScope,
and treating each owner-parent-node of the StyleSheetContents as a
scoping root.

The following likely doesn't work, and is postponed for future CLs:

 - Constructed stylesheets
 - An owner node whose parent node is a ShadowRoot

w3c/csswg-drafts#7349

Bug: 1379844
Change-Id: Icbfae88636662e9a16dd11f9c7a371c997447f60
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4161741
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1093015}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 16, 2023
This CL makes it possible to specify a @scope rule without any
prelude, scoping the rules implicitly to the parent of the owner node.

This is implemented by storing a StyleSheetContents in each StyleScope,
and treating each owner-parent-node of the StyleSheetContents as a
scoping root.

The following likely doesn't work, and is postponed for future CLs:

 - Constructed stylesheets
 - An owner node whose parent node is a ShadowRoot

w3c/csswg-drafts#7349

Bug: 1379844
Change-Id: Icbfae88636662e9a16dd11f9c7a371c997447f60
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4161741
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1093015}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 16, 2023
This CL makes it possible to specify a @scope rule without any
prelude, scoping the rules implicitly to the parent of the owner node.

This is implemented by storing a StyleSheetContents in each StyleScope,
and treating each owner-parent-node of the StyleSheetContents as a
scoping root.

The following likely doesn't work, and is postponed for future CLs:

 - Constructed stylesheets
 - An owner node whose parent node is a ShadowRoot

w3c/csswg-drafts#7349

Bug: 1379844
Change-Id: Icbfae88636662e9a16dd11f9c7a371c997447f60
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4161741
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1093015}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jan 19, 2023
… a=testonly

Automatic update from web-platform-tests
[@scope] Support implicit scoping roots

This CL makes it possible to specify a @scope rule without any
prelude, scoping the rules implicitly to the parent of the owner node.

This is implemented by storing a StyleSheetContents in each StyleScope,
and treating each owner-parent-node of the StyleSheetContents as a
scoping root.

The following likely doesn't work, and is postponed for future CLs:

 - Constructed stylesheets
 - An owner node whose parent node is a ShadowRoot

w3c/csswg-drafts#7349

Bug: 1379844
Change-Id: Icbfae88636662e9a16dd11f9c7a371c997447f60
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4161741
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1093015}

--

wpt-commits: 88acd4d4af38934ec6f035cb214c51aeb5b346d5
wpt-pr: 37926
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Jan 20, 2023
… a=testonly

Automatic update from web-platform-tests
[@scope] Support implicit scoping roots

This CL makes it possible to specify a @scope rule without any
prelude, scoping the rules implicitly to the parent of the owner node.

This is implemented by storing a StyleSheetContents in each StyleScope,
and treating each owner-parent-node of the StyleSheetContents as a
scoping root.

The following likely doesn't work, and is postponed for future CLs:

 - Constructed stylesheets
 - An owner node whose parent node is a ShadowRoot

w3c/csswg-drafts#7349

Bug: 1379844
Change-Id: Icbfae88636662e9a16dd11f9c7a371c997447f60
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4161741
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1093015}

--

wpt-commits: 88acd4d4af38934ec6f035cb214c51aeb5b346d5
wpt-pr: 37926
@mirisuzanne mirisuzanne moved this from Needs Edits to Done in Cascade 6 (Scope) Feb 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

5 participants