Any finite number — quantities you measure, named for what it is rather than what it looks like.
On a text face, stepping follows the place under the caret — 24.5|3 ↑ → 24.63; unfocused, it steps by the smallest place. The ▴▾ obey the caret and never steal it:
Fractional numbers: a number with no whole-number constraint — the
Number family's base variant. Measurements, ratings,
rates, weights, coordinates.
Named for what it is, not for what it looks like. decimal is a
precision type in most systems — SQL's DECIMAL, C#'s decimal,
Python's decimal.Decimal — and in every one of them it is the type you
reach for when money must be exact. This is not that. This is an
IEEE-754 double, and calling it Decimal would promise the one property
it does not have.
Any finite number, fractional part included. There is nothing to declare
— a number field is decimal-capable until an
integer rule says otherwise — and min/max still
bound it where a range is real (a rating of 1–5, a percentage of 0–100).
| Label | Rating |
| Key | rating |
| Data type | number |
| Editor | text_input |
| Validation | min: 0, max: 5 |
<p><%= cms.asset.content.rating.toFixed(1) %> / 5</p>
Formatting is the template's job, and decimals almost always need it:
the stored value is 4.5 or 4.5000000001, and how many places a
reader sees is a presentation decision. Deciding it at the print site
is right; storing a pre-formatted string is not.
{ "content": { "rating": 4.5 } }
0.1 + 0.2 is famously not 0.3, and the error compounds across a sum.
Harmless for a rating; dangerous for money — which is why prices belong
in integer cents. The rule of thumb: floats are for
quantities you measure, integers for quantities you count —
including counting cents.
If exact decimal arithmetic ever earns its place here, it is a new data type with its own storage, not a rule on this one. That is the data type vs editor line doing its job: a promise about the value is never a setting.