additions… #43

…web design…

support first, recommend later…

You know, media queries hasn't reached the status of “recommended” yet. However, despite what some would have us to believe: the status of a particular part of CSS standards has nothing to do with anything.

It is browser support that matters, not the status of some W3C standard. Once at least two browsers have implemented interoperable support for something – proven that it works across the board, then we have a de facto standard. Recommendation will follow.

Opera introduced parts of media queries more than 5 years ago, with the arrival of version 7.2, and Safari confirmed it by adding its partial support a few years later, with the arrival of version 3. Thus, I was prepared for progress in this field, and had already implemented and tested this particular part of CSS.

Not much I can do to drive progress, but I like to be prepared for what little there is. The current state of web development is a bit too static for my taste.

Internet Explorer is still struggling to get up from the hole Microsoft dug for it back in 2001, and will probably not get completely out of that hole for years to come. Thus, the web standards playing-field is pretty much left to the others, and they are responding better and better with each released version.

step by step standards…

Web standards surface through ideas and implementations, and are drafted, experimented with and expanded on until they are proven to actually work in an interoperable way. Browser developers look at each other as much as on drafts and specs when they are about to implement something new or refine something existing, and then at least some of them go back and help fine-tune the relevant standards to remove any ambiguity.

Cooperation-level when it comes to web standards is on the rise, as even those browser vendors who have had little interest in this field up until recently have finally figured out that making one set of standards work for all is better than having to deal with numerous splits and individual pseudo-standards. Maybe not all browser vendors are equally sincere and active in their cooperation – yet, but at least they're in.

Interoperability is the key here. End-users and web designers don't care about how something works, as long as it seems to work the same way in all browsers. Browsers may be fast, slow, nice, ugly or whatever, but in the end they're just go-betweens in the relationship between web designers/developers/suppliers and end-users, and as such they just have to deliver at both ends.

No reason to blame W3C and their work on standards for the seemingly slow progress, as every aspect of progress beyond the idea and draft stages where literally everyone can participate, is up to browser developers – all browser developers. If they can't make it work, then we obviously have no working standard.

W3C does not so much create standards, as they promote interoperability based on standards. W3C also make sure noone else owns or can make claims on any parts of the standards they promote, to make sure there will be no legal problems related to implementing them.

In CSS3 and upwards the individual parts don't become recommended parts of W3C CSS standard before at least 2 browsers have implemented support for them in an interoperable – fairly identical – way. If such initial support can't be achieved within a reasonable timeframe, then the individual part may be redefined, or dropped.

one stylesheet fits all…

While we can ignore Internet Explorer for the time being – IE8 won't be up to much when it comes to CSS standards, we have 3 browsers that literally are competing between themselves about being the first to implement support for the latest and most interesting CSS drafts – and they are also coming up with new proposals for CSS parts as part of the process. Such a competition drives progress, and that's what we want, isn't it?

The thing is: browsers have to implement interoperable solutions to the challenges CSS poses, as otherwise the individual parts of CSS won't work and therefore won't be used in regular web design productions. When something works in a number of browsers to the benefit of the majority of end-users, then it will be used even if it doesn't work in all browsers and/or in older versions. The rest is up to the individual browser developer to figure out.

We're hopefully way past the time when we served separate solutions across browser-land, although some old and obsolete versions may still get some extra help while we're waiting for them to be replaced. New browser versions will have to do with standards, and if any of them can't(?) … well, that's too bad.

what it does…

Guess it's about time I tell you what my little media query actually does. It redefines some “position: fixed” to become “position: absolute” or “position: static”, or simply makes superfluous design-elements disappear, when conditions are such that my “fixed” elements risk running out of screen-space and become inaccessible and unusable, and the browser-window gets too crowded.

@media screen and (max-width: 620px) and (min-device-width: 630px) {
/* styles to redefine my layout for these conditions */
}

This little piece of CSS code is only found on pages like Home and Contents, where problems may arise because both the footer and side-column are fixed to the screen.

For what it's worth: Safari on the iPhone does something similar, by simply not supporting “position: fixed” at all on those small screens.

My media query will excite all browsers that are up for it – for now that's Opera, Safari and the latest Firefox, and will work on all screens and devices. Comes pretty handy now that “full-page zoom” is taking hold across browser-land.

what I do…

As mentioned elsewhere: progress is painfully slow across browser-land. To some this means they don't have to keep track of progress in standards, and that all they have to worry about is whether to design for 800×600 or 1024×768 screens. To me that's a moot point, as unless I'm explicitly told to design for a particular screen resolution – and paid well to do just that, I'll design for and let my designs adapt to as large a resolution-range as I can possibly cover and test for.

To me a screen is from around 200 to 3800px wide, and randomly tall – I generally don't need to know since I don't design “above and below the fold.” I design within a limited part of this range – 600 to 1200 in most cases, and extend my designs adaptability to the rest of the range as far as browsers' standards support allows for.

Browsers' standards support will always be a limiting-factor for the end-user, but not so much for me. End-users are free to use whatever browser they like, but browsers with better standards support will always be allowed (by me) to deliver more than those with weaker. I'll never restrict my designs to that of the “lowest common denominator”, no matter what.

So, “progressive enhancement” and the sometimes unavoidable “disgraceful degradation” it is, and I'll always be happy when browsers catch up and start delivering. Feature-creep isn't a problem around here, as I'm more interested in delivering content than adding new design-features unless those features really improve my designs as content-delivery vehicles. Some features, like media queries, have the potential to do just that.

I have more “conditional rendering” and other goodies waiting in my stylesheets, so once a browser is ready it'll get the best layout I can create for it and the device it's running on. I am prepared for progress and preparing for more, and can't wait for the next sign of some.

sincerely 

Hageland 10.dec.2008
last rev: 12.dec.2008