The way 'responsive design' makes a website fit any screen size

Back when the internet was in nappies, we built websites like heavy oak sideboards—sturdy, but impossible to move. If your screen was too small, you simply missed half the show. Now, we use "responsive design" to make sites behave more like a decent batch of bread dough; they stretch and squish to fit whatever tin you drop them into.

It’s all down to clever code acting like a fussy housekeeper. It measures the window and says, "This screen is narrow as a hallway, let’s stack the menu." Or, "Ooh, a wide desktop! Spread the photos out like a holiday buffet." No more pinching and zooming like you're hunting for a lost earring in the sand.

Wait, how does the browser actually measure the screen in the first place?

We call those specific instructions "media queries." It’s essentially a list of "if-this-then-that" notes left for the browser. Before the page even finishes loading, the browser checks the screen's width—much like a tailor stretching a measuring tape across a customer's shoulders—to see which category it falls into.

If the width is below a certain number, the code triggers a specific layout. It’s like having different sets of instructions for a picnic: one for a tiny rug on the sand and another for a grand banquet table. The device tells the browser its size, and the CSS simply follows the matching recipe.

But what if I rotate my screen halfway through reading?

Oh, the browser doesn't just measure once and go for a nap! It’s constantly eavesdropping. The moment you flip that phone, it’s like a guest suddenly announcing they’ve brought three extra friends to dinner—the code has to scramble to rearrange the seating plan immediately.

This is what we call being "fluid." The media queries are always on standby, ready to swap the "narrow hallway" instructions for the "grand banquet" ones the split-second that width crosses the line. It’s a bit of a faff for the processor, but it keeps everything looking tidy.

Doesn't all that constant checking make the battery die faster?

It sounds exhausting, doesn't it? Like a lifeguard watching for a tide that never turns. But the browser isn't staring at the ruler every microsecond; that would be a recipe for a flat battery and a hot phone.

Instead, it uses "event listeners." Think of it like a sleepy cat that only opens one eye when the cupboard clicks. The system only sends a "ping" to the code when a physical change actually occurs.

Unless you're spinning your phone like a fidget spinner, the processor stays relaxed. It only rolls up its sleeves when that specific "resize" signal rings the doorbell—a clever bit of footwork to avoid unnecessary faff.

So, who exactly is ringing the doorbell to wake the code up?

That would be the operating system, acting like a nosy neighbor peering through the net curtains. Since the OS is the one actually holding the hardware's hand, it’s the first to feel the physical tilt of the device or the drag of a mouse.

Once it detects a change, it sends a 'system event'—basically a loud shout over the garden fence to the browser. The browser then taps the shoulder of your code's event listener. It’s a tidy little chain of gossip that saves the code from having to do any exhausting detective work itself.