Facets and Multiple Views

Facets repeat one encoding across groups. Multiple-view compositions place different but related encodings together. Both reduce the amount of data one plot must carry, but they answer different questions.

Use facets when every panel has the same role. Use distinct linked views when one panel provides context, a marginal distribution, controls, or detail for another.

Choose the layout#

Faceting and Composition owns the implementation boundary. This page helps choose a layout and verify its comparison semantics.

Repeat one encoding by group#

Faceted distributions give each cohort its own panel while preserving a common binning and positional scale. The reader can compare both local shape and absolute position without decoding overlapping fills.

Use shared domains when position should be directly comparable. Independent domains can make local variation easier to see, but they can also exaggerate small differences. If independent scales are intentional, give panels their own guides and state the policy.

Prepare reductions independently within each facet. A proportional histogram, for example, divides by the cohort's count rather than a global count unless the global population is the intended denominator.

Add marginal context#

A scatterplot with marginal histograms combines three roles:

• The central plot shows the joint relationship.
• The top histogram shows the x distribution.
• The side histogram shows the y distribution.

All regions can derive from the same raw observations, but they do not share the same marks or plot rectangle. Keep their domains coordinated and their accessibility labels distinct.

Several chart hosts are usually simpler and more accessible. Use one custom scene with embedded regions only when exact responsive alignment materially improves the product. Custom Marks and Renderers covers that advanced boundary.

Pair detail with context#

A focus-plus-context layout uses a compact overview to control the explicit domain of a larger detail chart. The selection is semantic application state, not a rectangle stored inside one renderer.

The overview should retain the complete domain. The detail should receive the selected start and end as its configured scale domain. Pointer, touch, and keyboard controls should update the same semantic values, and those values should survive data revisions and resizes.

See Interactions and Selections for controlled brushes, zoom, and linked state.

Coordinate views by values, not pixels#

Shared selection, cursor, category, or domain state belongs in the application:

1. A view emits a semantic value through focus, selection, or a controlled gesture.
2. Application state validates and stores that value.
3. Each view derives its own input and configured scales.
4. Each chart compiles a new scene through its normal update path.

Do not query one SVG for a pixel and apply that pixel directly to another view. Different margins, widths, orientations, and scales can represent the same semantic value at different coordinates.

Production checks#

• Use one repeated encoding for true facets; use named views when roles differ.
• Make shared versus independent domains explicit.
• Keep bin boundaries, group order, color meaning, and units comparable.
• Give each independently interactive view its own accessible label.
• Preserve selection and viewport state across data and size updates.
• Avoid duplicating a full axis on every panel when shared outer guides are accurate.
• Verify panel order at narrow widths in Responsive Charts.
• Provide a table or textual summary when exact cross-panel comparison matters.

For the underlying row and channel model, see Data and Channels.