CSS3

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!

Håkon Wium Lie, the inventor of CSS answers some very interesting questions about the future of CSS in this article.

Probably the first CSS3 Module to become a full recommendation will be Selectors; the W3C CSS3 Roadmap reports that the date for release is March 2006, so it’s overdue already.

Due to the fact that it’s passed all the previous testing stages, many CSS3 Selectors have already been implemented in modern web browsers; Mozilla, Opera, Safari and IE7 all recognise at least a few of them.

We’re putting together a table of levels of CSS3 Selectors support in browsers; it’s still early and the testing is by no means exhaustive, but it should act as a good guide for those who want to start to implement CSS3 in their web pages.