[css-values-5] Can ident() bypass dashed-ident requirements?

[andruud]

Some properties require <dashed-idents>, for example scroll-timeline-name. So e.g. scroll-timeline-name:nondash would be invalid at parse-time. However, with the ident() function, we'll no longer be able to reject those values parse-time: scroll-timeline-name:ident(var(--maybe-dashes-maybe-not) "mytimeline").

I guess we have two choices:

• Allow ident() to bypass the dashed requirement, making scroll-timeline-name:ident(timeline) actually a define a timeline named timeline. (In order for the timeline to be reachable, the name would have to be "escaped" with ident() on the animation-timeline side as well).
• Enforce the dashed requirement computed value time instead.

[andruud]

I suppose this issue should be generalized to any custom ident restriction. E.g. not isn't a valid container name. Can ident() bypass this?

[tabatkins]

I don't think it should allow bypassing; we have those restrictions for a reason. And I think enforcing it at parse time, when possible, is still useful.

I guess we should just define that <custom-ident> also checks its computed value for whatever restrictions are applied (disallowed keywords, required dash prefix, etc), and makes its property IACVT if that fails.

[andruud]

we have those restrictions for a reason

The reason (ambiguity with keywords) isn't an issue with ident(), though. Are there other reasons?

[tabatkins]

Hm, that is true, ident() is specified to only return a <custom-ident>, so I suppose there's no ambiguity. 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.

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?

[andruud]

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.

[tabatkins]

This works until we spec a regular function that returns a string/ident that can't be known at parse-time:

We already have that - counter() can take a counter style, which can produce arbitrary strings.

So yeah, we do need to worry about this even ignoring arb-sub functions.