A `<Fields>` React component wraps the inputs it returns in a `<div>` so that it can return several elements. Once it is placed inside a `display: grid` form container, everything it renders lands in a single grid cell instead of flowing across the grid's columns. Explain the mechanism and the fix.

## What the grid actually sees CSS grid and flexbox establish a formatting context on the container, and the items that context lays out are the container's *direct children*. Not descendants — children. This is the entire mechanism behind the bug. Write the form as a two-column grid and the intent is that each label goes in column one and each input in column two. Compose it out of a `<Fields>` component that returns: ```jsx function Fields({ user }) { return ( <div> <label htmlFor="name">Name</label> <input id="name" defaultValue={user.name} /> </div> ); } ``` and the `<form>` now has exactly one child. Grid creates one item for it. The label and input are laid out *inside* that item by ordinary block flow — stacked, full width, ignoring the track definitions, the `gap`, and any `grid-column` rules you wrote. The styles are all still correct; they are simply being applied to a level of the tree your content no longer occupies. The same failure appears with `gap`, with `flex: 1`, with `justify-content`, and with any `:nth-child()` or `>` selector aimed at the fields. ## Diagnosing it The tell in the browser's element inspector is an unexpected node between the container and the content, and a grid overlay showing one item where you expected several. The tell in review is a wrapper element with no class, no role, and no styles — an element that exists only to satisfy the single-root rule. Whenever layout "works when I inline the markup but breaks when I extract a component", suspect exactly this. ## The fix Return a fragment: ```jsx function Fields({ user }) { return ( <> <label htmlFor="name">Name</label> <input id="name" defaultValue={user.name} /> </> ); } ``` A fragment gives React the single root the JSX expression needs and renders nothing itself, so the label and the input become direct children of the `<form>`. They are now grid items, the tracks apply, and the component composes into any parent layout without dictating structure. ## Where else the stray wrapper bites Layout is only the most visible symptom. **Invalid HTML nesting.** Certain parents accept only specific children. A `<div>` between `<tr>` and `<td>`, or between `<ul>` and `<li>`, or between `<dl>` and `<dt>`, is not permitted. When markup like that is parsed from HTML text the browser repairs it, typically by moving the offending content out of the table entirely, so the rendered result differs from the tree you authored. **Semantics.** A list whose `<li>` elements sit under an intermediate `<div>` is no longer reliably a list to assistive technology; the implicit relationship between the `<ul>` and its items has been severed. The wrapper adds a node with no meaning while destroying meaning that was there. **Selectors.** `.form > label`, `input + button`, and `:nth-child()` count the real tree, so an inserted level silently unmatches rules written against the content. ## Why not `display: contents`? Setting `display: contents` on the wrapper removes its own box so the children participate in the parent's layout, and it does resolve the grid symptom. It is a legitimate escape hatch when you do not control the markup — a third-party component, or an element you need for another reason. It is the wrong first answer here, because the node still exists in the document and the tree, the fix has to be remembered by every future reader of the CSS, and browsers have had accessibility bugs where removing an element's box also removed the semantics of elements like tables and lists. Deleting the element is strictly simpler than neutralising it. ## When the wrapper is right This is not a rule against `<div>`. Keep a real element when the group is genuinely a thing: it needs a background, a border, padding, a ref for measurement, a scroll container, a click target, or a landmark or ARIA role. The test is whether the box means something. "JSX made me" is not a meaning. ## The design point The deeper lesson is about contracts. A component's rendered DOM shape is part of what it promises its callers, and a component that emits an unnecessary container is a component that cannot be dropped into an arbitrary layout. In a shared library that cost compounds: every consumer either fights the wrapper with `display: contents`, or duplicates the component, or moves the layout up a level. Reviewing extracted components for gratuitous wrappers is cheap; unpicking them once dozens of screens depend on the structure is not.