[css-values] String parsing function (replaces multi-value attr())

[AmeliaBR]

With the discussion in #542 about converting non-string variables to string, it's worth discussing the reverse: a parser function that can take a string and parse it according to a specified CSS grammar.

Such a function could replace the multi-value attr() function that was supposed to allow authors to extract typed values from attributes. The type-aware attr() function is not supported in any current web browsers; I'm not sure if it has support in other CSS environments.

At the same time, a general parsing function could be used with CSS variables, or with strings generated by combining variables with the new concatenation function in ways that require re-tokenization.

Suggested syntax:

<parse-function> = parse(<string> <syntax-string> / <fallback-value>);

It would use syntax strings as defined in the Properties and Values API instead of the custom keywords in the current attr() definition.

Examples:

.icon {
  content: parse(attr(href) "<image>" / url("fallback.png"));
  width: parse( concat(attr(data-width), var(--icon-unit)) "<length>" / 1em);
}

[ExE-Boss]

We’d still probably need a fallback argument for attr(…) though.

[tabatkins]

Other than implementing the attr()-with-type functionality, what other use-case would there be for this? We can't work around "browsers aren't implementing X" by creating a Y that's identical to X.

Notably, both of your example are just exactly attr()-with-type, except attr() is easier to read:

.icon {
  content: attr(href image, url("fallback.png"));
  width: attr(data-width var(--icon-unit), 1em);
}

[AmeliaBR]

Yeah, I guess I don't have a lot of other good use cases. Being able to concat together a unit value and a number value and then parse them as a length would be another case, but it can be solved by the calc(var(--num) * var(--unit)) approach.

The only other time where I see people complain about the difference between strings and numbers is for counter(). Getting a counter-val() function, as requested in #1026, in combination with a concat/format function for printing numbers in content would take care of those issues.

Mostly, this issue was because I didn't understand why the full attr() hadn't been implemented. I guess I'd assumed it was a problem with the type parsing syntax being too vague, rather than an objection to having properties other than content depend on element attributes.