Is <attr-unit> parse-time behavior intentional?

[emilio]

Per spec, getting a wrong <attr-unit> causes the whole declaration to be invalid:

div {
  width: 100px;
  height: attr(foo cool-new-unit, 100px);
}

That's probably fine but is it intentional?

It feels a bit weird that attr(foo cool-new-unit, fallback) wouldn't use the fallback (or trigger IACVT).

I could see arguments the other way around I guess? But feels a bit like env(something-random) to me, which does trigger fallback / doesn't validate the identifier.

cc @dshin-moz @tabatkins @andruud

[tabatkins]

I could see it going either way, but I do lean slightly towards the current behavior of making things invalid; putting the number in an attribute and using attr(foo cool-unit) to reference it then acts identically to just putting 2cool-unit in. Fallback is, generally, meant to handle dynamic failures that can't be predicted ahead of time.

[emilio]

@tabatkins You could make the same argument with env(unknown-variable) tho, right? And IIRC we resolved the other way around for it... Do you happen to recall why? (I'd have to do the digging, talking from memory)

[andruud]

I agree attr(foo cool-new-unit, fallback) seems quite similar to env(cool-new-env, fallback).

Note: both env() and units can be author-defined (in the future):

• https://drafts.csswg.org/css-link-params/#using (env())
• https://drafts.csswg.org/css-variables-2/#variable-units (units)

Obviously, env(--unknown-env, fallback) should take the fallback, so probably attr(foo --unknown-unit, fallback) should take the fallback too. At that point, attr(foo unknown-unit, fallback) not taking the fallback starts to look inconsistent.

[SebastianZ]

Strong +1 to what @andruud wrote. In any case, we should stay consistent between those two functions.
See also #4482, which seems related.

Sebastian