• 200725 Jul

    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.

  • 200710 Jul

    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.

  • 200709 Jul

    I’ve written a number of posts about CSS3 on my personal blog, so when I was asked to write on CSS3.info I jumped at the chance. To get the quick disclaimer out of the way, my day job is working for Opera Software as their Chief Web Opener. Any thoughts are my own, and any use of CSS3 properties doesn’t imply that they will or will not be supported by Opera in an upcoming release, unless otherwise explicitly stated.

    With that out of the way, I was discussing the difference between opacity and RGBA in the office, and thought that it would be useful to write an example showing what the later can be useful for. In the main part, using RGBA is different from opacity, as the transparency only applied to the property you are setting the colour of, while opacity sets the transparency of the entire element. For example, setting opacity on a p element will set text as well as the background colour to the setting chosen, while setting RGBA will only make the background colour transparent, and not the text, if background-color property is used. I decided that overlaying a text block over an image would show this quite well, so I’ve knocked up an example using this to style a figure contain within an article. This example can be found here.

    To mark-up the figure, I wrapped the img and the p containing the caption in a div element. While this wasn’t strictly needed, I feel like the figure is a division of the page, and so give some semantic meaning and convenient grouping of the figure’s components. I gave it the class name of figure as suggested in Dan Cederholm’s blog post on marking up figures and Chris Messina’s post on a similar topic. I then added a class of caption on the caption, to state explicitly what the element contains.

    The first important point to note when using CSS3 is that only the very latest browser versions support any given feature, if any do at all. Therefore as Peter points out in the previous post, it is important to use graceful degradation. this is especially important when using RGBA colour values, as browsers are instructed to ignore the CSS statement if it doesn’t understand the Alpha channel part. It doesn’t fallback to just using the Red Green and Blue channels. In the example used here, the figure caption has been set to red with a alpha channel value of 0.6, using background-color: rgba(255, 0, 0, 0.6);. A value of 1 would mean the colour would be fully opaque, while 0 would be fully transparent. For browsers that don’t support RGBA, there would be no background colour at all, and the text would be illegible. To solve this, a regular background colour is given, in this case background-color: red;. This has to be included before the statement using RGBA, so that it will be overridden by browsers that do support RGB with Alpha channel.

    To get the caption to overlay the image, the paragraph in question was set to use position: relative;, and given left and top values that position the element in the correct position; in this case the bottom right corner of the image. A positive z-index value was given to ensure that it was displayed above the img element. I was tempted to use em values for the sizing and placement of the caption and the padding/margin of the figure, but as the image uses pixels for it’s height and width, it made the cross browser placement of the caption inconsistent across the browsers tested (Opera, WebKit, Minefield). Even using pixels, Minefield (current nightly of Firefox 3) is 1 pixel out on the vertical placement compared to Opera and WebKit. I’m sure there is probably a better way to place the element than what I’ve used in this example.

    As this blog is about CSS3 I added a couple more features. I gave the caption a slight shadow (okay, not strictly CSS3) using text-shadow: 2px 2px 2px black; (This works in Opera Kestrel and Safari) and gave the whole figure a slight 3D effect by specifying a shadow around it. This was done using box-shadow. In truth no browser supports this without prefixes but Safari 3 supports it using -webkit-box-shadow. I also initially added a CSS3 selector to style the first line of text in the article as bold, using .content p:first-of-type:first-line. Unfortunately Safari 3 currently has a bug where it will apply this to every p and not just the first one, while Firefox totally ignores it as it doesn’t support the first-of-type selector. Safari will probably fix this bug before version 3 is released as I noticed they’ve just fixed a similar bug with using p:first-of-type:first-letter, but as I can predict when the first paragraph will come in this example (after the figure) and it works across each of the three browsers I tested, I just settled on using .figure+p:first-line. If anyone has any questions comments or has any better way of doing things, then feel free to leave a comment.

  • 200728 Jun

    Graceful degradation means that your Web site continues to operate even when viewed with less-than-optimal software in which advanced effects don’t work.

    Fluid Thinking, by Peter-Paul Koch

    With CSS 3 so tantalisingly close (and yet so far away!), it’s fun to play around with some of the new cosmetic features. In fact, we can even start to implement them on websites – as long as provision is made for users with older browsers.

    I’ve made a quick example of a horizontal, tabbed navigation using CSS 3, which degrades gracefully for older browsers.

    Here’s the markup:

    <li><a href="">One</a></li>
    <li><a href="">Two</a></li>
    <li><a href="">Tre</a></li>
    <li><a href="">Qua</a></li>

    The CSS is quite lengthy, so view the source of the example page and you’ll get some idea of what I’ve done.

    If you’re using IE6, you’ll see just a row of plain, grey boxes which don’t animate when you mouse over them. IE7 and Opera users get a slightly better experience, with the text going white when hovered:

    li:hover a { color: #fff; }


    Firefox and Safari 2 users get it better still, with border-radius and multiple backgrounds respectively supplying curves to the tabs:

    li {
    url('corner_fff_topleft.png') no-repeat top left,
    url('corner_fff_topright.png') no-repeat top right;
    -moz-border-radius-topleft: 25px;
    -moz-border-radius-topright: 25px;


    It’s when you get to Konqueror (and, presumably, Opera 9.5), however, the new styles really kick in; use of the nth-child declaration allows for alternating colours, and text-shadow give a slight illusion of depth when hovered:

    li:nth-child(1n) { background-color: #9f9; }
    li:nth-child(1n):hover { background-color: #0c0; }
    li:nth-child(1n):hover a { text-shadow: 2px 2px 2px #000; }
    li:nth-child(2n) { background-color: #6f6; }
    li:nth-child(2n):hover { background-color: #090; }


    This was a very quick and easy example, but I’m sure you can imagine much more creative uses for graceful degradation. It’s a useful technique if you have the time to implement it, and comes in very useful when trying to persuade people to upgrade to a better browser: “If you think that website looks good now, take a look at it on my computer!”

  • 200719 Jun

    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:


    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;
  • 200708 Jun

    I’m at @media 2007 at the moment, and just watched a very interesting presentation by Håkon Wium Lie – who, as we know, wrote the original specification for CSS, 13 years ago.

    In his presentation he talked about Opera on different platforms, then went into the future of HTML and CSS, talking about the HTML 5 spec, the new <video> element, @media queries, the CSS 3 paged content modules, multiple-columns, and much more.

    I asked him what he thought of Andy Budd’s call for a CSS2.2 specification, and he said that he was all for it – now that’s an influential ally!

    He also let slip a heavy hint that the next release of Opera (or at least an imminent release) will support the @font-face declaration, enabling us to finally break free of the limited font set!

    It was a very interesting talk that touched on many more subjects, some of which I may return to later.

  • 200703 Jun

    The header of my own blog (still in development; please don’t judge me!) features a single image which spans two columns, with a semi-opaque panel featuring text over the top of it. I wanted the image to be clearly visible in the left column, and faintly visible in the central column. I could have done this by designing it that way in a graphics package, but as I intend to swap the image around in future, I wanted to come up with a client-side solution.

    I could have just used a semi-opaque background image, which would have worked immediately with all major browsers bar IE6. But I didn’t want to use an extra image and I wanted to play around with CSS 3, so this is what I came up with:

    Firstly, I put the image as a background property on the <body> element. Next I created an empty, presentational <div> with a class of ‘header’. To this I assigned the colours and border colours, then gave it a large left-margin to allow the image to completely show through on the left column, and an opacity of 0.9 in order to allow the image behind to faintly show through on the central column.

    The problem with opacity is that it is inherited by all child elements, so if I had put text inside div.header, the text would also have become semi-opaque. To get around this I assigned position: relative to the <body>, then wrapped another <div> called .title around <h1> and <h2>, put it after .header, then absolutely positioned it where I wanted it to appear:

    <div class="header"></div>
    	<div class="title">	
    body { background: white url(images/header.png) no-repeat; }
    .header {
    border-top:60px solid #4A5C61;
    .title {

    Opacity doesn’t work in Internet Explorer, of course; I could have used a proprietary filter, but decided that the 19% of visitors to my site who use Internet Explorer wouldn’t suffer by not being able to see the whole image; it would be a little ‘bonus’ for whoever uses a better browser (here’s an image if you’re using IE and want to see what other users see).

    Another solution was available to me; keep the <h1> and<h2> inside .header, and use rgba values on it instead. This would be better semantically as I could drop .title, and wouldn’t involve any positioning as rgba values are not inherited. I could have used the following code:

    <div class="header">
    body { background: white url(images/header.png) no-repeat; }
    .header {
    background-color: rgba(141,204,58,0.9);
    border-top: 60px solid rgba(74,92,97,0.9);
    margin-left: 20%;
    padding-top: 20px;
    h1, h2 { padding: 0 7%; }

    While this is obviously leaner and quicker, support for it is not as widespread; at the time of writing this, perhaps only 4% of my visitors would see the effect I wanted.

    My two most extreme options were to have added extra styles and conditional comments to the document in order to getting working across all browsers, or to use the purer, smaller CSS3 to get it working on only a tiny amount of current browsers. In the end I did what we’ve been doing for so long now, and made a compromise.

  • 200712 Apr

    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?

  • 200707 Mar

    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.

Page 4 of 6:


Advertise here?