Your team wants to use `subgrid` for card alignment in a shared component library, but the support matrix still includes browsers without it. How would you approach adopting it?

## Frame it as enhancement, not compatibility The first judgment call is what subgrid is actually providing. In the card case it is *alignment of internal bands* across siblings, on top of a layout that already works. That makes it a textbook progressive enhancement: the page is fully usable without it, and better with it. Frame it that way and the whole plan follows — you do not need parity, you need a baseline nobody would file a bug against. Contrast this with a case where the feature is load-bearing (a layout that is unreadable without shared tracks). There, the honest answer is not "fall back"; it is either redesign so the feature is optional, or accept the older browsers are out of scope. Recognising which case you are in is the part a lead is expected to get right. ## The mechanism: feature detection `@supports` tests a declaration, so it detects the value, not just the property: ```css /* baseline — works everywhere */ .card { display: grid; grid-template-rows: auto 1fr auto; } /* upgrade */ @supports (grid-template-columns: subgrid) { .card { grid-row: span 3; grid-template-rows: subgrid; } } ``` Testing `grid-template-columns: subgrid` while applying `grid-template-rows: subgrid` is fine and common — a browser that supports the keyword supports it on both axes. Note also that the parent's `grid-template-rows: auto 1fr auto` can live in the baseline harmlessly, because in a non-subgrid browser the cards simply occupy one row each. ## Keep the diff, not a second layout The expensive mistake is maintaining two layouts: one inside `@supports not (...)` and another inside `@supports (...)`. Every future change then has to be made twice, and the two drift. Write the fallback as the unconditional rules and let the supports block override only the two or three declarations that differ. If you find the supports block growing past a handful of declarations, that is a signal the baseline design and the enhanced design are actually different designs, and you should reconsider one of them. ## The coupling cost, which outlasts the support question Subgrid makes a component's internals depend on its parent's track template: the card only works if it is placed in a grid that declares the three bands and if the card spans them. For a shared library that is a real API surface. Options, roughly in order of how much you are prepared to constrain consumers: - Ship the container and the card as a matched pair, so the library owns both sides of the contract. - Ship the card standalone but document the required row template and span, and keep it functional (unaligned) when dropped into any other grid. - Expose the enhancement behind an opt-in class or a custom property so consumers who cannot provide the outer grid never get the coupled behaviour. This question does not go away when every browser supports subgrid, which is why it deserves more attention than the fallback does. ## Testing and removal Decide up front how you verify the fallback: if nobody ever renders the non-subgrid path, it will rot. Either pin a check in visual review, or accept the risk explicitly. And set a review point — a note in the component, a ticket, whatever the team actually reads — for dropping the fallback when the support matrix moves. Subgrid shipped in Firefox 71, Safari 16, and Chrome/Edge 117 in September 2023, so for most products the fallback is already dead code carried out of habit; deleting it is a real simplification, not a risk. ## What a strong answer sounds like It covers: classify the feature as enhancement or load-bearing; detect with `@supports` on the declaration; keep the upgrade additive; name the parent-child coupling as the durable cost; and commit to removing the fallback rather than carrying it forever. A weak answer stops at "use `@supports`" and never mentions the maintenance or the coupling.