CSS3

I recently posted a preview of the CSS3 colour module on my own blog, but avoided using any actual examples. This was because of the things that have been implemented, the true power isn’t really seen using a simple example. With opacity and the HSLA/RGBA colour models, any elements that have been coloured just look like they fade to a lighter tint if there is only a white background behind it. Support for SVG colour keywords has also existed for a long time, just without being accepted by the validator.

To show the true flexibility of CSS3 colour, I had to build a more complex example with overlapping elements. I also added a number of other CSS3 properties to show case them while I was at it (Why not?). Due to using a lot of transparency, there are a number of issues with Minefield, where it crawls to a hault then eventually stops responding. This may only be a issue with the Mac build or my hardware, so your mileage may vary. There shouldn’t be any issues with using webKit, except for a number of bugs that I seem to have uncovered. Most of these were hi-lighted in my previous post.

Without further ado, here is the example for you to try out (warning large background image). It is based on a loose mock-up of a Mac OS X Leopard style interface. I needed a background image, so took a wallpaper from Michael Palin’s great Sahara series. The photo is copyright Basil Pao and is of a mother and her child in Tabelot, Niger.

Because the example was designed to showcase the various colour values, I’ve mixed between using opacity, HSL, HSLA, RGB, RGBA (both hex and percentage) and keywords. In a real production site I’d have avoided this and stuck with the same colour models where appropriate. I tend to use keywords myself as they are easier (for me) to remember. HSL (and by extension HSLA) would be very useful when greater control over the colour is needed, but at the current moment it isn’t supported enough to be used. The correct RGB value would have to be used anyway to act as a fallback colour.

The example showcases the difference between HSLA/RGBA and opacity. If you hover over the File or Go menus, I’ve added a sub menu that has opacity applied too it. When hovering over a menu item that is displayed over the white title bar behind it, you’ll notice the text is more white than the text with the mud background behind. This is because opacity is set on the foreground and well as the background. for elements that have been styled using HSLA or RGBA on the background colour, such as the faux-window title bars, contents area and menu bar, retain fully opaque text. While the difference isn’t too great with this example, there can be cases where the difference is quite obvious. It also allows things like just the shadows to have transparency.

I’ve included quite a lot of other CSS3 into the mix. There is liberal use of box-shadow to give the allusion of depth on the windows and title bar. Rounded corners have been added to windows. There is an issue with rounded corners, where if overflow is set (which adds scroll bars) then the corner with the scroll bar ignores the radius (or is displayed behind it). I moved the overflow to a div inside the faux-windows to avoid this problem. I’m not sure how browsers can be fixed to avoid this problem without the spec changing to accommodate things like scroll bars. resize was added to both faux-windows, but there is issues with each element inside the window being resizable independently in Safari, and not being able to resize it smaller (the later wasn’t an issue in earlier builds).

One of the big compatibility issues with current browser support is the difference between overflow using multi column layout. In Safari it doesn’t respect the setting of having two columns, by adding extra columns to the right of the visible columns. This seems smart at first as it avoids the issue of having to scroll to the bottom of the first column and back up to the start of the next column, however it is generally harder to scroll horizontally than vertically. You can also imagine if a height was set and overflow wasn’t used then it could push any content to the right of the columns out of view, such as a right hand side bar. Minefield just uses the two specified columns and makes the content as long as needed. This has issues as you get the scrolling problem mentioned previously. This will be a usability annoyance. My only suggestion is that a column height can be set, and when all available space is taken up without scrolling, a column break is inserted and columns of the same width and height are repeated below until the content runs out. There would have to be some way to specify the vertical column gap though. This would solve the readability issue, a one block of columns could be read at one time, and it will stop and important right sided content (or left in rtl layouts) from being pushed off the screen.

The next CSS3 used was background-size. This was set at 100% so that no matter how big or small the browser window is, all the background image is shown (overflow:hidden; had to be added as the very latest versions of WebKit add scroll bars, unlike previous versions). This currently only works in WebKit. While most of this works fine in WebKit (if you ignore the bugs), one thing that only works in Opera and KHTML is the menu separators. Instead of adding mark-up such as a br I used the nth-child selector to select the exact element where the separator should go, and added the appropriate margin, border and padding. Without there being an element to group related list items, I though this was the best way to go about it, plus it was another excuse to show off more CSS3. Finally I used a attribute selector to grey out the print menu option (or any option in the menu with a URL of #). This is a bit of a hack to demonstrate the technique, but you can see how it could be useful in the real world.

The great power I see coming with CSS3 is that this example looks fairly complex and flashy, yet only uses one image (the background image), and the mark-up is very brief. I could have used even less mark-up and ID/Class attributes, but they were added for semantic meaning. The problem is more that the browser has to do much more processing to work out things like the transparencies so there can be performance issues, especially on older hardware. One can expect that performance will be tuned as support for the new properties are included in final releases.

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.

While preparing an example of using the colours specified in the CSS3 Colour module, I come across something after Minefield (the nightly builds of Firefox 3) updated itself. It now supports the resize property from the Basic user interface module.

Unfortunately, Minefield loads, then freezes and eventually doesn’t respond when trying to use this. This is unsurprising of a nightly release, and was likely due to the other CSS3 properties I was using on the example. The strange thing however is that the examples on the css3.info resize preview page do not work at all.

I decided to strip out a lot of the extra styles and content that I was using, and have an example where resize works both in WebKit and the latest Gecko builds. As this is part of another example that isn’t quite finished yet, there are a number of bugs, which may or may not be my fault. There are also a number of styles which probably don’t need to be there, but are part of a bigger example, that will be coming soon. I just wanted something quick that would show this in action. Feel free to suggest any improvements.

You can check out the resize example here.

So what are the issues? In the example I wanted to make a faux window, much like a desktop application window. The whole window should be resizable as one block. For this I placed the resize on the app-window div. The main contents of the window had to be scrollable when there is too much contents for the size of the window, but the rest of the contents shouldn’t scroll, such as the title bar (a h2 element). Therefore I put the scroll on the contents div.

In Safari there is a problem where both the h2 title bar and the main contents resize independently of each other. There doesn’t seem to be a way to resize the whole containing div where the resize is set. In Firefox this works correctly (or at least how I expected it to work). In Safari the content also can’t be resized smaller that the initial value of the div. This wasn’t an issue in an earlier build I was using while developing the example.

Minefield can be resized down to the minimum size and width requested, but it only resizes correctly horizontally. The div resizes vertically but the containing content div doesn’t resize at all. This may be a bug of mine as the contents seems to break out of the container slightly at the bottom. I haven’t had time to look into this.

One strange thing about Minefield’s support for resize is that it adds a cross-hair icon that allows one to move the contents around the page. This works correctly, unlike the resize, but I can’t find anywhere in the spec which specifies this should be allowed when using resize and it isn’t expected behaviour, or at least I wasn’t expecting it, and I didn’t specify that the div should be moveable. It would be nice to be able to specify this with a different property however.

Also, as I use a Mac, I expect the content to be only resizable from the resize widget on the bottom right hand corner (for better or worse). Minefield ignores this and has its own controls, which can’t be styled as far as I know. I also can’t remove the resize controls after clicking out of the resizable content. They stay until the page is reloaded. As resize has probably just been implemented, it is expected that their will be a number of bugs like this however, so things should improve as more people test out this and other CSS3 properties. Resize with HSLA/RGBA and overflow: scroll; is particularly buggy for instance.

I’m working on the original example, that I’ll post here at a later date, along with an updated version of the overview of the CSS3 Color Module that I posted on my personal blog recently. I guess I’ll have to report the bugs I’ve found to the appropriate places, unless it turns out I have bugs in my code instead.

I mentioned earlier this year a tutorial which shows how to use CSS 3 selectors to enhance hyperlinks. Of course, you don’t need to limit yourself to just the href attribute; with CSS 3 selectors, you can use the same technique for any tag which has an attribute. I’m going to give a couple of quick examples, which will output the following result (of course, you’ll need a browser better than IE6 to see them!):

• Home
• Download a PDF
• En Français

All icons are from the fantastic collection at famfamfam.com.

The first list item uses the general attribute selector to look for any tags with an accesskey attribute and display an icon to alert users to its presence:

#test_selectors a[accesskey] {
background: url('icon_key.gif') no-repeat 0 50%;
text-indent: 20px;
}

The second item looks for links with a type attribute value of ‘application/pdf’ (you do mark up links to documents using the type attribute, right?) using the exact attribute selector, then inserts an icon advising you of the destination document:

#test_selectors a[type='application/pdf'] {
background: url('file_acrobat.gif') no-repeat 0 50%;
text-indent: 20px;
}

Finally, if you have a multi-language site you can link to another version using the lang attribute with the value of that language, then use the language attribute selector to apply that country flag:

#test_selectors a[lang|='fr'] {
background: url('fr.gif') no-repeat 0 50%;
text-indent: 20px;
}

As always there is much more you can do with the selectors; if you use or develop this idea on your site, post links here for us to see.

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;

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.