Re: [csswg-drafts] [css-values-5] Can ident() bypass dashed-ident requirements? (#12206)

> Weird that it requires us to detect a troublesome custom ident and serialize it back out with an `ident()` wrapper, tho, especially since "troublesome" varies by usage site. I suspect we'd screw that up and end up generating serializations that don't round-trip.

Yeah, that's indeed an issue. We get roughly the same problem with the IACVT approach, since we need to figure out if an `ident()` produces something valid or not. I would expect the IACVT approach to be harder to do, but both should be possible.

> Stepping back, tho, your example is _already_ not parseable at parse time due to the use of `var()`; the `ident()` has nothing to do with this. A simple `scroll-timeline-name: var(--foo)` already troublesome. Are there any cases where we can trigger this "can't determine at parse time" that don't rely on an arbitrary-substitution function?

Riiight, so we could, for example, "mock"-evaluate the `ident()` at parse-time, using a placeholder value (`0`) for any integer part, and reject anything that doesn't meet the local requirements. That would make it possible to drop e.g. `scroll-timeline-name: ident(ident("myname" sibling-index()))`, since `myname0` doesn't start with dashes. `--myname:myname; scroll-timeline-name: ident(ident(var(--myname) sibling-index()))` would then automatically be IACVT by the mechanisms we already have.

This works until we spec a regular function that returns a string/ident that can't be known at parse-time: we won't be able to check that `container-name:ident(some-string())` doesn't yield `none`, for example.

-- 
GitHub Notification of comment by andruud
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12206#issuecomment-2903641299 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 23 May 2025 08:13:14 UTC