CSS3

While thinking about suggestions for new features wanted in CSS3, my mind strayed onto image replacement methods. At the moment we have a cornucopia of methods, none of which resolves the style on/images off problem without extra markup (I’m referring to CSS-only techniques).

CSS3 should be able to solve this problem for us, shouldn’t it? Isn’t that what it’s for? My initial idea was to suggest a pseudo-class that detected whether or not images were disabled and changed the content accordingly; something like:

h1 {
background-image:  url('image.png');
text-indent: -9999px;
}

h1::no-images { text-indent: 0; }

After doing a quick search, I found out that a solution has already been proposed, and it is much more elegant than mine! It uses the content declaration to replace the content, with a fallback option given after a comma:

h1 { content: url('image.png'), contents }

On the unofficial CSSWG wiki, the idea has been taken even further and the require-font function added; using this will allow you to instruct the browser to use a required font if available, download it if not, display an image if that’s not possible, or display in the fallback font style if none of the previous apply:

h1 { 
content: require-font('FF Meta Serif'), url('image.png'), contents;
}

A very neat solution! The drawback? Although accepted, this is not in the Generated and Replaced Content draft yet; and the module has been assigned a low priority.

If you’ve been reading this blog, you’ll know that Opera has been making great progress on the CSS3 selectors front in the latest version of its engine – Presto Core-2. While Opera 9.5 does pass every test in the CSS3.info selectors test, it wasn’t without issues. The test doesn’t test the ::selection pseudo element. It also doesn’t test what happens when manipulating the markup through the DOM. Both of these were not supported in Core-2, but that is now not the case.

If you go to this test page (Warning Geocities) with the latest Opera weekly, you’ll notice it is now working correctly. This is the last selector that Opera didn’t support. The dynamic behaviour of the selectors have also been fixed. If you head off to Quirksmode and try out either the :first-child and :last-child, :only-child, :first-line and :first-letter or the :empty tests, you’ll find that they all work. Although it is most likely not without bugs (what software is?), it seems Opera 9.5 will be the first browser that fully supports all selectors in CSS correctly. It could be that Konqueror has fixed the issues high-lighted on PPK’s blog, but I don’t have a copy to test. Leave a comment if that is the case. Konqueror does fantastically well even if it doesn’t support everything.

There’s a good article online at Vitamin, Stay On :Target, about the CSS3 :target pseudo selector, which provides a good explanation and some working examples. :target is supported by all current browsers, except – well, I don’t need to say it, do I? – so you can start using it straight away.

Ian Hickson, the Google employee tasked with creating the next generation of acid test, has completed his work, which is now available for public consumption at its new home, acidtests.org. Unlike the first acid test, which focused on the box model, and the second acid test, which covered a broad variety of basic HTML and CSS features, Acid3 covers 100 of the nooks and crannies of HTTP, HTML, CSS, ECMAScript, SVG and XML, all through the medium of DOM scripting, a critical requirement for any modern web application. Ian Hickson is also the primary author of the HTML5 specification, which started life as a spec. called ‘Web Apps 1.0’, and as such has lots of application‐related features such as client‐side storage and enhanced forms. Ian wrote 64 of the tests, with the remaining 36 being submitted by both browser vendors and interested web developers.

Work started on the new acid test almost as soon as the IE developer team posted notification that IE8 passes Acid2. As was widely criticised around the ’net recently, it was revealed Internet Explorer 8 would now only pass the test if the server was modified to output a special HTTP header. It is not known to css3.info at this time whether the header would be required for IE8 to achieve compliance in the new test.

You can’t have failed to have noticed the announcement by Microsoft’s IE team this week, that the next version of the browser will require an ‘opt-in’ switch to display documents with older DOCTYPEs in full standards mode. That’s been debated at length elsewhere, but I thought it would be useful to do a quick, non-scientific poll of current browser share to get an idea of how long it might be before this becomes a pressing issue for us.

Note: The following results are taken from the last month’s statistics from 12 sites I manage, from personal blogs to international companies, with monthly visits from 300 to 320,000. The error of margin can not be calculated, so these figures should be taken as a guideline only. That said…

The last time I conducted a poll like this, back in May 2007, the total market share of all versions of IE stood at approximately 68%. According to my new figures, the share is approximately… 68%. Oh.

What has changed, however, is the share of different versions of IE; in May 2007 IE6 had 46.5% of the total, and IE7 had 21.1%; in my new figures, IE6 has 33.5%, while IE7 narrowly beats it with 34.3%.

While perhaps not as big a difference as we might have expected in eight months, at least we can see a noticeable decline in IE6 usage. Microsoft are currently including IE7 in their latest round of security updates, so with luck we’ll see another big shift in the months to come.

I’m not sure how aggressively we’ll see IE8 pushed when it is finally released, but on current form it looks like we may have to wait another couple of years before it gains decent market share and we can really take advantage of its advanced (fingers crossed!) features.

While browsing the admin section of this site, I saw an incoming link titled Fun with CSS3. It includes three examples of creating a recipe card mock up using CSS3 that is currently implemented in browsers. Due to the various levels of implementation, no browser can create the whole design using the CSS3 techniques, which is why it was split in three parts.

Because no single browser supports all the innovations in CSS3, I’ve split the Recipe Card page into several examples, each with unique markup. No point in looking at these in IE or Firefox – fire up the latest Safari or Opera instead.

I’m looking forward to a time when examples like this can be displayed fully by one browser. As for improvements to the examples, I’d like to see the heading images replaced with Web Fonts, and the images in the footer should be trivial to turn into SVG and added using list-style-image. The most difficult parts would be the effect the main title has inside the text (a transparent background image should be able to make this work) and the rotated main menu text. There is currently no way to rotate text in CSS. The example is making me hungry though.

Using a different approach, there are also some nice CSS3 examples on the CSS section of Dev Opera show casing what can be done with CSS today using progressive enhancement.

Do you know of any nice CSS3 demo, or have you created your own? If so share them in the comments. I’d love to see them.

Is there ever a time when you wish CSS allowed you to apply style in ways that either are not currently possible, or require hacks and extra markup to make it possible? Well now is the chance to let the working group know exactly what you want. Bruce Lawson is collecting your feedback on the WaSP site. Go there and leave a comment outlining what effects you’d like to achieve. You can also leave feedback on the CSS3 Soapbox.

Remember that the Working Group want examples of what you are trying to achieve, so that they know if current proposals fit that need, or they can think about adding new functionality. Also state why you want to be able to do that, if it isn’t obvious. They are not looking for feedback on syntax, so just leaving a list of new properties you want added won’t be helpful. Also try to check the latest draft modules to see if your proposal is already possible. Things like rounded corners (border-radius) and striped tables (tr:nth-of-type(odd); or nth-child(even); etc.) are already possible. There may be things that you want to be able to do with a property that isn’t possible in the current spec (such as being able to have an inverted rounded corner using border-radius for an example off the top of my head). If this is the case then the suggestion will be very much worthwhile.

Also remember that there is no guarantee that things you suggest will be added to the spec, even if it makes sense, and is technically realistic to achieve.

We at CSS3.info are planning to have a wiki (or similar system) to collate feedback on CSS3 in one place, which can be referenced easier than a mailing list. We will include the most popular suggestions from the WaSP post (with full attribution) when the wiki is in place, and open it up to the public to edit. If suggestions get added to the spec, we can also include the syntax that will achieve that suggestion, and eventually a demo that will produce the same result, once it gets implemented.

Much of the editorial work done on the various CSS3 modules is done in private. Due to this, there is often the impression that no progress is being made. This impression is deepened if you look at the date of publication for many of the public drafts. However, the perception is not always the same as reality. Some of the editorial work has been made public on the W3C Public CVS Repository for a few modules, and there has been some nice progress.

I’ll start with the module that seems to have the most demand from developers – Backgrounds & Borders. The Working draft that I’ve just linked was last updated in 2005, but as you can see the Editors draft has moved on somewhat, with its last update on Christmas Day (someone was busy giving us a Christmas present). It also has an additional editor, which should speed things up.

So what is new here? Well one of the most demanded properties is border-radius. WebKit and Gecko both implement this, but implemented it in different ways. This has been resolved in this latest draft, to define it to be the same as how Gecko implemented it, but with the addition of a / notation so that both the x and the y radius can be specified in the border-radius shorthand notation. An example of this would be as follows:

border-radius: 1em 2em 3em / 2em 1em;

This would give the top left corner a radius of 1em for the horizontal radius and 2em for the vertical radius. For the top right, it is quite clear that this would be 2em for the horizontal and 1 em for the verticle. As there isn’t a radius value for the verticle bottom right, it takes the value of the top left (opposite corner) which is 2em, and the same for the bottom left corner for both values (2em / 1em).

You can also see the spec defines what happens when the intersecting borders are a different thickness. This property should be more or less ready for implementation, or adapting to the new spec in the case of Safari and Firefox. As always test cases are important, so that implementations can be made interoperable. If any developers want to make any then that would be higly useful.

The box-shadow property has been split in this draft to border-shadow and background-shadow, but I’ve been told this will be changed back to be more inline with what Safari does. The border-image and comma notation for multiple background images are pretty much stable now too.

The Backgrounds and Borders module isn’t the only one to go through changes however. The Namespaces module was also updated on Christmas day and can be found here in Editorial draft form. This has also gained an additional editor. As this module is brief and has already been included in the 2007 CSS snapshot, I assume the changes are just trivial tidying up. I didn’t notice any glaring changes when briefly checking it out. This module is also widely implemented (except IE), so likely doesn’t need much updating.

Grid positioning module is something that has also been in high demand. The fine folks over at Microsoft have been busy on updating this spec, with the editors draft last published in October. You can see a lot of new pretty pictures in the spec. Props for the use of Khoi Vinh’s Yahoo!-a-like Yeaaah example. I look forward to when this reaches an implementable state.

Also updates recently and included on the public server are Paged media, Text and Text Layout. I’ll leave it as an exercise to the reader to see what has changed here.

As well as CSS3 modules, are APIs for the CSS Object Model and CSSOM View module. This is designed to replace DOM Level 2 Style in due course, and are very early level drafts.

As all of these modules are editorial drafts, it should be pointed out that they may change at any time, and any changes are not finalised or offical W3C specs. It is exciting however that there is clear signs of progress, and that the important Backgrounds & Borders module is maturing.

I believe that 2008 will be notable for the second salvo in the browser wars, and although previous combatant Netscape is out of action, we now have a four-way battle on our hands. In fact, ‘browser wars’ may not be the best description any longer; perhaps ‘layout engine wars’ is a more accurate description. With all four major engines releasing new versions, it’s going to be exciting to watch.

The four contenders are:

IE8 New Engine: Will it be a successor to Trident or a brand new engine? Microsoft are playing their cards close to their chests on this one. It will be much more standards-compliant, but details of potential CSS 3 support are non-existent. Also, with IE7 still struggling to overtake IE6 in terms of popularity, will it make much of an impression this year?

Gecko/Firefox: Firefox 3 will probably be the first browser on the market to use Mozilla’s latest engine revision (1.9). It’s much faster than it’s predecessor and more standards-compliant, but doesn’t introduce many new CSS features; alpha channel for colours is the only notable new addition.

WebKit/Safari: Safari 3 is out for OS X and in beta on Windows, and leading Linux browser Konqueror will switch to Webkit for their next release. It’s very fast, and has lots of shiny new CSS 3 features (shadows, mutiple backgrounds, etc). Default (and only possible?) browser on the iPhone, but they won’t gain much headway on Windows machines unless they think about a redesign.

Presto/Opera: Still the minority desktop browser, Opera is huge on mobile and on the Wii. Their ‘Kestrel’ browser (version 9.5) has lots of new CSS 3 features and they’ve been working closely with major web app providers to make sure that the browser is compatible. Their suit against Microsoft could be a turning point for the company, but a decision may not be forthcoming in the near future.

It’s pretty exciting to have so much choice, and even more exciting to have them all be standards-compliant; this will allow web developers to concentrate more on user experience and less on cross-browser compatibility, while the browser makers can get on with providing new features for their users.

The dark horse in this race – and it seems strange to say this, as they are the market leaders – is Microsoft. We know almost nothing about IE8 yet, but if they come out with a genuinely radical product we could well see them take market share back from their competitors.

During the last browser war it was the developers and users who lost out, as websites were built to favour one browser over another or involved double the work to be compatible with both. This time, however, standards are a well-developed core around which the battle rotates; so whoever loses, we all win.

Dave Hyatt has recently checked in to the WebKit repository some basic support for using the ClearType text rendering system, which uses a different algorithm for subpixel anti-aliasing than the current CoreGraphics libraries do. Windows users will find that this makes text in Safari look similar to text in other web browsers and elsewhere on the system.

To experiment with this, you need to download the latest WebKit nightly build for Windows and set Safari’s ‘WebKitFontSmoothingType’ preference to a value of ‘4’. The preferences are stored in an XML property list file in the folder /Documents and Settings/username/Application Data/Apple Computer.
There are many caveats though, as this is clearly just the first step of a work-in-progress. At present the ClearType code path doesn’t support the opacity, text-shadow, -webkit-text-stroke, or -webkit-text-fill CSS properties, amongst other things. Let’s hope this development dampens down the recent heated debate on font rendering.