The new CSS3 @supports() rule is really rather cool!

As all devs know , browsers can in varying degrees be a right royal pain in the arse when it comes to standards compliance and when you throw in companies like Never Upgrade a PC Till It Breaks Inc. who are still running XP with IE6, planning your super duper new web site to support them can be fraught with problems.

Most of us are used to the idea of designing a UI that degrades into a DBA-UX  (Different But Acceptable User Experience) to do this we have to be able to work out exactly the support for each feature that use in our design and have some "alternate" view that we can switch to.

Up until now I have relied on the wonderful Modernizer.js which smooths out a lot of the inconsistencies between browsers particularly the older rust buckets that NUPCTIB Inc use.

However there is a new CSS rule that will also help you - ladies and gentlegeeks let me introduce @supports() which has the syntax

@supports <supports_condition> { /* specific rules */ }

@supports is supported in most of the current browsers but as you might expect IE has ignored it and Safari doesn't have it yet. If you do use it in your CSS and a browser loads it that does not know what @supports is.. it will ignore the enclosed block, so you can still use your normal methods.

Basically what @supports() does is , it queries the CSS engine for support of whatever it is you need and then invokes the enclosed CSS rules accordingly.

@supports (display: table-cell) { /* some table-cell css in here */ }



Will test the CSS capability for box-flex and apply the rule if it is supported
You can also use a negative test for a rule not being supported.

@supports not (display:table-cell) { /*cope with non support CSS here*/ }

... and you can string together logical NOTs and ORs!

@supports (display:table-cell) and (display:list-item) { /* CSS goes here }

I am sure you get the idea and can see the usefulness of this addition to the Designer's toolbox


 

.o0( Why shosuld I use Browser Prefixes in CSS ?)

Browsers don't ya just love em? We wait with baited breath for each new iteration of our favourite window onto the internet and with each new version we devs get new toys to play with. Now the Browser writers (well all of them except the ****wits that write IE) like the new stuff that is coming down the tuvbes from the W3C however there are things that are no yet at Cadidate Recommentation status, so they add a browser specific prefix in front of the property so that the particular rendering engine can process it. For example the -mox-border-radius is the Mozilla (Firefox, Camino and Flock) version of the border-radius  property.

The prefixes are:

1. -khtml- for Konqueror rendering engine KHTML
2. -ms- for IE's rendering engine Trident
3. -moz- for Firefox,Camino and Flock's engine Mozilla
4. -o- for Opera, Opera Mobile, Opera Mini, Nintendo Wii engine Presto
5.  -webkit- Safari, Mobile Safari, Chrome,Android engine webkit.

So why do these boyos exist? Well it allows the rendering engineers to "play" with new properties and values before they are finalised which is a good way for them to be tested in the wild and then corrected and tweaked as required. If they were just to jump straight in they would then be locked into that behaviour for ever. Devs like me would start making curvey corners and using partially opaque PNGs and quite rightly expect that when the browsers updated that particular behaviour would continue to work in a standard way.from that point onward. If the browser changed the standard property for whatever reason, buggy or a W3C spec change then lots of websites could potentially stop working as expected ... so they use the prefixes to get around this.  Have a look at Prefix or Posthack by Eric Meyer for an example of this actually happening.

CSS has long been a country full of "hacks" and kludges that rely on bugs in rendering engines most completely unrelated to the property you want to "hack" which are used to get the browser to do what you want it to do.


So you can use both the standard unrefixed property in your CSS and use the prefixed version as well, this means that as the property becomes a standard an impliemented in the same way over all the browsers your precious web pages will not break. It should be noted that IE9's prefixes are a bit "odd" at the minute for lots of properties they decided to jump straight into the standard and hope that the W3C doesn't change the spec!

div {
                  -moz-transform: rotate(45deg);
                  -o-transform: rotate(45deg);
                  -webkit-transform: rotate(45deg);
                  transform: rotate(45deg)
}

In the code aboveI am rotating a [DIV] element thru 45 degrees and I am covering the main browsers (inc IE9) However .. all this repitition will lead to large css files. It really would be so much nicer to have one single entry and have done with it. Well there is a way around this using a CSS pre-processor. SASS is one and LESS and eCSSTender to name 3. However by hiding prefixes with pre-processors devs may forget that they are using "experimental" properties that are likely to change when they are infact nothing of the kind. Also the Pre-Processor comes with a browser overhead and process overhead on the user's PC which becomes more noticeable on complex pages,

As time progresses you can remove the browser prefixs from your CSS, which is MUCH easier than "unhacking" css using the older hacks that relied on browser bugs.

A minor annoyance of using prefixes is that they do not validate and in DDE this can be a pain and can hide real errors in your CSS. to get around this I generally have two CSS files.. one with the pristine Standard CSS and one with the prefixes. There is an extra HTTP request hit here, but it does make debugging easier during testing.

So there you have it Prefixes .. next time I will have a think about coping with browsers that don't support CSS3

.o0( ok Why CSS3? )

Since the dawn of the first browser CSS (Cascading Style Sheets) have been evolving with progressive enhancements that allow developers more and more "design" options when designing a web site and the most recent iteration of this standard is CSS3 and having been playing with it on a couple of "new build" projects over the last couple of months and it has to be said I am impressed. Very Impressed!

The new techniques inherent in CSS3 give the developer more advantages over the older alternate more hacky methods. They extend the developer toolkit and in doing so bring the web-pages we create closer to the idea of a "web app" that looks and performs exactly like a desktop app.

Used correctly CSS3 can totally replace images, for example drop-shadows can now be done with CSS so you no longer have to design, place and download PNG or GIF images to get this effect. If you client wants to see what it looks like a little darker, a little further or wants it as a neon purple glow no longer do you have to hit GIMP or Photoshop a simple change to the CSS style is all that is required.

Some CSS allows you to do away with Javascript functions or Embedded Flash Objects which can be ackward to code for every browser particuklarly now we have to provide for a myriad of mobile browsers as well as desktop ones.

CSS3 also can reduce your markup by requiring fewer and less complex DIVs and associated Classes. for example you can now load multiple background images into a single Element so you do not have to have nested internal DIVs each one styled differently. Also and IMHO most markedly you can now target elements in the DOM directly based on their position in the document tree.

[All the above comes with the presupposition that all versions of IE are shit shit shit shit shit]

Having said that I have discovered that there are "the right tools for the job" and sometimes although the CSS3 technique is dead cool and sexy doing it using Javascript can sometimes do it more efficently and with less development time. So basically watch out and if CSS3 can do something quicker and more efficently use it otherwise .. well use your common sense. ;-)

I will endeavour over the next couple of posts to throw out some both my "oooooo!" and the less frequent "oh bollox!" moments that I have had with CSS3 over the past few months and perhaps spur you on to have a look at what I think is a definite gain to the art of web design.