Session 4: Flexbox, Grid & Responsive Layout

Flexbox arranges items along one axis — a row or a column — and it is the right tool when you are lining things up: a navigation bar, a row of cards, a centred element. Set `display: flex` on the parent and the children become flex items that can be aligned and distributed.

The two properties that do most of the work are `justify-content` and `align-items`. `justify-content` distributes along the main axis — `space-between` pushes items to the edges with gaps between, `center` groups them in the middle. `align-items` aligns across the other axis — `center` is what actually centres something vertically, which was genuinely difficult before Flexbox existed.

Then `flex-wrap`, which beginners omit and then wonder why their row overflows on a phone. By default flex items refuse to wrap and squeeze instead, producing unreadably narrow columns. Setting `flex-wrap: wrap` lets items drop to the next line when there is not room, and combined with a sensible `flex-basis` it produces a layout that reflows naturally without a single media query.

CSS Grid arranges items along both axes at once — rows and columns together — and it is the right tool for page-level layout and anything resembling a table of content. Set `display: grid` on the parent, define the columns, and place items into cells.

The most useful modern feature is `repeat(auto-fit, minmax(250px, 1fr))`, which creates as many columns as will fit at a minimum of 250px each and lets them share the remaining space. That single line produces a card grid that goes from four columns on a desktop to one on a phone with no media query at all, which is one of the best value-for-effort lines in CSS.

Then `gap`, which sets the space between grid items and replaces the old hack of margins that always broke at the edges. And named areas — `grid-template-areas` — which let you describe a page layout in something close to a picture, making the code readable and the layout easy to rearrange at different widths.

The rule is short: Flexbox for one dimension, Grid for two. A row of navigation links is one dimension — Flexbox. A page with a header, sidebar, main area and footer is two — Grid. A card that has an image on top and text below with the button pushed to the bottom is one dimension — Flexbox, with `margin-top: auto` on the button.

They are not competitors and the best layouts use both: Grid for the page structure and Flexbox for the components inside it. A grid cell containing a flex row is completely normal and usually the cleanest way to build something.

Then the thing to avoid: forcing the wrong tool. Using Grid for a single row of buttons works but is more machinery than needed; using nested Flexbox to build a two-dimensional page layout produces markup that is hard to read and hard to change. When a layout feels like it is fighting you, the usual cause is using a one-dimensional tool for a two-dimensional problem.

`static` is the default — the element sits where the document flow puts it. `relative` keeps it in the flow but lets you nudge it, and, importantly, makes it a reference point for absolutely positioned children. `absolute` takes it out of the flow entirely and positions it against the nearest positioned ancestor, which is why a parent often needs `position: relative` for no other reason.

`fixed` pins an element to the viewport — a sticky header, a floating button — and `sticky` behaves as relative until it reaches a threshold and then sticks, which is what modern sticky headers use and is far simpler than the JavaScript that used to be required.

Then stacking. Elements later in the document paint on top of earlier ones, and `z-index` changes that — but only on positioned elements, which is the source of endless confusion when a z-index appears to be ignored. Set a position first. And keep z-index values low and deliberate; a stylesheet with values in the thousands means someone was fighting rather than designing.

Responsive design means one page that works at every width, and it starts before any media query. The viewport meta tag — `<meta name="viewport" content="width=device-width, initial-scale=1">` — is required, because without it a phone renders the page at desktop width and scales it down to illegibility. Then fluid sizing: percentages and `fr` units rather than fixed pixels, and `max-width` on containers so text does not stretch across a wide screen.

Media queries apply styles at particular widths, and the discipline is to design mobile-first: write the base styles for a narrow screen, then add rules inside `min-width` queries as space allows. This produces less CSS than starting at desktop and undoing it, and it means the simplest experience is the default rather than something you patch in later. Breakpoints should come from where your content breaks, not from the widths of particular devices.

Then transitions, which make changes feel intentional rather than abrupt. `transition: background-color 0.2s ease` on a button makes a hover feel responsive. Three rules keep them useful: keep them short — 150 to 300 milliseconds, because anything longer feels sluggish; animate only cheap properties like colour, opacity and transform, since animating width or height forces the browser to recalculate layout on every frame; and respect `prefers-reduced-motion`, because some people are made genuinely unwell by animation and a media query can switch it off for them.