CSS3

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.

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.

Disclaimer: The following post is my personal opinion, and not necessarily those of my employers. My colleague, Chris Mills provided feedback and suggestions for this post.

Since Opera’s antitrust complaint to the EC, some people have used the complaint as a catalyst to promote their agenda against the W3C and the CSS Working Group, with arguments flying on either side. There is no doubt that there are issues there, and action is needed. Transparency is one such issue, with many CSS3 modules not having been publicly updated since 2002. This gives the impression that it is moving at an unacceptably slow pace. There are also accusations that in fighting is delaying progress to suit various parties’ own agendas. I’m not a member of the W3C CSS Working Group, so I can’t comment on how true this is, as I don’t know. I do know however that something has to be done, and the W3C has starting to make progress on remedying this issue. In this post I state where I feel the working group is right now, and propose some changes that I feel will help move things forward.

The current state of proceedings

Lets start with what they have done. They recently started a blog, in which they report on progress and issues. They’ve also created an aggregated feed of blogs and sites to report on CSS3 so that they can hear the voice of people that are discussing CSS3 outside the W3C, ie real world developers. They’ve also started working closely with css3.info. We have a CSS Soap box to let everyone get their issues off their chest, and they have written posts requesting feedback from designers saying what they want from certain properties. Is that far enough? Maybe not, but it is a beginning and I commend the work that Fantasai has done on this outreach.

Transparency of the Working Group

If this is where we are, where do we want to go? Firstly, transparency and accountability have to be greatly improved, so that if anyone is trying to hold up the process or are playing politics this is exposed, whether it is Opera, Microsoft, Mozilla or anyone else. I propose that minutes to meetings and any important documents or drafts are published on the working group blog.

Who should be represented on the Working Group?

Next, there are calls for browser vendors to be removed from the group. This is unworkable (disclaimer: I work for a browser vendor), for many reasons already exposed. I do strongly believe however that a better balance between designers, browser vendors and other parties has to be reached. Gibson or Fender don’t get guitar players to design their guitars – that would be ridiculous, as guitar players can play guitar, but the vast majority of them have very little knowledge of the processes involved in actually building a guitar. They design them themselves, with input from guitar players on what they want. Writing specifications is very difficult, especially when making sure they are implementable in not only a cross platform, device and browser independent way, but also cross culture and language. Test cases are difficult to write. Browser vendors have many of the best people in the business for writing these specs, as they are the kind of people we hire. Ian Hickson is widely regarded as one of the best specification writers of our generation, and he used to work for a browser vendor.

Keeping browser vendors out of the Working Group would also be difficult to police. For example Fantasai works for HP (I believe), but has close ties to Mozilla. Would she be counted as a representative of a browser vendor? Also, would designers be willing to give up what they are passionate about (designing web pages and other media) in order to work full time writing technical specifications? Why also should browser vendors be reduced to an advisory role, for technologies they have to do the hard work in implementing? If this were to happen, we would probably end up with a break away group similar to the WHAT-WG, of browser vendors that don’t want to be told what to do by designers.

A power struggle isn’t what is needed – instead, we need a balance between vendors and designers. The specs should be left to the people that are good at writing specs, and enjoy it, the designers should be there to comment on if the proposals are useful in the real world, and the browser vendors should be there to comment on their side of things – whether the proposals are realistic to implement in their rendering engines.

The designers included could be part of an advisory panel of respected designers (CSS11 for example), adding more invited experts that are willing to spend their time on this and/or having a place where designers can post and discuss mock ups of what they want to be able to do with CSS3. CSS3.info for example could create a wiki where screenshots of desired effects for CSS3 properties could be added by designers, and the merits debated. New proposals could also be added. The WG could then refer to that site for ideas and to solicit feedback. I personally think that the HTML5 working group has far too many invited experts, so limiting the group to a select number, but allowing anyone to leave feedback would be more ideal. It is important that feedback is gained from multiple sources however – the needs of a Japanese designer is probably very different to the needs of a British designer, for example.

Speed of CSS3 development and relevancy of proposals

Furthermore, the speed of development of CSS3 must improve. Making the process more open to inspection will help this by making it harder to use stalling tactics. Action needs to be taken here – I’ve tried to get designers to send me feedback on what standards features they’d like to see in Opera first, but this is difficult, and I received little response. What we need to do is set clear priorities of CSS3. First we need to get the ’07 snapshot finalised (it is currently in Working Draft) and get browser vendors to implement those modules. This is going fairly well at present in three out of the four major browsers. It could also be going well in IE8, but we’ll have to wait to find this out.

In parallel we need to get a list of what properties designers most want to be able to use. Gather the most talented spec writers in the group to work full time, or as much as their employers allow, to mature those specs. It can be finer grained than a whole module, if other parts of that module have issues and are not related to the core properties that are needed. At each iteration, designers should review the progress to see if is moving in the right direction, and the feedback solicited from the working group if there are questions. Properties that have reached proposed final form should be marked as such, even if the rest of the module isn’t ready. These should then be given to the vendors to implement with the dash vendor prefix. Test cases should be built in parallel. Vendors should submit all that they have, while designers should help with this process if possible. The more test cases, the more likely it will be interoperable and the standard will be finalised sooner. These properties or modules should then be added to the CSS snapshot for the current or next year.

One question will be definitely be asked – which modules should be made a priority? Vendors will have an opinion on this, as it depends on the aim of the browser. Apple and Opera will care more about Media Queries than a vendor without a mobile browser, for example, but largely I think this should be down to the design community. If we had a public wiki to discuss this on, I’d suggest the modules or properties with the most active suggestions would be up there, while ones with no activity would be pushed to the bottom. Through the feedback I have collated, designers preferences seem to be borders & backgrounds, selectors, multi-column layout and web fonts, and there has also been interest in the grid layout (although this seems to be the furthest back in terms of both spec and implementations).

Another issue is who will work on these. That isn’t a question I can answer, but if we can somehow get the existing working group to be able to spend more time on it that will help. I’m willing to help out if desired. It should be easier for big companies such as Yahoo! to supply people to represent designers as they have the resources. The problem is that many of the most highly regarded and vocal designers are freelancers that can’t afford to give their time for free. We need to find a solution for this, be it through sponsorship or other means.

Can browser vendors work together?

The other concern that has been raised is that, in light of Opera’s complaint against Microsoft, the browser vendors wont be able to work together. I don’t believe this to be the case. Håkon has stated he has no problems with Microsoft employees, and I’ve personally heard him say he has great respect for the likes of Chris Wilson. I’ve also heard the same coming from Chris. I know or have worked with the likes of Chris, Markus Mielke and Joshua Allen for a while now, and I very much hope that continues. I’m sure they’ll also agree.

Conclusions and the way forward

What we need most of all is action and not talk. I propose the following:

• Get a priority list of CSS3 modules or properties hammered out for both the W3C and the browser vendors
• Get the modules included in the ’07 CSS snapshot to recommendation stage, and push browser vendors to implement them
• Aim to get these priority modules ready for the next CSS3 snapshot (’08)
• Put a mechanism (such as a Wiki mentioned above) in place to give feedback on the issues the WG come up with
• Promote the said mechanism to developers in multiple countries, such as those that use none-latin scripts, and right to left text
• Re-engage the Web Standards Project (WaSP) to take an active role in the activities
• Get the W3C to open up the private communications of the WG, so there is transparency for all to see. Post communication on the Working Group blog or another suitable medium
• Get an official statement from each of the browser vendors on the working group that they are willing to work together in a co-operative and unhindered manor
• To ensure a fair balance between designers and browser vendors on the working group, build a short list of respected designers or developers who should represent designers on the working group. We can get a respected designer like Molly or Zeldman to propose people, again making sure there is diversity of opinion.
• Find a way to fund these designers, either through W3C funds or corporate sponsorship
• Ensure the chosen designers can commit the required time to the project
• Ensure there is at least one designer assigned to each of the modules that are deemed a priority

Opera’s complaint against MS caused quite a bit of stir in the CSS related parts of the blogosphere. Andy called the CSS WG the CSS un-working group, H&akon updated, complaining that “we didn’t get it”. You know what? I, personally, couldn’t care less about all this nonsense.

What we need, and not just we at css3.info, but all of us, is to get working on making those specs work. That means getting test cases for CSS 2.1, and making sure that complete spec is usable, because there are still parts of it which are found, by browser vendors, not to be usable. Next to that we need to focus on getting CSS3 off the ground. Controversy and this kind of bickering amongst each other is NOT going to get us there.

So what DO we need? As Fantasai put it, we need “a way for average users to run tests and generate reports off the official CSS test suites”. Here’s where I ask you guys and girls to help. We have some input, the system might work something like this system. This system shows people a test and asks whether it failed or passed, and uses that data to generate a report based on the user agent string. Now I know we have some bright readers. Who of you would be willing to help improve this system / build a system like this?