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;

The W3C announced yesterday that they released new versions of the Multi-Column Layout module and the Media Queries module.

The last version of the Media Queries module dated back to July 8th 2002, so some time had passes since. The Multi-column layout module had been updated somewhat more recently, on the 15th of December 2005.

Changes to the Media Queries module

Other than quite a few new examples and the module being updated to the new look and feel, I can’t find much changes to this module…

Changes to the Multi-column layout module

This new version removes the property column-break-inside, which basically worked the same as column-break-before or column-break-after but for the inside (hah, you weren’t expecting that, where you?), and “replaces” it with column-fill.

It also adds the column-span property, which makes a lot more sense to me, allowing an element to span multiple columns. Example:

h2 { column-span: all; }

Good to see those modules updated, let’s hope they make it to final soon(-ish).

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.

Andy Budd gave a talk at this year’s Highland Fling web conference on the subject The Future of CSS (direct PDF download, 1.3MB).

Readers of this site will be familiar with most of the content (although it’s still worth reading), but two things stood out for me:

First, the use of simple calculations; I’ve thought for a long time that this would be useful, and I’m really glad that it’s being considered. Here’s an example:

#mainContent {
width: calc(100% - 200px)
}

Second, the call for a CSS2.2. As he says:

[There are] some really interesting things in CSS3. Many of them are fairly niche, with little demand. Many browsers already support the more interesting features of CSS3; Why not have an intermediary step covering the stuff people want?

I hadn’t considered it before, but it makes sense. Most browsers now support a small range of simple CSS3 features, so why not partition those off to an intermediate recommendation while the other, more complex features are worked on?

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.

First, here’s another table showing CSS support in web browsers, including CSS3 declarations. Unfortunately the author only seems to have access to browsers that run in Windows, so it’s not as complete as it could be. Interesting, nonetheless.

Update: I stand corrected. There are options to choose which browsers display in the table, which makes it very useful.

And here’s a demonstration purportedly showing an implementation of the text-overflow: ellipsis property using CSS and Javascript (read about the property here). Perhaps I’m missing something, but it only seems to work patchily for me in Firefox and Opera; I wonder how much testing it’s had.

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

Some of you might have noticed that this site is not valid CSS, which is of course a tid bit weird for a site as this… There’s a reason for this though. New CSS3 features are often “tested” by browser manufacturers by implementing them as vendor specific extensions. These are allowed by both CSS2.1 and CSS3, yet, the validator does error on them, even when it’s validation profile is set to CSS3.

In my previous post I don’t think I put enough emphasis on the fact that the Advanced Layout method may never happen; it could be dropped by the W3C, never implemented by the browser makers, or replaced by a better method.

However, let’s work on the assumption that it does get implemented and take a closer look.