CSS3

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 latest Webkit builds now support an open implementation of the @font-face rule, which we wrote about some time ago. Recent articles by Håkon Wium Lie had indicated that Opera might be first to market with this, but the Webkit team seem to have beaten them to it.

In short, @font-face allows you to download fonts to the visitor’s browser, meaning you can use any licensed font to display your pages. An example of use would be:

@font-face {
font-family: 'The New Font';
src: url('http://www.example.net/newfont/');
}

It’s a step forward for the web, and I’m delighted it’s here. Congratulations to the Webkit team, and here’s hoping that Opera push forward with their plans to implement it too. It seems like Firefox 3 won’t support this rule, so late 2008 may be the earliest we see this in Mozilla browsers.

As for Internet Explorer, they’ve actually implemented @font-face since version 4! However, it only works with their proprietary font format, .eot, and never took off. I wonder if they will reimplement it with Open- or True-Type fonts now.

@font-face isn’t actually new in CSS 3, it’s been around since CSS 2. However, as it’s never been properly introduced I think it’s okay to include it here!

Until the Advanced Layout and Grid Layout modules are implemented, we have to get by with the existing tricks of the trade. One of those is the use of faux columns, a background image which simulates equal-height columns. This is a good technique, but the drawback is that it only works with fixed-width columns.

That problem was overcome with the advent of liquid faux columns, which uses some background-position trickery and a bit of maths to create a variable-width effect.

With the (tentative) introduction of background-size in Safari and Opera, however, faux columns are about to become a lot easier; all you need to do is create a background image and assign a percentage value to background-size, allowing the image to expand or contract with its containing box.

Take a look at this example (only tested in Safari 3 and Opera 9.5; may work in Konqueror 3.5.7 also). If you resize your browser window, the text and columns should maintain their proportions.

The way this is done is with a simple PNG image; I’ve made it 1000px wide, with two coloured columns of 250px each, so that it’s easier to calculate column widths (25%,50%,25%).

I’ve set this as the background-image on the html element, which has been assigned a width of 90%. Inside this there is a container div with a width of 100%, and my three columns with the widths set at the same ratio as the background image:

<div id="container">
	<div id="one">
	</div>
	<div id="two">
	</div>
	<div id="tre">
	</div>
</div>

#container {
position: relative;
width: 100%;
}
#one {
margin: 0 25%;
}
#two, #tre {
position: absolute;
top: 0;
width: 25%;
}
#two { left: 0; }
#tre { right: 0; }

The html element has the background-size declaration applied to it, with a percentage value to make it liquid, using the browser-specific prefixes followed by the proposed declaration (for safety):

html {
background-image: url('opera_bg.png');
-khtml-background-size: 100%;
-o-background-size: 100%;
-webkit-background-size: 90%;
background-size: 100%;
background-position: 50% 0;
background-repeat: repeat-y;
width: 90%;

You’ll notice that the Webkit value is different from the others; during this test, it seems that Webkit obtains its width from the entire browser window, not from the containing element; therefore, we have to set this value to be equal to the width of the containing element. I haven’t tested this thoroughly yet, so I’m not sure if this is a persistent bug or if there’s something I’m doing wrong. Anyway, Opera 9.5 behaves as expected.

After that I’ve added the background-position and background-repeat declarations; background-repeat to tile the image down the page, and background-position because Webkit seems to ignore the margin values and puts the image at top left of the browser window; this is only necessary if you’re centre-aligning your page.

Apart from a little tidying up, that’s it; once the module becomes a recommendation and the browser-specific prefixes are dropped, it will require only a few lines of code for the simple effect. In the meantime, remember that this is for experimentation purposes only and shouldn’t be used in a live environment. This is just a sketch of the technique at the moment, and requires more testing.

Here’s the concluding part of our interview with Håkon (you can read the first part here).

6. Name the top five CSS3 features you’d like all major browsers to support in their next major release.

   Here’s some of my favorites:

   • Backgrounds and borders
   • Media queries
   • Multi-column layout
   • Selectors
   • Paged media

   Also, we must not forget Generated content, and tables from CSS2.1. These are great features that still can’t be used due to lack of support from one browser.

7. Do you think there should be a Acid3 that focuses on CSS3 features that designs want supported as soon as possible?

   Yes, I think it’s time for another Acid test — all major browsers but one (guess which one!) support Acid2 by now. I believe Acid3 should test CSS3 features that a critical mass of browsers can agree to implement. Also, it should probably test features from the upcoming HTML5 and the DOM.

8. Do you have a favourite designer who you admire their work, either from a design or technical respect?

   I can’t give you one name. I often show designs from the CSS Zen garden when I give talks; I like many of them.

   I can name two favorite fonts designers, though: Ray Larabie and Dieter Steffmann.

9. How do you think designers can get more involved with the CSS3 progress, to make sure features designed by designers themselves are added to the spec, instead of the features the spec writers might think are important? Is there a way this can be done without designers (many who don’t have much free time to spare) having to read through long mailing list histories and understanding a lot of very technical implementation details (I’m thinking such as having a appointed advisory board of designers for example that advise what features they want, and gather feedback from others, then the implementers can discuss this and come back with issues or start to draft specs for those features)?

   We’ve always encouraged designers to be part of the CSS Working Group, and there has always been strong designer presence in www-style. Many of the choices we’ve made along the way are based on input from designers. For example, you wouldn’t find Backgrounds and borders on top of my list if it hadn’t been for designers. The idea of an advisory board may be a good one.

10. How do you feel about being nicknamed “the father of css”?

    I often refer to CSS as my baby, and I’m fine with being called the father :-) It must be emphasized, though, that the child was shaped by a community. Bert Bos was the first to join the efforts, he came with a proposal of his own that we worked into CSS. Thomas Reardon and Chris Wilson of Microsoft were also influential in the time before the CSS WG and and the www-style mailing list was started.

11. What do you think of the Brazilian band CSS?

    Wow. Right. Change of mindset. Music, right? When it comes to music, I prefer Opera!

We’ve had some great interviews with luminaries of CSS-based design here on CSS3.info already, but this one is my personal favourite! Håkon Wium Lie, ‘the father of CSS’*, spared us some time to answer a few questions about the evolution of web design and the future of CSS. I’m so excited by this, I’ve almost forgiven our friends at Opera for not letting us have an early preview of Opera 9.5!

1. Is the use of web fonts the next big step in web design?

   Yes! Web fonts will be the next big thing if browsers start supporting them. Fonts are one of the core ingredients of design, along with space and colors. CSS is pretty good with space, colors, and fonts, but in the case of fonts the raw materials — the font files — are in short supply. Interestingly, there are lots of freely available TrueType font that authors allow us to use for free. So, I’m trying to connect the dots between web pages and the available fonts. I’ve written more about this in an article in Alistapart and you can play with web fonts in Prince.

2. With the current battles over copyright infringement with music and video on the web, can you imagine something similar occurring over the misuse of rights-protected fonts?

   Almost all the content on the web is copyrighted. It’s still available because copyright holders want it to be available. Sure, there are cases when the copyright holder has not given permission. But I don’t think anyone would argue that we should remove all images, video or music from the web for this reason? There are plenty of freely available fonts out there and no need to use fonts with resistant owners. Also, plenty of new font will be created open-source style if browsers start supporting web fonts.

3. Has web design turned out more or less the way you imagined when you wrote the CSS spec so many years ago?

   CSS was partly about design, and partly about markup. We — Bert Bos and I in the beginning, soon others — wanted to improve web design, but also to keep markup clean. I think the first part has succeeded quite well; I continue to be amazed by the things people are able to do with CSS. I’m less certain about the markup. But you didn’t ask me about markup, so I don’t have to answer for it :-)

4. Outside of web fonts, which part of css needs most work in your opinion? And why?

   Lots of work has gone into the CSS specifications. That will continue, but it’s not where work is most needed. What we need now are implementations — interoperable implementations. In order to get them, we need tests and testers. Lots of them. People who are interested in this subject should join the CSS testsuite mailing list.

5. If you could start all over again, what would you do differently in CSS?

   I’ve written a long PhD thesis, in part on that subject. That’s the long answer. The short answer is that we should have published a test suite earlier. We worked hard to get the CSS1 specification right, but implementors don’t really like to read specifications. They will work long hours, however, for so that their code passes a well-designed test. Eric Meyer came to our rescue and made sure CSS1 got a the test suite.

Part two of this interview, where Håkon discusses CSS3 and web design, will be available shortly.

* Maybe we should have asked him what he thinks of that nickname!

Struggling with the boxmodel sometimes? Need some help to figure out what the size of the element that’s troubling you really is?

John Allsopp has created the perfect solution to this problem. It’s a bookmarklet called XRAY, And you’ll love it. Click on it once to activate it, and click a second time on any element to display it’s box model!

What’s cool about it too is that it uses some CSS3 as well, including box-shadow, border-radius (webkit only), opacity and rgba!

So go check out XRAY!

I haven’t seen any official announcement yet, but it seems that KHTML and WebKit are to unfork. According to the linked article – which also provides an interesting history of the two engines – there is a bit of work to be done, such as importing KHTMLs advanced CSS 3 features, before the unforking happens, but it should mean that WebKit gains a lot more active developers, which can only be good news.

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.