the cell · v1.13.0
A cell holds a value. It can show a great deal more.
The same value can be coloured by where it sits in the data, drawn as a chart the width of the column, computed from a formula the grid parses rather than runs, and rendered in the reader's own language and reading direction. None of it changes the number underneath, so the sort, the filter and the totals are the ones they always were. This is the layer between the data and the eye.
conditional formatting
Rules that describe the data, not a threshold you guessed.
Most conditional formatting compares a cell to a number you typed, and a number you typed is out of date the moment the data moves. These rules read the distribution instead: the top decile, the values more than two deviations above the mean, the statistical outliers. The grid computes the boundary from the filtered rows, so the highlight follows the data as it changes rather than marking a line that used to matter. A colour scale can take its bounds the same way, spanning the fifth to the ninety-fifth percentile so one wild value cannot flatten every real one into the first swatch.
Rules from the data → Quantile colour scales → The formatting panel →
in-cell charts
A chart inside the cell, the width of the column.
A renderer draws a cell from its value rather than printing it. A sparkline turns a row's recent history into a line the width of the column, a progress or bullet bar reads the value against a target, a win-loss strip shows a run of results at a glance, and a gauge or a range reports where a number sits between its limits. Each is a real cell throughout, sorted and filtered on the number it draws, so a column of sparklines still orders by the last value or the trend. Fifteen renderers ship, and the gallery below is all of them at once.
The renderer gallery → Sparklines → Progress and bullet → Win-loss, gauge and range →
formulas
A formula language with no eval in it.
A column can be a formula a user types, = (price - cost) / price,
and the grid computes it for every row. The expression is parsed into a small typed tree and
walked, never handed to eval or the Function
constructor, so a spreadsheet a customer authored cannot reach the page around it. That is a
security answer as much as a feature: a formula is data, and it is treated as data. The same
engine backs the statistical functions and the computed columns you declare in code.
locales, and it mirrors
Eighteen locales, and the grid reads right to left.
Every string the grid renders comes from a message catalogue, so the whole interface translates. Numbers, currency and dates format through the reader's locale, down to the Arabic-Indic digits. And setting the direction to right-to-left mirrors the grid entire: the pinned column moves to the right, the columns run the other way, and the scroll follows. The grid below is one configuration and one set of rows in three locales; only the chrome and the formatting change, never the data.
Locales and RTL → Translating the grid → Locale collation → Screen reader →
The number never changes
A colour, a bar, a formula's result and a locale's digits are all presentation. The stored value stays what it was, so the sort, the filter, the totals and the export read the data, not the decoration on top of it.
Nothing runs your customer's text
A typed formula is parsed and walked, never evaluated as code. A spreadsheet a customer pastes cannot reach the page, because there is no interpreter to reach.
One grid, every reader
The catalogue translates the interface, the locale formats the numbers, and the direction mirrors the layout, from one configuration. The person in front of it reads it in their own language and their own direction.