When a token build converts one source size into web and native outputs, what unit conversions happen, and where can information be lost?
answer
- same size at every screen density
- text sizes that follow the user
- no relative unit on the target
- a default text size is assumed
- color gamut and line height too
basics
~20 sIdealised-pixel sizes map to each platform's density-independent unit, and text-relative sizes map to scalable text units. Where a platform lacks a text-relative unit, the build assumes a default text size, and the output stops following the user's text setting.
solid answer
~50 sThe Design Tokens Community Group draft stores lengths in one of two units: an **idealised pixel** and a **multiple of the default text size**. The build maps the idealised pixel to each native platform's density-independent unit, so a 16 looks the same physical size on every screen density. It maps text-relative sizes to units that follow the user's text-size setting where the platform has one. Where it does not, the draft says the tool may need a **lossy** conversion to a fixed size by assuming a default, usually 16; the output then stops growing with the user's setting, which can undermine the text resizing that WCAG 2.2 criterion 1.4.4 Resize Text expects. Other conversions carry similar traps: durations between milliseconds and seconds, colors into each platform's color representation and gamut, and a unitless line height into whatever form the platform wants.
go deeper
Recall that the same size token becomes a different unit on each platform, and that the aim is the same apparent size everywhere.
Explain both source units, their native equivalents, and why converting a text-relative size to a fixed one is lossy and hurts text resizing.
Show how you would detect and prevent silent lossy conversions with snapshot tests, logged exceptions and routing text sizes to each platform's scaling mechanism.
Weigh platform-idiomatic outputs, which honour each platform's text scaling, against identical numbers everywhere, which are simpler but can fail users.
## Why conversion is needed A **token build** reads one source and writes outputs for the web, each native mobile platform and the design editor. The source expresses sizes, durations and colors in a neutral form; each platform needs its own. Conversion is where a single source can quietly stop meaning the same thing everywhere, so it deserves as much care as the values themselves. ## Lengths: two source units, several targets The Design Tokens Community Group draft allows a `dimension` value in exactly two units: - An **idealised pixel** - a device-independent measure, not a physical screen pixel. The draft says its equivalent on the native platforms is their density-independent unit (the density-independent pixel on one, the point on the other), and that translation tools should convert to such units. - A **multiple of the default text size**, which the user may be able to configure. On the web this scales with the user's text setting; the draft notes one native platform has an equivalent scalable text unit. | Source size | Web output | Native output | Risk | |---|---|---|---| | 16 idealised pixels | same measure | 16 density-independent units | little - same physical size | | 1 text-size multiple | text-relative unit | scalable text unit, where one exists | lossy where none exists | | 1 text-size multiple, no relative unit on the target | text-relative unit | fixed 16 of the density-independent unit | stops following the user's setting | ## The lossy case When a platform has no unit that follows the default text size, the draft says a translation tool may need a lossy conversion to a fixed size by assuming a default text size, usually 16. Three consequences follow: 1. **Accessibility.** A text size that no longer grows with the user's setting can undermine text resizing. WCAG 2.2 success criterion **1.4.4 Resize Text** (Level AA) expects text to be resizable up to 200 percent without loss of content or functionality, and native platforms carry comparable text-size settings of their own. 2. **Layout coupling.** Spacing expressed relative to text size was meant to grow with it; once fixed, tight row heights clip enlarged text. 3. **Hidden divergence.** The web and native outputs now behave differently for the same token, and nothing in the value shows it. The mitigation is to route text sizes to whatever mechanism each native platform uses to honour the user's setting, even where that is a named text style rather than a unit, and to make any lossy conversion a deliberate, documented exception. ## Other conversions with traps - **Durations** move between milliseconds and seconds; a factor-of-1000 slip turns a 200 millisecond transition into a 200 second one. - **Colors** move from the source's color-space components to each platform's color representation, with alpha. A wide-gamut color is clipped or mapped when an output is limited to the standard gamut, so two platforms may render it differently. - **Line height** is a unitless multiplier in the draft's typography type; some platforms want a multiplier, others an absolute height or extra spacing, which the build must compute from the font size. - **Easing curves** become each platform's curve representation; the four control-point numbers must stay in order. ## Rules that keep outputs honest - Convert at build time, once, with the conversion table documented. - Snapshot-test representative tokens per output, so a changed transform shows up as a reviewed diff. - Flag lossy conversions in the build log instead of performing them silently. - Round consistently, and only in the last step. ## An accounting example A small-business accounting product shows ledger tables on the web and in two mobile apps. The ledger's body text is a text-relative token and its row height is also expressed relative to text size. On one platform the build fell back to a fixed size, so bookkeepers who enlarged their text saw it grow in some screens and not the ledger, and on the web the amounts overflowed rows that had been fixed by hand. Mapping the text tokens to each platform's scalable text mechanism and deriving row height from them removed both defects.
- Why does a token build convert an idealised-pixel size to a density-independent unit instead of to physical pixels?Screens differ in pixel density, so a fixed number of physical pixels is a different physical size on each device. The density-independent unit is scaled by the platform so 16 looks the same size everywhere, which is what the idealised pixel in the source means. Converting to physical pixels would shrink the interface on dense screens.
- How would you catch a token build that silently changed a conversion?Snapshot-test a representative set of tokens for every output - a text size, a spacing step, a duration, a wide-gamut color - and require review when a snapshot changes. Have the build log every lossy conversion it performs. Together these turn a quiet regression into a visible, reviewable diff.
saying these in an interview costs you the question
- An idealised pixel should be converted to physical screen pixels.
- Converting a text-relative size to a fixed size loses nothing.
- Every platform has a unit that follows the user's text setting.
- Line height can be copied to every platform without conversion.
- Unit conversion is best done by hand in each app.