Since the idea of CSS2.2 was raised, there’s been some discussion as to what it should encompass, who should be responsible for the spec, and what it should be called; here’s what I think:

First, it doesn’t matter what it’s called. Whether it’s referred to as CSS2.2, CSS2.1+, CSS3 Interim, or whatever, makes no difference. It doesn’t need to have a name at all; the important thing is that we have it.

Second, it doesn’t need to be an official recommendation from the W3C; in fact, it may be easier if it’s not. The optimal solution would be communication between developers and browser manufacturers, and – crucially – between the browser manufacturers themselves. What’s needed is an agreement as to which features are implemented, and to make sure those features are implemented in the same way; a de facto standard.

The most-requested feature is multiple background images; if you’re going to have that, background clip, origin and size would be wanted too. Border images would also be useful, as would an agreement on implementation of border radius.

Opacity, and with it RGBA and HSLA, box shadow, and text shadow would round off the decorative declarations.

Even if those few could be agreed on, a lot of workarounds could be avoided.

I would have said that multi-column layouts were less urgent, but as they are already part of the Gecko engine and about to be introduced in Safari 3, it seems that that should be part of the standard. Media queries would be pretty necessary as we move into the mobile era, too.

Nothing I’ve mentioned above would be unrealistic; most have already been implemented in at least two current or imminent browsers. As they are available, why are we being kept waiting before we can use them? Think of all the extraneous markup we could be freeing ourselves from!

Come on, browser makers: open up lines of communication and get talking to one another; float the ideas on your company blogs, see what your readers have to say. There’s a whole big community of developers who love to download nightly builds and test new features, and are hungry to improve their pages.

While preparing an example of using the colours specified in the CSS3 Colour module, I come across something after Minefield (the nightly builds of Firefox 3) updated itself. It now supports the resize property from the Basic user interface module.

Unfortunately, Minefield loads, then freezes and eventually doesn’t respond when trying to use this. This is unsurprising of a nightly release, and was likely due to the other CSS3 properties I was using on the example. The strange thing however is that the examples on the css3.info resize preview page do not work at all.

I decided to strip out a lot of the extra styles and content that I was using, and have an example where resize works both in WebKit and the latest Gecko builds. As this is part of another example that isn’t quite finished yet, there are a number of bugs, which may or may not be my fault. There are also a number of styles which probably don’t need to be there, but are part of a bigger example, that will be coming soon. I just wanted something quick that would show this in action. Feel free to suggest any improvements.

So what are the issues? In the example I wanted to make a faux window, much like a desktop application window. The whole window should be resizable as one block. For this I placed the resize on the app-window div. The main contents of the window had to be scrollable when there is too much contents for the size of the window, but the rest of the contents shouldn’t scroll, such as the title bar (a h2 element). Therefore I put the scroll on the contents div.

In Safari there is a problem where both the h2 title bar and the main contents resize independently of each other. There doesn’t seem to be a way to resize the whole containing div where the resize is set. In Firefox this works correctly (or at least how I expected it to work). In Safari the content also can’t be resized smaller that the initial value of the div. This wasn’t an issue in an earlier build I was using while developing the example.

Minefield can be resized down to the minimum size and width requested, but it only resizes correctly horizontally. The div resizes vertically but the containing content div doesn’t resize at all. This may be a bug of mine as the contents seems to break out of the container slightly at the bottom. I haven’t had time to look into this.

One strange thing about Minefield’s support for resize is that it adds a cross-hair icon that allows one to move the contents around the page. This works correctly, unlike the resize, but I can’t find anywhere in the spec which specifies this should be allowed when using resize and it isn’t expected behaviour, or at least I wasn’t expecting it, and I didn’t specify that the div should be moveable. It would be nice to be able to specify this with a different property however.

Also, as I use a Mac, I expect the content to be only resizable from the resize widget on the bottom right hand corner (for better or worse). Minefield ignores this and has its own controls, which can’t be styled as far as I know. I also can’t remove the resize controls after clicking out of the resizable content. They stay until the page is reloaded. As resize has probably just been implemented, it is expected that their will be a number of bugs like this however, so things should improve as more people test out this and other CSS3 properties. Resize with HSLA/RGBA and overflow: scroll; is particularly buggy for instance.

I’m working on the original example, that I’ll post here at a later date, along with an updated version of the overview of the CSS3 Color Module that I posted on my personal blog recently. I guess I’ll have to report the bugs I’ve found to the appropriate places, unless it turns out I have bugs in my code instead.

The Short Answer:

None of it.

The Slightly Longer Answer:

I’m in the process of updating the Preview area at the moment (sneak preview), and what’s immediately apparent is the low level of implementation of the new CSS 3 features across the major browsers. As IE6 is still the most widely-used browser, roughly 50% (and, slowly, falling) of the market has next to no CSS 3 support at all. A sobering thought.

Next most-widely implemented property is opacity; with support in all the key browsers other than IE, perhaps 25% of site visitors will see this effect if you use it. Again, make sure that your designs degrade gracefully if tempted to add this to your code.

After that, you can more or less forget it. The properties in the Backgrounds and Borders module have patchy implementation in browsers, and almost all use browser-specific prefixes, which you probably want to steer away from in a production environment as they are subject to change (see the border-radius conflict as a good example of why they are tricky to implement).

text-shadow should gain support from Safari 3 and Opera 9.5, but even being generous that’s only around 5-10% of the market. Most of the other properties have little or no cross-browser support.

What You Can Do About It:

Get behind Andy Budd’s ‘CSS 2.2’ idea. Think about it. If you have a blog, discuss it there. Write to browser manufacturers and the W3C. We’re putting together a campaign website to promote the idea, so get in touch with us and offer support.

We want – no, need – these new properties, to do away with many of the non-standard or non-semantic solutions we have to use today to provide complex solutions for simple problems. CSS 3 provides many of those solutions, but they won’t be implemented cross-browser until they become standard; that can be via the W3C, or a de facto standard agreed by browser manufacturers. But however that standard is made, it won’t happen unless there’s concerted pressure from the development community.

With CSS 3 so tantalisingly close (and yet so far away!), it’s fun to play around with some of the new cosmetic features. In fact, we can even start to implement them on websites – as long as provision is made for users with older browsers.

The CSS is quite lengthy, so view the source of the example page and you’ll get some idea of what I’ve done.

If you’re using IE6, you’ll see just a row of plain, grey boxes which don’t animate when you mouse over them. IE7 and Opera users get a slightly better experience, with the text going white when hovered:

li:hover a { color: #fff; }

Firefox and Safari 2 users get it better still, with border-radius and multiple backgrounds respectively supplying curves to the tabs:

It’s when you get to Konqueror (and, presumably, Opera 9.5), however, the new styles really kick in; use of the nth-child declaration allows for alternating colours, and text-shadow give a slight illusion of depth when hovered:

This was a very quick and easy example, but I’m sure you can imagine much more creative uses for graceful degradation. It’s a useful technique if you have the time to implement it, and comes in very useful when trying to persuade people to upgrade to a better browser: “If you think that website looks good now, take a look at it on my computer!”

They mention that CSS 3 support will be improved (text-shadow is provided as an example), as well as superior SVG support, and a new Javascript engine will allow better access to websites with wonky coding.

This sounds like a really exciting release, and should give Opera the accolade of being the most CSS 3 compliant cross-platform browser. Weekly builds will be available shortly.

Apple has released Safari 3 in beta to the public, running both on Mac OS X and on Windows! This enables all of our fans to now have a look at the wonderful CSS3 stuff that’s in there, as it’s based on a very very recent version of Webkit.

The header of my own blog (still in development; please don’t judge me!) features a single image which spans two columns, with a semi-opaque panel featuring text over the top of it. I wanted the image to be clearly visible in the left column, and faintly visible in the central column. I could have done this by designing it that way in a graphics package, but as I intend to swap the image around in future, I wanted to come up with a client-side solution.

I could have just used a semi-opaque background image, which would have worked immediately with all major browsers bar IE6. But I didn’t want to use an extra image and I wanted to play around with CSS 3, so this is what I came up with:

Firstly, I put the image as a background property on the <body> element. Next I created an empty, presentational <div> with a class of ‘header’. To this I assigned the colours and border colours, then gave it a large left-margin to allow the image to completely show through on the left column, and an opacity of 0.9 in order to allow the image behind to faintly show through on the central column.

The problem with opacity is that it is inherited by all child elements, so if I had put text inside div.header, the text would also have become semi-opaque. To get around this I assigned position: relative to the <body>, then wrapped another <div> called .title around <h1> and <h2>, put it after .header, then absolutely positioned it where I wanted it to appear:

Opacity doesn’t work in Internet Explorer, of course; I could have used a proprietary filter, but decided that the 19% of visitors to my site who use Internet Explorer wouldn’t suffer by not being able to see the whole image; it would be a little ‘bonus’ for whoever uses a better browser (here’s an image if you’re using IE and want to see what other users see).

Another solution was available to me; keep the <h1> and<h2> inside .header, and use rgba values on it instead. This would be better semantically as I could drop .title, and wouldn’t involve any positioning as rgba values are not inherited. I could have used the following code:

While this is obviously leaner and quicker, support for it is not as widespread; at the time of writing this, perhaps only 4% of my visitors would see the effect I wanted.

My two most extreme options were to have added extra styles and conditional comments to the document in order to getting working across all browsers, or to use the purer, smaller CSS3 to get it working on only a tiny amount of current browsers. In the end I did what we’ve been doing for so long now, and made a compromise.

Andy Budd is a well-known figure in the world of web development. If you haven’t heard him speak at one of the many conferences he attends (or even the one he helps organise), you may have read his book CSS Mastery or one of the many articles he has written.

Apologies to all for the delay between posts, the site authors are busy with jobs, family and holidays. We’ll have some new content very shortly. In the meantime, here’s a quick browser update.

Based on my own statistics – and these are not, of course, meant to be in any way representative – April saw a pretty decent leap for IE7; its share of the market rose to 21.1%, up from 18.6% the month before. Even more encouraging, IE6 fell to 46.5% after its shock rise to 50.6% last month.

Firefox’s share continues on a slow decline since I began my figures; from a high of 16.9% in November, it falls to 14.8% in the latest figures.

Microsoft were noticeably guarded with details of changes in future versions of IE at their recent MIX event, although hints were dropped that we’d see improvements to CSS, RSS, and AJAX, and that Microformats could be on their way.

In an effort to tie this post to the theme of this blog, let me ask a question: what three CSS3 features would you most like to see in IE8?

Update: Maybe I should reword the question: With the presumption that all outstanding CSS2 bugs are removed, and all remaining CSS2 declarations implemented, what CSS3 features would you most like to see in IE8?

I like to keep track of browser market share, specifically the growth of IE7, so that I can tell when its new CSS features become mainstream enough to start using. This month, I had a bit of a shock.

I’ve based my figures on eight different websites I manage, from personal blogs to international businesses, to try and get a broad range of figures – although they are not, of course, meant to be definitive in any way. I’ve tracked figures back for six months – IE7 was launched in October 2006 – and only included sites with that much historical data.

The figures (click here to see the graph) didn’t surprise me at first. IE7 started at 1.6% in October, had a huge boost to 12.1% in December, and growth has slowed since. Most of its share came at the expense of IE6, which started off with 60.8% and was down to 47.2% by February. But then, in March, IE6’s share increased to 50.6%. I thought I could put this down to an anomaly on one site skewing the results, but in 6 of the 8 sites I monitored, the result was the same – an increase in usage over the last month.

I can’t explain it. It’s like it just refuses to lay down and die.

If we want to move the web forward, we need to encourage people to drop IE6 as soon as possible. As far as I’m concerned, there are very few reasons to still be using it; either you work for a company that deploys software centrally and hasn’t upgraded yet, you’re a developer testing your code, or you don’t really know what a browser is and you’re unaware that other choices are available.

I’m assuming that a reader of this article is a web developer interested in CSS3. If we want to start using all the new opportunities that it creates, we need to kill off legacy browsers that don’t support it. If you’re using IE6 and you have any option whatsoever, switch to a better browser; IE7 at the very least. If you know someone who still uses IE6 and has any option whatsoever, get them upgraded. Evangelise all the options; Firefox, Opera, Flock, whatever; get people switching. Let’s kill this dinosaur off and let the fast mammals evolve to take its place.