CSS3

Apple surprised a lot of people by releasing Safari 3.1 today (myself included!), and amongst its list of new & improved features (audio and video tags! SVG in img and background-image!) are two which will be of interest to readers of this blog: full CSS3 selectors support, and web fonts.

The first means that Safari now supports the missing nth-child / nth-of-type selectors, which are useful for styling tables and lists (amongst others), and also now passes our Selectors Test (which, while by no means exhaustive, is very useful). Opera 9.5 will also support these selectors; Firefox 3 probably won’t, IE8 is unknown.

The second is the more exciting to me, and I’ve already written a quick introduction (with example) on my own blog. In a nutshell, you can now embed fonts in your pages to display even to users who don’t have that font installed. There’s a longer article with more examples on A List Apart.

We’d known most of this was being implemented by Webkit/Safari, but had no idea it would be coming so soon. Congratulations to the whole team, and here’s hoping it serves as an example to the other browser makers.

Daniel Glazman has created a new test to show CSS3 Selectors support in your browser. He has also posted results for current browsers.

With this and the Acid 3 test, there’s a lot for browser makers to aim for.

Mozilla’s John Resig has removed support for certain CSS3 selectors from the jQuery Javascript library, and says the fact that no-one has asked for them to be reintroduced is evidence that they aren’t very useful:

Now, I’m sure I’ll probably get lots of feedback saying “but ‘E + F’ can be useful, look at this example” or “of course ~= is useful, you can use it on rel attributes” – that’s not the point. The fact is that they are woefully un-used. To the point that they are a burden upon the implementors of the specification. What’s the point of implementing the above features – or more importantly: optimizing the above features for speed – if no one is using them.

Daniel Glazman, who authored the original spec, says that John is looking at them from a purely HTML-centric viewpoint, that lack of support means that people haven’t really thought of using them yet, and that just because the majority don’t have a use for them, doesn’t mean that they are useless;

So we have here selectors that are not implemented yet or not interoperably and Web designers don’t use them. How surprising!!! In CSS, we have some features here to serve some typographic local constraints, because we saw a menu in a restaurant nicely designed and we needed a new feature to be able to make it in CSS. Serves a very little community of users. That community will NEVER show up in any stat. Is that a reason to drop the feature? You don’t see a wide community of users for a given selector? Is that a reason to drop it? CERTAINLY NOT.

I’m with Daniel on this one; the key point for me is that the support for them at the moment is so limited that we haven’t yet seen what the talented development community can do with them. I’m sure I, as a front-end HTML developer, won’t use them as frequently as the existing selectors, but I already use some of them infrequently and look forward to using them more.

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.

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’m working on the CSS3 Backgrounds and Borders module with Bert Bos, and I’d like to start a new Q&A series because I think we need some help: This time I’ll ask the questions, and you give me answers. Ok? :) Since the CSS Working Group Blog currently doesn’t accept comments, CSS3.info has kindly allowed me to cross-post so you can write back. The first issue is a complicated one, so I’ll start with an easy question. The topic is drop shadows.

In the latest public working draft we have a box-shadow property. The point is, obviously, to be able to draw a drop-shadow for a CSS box. It starts to get complicated once you ask “what happens when there are semi-transparent parts of the box?” At first we figured ‘box-shadow’ should just draw the shadow as if the box was opaque. Then Dave Hyatt, who had started implementing this, started questioning that logic. We’ve got proposals for a ‘border-shadow’ property to shadow just the border and a ‘background-shadow’ property to shadow just the background color (but not the image?), etc. We could also just “shadow everything drawn in this element”. This all sounds rather complicated to me so I want to step back and ask:

What do you, the web designers of the world, want to do with shadows? What’s the end result you want to get?

Show me. Post a few links to stuff from your portfolio that uses anything beyond pure text shadows, even if it’s all done with pure Photoshop(/Painter/GIMP) graphics. Draw (or explain) a picture of what you want to achieve. Then maybe we can figure out how best to make it happen in CSS.

The Webkit team have certainly been busy recently; since we mentioned the introduction of web fonts, they’ve also implemented transformations and animations.

Transformations, via the -webkit-transform property, allow you to scale, rotate and skew block elements; reader Ain Tohvri has put together an impressive test suite. At the moment this property doesn’t affect layout, so behaves more like a relatively positioned element.

Animation, which uses the -webkit-transition family of properties, allows you to set timings for fades, rotation, expansion, collapses, and more. They work in the same way as many current JavaScript libraries.

I’m in two minds about this; while it’s always welcome to see more innovation from browser manufacturers, I can’t help but think that they’re focussing their energies in the wrong direction. As I mentioned above, all of the above effects can be replicated with JavaScript libraries, and I don’t think that CSS should be used for controlling behaviour so explicitly. Users who don’t like to see animated pages currently have the option of disabling scripts, but they won’t have the option of disabling CSS in the same way.

Also, IMHO, there are a more pressing areas of CSS that need investigating; the Advanced Layout or Grid Layout modules are more important to the future of CSS than animations and transformations.

On the positive side, the Webkit team have promised to release technical documents which explain the proposed spec in detail.

If these new features float your boat, you can test them out by downloading the latest Webkit nightlies.

As we mentioned at the end of last month, the W3C have released a working draft of their first annual snapshot. The snapshots are intended to show which specs are stable enough to be considered part of the current state CSS.

The 2007 snapshot is:

• CSS Level 2 Revision 1
• Selectors Level 3
• CSS Namespaces
• CSS Color Level 3

The browser with the least support for the snapshot is, as you’ve probably already guessed, Internet Explorer. Opera has implemented all of the new selectors, but doesn’t yet have support for RGBA & HSL/A colours, which both the forthcoming Safari 3 (Webkit) and Firefox 3 (Gecko 1.9) have implemented. FF3 doesn’t do well with many of the new selectors, however, which Safari does.

While it would be nice to have included text effects and backgrounds & borders in this snapshot, differing browser implementations means they’re just not ready yet.

Even if this working draft becomes a recommendation shortly, no current or imminent browser fully supports the modules contained within; and with Firefox 3, Safari 3, and Opera 9.5 due for release over the next few months, it’s not impossible that none will do so until the latter half of next year. It could even be the case that IE.Next swoops in to beat the others!

With the CSS Eleven set to provide feedback to the W3C over the next few months, the 2008 snapshot could be a little more adventurous than that of 2007.

The announcement of the formation of the CSS Eleven has caused quite a stir in the web development community, with a few questions raised over the self-appointed nature of the group and the way the announcement has been presented. One thing that everyone agrees on, however, is that there’s a clear and obvious need for their existence.

We spoke to Andy Clarke, respected designer and author, who announced the group’s formation (and explained it further here), and asked him a few questions about what we can expect from the CSS Eleven.

1. Please could you sum up very briefly for anyone who hasn’t read your introduction what the CSS Eleven is, and what you aim to do.

   One of the biggest challenges that the CSS Working Group faces is engineering solutions that meet the expectations of visual designers and developers. Leaving aside for a moment their other difficult tasks such as internationalization, understanding what designers need is a tough job; particularly as CSS gets more complex in the areas of layout, typography and other design related areas. The members of the working group, largely technical people, need help. They need practical help to understand what designers need, and in detail. This help cannot come simply from reading emails that are sent to them with suggestions. So far, the channels of communication between creative people and the CSS Working Group have been difficult and many people that I speak to feel that a new way needs to be found to get the designer’s voice heard and their needs understood.

   CSS Eleven is an informal group of visual designers and developers who have agreed to give up a little of their time to helping the CSS Working Group to understand what we need from CSS in the future. We will help by making suggestions, but more importantly by providing clear, real-world, visual, graphical examples of the results of the CSS that we need and helping with making test suites; two areas that have proven very time consuming in the past.

   Are we the only group that the Working Group will listen to? I hope not. We’re simply the first of what I hope will many ways that visual designers and developers get together to help make sure that CSS3 is what designers deserve it to be.

2. How will you arrive at the decisions as to which modules are most keenly needed?

   The decision to look at CSS Multi-Columns was purely mine as it is a mature draft with some features already available to test in some browsers. In the future I’m sure that efforts will be focussed on the modules that matter most to us as visual designers (personally, I’m particularly looking forward to seeing what happens with Advanced Layout). I’m sure that we’ll get lots of feedback and suggestions from the industry at large too.

3. Won’t it be hard to make judgements about implementation when there are no browsers available to test the more advanced features on?

   Of course implementation is important, and we would hope that the browser makers on the CSS Working Group will help us all they can by continuing to implement new features. For me as a visual designer, describing the features that I need from CSS visually is one of the most important jobs that I can do to help the development of CSS. We need clear, real-world visual examples from people who also understand CSS from an everyday working perspective. I’m sure that with so many great people volunteering, there will be plenty to work on.

4. What kind of timescale are you looking at for releasing the first batch of recommendations?

   I would think that we will two months working collaboratively on CSS Multi-Columns, after which I expect that we will open the wiki (or some similar facility) to a wider audience for a month before wrapping things up and handing it to the CSS Working group. Of course everybody involved is volunteering some of their valuable time, so time-scales may change.

5. Which aspect of CSS 3 are you personally most looking forward to?

   Grid Positioning and Advanced Layout will help to solve many of the problems that designers face every day using CSS. There has been a little confusion about the role of Grid Positioning and its relationship to Advanced Layout, but both are exciting developments that I am looking forward to seeing.

The CSS Working Group recently met face-to-face in Beijing, and have released a series of notes about some of the issues they discussed regarding the current and future states of CSS.

One interesting possibility that was raised is to allow rotation of page elements; according to the original proposal, these are some of the possible use cases:

1. rotate a block of text 90 degrees as for a tab on left of page
2. rotate an image (or block of text) an arbitrary amount
3. use rotated column headings for narrow table columns

It must be stressed that this exists purely as an idea at the moment, so we won’t be seeing it any time soon. Still, it would create many new possibilities in web design.

Following our discussion of the inherent ambiguity in the border-radius declaration, it has been decided that the simpler syntax used by Mozilla will used for the shorthand; that is, in order to apply elliptical corners on elements, you will have to declare them all separately. I think this is a good decision, and I’m delighted that the CSSWG have listened to the views of the community. A pat on the back for everyone involved!

Finally, the CSSWG are to release an annual(?) snapshot of modules considered stable, in order that browser makers and developers can begin to implement them. The 2007 snapshot will include:

• CSS2.1
• Selectors
• CSS3 Color
• CSS Namespaces

The 2008 version is likely to include Paged Media and Media Queries, and possibly Ruby and Backgrounds and Borders.

So that’s the state of CSS today. Interesting stuff; many thanks to the CSSWG for making it all public.