- From: Sebastian Zartner via GitHub <noreply@w3.org>
- Date: Wed, 28 Jan 2026 08:09:40 +0000
- To: public-css-archive@w3.org
FWIW, another affected property would be [`view-transition-name`](https://drafts.csswg.org/css-view-transitions/#view-transition-name-prop), which excludes `none`, `auto`, and `match-element`. (We should really start enforcing the use of `<dashed-ident>` for all new user-defined names...) @Crissov: > I also thought about allowing more than just keywords in the exclusions list. I assume this syntax might already allow other values than keywords like `<integer -[ 1 | 2 | 3 ]>` or even `<number -[ <integer> ]>`. Though I wonder if there's a use case for that. @AtkinsSJ: > Could always spread this across multiple lines for readability. Eg, > > ``` > <custom-ident > ![ none | foo | bar | baz | something-long ] > > > ``` Spreading into multiple lines like this might be a solution to improve readability in those cases where you only have a single data type and nothing else. If you have multiple values, you probably want to push the data type with the exclusions into its own line. Though I'm with @tabatkins, that in most cases it's probably better for readability to introduce a new non-terminal data type. ----- So, it sounds like everyone is agreeing that this is a useful extension to the syntax, leaving us with syntax bikeshedding and the questions whether to expose this to authors (to which I strongly agree, even when it probably won't be used very often) and whether additional tagging is needed for webref. Adding this to the agenda. Sebastian -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11924#issuecomment-3809666630 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 January 2026 08:09:41 UTC