CSSNumericValue Type-aliases
Kobweb introduces a handful of type-aliases for CSS unit values, basing them off of the CSSNumericValue class and extending the set defined by Compose HTML. They are:
This section explains why they were added and why you should almost always prefer using them.
Background
CSSSizeValue
When you write CSS values like 10.px, 5.cssRem, 45.deg, or even 30.s into your code, you normally don't have to think too much about their types. You just create them and pass them into the appropriate Kobweb / Compose HTML APIs.
Let's discuss what is actually happening when you do this. Compose HTML provides a CSSSizeValue class which represents a number value and its unit.
This is a pretty elegant approach, but the types are verbose. This can be troublesome when writing code that needs to work with them:
Note also that the above cases are overly restrictive, only supporting a single length and angle type, respectively. We usually want to support all relevant types (e.g. px, em, cssRem, etc. for lengths; deg, rad, grad, and turn for angles). We can do this with the following out syntax:
What a mouthful!
As a result, the Compose HTML team added type-aliases for all these unit types, such as CSSLengthValue and CSSAngleValue. Now, you can write the above code like:
Much better! Seems great. No problems, right? Right?!
CSSNumericValue
You can probably tell by my tone: Yes problems.
To explain, we first need to talk about CSSNumericValue.
It is common to transform values in CSS using many of its various mathematical functions. Perhaps you want to take the sum of two different units (10.px + 5.cssRem) or call some other math function (clamp(1.cssRem, 3.vw)). These operations return intermediate values that cannot be directly queried like a CSSSizeValue can.
This is handled by the CSSNumericValue class, also defined by Compose HTML (and which is actually a base class of CSSSizeValue).
These numeric operations are of course useful to the browser, which can resolve them into absolute screen values, but for us in user space, they are opaque calculations.
In practice, however, that's fine! The limited view of these values does not matter because we rarely need to query them in our code. In almost all cases, we just take some numeric value, optionally tweak it by doing some more math on it, and then pass it onto the browser.
Because it is opaque, CSSNumericValue is far more flexible and widely applicable than CSSSizeValue is. If you are writing a function that takes a parameter, or declaring a StyleVariable tied to some length or time, you almost always want to use CSSNumericValue and not CSSSizeValue.
Prefer using Kobweb's CSSNumericValue type-aliases
As mentioned above, the Compose HTML team created their unit-related type-aliases against the CSSSizeValue class.
This decision makes it really easy to write code that works well when you test it with concrete size values but is actually more restrictive than you expected.
Kobweb ensures its APIs all reference its CSSNumericValue type-aliases:
If you are using style variables in your code or writing your own functions that take CSS units as arguments, you might be referencing the Compose HTML types. Your code will still work fine, but you are strongly encouraged to migrate them to Kobweb's newer set, in order to make your code more flexible about what it can accept:
Perhaps in the future, the Compose HTML team might consider updating their type-aliases to use the CSSNumericValue type and not the CSSSizeValue type. If that happens, we can revert our changes and delete this section. But until then, it's worth understanding why Kobweb introduces its own type-aliases and why you are encouraged to use them instead of the Compose HTML versions.