[css-typed-om] CalcLength isn't sufficient to represent css-values-4 calc()

[dbaron]

If I'm understanding https://drafts.css-houdini.org/css-typed-om/#lengthvalue-objects correctly (which is definitely far from certain, since there's no prose at all to explain the interfaces), I don't think CalcValue is sufficient to explain what the current spec for calc() allows in calc().

It is sufficient to explain what the original calc() proposal in css-values-3 can do, since any length calc() expression in the original proposal can be simplified to Aem + Bpx + Crem + ....

However, in https://lists.w3.org/Archives/Public/www-style/2014Apr/0373.html we resolved to extend calc() beyond that proposal (no editor's draft yet) in a way that cannot be represented by what I interpret this API to be.

[shans]

I think probably the best idea here is to allow CalcLengths (or another LengthValue subclass) to represent extended calc expressions by including a list of custom value/unit pairs.

e.g. { px: 5, percent: 20, artisanal_units: [["em.px/percent", 4.2], ["px.percent/rem", 37]]}

For now we'll use UnsupportedStyleValue.

[shans]

We decided to defer custom value/unit pairs until level 2. UnsupportedStyleValue is enough for now.

[tabatkins]

Yeah, def defer until/unless V&U updates to allow extended calc().

(Note, tho, that a list of values with complex units isn't enough - calc(1px / (2em + 3%)) can't be simplified into that. The best we can do with terms like that is to simplify them into inverses, of the form "1 / (list of complex-unit values)". So we'd need to give CalcLength both a list of complex units, and a list of inverses. Or just hang an AST off for all the stuff that can't be simplified, let authors handle it on their own. That's more complex, but it's unified for all complex cases, rather than having two approaches.)