[css-values-5] Normalized attr() substitution value

[andruud]

What do you get if you serialize the computed value of --x here?

<div data-x="calc(1px + 2px)">

div { --x: attr(data-x length); }

I think we expect eager simplification (3px), and generally we may need something like the equivalent token sequence (but for non-computed values)?

[andruud]

OK, I now see the attribute value needs to be a single token (surprising), which means the example in the first post was bad.

In that case, what about:

<div data-x="10.000px">

div { --x: attr(data-x length); }

Does this serialize as 10px or 10.000px?

[andruud]

Agenda+ on behalf of @tursunova.

[tabatkins]

IIRC, the "single token" thing was written in back in the day to simplify implementation; for whatever reason, impls didn't want to invoke their full CSS parser on attribute values. (Similarly, the color type is restricted to just hex colors and color name keywords.)

I suspect that whatever reasons impls had for avoiding that at the time are probably less pressing now, and we should just invoke the CSS parser normally? We invoke the CSS parser for a few other HTML attributes already anyway, like <meta name=color-scheme> or <img srcset>

[astearns]

@tabatkins @tursunova could this be an async resolution?

[andruud]

Right, the point about "single token" is now moot with the new <syntax>-based spec.

Now that attr() and registered custom properties share a type system, it seems fairly obvious that we should keep the substitution behavior as consistent as possible between those features. For example, we don't want --reg-length: 10.00px to substitute as 10px while attr(myattr type(<length>)) (given myattr="10.00px") substitutes as 10.00px.

I suggest that we rephrase equivalent token sequence to be about "values" instead of specifically "computed values", and then we spec attr() to substitute as that. (Sidenote: attr(myattr type(*)) would substitute as the original string, however, since that's how "untyped" values serialize; see 4.1. Serializing Custom Properties).

---

We could indeed try this as an async resolution:

Proposed: attr() substitutes as the equivalent token sequence, and that definition is adjusted to accommodate non-computed values

[astearns]

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: attr() substitutes as the equivalent token sequence, and that definition is adjusted to accommodate non-computed values