Flex & Containers

I mentioned that Grids are ‘block-like’ by default – with a layout layer defined on the parent. In many ways, Flexbox is more inline-like – not describing a layout, but allowing items to negotiate their own space.

Items flow on a primary axis, that optionally wraps at the edge of the container.

• container controls -flow (-direction & -wrap) & gap
• Any explicit sizes have to be set on items

If you were around for the old days of floated grid layouts, flexbox is a pretty direct 1-to-1 mental model –

but with more flexible boxes. Like floated layouts, any resulting structure on the page comes from each element being individually sized and positioned.

We can revisit the same layout from yesterday, and get a similar result – but this time there’s no internal layout structure and no parental controls. Children have to define their own position in space.

The difference is not intrinsic and extrinsic sizing – both grid and flexbox can mix explicit and fluid sizes. The difference is grid has an internal layout structure that is separate from the size of individual elements.

With flexbox, there’s no structure, just items taking up space.

Because of that difference, flexbox has fewer alignment options than grid.

• We can still align or justify the ‘content’
• And we can align-items or align-self on the cross-axis
• But there’s nothing for individual items to justify- against
• There’s no cell, the item is creating its own space

We get what we asked for: flexible boxes.

• There are three underlying controls: basis, shrink, and grow
• By default, items start from their auto content basis
• And shrink equally (factor of 1) when we run out of space
• But they don’t grow at all (factor of 0)

We can see what’s happening most clearly in the Firefox flex inspector.

Other browsers provide an overlay on the parent, but only Firefox explains where each item gets its size.

I find that complex flex settings often mean I should be using grid instead. That’s not universal, just a hint to reconsider. In fact, flexbox was designed with four special shorthands to cover most common cases. I especially rely on auto and 1.

• Initial, the default
• No growth, shrink as needed, auto basis
• Great for distributing space around or between elements

• Auto allows growth as well
• Distributing extra space into elements

Instead of adding growth to the initial value, we can remove shrinking – so boxes don’t flex in either direction.

• A single number (usually 1)
• Fully flexible, growing from 0 basis
• This removes the auto-content sizing,
• So every element starts from the same place

Note that values less than 1 are also useful! Items can stretch to take up half the remaining space, for example.

• initial
• auto
• none
• <grow>

• Generally I avoid explicit flex-basis
• Not because it’s bad to use, go for it!
• But if I want more control over explicit sizes…

• I probably want grid instead
• Probably! Not always.
• This is not a strict rule,
• There’s nothing wrong with flex-basis

• And they go great together
• We can nest either inside the other
• To get powerful results!
• These were always meant to be a pair

Andy Bell makes a case for ‘automatic’ layouts using flex-basis as a sort of container-query. It’s very clever, but… if we know the sizes, I prefer clarity. I would only use this if we don’t know the sidebar size in advance.

Otherwise, we might want a container query. So let’s look at them.

All of these tools are designed to handle change and uncertainty in various ways, responding to different conditions, like the size of the viewport…

• Or any other extrinsic constraints
• But also the intrinsic sizes of things
• This constant push and pull negotiation

• Web layout is like filling a balloon with water.
• The contents have to change shape to fit inside,
• But the container also changes shape,
• and if we’re not careful…

• Things can go wrong

• When coining the term Responsive Web Design
• Ethan mentions several tools for responsiveness…
• Percentage-based image and layout sizes are central
• But then media queries to handle bigger shifts
• What we call breakpoints,
• (At the point where something breaks, we apply a query)
• This is the same year that media queries became available!

• And that’s extremely handy!
• But there’s a small issue
• What if we have nested components?
• It’s not the viewport size that matters,
• But the size of the container

• People pointed that out right away
• And started asking for better options
• selector queries, element queries, container queries
• Whatever we call them,
• we need some way to know about nested context

• We need some way to query containers
• And the browsers heard us asking
• And responded together

• And the answer makes sense when you think about it.
• How do you measure a water balloon?

If we can query the size of the container, and you use that information to change the size of the content…

That would change the size of the container again, and we’re stuck in a loop! But then some folks pointed out…

We’re not dealing with fluid dynamics here. We know that inline elements use the contents for inline size –

And block elements only rely on contents for the block axis. So web layouts generally get their width externally, and allow content to resize the height. Maybe we can measure one axis, and change the other?

• So how do we make sure there’s no loops?

• We can’t rely on the fact
• That we’re mostly measuring an extrinsic axis
• We have to be clear about it

• And turn off any ability
• For an element to be resized by content

• First we got the containment features
• Which are useful on their own for handling extreme
• performance optimizations
• but…

• Maybe a bit too dangerous
• For us to use in container queries

• Containers should no longer apply layout containment!
• Still create ‘formatting context’
• Still contain counters

• We’ll see what else comes out of this!
• I imagine there are a lot more questions worth asking

• But for now,
• Please do query the containers actually, thanks!