This article is a brain dump from last night’s event.

CSS3 media queries let us adapt CSS rules to different viewport properties; width, height, pixel ratio, even colour and monochrome screens (full list). Aside: the Amazon Kindle (which uses webkit) reports itself as colour, with 8 levels, rather than monochrome.

The common process is to design for the desktop and use media queries to adapt downwards. On thinner devices content is linearised, navigation moves to the top or bottom, less important elements are sometimes hidden; everything is simplified down to the page’s core use case.

A number of tutorials have offered up the exact pixel-based media queries needed to target specific devices, a sort of restricted browser sniffing. This isn’t truly progressive, you can never cover all devices, and devices change, revisiting code for device iterations isn’t going to be fun.

Media queries don’t need to be pixel based either, changing a page layout based on ems will adapt content for larger text sizes. If the user’s text size is huge, our viewport is the same but we’ve got less space to play with, a linear mobile-like design might be more desirable.

This act of adapting downwards works for devices like the iPhone and iPad, but what about those that don’t support media queries? They’re going to get the full desktop version and it’s not going to be pretty.

Luke Wroblewski has suggested designing for mobile first (an excellent read). In terms of responsive enhancement that means creating your linear site as the baseline and building outwards around content, bringing in features as capabilities improve and constraints are relaxed. As the viewport widens, media queries can introduce columns, rather than remove them. It’s the same process but in the opposite direction.

All mobile devices and older browsers would get the simplified, linear design. This works on the assumption that desktop browsers support media queries, IE 8 and below do not, ergo they’ll be seeing the linear site design. This may be acceptable, but in the majority of cases IE will need some sort of hack to get the full featured version.

Using conditional IE comments an IE layout can be hacked in. The IE specific styles are likely to repeat existing code, undesirable, but unavoidable? This is still a one size fits all approach as IE will not adapt to screen or text size. For this we need a JS poly-fill, one that enables media queries in older browsers. There’s a library on Google Code that does just this, CSS3 Media Queries JS.

Building a page that can be linearised means putting the most important information first in the source code. This assumes that the context of “what is important” is similar on different devices. If the context is different, that makes a case for serving different content, usually via a standalone mobile site (which should always come with a link to the full version).

And on the topic of serving different content, there is also the speed problem. Hiding and showing parts of a page using CSS is great, but it doesn’t stop the slower mobile networks from downloading the unnecessary parts, including those huge background images. PPK has written an excellent article on combining media queries and javascript to avoid some of these caveats.

To round this brain dump off, I’ll recommend some other articles on the subject, which go into some of the technical aspects in a little more depth.

Ethan Marcotte’s “Responsive Web Design“
Jeremy Keith’s “Responsive Enhancement“
Yiibu’s “Rethinking the mobile web“
PPK’s “State of Mobile Web Development”

This clock experiment does not advocate such use of style sheets, it is instead used to demonstrate the capabilities and possibilities of WebKit’s transform and transition properties. It has inadvertently highlighted the controversial and unexpected nature by which web developers may use them. Should this cross-pollination of behaviour definition become standard? Is it risky? What might the side effects be?

Comments on the Ajaxian post began the discussion, Malic opened the debate (this comment is particularly in reference to ‘transition’ rather than the more widely accepted ‘transform’):

While this [is] interesting and maybe a little bit cool, I think it is inappropriate for Webkit to take CSS (even if only for itself) in this direction. CSS was created to define style. This seems more like a behavior to me and that belongs to the Javascript problem space. Going down the the road that Webkit is going, the question is — where do you stop? Just how much do you extend CSS to be? I think you run the risk of creating solutions for problems that have already been solved.

This yielded some opposition but the majority supported the notion, Travis Almand champions the new transform property but strongly questions its counter-part:

CSS should be a style guide, not a programming language.

Before highlighting that the road to behaviour in CSS has already begun with the much used :hover, accompanied by :active, and :focus — user action pseudo-classes, agents sometimes change the rendering in response to user actions; response being the keyword.

Will Peavy comments that these behaviours wreak reek of IE’s abandoned CSS expressions, and edthered asks:

What happens when your CSS library and your javascript library start trying to do the same thing to the same element, or different things to the same element?

John Dowdell of Adobe has also weighed in with an honest rant that I heartily recommend reading, even if I’m slightly jealous that I cannot articulate my prose as well.

The clock example shows that people will use technologies in unexpected ways. The creators of Usenet did not intend mass advertising. […] Stuffing the genie back inside the bottle is harder than looking carefully at the bottle before opening it.
[…]
We may not be able to persuasively articulate why this will eventually be considered a bad architectural decision. It’s like when vendors of email clients started talking about how wonderful it would be to add hidden graphics and scripting to the emails strangers send to you. Vague warnings of an unsound future are at a disadvantage to self-interested “But I wanna do it!!” evangelists.

It’s hard to persuasively document future risks. But encumbering HTML and CSS like this is not the way to bless your own multimedia engine.