[css-cascade-6] Do we want to defer some or all of these scope extensions to level 7? · Issue #8628 · w3c/csswg-drafts (original) (raw)

Skip to content

Navigation Menu

• • GitHub Copilot Write better code with AI
  • GitHub Advanced Security Find and fix vulnerabilities
  • Actions Automate any workflow
  • Codespaces Instant dev environments
  • Issues Plan and track work
  • Code Review Manage code changes
  • Discussions Collaborate outside of code
  • Code Search Find more, search less
• Explore
  • Learning Pathways
  • Events & Webinars
  • Ebooks & Whitepapers
  • Customer Stories
  • Partners
  • Executive Insights
• • GitHub Sponsors Fund open source developers
  • The ReadME Project GitHub community articles
• • Enterprise platform AI-powered developer platform
• Pricing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Description

Two of the open issues related to @scope are related to defining extensions to the syntax:

• [cascade-6] Unclear proximity for scoped descendant combinator #8380 attempts to resolve complexity in 'scope proximity combinators' (>>/~~)
• [css-cascade-6] Handle sibling-proximity in @scope #7751 proposes an alternative 'sibling-scope' rule for generating DOM-horizontal scopes

Before we get into discussing and resolving on the details, I just want to note that neither is a core requirement for shipping the existing scope syntax. If we want to defer them to a future spec, the current scope rule can ship uninhibited. To consider each one at a time:

• The scope combinators are a syntax sugar over behavior that can already be achieved using @scope - but with the added complexity of resolving multiple subjects from a single selector. These may be worth pursuing, but it's not clear that there is a strong need for them - or that the 'semi-de-sugaring' solution proposed will make sense in practice. To me, these feel non-essential.
• The sibling-scope proposal has a stronger and more distinct use-case, but not an extremely common one. Since it would reflect the @scope rule more precisely, it may also be simpler to spec -- but not trivial.

I think both discussions are worth pursuing. I also think both could be deferred in order to ship the central functionality here.