Examples citing CSS.px API are incorrect

[rwaldron]

The explainer prose in CSS Typed Object Model, which references Numeric Factory Functions ignores that CSS.px (and friends) don't actually accept an object argument.

// For the sake of playing along with this proposal's syntax, alias "px" to "_px"
let { px: _px } = CSS;

document.body.style.fontSize = 3_px;

According to this proposal's semantics, 3_px desugars to _px(Object.freeze({number: 3, string: "3"})), but _px (CSS.px) doesn't know what to do with Object.freeze({number: 3, string: "3"}), because it's expecting a number, ie. 3. As a result of this misrepresentation, the given example doesn't represent an actual use case burden to be eased by this proposal.

[littledan]

Good point. This explainer is in terms of potential things that CSS could expose, based on general input from @tabatkins, but with my own interpretation. Tab, since this isn't what CSS.px ended up doing, do you have a different idea for a fully realistic example?

[rwaldron]

This explainer is in terms of potential things that CSS could expose,

Then it doesn't represent the easing of an actual developer burden, or a measurable improvement to any existing practice. I think that practitioners would prefer if the language worked towards improving the existing landscape, instead of padding proposals with hypothetical future APIs.

[littledan]

This is a response to a feature request from a leader of the CSSWG, @tabatkins. I think he could give you some more context here about the motivation with respect to CSS, but I was largely going from his blog posts in https://www.xanthir.com/b4UD0 and conversations with him that branched off from that.

[tabatkins]

There's no reason for CSS.px() to, today, take an object of that form; it would be a somewhat ridiculous thing to pass to the function by hand. That doesn't mean we can't add such an argument pattern in the future, which we would do if that's what this proposal ends up passing to the constructor.

(I was originally assuming that it would just pass the numeric argument to the function, in which case it works automatically; the fact that it needs to pass a more complex argument to accommodate use-cases like BigInt is fine, it just means we'll need to extend the CSS side of the API in the future.)

So it should still be considered to be easing a developer burden; 3_px is still easier to type than CSS.px(3).

(Possibly more likely would be us exposing a set of CSS._foo methods that are identical to the CSS.foo ones, except that they instead expect an appropriately-shaped object per this proposal. Then you can extract them with let {_px, _em} = CSS;, no remapping required.)