Search
5 results for “flexbox”
Search results
CSS Grid vs Flexbox
When to reach for CSS Grid versus Flexbox, the one-dimensional vs two-dimensional distinction, with syntax and layout examples for each.
What is the core difference between Grid and Flexbox?
Flexbox lays items out along a single axis (row or column) and is content-driven, items can wrap, but each row or column sizes independently based on its own content. Grid lays items out on a two-dimensional row-and-column track system defined up front, so rows and columns can be aligned to each other across the whole layout. The practical rule: reach for Flexbox when you are arranging items in a line, Grid when you need rows and columns to line up together.
Can Grid and Flexbox be used together in the same layout?
Yes, and in practice most real layouts use both, Grid for the overall page or component structure (header, sidebar, main content, footer), and Flexbox inside individual grid areas for things like a horizontally arranged button group or a centered card. They are complementary tools, not competing ones.
How does the fr unit in Grid differ from flex-grow in Flexbox?
Both distribute available space proportionally, but fr operates on Grid tracks (rows/columns) as part of an explicit track list, `grid-template-columns: 1fr 2fr` splits width into three parts with the second column taking two of them. flex-grow operates on individual flex items along the main axis and only kicks in for leftover space after each item's base size is accounted for. fr is about defining the track structure; flex-grow is about how items compete for remaining space within it.
If a microtask itself queues another microtask while it's running, does that new microtask wait for the next event loop iteration, or does it still run before the next macrotask?
It still runs before the next macrotask. The rule isn't "run the microtasks that were queued when this iteration started", it's "drain the microtask queue completely," and if executing a microtask adds another one, that new one is still part of the queue being drained. This means a chain of microtasks that keep scheduling more microtasks can, in principle, starve the event loop from ever reaching the next macrotask (a real, documented way to accidentally block timers and rendering), which is different from a single flat batch of microtasks all queued up front.