The family tree started life as an indented outline — chips and CSS lines standing in for a chart. This week we rebuilt it into an actual generation-row genealogy diagram: computed x/y layout, SVG trunk-and-branch connectors between generations, a heritage colour palette (sage green, dusty rose, antique gold) instead of literal pink/blue for gender, and a serif face for names only. The detail panel moved from a permanently-reserved side column into a modal, so the tree itself gets the full width of the screen.
A bug that made people vanish from their own family
While rebuilding the layout we found a real one: the original tree only ever renders a person once, globally. If someone appears as a spouse in one branch — say, shown as their partner's wife — they were being skipped entirely from their own birth family's branch, even though they're a real child there. Their parents' section would show a sibling, but not them.
Fixed it by allowing a person to appear a second time as a plain "stub" card — just their name, no re-expanded spouse or children — anywhere they're a blood child but have already been drawn in full elsewhere. Every branch is now genealogically complete on its own, without exploding into full duplicate subtrees.
Chasing a data bug that was actually CSS
Partway through, several people appeared to disappear from the tree completely — different symptom, and our first instinct was that we'd broken the same rendering logic again. Instead of touching the data code, we checked the actual DOM in a real browser: markup, bounding boxes, computed styles on every ancestor element. The markup was correct. The real cause was a scroll pane nested inside an already-scrollable parent, silently clipping content with no visible scrollbar to tip us off. Un-nesting it to one scroll region fixed it — no data logic was ever wrong.
Where we're still stuck
We also added proper multi-partner relationship history — ex-spouses, remarriage — since the tree's underlying data only ever recorded one partner per person. That part's shipped and working.
Then we bulk-imported 52 more people from an Ancestry.com pedigree PDF into one household's tree, taking it to 71 people, and that's what broke things properly. The tree-building logic only ever expands in one direction: pick an ancestor with no recorded parents, then draw downward to their descendants. Anyone who married into the family partway through — rather than being born into it — never has their own parents explored from that starting point. Their birth family renders as a totally separate, floating mini-chart under the same household label, with no line connecting it to the main diagram.
Our first attempt just fixed the label on the floating chart, using a "connected components" check, so at least both pieces said they belonged to the same family. It did not fix the diagram — it still looked totally disconnected, because it was. We rejected that fix ourselves rather than ship it: a relabelled disconnected chart is still a disconnected chart.
The actual fix is a bigger piece of work: a genuinely bidirectional pedigree layout that starts from the people already linked to real accounts and climbs upward through ancestors on both sides at every generation, positioning married-in branches relative to where their spouse actually sits in the main diagram — not as an independent canvas that happens to share a label. That's closer to rebuilding the layout engine than patching it, so it's deferred rather than rushed. We'd rather tell you it's not done than ship something that "connects" families in name only.