the birth of media queries

Just looking at the (poor) flexibility of the media queries spec, it's plain to see that they were build to differentiate between devices. This wasn't too much of a problem back in the day, because apart from the iPhone there were very few decent alternatives to venture onto the web with your phone. So device-width was a pretty good differentiator to determine the context of your user (touch, connection speed, available width), only anyone with half a brain realized this situation wasn't going to last very long. Other players came along and with the rise of smartphones and tablets it soon became apparent that adding two or three breakpoints wasn't really going to cut it.

Nowadays the market is exploding with all kinds of varying form factors and interfacing options. Touch or no touch, resolutions and aspect ratios, retina or bigger, connection speeds and web or in-app web technologies. A million different factors that could in some way or another affect the way you want to display your site. I've complained about this before though, so let's just stick with plain old widths and see how media queries are failing us there.

components and context

More and more I feel the need to determine the style and function of a component based on its actual context. By actual context I don't mean the device its on or the browser its in, but simply the available space it has. Whether a component has enough space to show certain of its elements does not rely on the size of your device, it relies on the available space it has. And sadly, the connection between device width and available width is a very wonky one.

For example, you can differentiate the look and behavior of a carousel on a smartphone because you lack the space that a normal desktop website has, but what if you drop a carousel in the secondary column on desktop? Your column width may be the same as the width of a phone, so why make a difference? (For the record, I'm not taking into account touch-related interface changes, but since the surge of Win8 hybrids that differentiator has come to die too.) Maybe you dropped your carousel in a %-based column grid, which means that it has a different size for every browser window state.

Rather than define all these different contexts (now it's in a 300px fixed right column, now it's in a 50% wide equal width grid) for each device/browser width option, wouldn't it make a lot more sense to just tell the carousel how to behave between varying widths? If it has less than 300px width available do A, if more do B? No more worries about when you're going to hit that breakpoint on whatever device or browser size.

conclusion

It would be truly great if we could devise our css in such a way that depending on the width of its own size, a component would react in a certain way. It's the only sane way to keep incorporating liquid/adaptive designs for the current load of devices on the market. Stop worrying about the width of your device or browser and simply base the behavior of a component on the available space its given. After that you still need to combine your width-based setup with the million other differentiators out there (of course).

Currently there are some javascript solutions (hello there) to fake this behavior, but this really should be a native css thing. I've looked around a little on the web, sadly not too many people are even talking about this lack of functionality (which I find strange since everyone seems to be loving OOCSS and related component-based styling methodologies), so I don't expect any major breakthroughs soon. Then again, if nobody complains we might never see this implemented, so here goes nothing.