[css-values-5] Invalidation of ident()

[bramus]

This is a follow-up to #9141 which introduces ident(). Something that is not defined yet is what should happen when the input for ident() is invalid.

E.g. what happens if you do the following:

@property --length {
  syntax: "<length>";
  inherits: false;
  initial-value: 0px;
}

.target {
  --length: 120px;
  anchor-name: ident("--anchor-" var(--length));
}

Because --length is a <length>, ident() can’t generate a valid <custom-ident>. I assume that in this case the declaration should become Invalid At Computed Value Time (IACVT) and the value should be considered to be unset.

However, we might also consider adding an extra argument to ident(), to allow a fallback value in case the constructed value is not a valid <custom-ident>.

The definition for ident() would then become the following:

<ident-fn> = ident(<ident-arg>+, <declaration-value>?);
<ident-arg> = <string> | <integer> | <ident>

I prefer this last version, as ident() then behaves similar to var() and attr(): when the input cannot be parsed into a <custom-ident> (or is the guaranteed invalid value) then the fallback value is used.

[LeaVerou]

Yup, a fallback would be great, and the declaration is just invalid if no fallback is provided. I don't think IACVT needs to be explicitly mentioned here: just like any other function, it can be invalid at parse time if the arguments are known at parse time (e.g. ident(foo 12px).

Just let's make sure that we don't accidentally make things invalid that don't need to be. E.g. people should be able to use an integer <number> in there without having to explicitly get it through round().

[bramus]

Just let's make sure that we don't accidentally make things invalid that don't need to be. E.g. people should be able to use an integer <number> in there without having to explicitly get it through round().

That is/was discussed in #11551

[tabatkins]

Something that is not defined yet is what should happen when the input for ident() is invalid.

Nope, that's perfectly defined already - the function is invalid because it doesn't match the specified grammar. (And because that happens due to var() substitution, it's IACVT rather than a parse failure.)

I don't think we really need a fallback here. In general, CSS functions don't guard against the possibility of some argument being invalid from a nonsense var() substitution. I'm not seeing anything special about ident() that would make it more necessary to add special handling.

[LeaVerou]

Fair, one can always do a fallback with a separate variable:

--name: ident(--color- var(--color));
background: var(var(--name, --color-blue));

That said…

In general, CSS functions don't guard against the possibility of some argument being invalid from a nonsense var() substitution. I'm not seeing anything special about ident() that would make it more necessary to add special handling.

I've often needed fallbacks for calc(), so this may not be such a bad idea. But shouldn't be a blocker for ident().

[bramus]

In general, CSS functions don't guard against the possibility of some argument being invalid from a nonsense var() substitution.

attr() has something like that built in, no? attr(id type(<color>), blue) will fall back to blue if it turns out that the id attribute cannot be parsed into a <color>.

Fair, one can always do a fallback with a separate variable:

--name: ident(--color- var(--color));
background: var(var(--name, --color-blue));

I must say that the equivalent below is much easier to read (I also added the ", knowing they are not really necessary):

--color: red;
background: ident("--color-" var(--color), --color-blue);

You could also write the following, but that only holds up when the fallback starts with the same prefix

--color: red;
background: ident("--color-" var(--color, blue));

--color: red;
background: ident("--color-" var(--color), --default-bg-color);