[css-conditional] Nested at-rules within at-rule()

w3c / csswg-drafts

CSS Working Group Editor Drafts

https://drafts.csswg.org/

Other

4.51k stars 669 forks source link

[css-conditional] Nested at-rules within at-rule() #11117

Open andruud opened 2 weeks ago

andruud commented 2 weeks ago

Some at-rules are only valid within a certain other at-rule, e.g. margin rules within @page, or @swash (etc) within @font-feature-values.

So, how do these evaluate?

@supports at-rule(@swash) {}
@supports at-rule(@top-left) {}

It seems unwise to just ignore context, since a given @foo may be specified to exist in more than one context, with different meanings (and possibly different descriptors being valid).

This was discussed during https://github.com/w3c/csswg-drafts/issues/2463, but I don't see a conclusion.

bramus commented 2 weeks ago

In https://github.com/w3c/csswg-drafts/issues/6966#issuecomment-2339051165 I suggested to allow authors to either test for an at-rule’s name or an actual full at-rule.

That would allow the following:

@supports at-rule(@page { @top-left { ... }}) {
  …
}

… which I believe fixes this issue.

cdoublev commented 2 weeks ago

@supports ( <ident> | [<at-keyword-token>#? , [<ident> | <declaration]?]! ) { ... }?

For example, @supports (@page, @top-left), @supports(@page, size), @supports (@page, size: var(--custom)), etc.

I have not read all related discussions so I do not know the motivations for using at-rule, and that might not always be enough to fully define the context. But mirroring CSS.supports() seems nice.

bramus commented 2 weeks ago

I have not read all related discussions so I do not know the motivations for using at-rule, and that might not always be enough to fully define the context. But mirroring CSS.supports() seems nice.

Motivation: Feature detect support for certain at-rules. See https://brm.us/at-rule for an intro.
Mirroring CSS.supports: That is already the case. Doing @supports at-rule(@starting-style) in CSS is equivalent to CSS.supports('at-rule(@starting-style)') in JS — this is similar to selector() feature detection.

cdoublev commented 2 weeks ago

Exact, I had CSS.supports(<declaration>) in mind whereas it takes <supports-condition>.

I already read your article before and forget about selector() and font-tech(), so now at-rule() makes sense.

Single argument blocks/functions is probably easier for authors, even if it means feeding a whole rule to define a nesting context.

SebastianZ commented 2 weeks ago

In #6966 (comment) I suggested to allow authors to either test for an at-rule’s name or an actual full at-rule.

For what it's worth, allowing to test a full at-rule's syntax is also what I suggested earlier and mentioned again in the discussion in #2463. This allows testing nested rules as well as at-rules only consisting of preludes.

The main counter-argument back then was that it's verbose. Though like @bramus I believe it makes sense to allow both testing for the full rule and offer a simpler way. Allowing to test for the full syntax ensures that every feature of at-rules can be tested for. In addition to that we can provide short forms to test them.

Sebastian