U10.01.3A nonzero baseline is an error under length encodingdesign

A bar chart's length only means what readers think it means when its baseline sits at zero

Aliases: length encoding · zero baseline rule

What it is

Bar charts, column charts, and area charts encode by length (or area), and readers decode them by "length is proportional to value." For that decoding to hold, the graphic has a mathematical precondition: length must be measured from value zero. Bars on a nonzero-origin axis (plotting 95-105 on an axis starting at 90) violate the precondition—bar heights are no longer proportional to values, and the graphic turns from a faithful mapping of the data into a distorted projection. This rule is not an aesthetic preference but a mathematical requirement of the encoding channel; for length-encoded charts, a nonzero baseline is therefore not "a suboptimal choice" but "the wrong chart."

Why it happens

The error's mathematical root is the intercept problem of linear mapping: length encoding promises height = k × value (k a constant), which requires height = 0 when value = 0. A truncated axis actually renders height = k × (value − baseline), and when baseline ≠ 0 the two mappings diverge entirely—readers decode by the former while the graphic draws the latter, so decoding systematically departs from the data. This also explains why the same truncation is acceptable under position encoding (dots, lines): position encoding promises only a monotonic mapping position = f(value), from which readers extract relative position and direction, not proportions—a nonzero origin merely shifts the readable window without proportional distortion. Distinguishing the two encodings is the key to judging "is truncation legal": the same 95-105 data as bars is wrong (length distortion), but as a dot plot with a zero reference line it is right (position fidelity). The common defense "bars are too short to see" deserves the correct reply: not truncating the bars (creating length distortion) but changing the encoding channel (dot plots, lines) or adding precise numeric labels.

Where it stops holding

The zero-baseline rule applies to quantities with a natural zero (counts, money, ratios); for quantities where zero is meaningless (Celsius temperature, exam scores), no natural origin exists, absolute bar heights no longer correspond to physical ratios, and the problem is that bar charts are the wrong chart type at all—not a matter of baseline choice. Cumulative quantities (time, distance) and their differences (duration changes) can also demand different baselines—charting "today's temperature minus yesterday's" should use bars starting at zero (differences start at zero), not at the temperature values. The legitimate alternatives to truncation (dot plots, tables, annotated axis breaks) each cost something, but all are more honest than length distortion. The rule's enforcement boundary is automation: most chart libraries will happily render nonzero-baseline bars, so the rule must be guarded by team review processes rather than tool defaults.

Applying it

  • Fix the y-axis (or radial axis) of every bar, column, and area chart to start at zero; lock this default at the chart-template level.
  • When narrow data ranges make bars look flat, switch to position encoding (dot or line charts) or add precise value labels—never truncate length encoding.
  • Add a "zero baseline for length encoding" item to the review checklist; any nonzero-baseline bar chart goes back.
  • Verification: audit all bar/column/area charts in your outputs for axis origins; any nonzero origin without an encoding switch is a violation instance.

Related

  • Same group: U10.01.1 Truncated axes exaggerate differences · U10.01.2 Stretching the aspect ratio changes the impression of trends
  • Nearby: U2.02.2 Baselines must start at zero · U10.01.1 Truncated axes exaggerate differences
  • Search terms: length encoding · zero baseline · bar chart rules

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/U10.01.3