CSS3

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.

Finally, what feature should it include? For me, it has to be the elements which have already been implemented and tested in at least one browser for an amount of time sufficient for developers to have used them.

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.

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.

With IE7 introducing support for attribute selectors, roughly 50% of the market can use those. You will still have to provide fall-back support for IE6, however, either with conditional comments or through graceful degradation.

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 the release of Safari 3, there are now two browsers with (browser-specific) implementations of border-radius; unfortunately, the two implementations are different. The problem is that there is an unresolved ambiguity in the CSS 3 working draft.

The draft proposes four declarations, which describe the four corners of a block:

border-top-left-radius
border-top-right-radius
border-bottom-right-radius
border-bottom-left-radius

Each of them should accept two values, which define the radii of a quarter ellipse that defines the shape of the corner; this allows for irregular curves (take a look at the diagram in the draft if you need clarification, or see this example of a box with border-radius: 5px 20px, horribly rendered in Safari for Windows).

Safari, with the prefix -webkit-, accepts these. Mozilla, with the prefix -moz- (and differing declarations), accepts only a single value and, therefore, only regular curves.

At first glance, it would appear that Mozilla are in the wrong; however, their implementation is due to the ambiguity I mentioned earlier.

This ambiguity comes about in the border-radius shorthand property; if you enter a double value in this you’d expect to apply the irregular curves to all four corners:

border-radius: 5px 10px;

If you wanted to have four different irregular curves on the box, you’d have to provide eight values to the declaration:

border-radius: 5px 20px 10px 5px 10px 20px 20px 5px;

But what if you wanted to have two corners with one value, and two corners with a different value?

border-radius: 5px 10px 10px 20px;

The problem is that this could be confused for four corners with regular curves. In order to get around this, you’d still have to provide eight values:

border-radius: 5px 5px 10px 10px 10px 10px 20px 20px;

In fact, from the brief testing I’ve done (and I can’t find any documentation), it seems you can’t do any of that; unless I’m missing something, the shorthand declaration in Safari accepts only 1 or 2 values, to provide either regular or irregular curves which are applied to all four corners. If you want different irregular corners, you have to supply values to all four declarations:

border-top-left-radius: 5px 20px;
border-top-right-radius: 10px 5px;
border-bottom-right-radius:  10px 20px;
border-bottom-left-radius:  20px 5px;

Mozilla avoid this by going against the spec and allowing only regular curves; so you can provide 1, 2, 3 or 4 values and it’s all perfectly clear.

This problem is down to interpretation of the draft. I personally think Mozilla’s non-standard solution is better – it’s less flexible, but easier to understand – but can’t blame the Safari team for following the standard in their implementation.

It will be interesting to see which comes out on top; in the meantime, if you want to use border-radius in your code the only way to get them to appear the same on both browsers is with a single value for four regular corners:

-moz-border-radius: 10px;
-webkit-border-radius: 10px;

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.

Recently we mentioned Andy’s call for a new intermediary version of CSS, which includes all the most commonly implemented features of CSS3. This led to a fair bit of discussion in the community, so we asked Andy for some clarification of his suggestion (there’s more on his own blog too), as well as a few more thoughts on the future of CSS.

After the issue of the overhauled CSS3 Text module recently, I wonder if the Fonts module is due for similar treatment? The current working draft states:

The working group believes this draft is stable and it therefore issues a last call for comments, before requesting the status of Candidate Recommendation for the draft. The deadline for comments is 30 August 2002.

Four and a half years ago! That’s a long feedback process!

The module introduces a few new features into the coder’s lexicon, and although none of them are truly essential, they would be very useful; there is so much text on the web, but typography is the least-developed aspect of CSS.

font-size-adjust lets you preserve the height of type even if the user doesn’t have your first-choice font installed. Certain fonts have higher height aspect than others, so type that you’ve carefully styled to appear at a certain height could suddenly appear smaller if font substitution was used. font-size-adjust let’s you overcome that problem. The module provides some examples of font height aspects.

font-stretch is useful when displaying font families with condensed or extended faces, such as Arial. You can select absolute (condensed, extended, etc) or relative (narrower, wider) values.

font-effect allows you to apply ‘special effects’ to your font; choose from embossed, engraved, or outlined text.

font-smooth switches anti-aliasing on or off. Fonts look so ugly without anti-aliasing, I can’t imagine a situation where you’d ever turn it off!

Finally, three declarations with limited use outside of East Asia: font-emphasize-style and font-emphasize-position, along with the shorthand font-emphasize. These are used only to set emphasis on East Asian characters.

Will this module make it to recommendation in this form? Or will it make a comeback in altered form? I suspect the latter. But I think the most radical change to web typography will come not from the implementation of this module, but from the implementation of @font-face, which will facilitate the use of non-core fonts.

By the way, anyone interested in web typography should, if they haven’t already, read Richard Rutter and Mark Boulton’s Web Typography Sucks presentation. It’s a 4MB PDF download, but well worth ten minutes of your time.

Back in May 2003, the CSS3 Text Module made it to Candidate Recommendation status, meaning:

[The] W3C believes the specification is ready to be implemented.

Before it made the next step to Proposed Recommendation status, however, it was decided that a complete overhaul was needed. Four years later, and the renamed CSS Text Level 3 has been issued as a Working Draft.

This module:

… defines properties for text manipulation and specifies their processing model. It covers line breaking, justification and alignment, white space handling, text decoration and text transformation.

This is still a very rough document, with some intended declarations not defined yet – text-overflow, for example. You can see how it differs from the previous version with this list of changes.

The W3C has updated the working draft of the CSS3 module — Generated Content for Paged Media.

It’s all gone a bit quiet round here… sorry about that, but there’s not a lot of movement on CSS3, and I know the authors here are quite busy personally.

Anyway, potentially big news is that the WHATWG are asking for developer feedback on HTML5.

I’m still wading through the document, but of what I’ve read so far, of most interest to CSS fanatics will be a group of new, semantic tags; for example

Of course these aren’t directly related to CSS3, but it should help save a lot of classes, ids and tag soup if implemented – and that’s the key. Even if it turns into a recommendation, how long until HTML5 is supported in IE – if at all. Many questions, many variables; but stay positive, and give your opinion.

Bert Bos announced on the www-style mailinglist that the CSS3 Paged Media module Working Draft (WD) is now in Last call status, which means that it will probably advance to being a Candidate Recommendation (CR), according to the W3C development process.

This module contains ways to define pages and printing behaviors for them. Read the announcement and the module if you’re interested.

Eric Meyer, in one of his latest posts in the W3C change series, proposes quite a radical change for the W3C: full independence.
The article is well worth a read, coming from one of the people with the most insight in to W3C operations, and I agree with him: it’s a very good idea. Let’s hope more people think of it that way, and let it happen!