Re: [csswg-drafts] [css-values] specification for calc() should be clearer about when the result has a percentage (#10017)

Unit division is actually well-defined, by reference to [Typed OM's concept of "matching"](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-match). Something matches `<length>`/etc only if it has `{length -> 1}` *and* its percent hint is null. I suppose technically it's only by implication that a non-null percent hint means it contains a percentage, tho, so we could probably put in a definition for that.

In-flight edit: actually it looks like I am invoking the types wrong for cases like min(); there I just say the args must have "the same type" and define that the function resolves to that type. This doesn't handle percent hints properly. I'll need to tweak it.

---------

sign() does indeed currently erase the percentage information, tho, as does anything that returns a value of a different type than its input calculations. We should think about whether it *should* transfer that information thru - doing so via the calculation type (copying the percent hint of the input calculation) would mean it doesn't match `<number>` anymore.

----------

The progress() family just need to define their type as the sum of their input calculation's types, same as min()/etc. (Subject to the changes I just discovered I need to make.)

-------

calc-size() makes an end-run around the issue, since it defines that it simply acts like its basis argument in all ways.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10017#issuecomment-1971986204 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 29 February 2024 21:24:04 UTC