E3.13.1cascade child depends on parentdesign

Each next level’s options depend on the parent choice

Aliases: cascading select · dependent dropdown · province-city

What it is

A cascading select splits one choice into successive levels, each level’s candidates determined by the value already chosen above: province then city, category then model, department then member. Until the parent is decided, the child is empty, disabled, or absent. It is not a tree flattened into columns for multi-select, and not two ordinary selects that happen to sit in a row. Dependence is one-way: the child’s legal set is a function of the parent value.

Without dependence there is no cascade. Two independent selects side by side are just two fields.

Why it happens

Legal combinations along a full path are often sparse: not every province has every city name, not every category has every model. Tightening the set level by level avoids listing illegal combinations on one flat roster. People use the parent as a filter; the child’s cognitive load drops from “the world” to “under this parent.”

Dependence also orders time. A parent value must be given before the child exists. Opening the child first either shows a stale universe or a blank, both of which look like a broken widget. The parent’s label has to be understood before the child’s, or the order itself becomes a puzzle.

Where it stops holding

When siblings must be compared (policy differences among cities), a cascade locks the comparison objects under different parents and is the wrong structure. A multi-select tree allows ticks on several branches at once; a cascade usually keeps one value per level, one path. If the child does not actually depend on the parent (model and colour independent), cascading fabricates a constraint and makes some colours look unavailable under some models. Asynchronous loading does not cancel dependence, but it needs an in-progress state; leftover children from the previous parent must not show before the request returns.

Applying it

  • Cascade only when the child set is truly a function of the parent value; independent dimensions sit side by side, not in a fake chain.
  • Disable or hide the child until the parent is chosen, and let labels show the order (“choose province first”).
  • Replace the child’s roster after the parent changes; do not leave the previous parent’s names.
  • How to check: change the parent and see whether the child roster becomes the legal items under the new node. An item that does not belong to the new parent means dependence broke.

Related

  • Within the group: E3.13.2 A parent change must clear or revalidate the child · E3.13.3 Too many levels make the cascade path too long · E3.13.4 Cascades are a poor fit when levels must be compared
  • Adjacent: E3.16 Tree Multi-Select and Parent-Child Coupling · E3.05 Select Menus
  • Search terms: cascading select · dependent dropdown · parent-child options

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E3.13.1