The drawback of this is that it’s not ready for use just yet—browsers that don’t support SVG in background-image will not provide any fallback, even if you supply another background-image value; so in non-supporting browsers, no image at all will be displayed.

This was annoying me a little, and I couldn’t find any workarounds that didn’t use JavaScript. However, after a bit of head-scratching I’ve come up with a way to get around it.

In order to have browsers which don’t support SVG display a PNG image instead, you should use this code:

E {
background-image:  url('image.png');
background-image:  none,url('image.svg'), url('image.png');
background-size: 100% 100%;
}

Browsers which support SVG and multiple backgrounds will show the SVG; browsers which don’t support SVG will fall back to the PNG in the background-image stack. As far as I know, all browsers which support SVG also support multiple backgrounds; any which don’t (i.e. IE) will fall back to the PNG in the first background-image declaration.

Update: Thanks to a comment I have amended this technique. IE was not falling back to the first background-image as it should have done, but I got around this by adding a none value in the declaration. This invalidates the rule in IE and forces the fallback to the previous declaration.

You can see a demonstration of it here: Background SVG with PNG fallback — demo.

This technique is not without its own caveats, however. First and foremost, the SVG must not have a transparent background, or else the PNG in the background layer below it will probably show through. Also, depending on how fast the SVG file loads, the PNG file may show up first and then be covered over.

Finally, if you’re using the same background image at different sizes and either your browser doesn’t support background-size or you don’t want automatically resized PNGs, you’ll have to use the rule for each instance:

E {
background-image:  url('image-small.png');
background-image:  none,url('image.svg'), url('image-small.png');
background-size: 100% 100%;
}

F {
background-image:  url('image-large.png');
background-image:  none,url('image.svg'), url('image-large.png');
background-size: 100% 100%;
}

And of course, if you’re creating multiple PNG images anyway, you may feel there’s not a lot of point in using SVG images as well. I’ll be the first to admit that this isn’t a completely bulletproof technique, but I offer it in the hope that in certain circumstances it could be useful.

You can now use SVG with the img element, as well as the background image in CSS.

I know you can already use SVG in background-image with Safari, Chrome and Opera, and this, coupled with Internet Explorer’s push towards SVG and the strong chance this will be available in IE9, made me decide to take a closer look.

I’ve put together a little demo page which you can view with Safari, Chrome or Opera — ironically, this doesn’t seem to be implemented in Firefox nightlies at the time of writing:

SVG in background-image demo

The same image is used many times at different sizes on this page, displaying the grand advantage of SVG over PNG: it can be resized without the same loss of quality that bitmap images suffer.

Implementation is very easy:

E { background-image: url('image.svg'); }

If you’re looking at the demo in a WebKit browser, you’ll notice an empty box labelled ‘SVGZ’ — the background-image on this element is in the compressed SVG format, SVGZ, which only Opera supports:

E { background-image: url('image.svgz'); }

The file size is less than one-third of the non-compressed version.

The drawback of this is that it’s not ready for use just yet — browsers that don’t support SVG in background-image will not provide any fallback, even if you supply another background-image value; so in non-supporting browsers, no image at all will be displayed.

Update: I’ve found a technique for using SVG images with PNG fallback.

The image used in this demo is from All Free Vectors.

If you have a nightly build of Firefox you can see a little demo I’ve put together of them in action.

The first new property is –moz-calc, which is the experimental implementation of CSS3’s calc function. This allows you to perform simple mathematical functions on length values.

Take a look at the demo, where you’ll see two h2 elements; both have the same styles applied to them, but the second also has some extra calc values for some of its properties:

font-size: -moz-calc(120% * 3);
letter-spacing: -moz-calc(0 + 2px);
text-shadow: rgba(0,0,0,0.33) -moz-calc(4px / 2) -moz-calc(4px / 2);
word-spacing: -moz-calc(0.75em - 0.25em);

The font-size property has a value of 120% * 3, or 360%; the letter-spacing property has a value of 0 + 2px, or 2px; the text-shadow property has x and y offset values of 4px / 2, or 2px; and the word-spacing property has a value of 0.75em — 0.25em, or 0.5em.

The values themselves are abitrary and not important; what matters is that we’re doing calculations in CSS!

At the moment the only properties which support –moz-calc values are:–moz-column-rule-width, –moz-column-width, letter-spacing, word-spacing, marker-offset, outline-offset, border-spacing, text-shadow and –moz-box-shadow; but work is underway to add this to all properties which accept length values.

Update: You can read more about calc() at hacks.mozilla.org.

Also implemented is a new selector, :-moz-any. With this you can group other simple selectors, removing the need for repetitive code. Consider, for example, a typical web page which has many types of list, and nested lists:

<ul>
  <li>We are all list items now
    <ul>
      <li>We are all list items now</li>
    </ul>
  </li>
</ul>
<ol>
  <li>We are all list items now
    <ul>
      <li>We are all list items now</li>
    </ul>
  </li>
</ol>
<menu>
  <li>We are all list items now
    <ul>
      <li>We are all list items now</li>
    </ul>
  </li>
</menu>

If we wanted to select all of the li children of nested ul elements we would currently have to do this:

ul ul li, ol ul li, menu ul li { property: value; }

But with –moz-any we can group the selectors like so:

:-moz-any(ul,ol,menu) ul li { property: value; }

In my demo page I’ve provided a couple of examples; the first selects all list types which are direct child elements of the body:

body > :-moz-any(ol, ul, menu) {
	float: left;
	width: 33%;
}

And the next selects list items of the lists which are children of those elements:

:-moz-any(ol, ul, menu) ul li {
	font-weight: bold;
	margin-left: 0;
}

The :any selector isn’t in any of the CSS3 modules, but it’s pretty useful and definitely a candidate for inclusion. You can read more about it on the blog of David Baron.

Update: Changed the examples for clarity.

The demo works in Firefox and WebKit.

As the title makes clear, the tutorial is for creating the effect in Photoshop — but really, the same effect is fairly easily achievable with some bleeding-edge CSS. That said, it won’t work in every browser, so currently it’s just a proof-of-concept piece.

You can see the finished work here: Create a studio-style backdrop with CSS3. You’ll need Firefox 3.6, Safari 4, or Chrome to see it as intended.

The first step is to create the markup for the backdrop; it’s pretty simple, you just need two divs:

<div id="studio">
<div id="surface"></div>
</div>

Next, the CSS. Set #studio to the required dimensions — I’ve used 800x600 pixels — and set #surface to occupy a third of that height, and absolutely position it to the bottom of #studio.

In the Photoshop tutorial they use circles and gaussian blur to create the gloss effect, but for our CSS tutorial we’ll use gradients. We must make two (one for each div), using the same colours but with slightly different dimensions. And we must use a different syntax for Firefox and WebKit, as I wrote about in my article CSS gradient syntax: comparison of Mozilla and WebKit (Part 2):

#studio {
background-image: -moz-radial-gradient(circle farthest-side, white, #011601 80%, black);
background-image: -webkit-gradient(radial, 50% 50%, 0, 50% 50%, 340, from(white), color-stop(95%, #011601), to(black));
}
#surface {
background-image: -moz-radial-gradient(circle farthest-side, white, #011601 60%, black);
background-image: -webkit-gradient(radial, 50% 50%, 0, 50% 50%, 320, from(white), color-stop(80%, #011601), to(black));
}

I won’t go into the details of why the syntaxes differ — I’ve done that in-depth already — but in essence I’ve set a gradient from white to black, passing through a shade of green (#011601) between. This gives the green-tinted gloss effect. The radius of the gradient in #surface is smaller, to display a pronounced difference between the two.

The next step was to add the product image — I’ve used the same generic media player image by Pzado. What I wanted to do was use the same image twice and flip it with CSS, but unfortunately that’s not possible, so I’ve had to make a copy of the original and flip it vertically to create two separate images. I’ve added these to the markup Update: I realised that I could use the scale transformation function to do this, so I just need to repeat the same image twice with a different id for each:

<img src="phone.png" id="product">
<img src="phone.png" id="reflection">

I’ve positioned these absolutely, then rotated them using the transform property; I’ve also made #reflection mostly transparent:

#product {
-moz-transform: rotate(20deg);
-o-transform: rotate(20deg);
-webkit-transform: rotate(20deg);
}
#reflection {
opacity: 0.2;
-moz-transform: scale(1,-1) rotate(20deg) translate(-50px,-140px);
-o-transform: scale(1,-1) rotate(20deg) translate(-50px,-140px);
-webkit-transform: scale(1,-1) rotate(20deg) translate(-50px,-140px);
}

Update: So what I’ve done here is flipped the reflection image by using a negative (–1) value for the scale function; I’ve also used translate to reposition it directly below the main image.

WebKit rotates them nicely, but the output in Firefox is very jagged; hopefully this will be fixed in a future version. Update: I was using Firefox 3.7a4 on Linux; in Firefox 3.6 (on Mac, at least) it rotates smoothly.

Finally, I’ve added some promotional text in The League Of Moveable Type’s League Gothic font, using @font-face.

You can see the final result here: Create a studio-style backdrop with CSS3; as I mentioned, you’ll need Firefox 3.6, Safari 4, or Chrome to see it as intended. If you don’t have access to those, take a look at these screen grabs (click to see them full size):

So what was the point of this? An intellectual exercise, really. It’s not suitable for use on a production site, and will need some polishing to be in any way useful. But it’s fun to play around with new CSS properties, and to start to get an idea of how we can use it to replicate effects which used to only be possible in graphics packages.

Has anyone reading this ever seen an example of these in action? I’ve searched for demos but have found nothing. If you know anything about this, please leave me a comment; your help would be gratefully appreciated.

At the beginning of the redesign project we agreed some design tenets: the new site should be a best-practice showcase and an opportunity to learn and use some of the latest web technologies; and it should employ existing services where practical.

To achieve the former we targeted users with the most modern web browsers, using the graceful (or progressive) enhancement method to ensure that even with older technology, no-one would be left unable to read all of the site content.

The most obvious example of this is in the design of the buttons; users with a decent browser (e.g. Firefox or Safari) would see these with rounded corners — because these browsers are capable of producing them natively with the CSS3 border-radius declaration — while users of other browsers (e.g. Internet Explorer) would see them square:

Browser comparison. Top: Safari 4; Bottom: Internet Explorer 8

While all users see the same content, those with a modern browser are rewarded with a slightly improved experience. We used other variations of this method elsewhere throughout the site.

Technology

Web Fonts

In order to achieve brand consistency we had a font in mind which we were going to implement using the Cufón Javascript technique. During the process of adding this the font foundry clarified their licensing, excluding this font from online use in this way, so we had to scrap it and look for a different angle.

While we were trying out various alternatives using Flash and Javascript (we now know more about font licensing and implementation than we ever wanted to), a new solution presented itself. Using Font Squirrel’s web font generator and Paul Irish’s bulletproof syntax we were able to use the browsers’ own built-in font support (with @font-face) and achieve our desired result for 95% of our users; the other 5% will see a standard system font, as per the graceful en­hance­ment method.

Glow

Glow is a BBC-developed Javascript library, with a jQuery-like syntax but a focus on interface widgets, which makes it easy to create animations and UI elements for websites. Having already used it briefly on a project earlier in the year, we decided it would be a good fit for what we wanted — and something new to learn.

The image carousel on the homepage was made with Glow, as was the slide-down contact details on each page, and the lightbox overlay effect for screenshots on the case study pages.

The only drawback we found with Glow was a bug in their carousel rendering in IE8; this meant that we had to force compatibility view for IE8 to display as IE7, but it’s something we’re hoping to change after the next Glow release.

HTML5

Under the bonnet we used some cutting-edge code to mark up our content. HTML5 is a very new specification and still somewhat in a state of flux, but we used it in two different ways:

First was to provide semantic structure to the pages with the new structural elements (the definitions of which are still being discussed, so may not be completely correct — HTML5 Doctor was an invaluable resource for this).

Second, and of more impact to the user, was using sessionStorage to take advantage of the opportunities for storing data in the user’s browser. We used this in conjunction with Glow to create the carousel and slide-down effects; if you have a modern browser these are created only once and held in the browser’s storage, whereas older browsers create them anew each time you visit the page — this leads to the site being somewhat snappier in modern browsers.

Conclusion

Working with brand new and cutting edge features meant spending time chasing down false leads and up blind alleys, but was a great way of learning and gave us invaluable experience to take into the sites we make for our clients in future.

There are still one or two changes which we’ll be rolling into the site in the coming months, but if you spot any problems — or just want to talk more in-depth about the methods and techniques we’ve used — don’t hesitate to leave a comment.

Here the syntaxes diverge slightly more, with WebKit requiring more values than Mozilla; while that adds some flexibility, it also increases the complexity.

I’ll be using the same page of examples, which you’ll need to view in Safari / Chrome (or other WebKit derivative) or Firefox 3.6 (beta 3+):

CSS Gradients comparison: Mozilla & WebKit

Radial gradients

As with linear gradients, the key differentiation between the Mozilla syntax and the WebKit syntax is that the latter requires a start and end point, whereas the former is constrained by the bounding box.

You can see in this first example (Radial 1) that the Mozilla syntax is much shorter when making a simple two-colour radial gradient:

-moz-radial-gradient(green, yellow);
-webkit-gradient(radial, center center, 0, center center, 70.5, from(green), to(yellow));

In Mozilla’s case I set only start and end color-stops; for WebKit I must specify a position (50% 50%) and radius (0 — I’ll explain that later) for the start point, and a position (50% 50%) and radius (70.5) for the end point, as well as the color-stops.

As far as I can see the radius value has to be a value in pixels, so in order for the end radius to be the diagonal of the square (where Mozilla defaults to) you need to use the calculation (side)(sqrt(2)) — or, do what I did and use this online calculator.

In the next example (Radial 2) I’ve offset the center of the gradient and set it to end at the furthest edge of the containing box:

-moz-radial-gradient(40% 40%, farthest-side, green, yellow);
-webkit-gradient(radial, 40% 40%, 0, 40% 40%, 60, from(green), to(yellow));

And then used the same center offset but constrained the radius to the distance of the nearest wall (Radial 3):

-moz-radial-gradient(40% 40%, closest-side, green, yellow);
-webkit-gradient(radial, 40% 40%, 0, 40% 40%, 40, from(green), to(yellow));

As you can see, Mozilla takes a series of constants using natural language — farthest-side, closest-side, contain, etc — to set the limits of the gradient, where WebKit accepts only pixel values. The advantage to the former approach is that the syntax is simpler and no calculations are required; the disadvantage is that if you want to create a radial gradient that is smaller than the limits of the containing box, you have to combine it with the background-size property.

Next (Radial 4) I’ve set the center of the gradient to the top-right corner, using three colours equally distributed; here’s where you can start to see the WebKit syntax start to become really unwieldy:

-moz-radial-gradient(right top, green, yellow, blue);
-webkit-gradient(radial, right top, 0, right top, 141, from(green), color-stop(50%, yellow), to(blue));

With WebKit I again have to specify start and end points (with radii), and also specify the stop position of the middle colour. Both outcomes are the same, but the Mozilla syntax is significantly easier.

One aspect of WebKit’s syntax which allows for more flexibility in a gradient is the start point and end point; by providing two separate values you can set the start gradient at a different point to the end gradient, as well as providing different radius values, allowing for effects that Mozilla can’t easily replicate (Radial 5):

-moz-radial-gradient(60% 60%,circle contain,yellow,green 75%,rgba(255,255,255,0));
-webkit-gradient(radial,45% 45%,5,60% 60%,40,from(yellow),color-stop(75%, green),to(rgba(255,255,255,0)));

You can see how that is rendered here (Mozilla on the left, WebKit on the right):

Achieving the same effect is only possible in Mozilla by using multiple values on the background-image property, along with background-size (Update: This isn’t necessary; see Tab Atkins Jr’s comment, below).

Conclusions

While the (original) WebKit syntax does allow for a few effects that the simpler Mozilla implementation can’t easily copy, I think these are really edge cases and the simplicity of the newer syntax is more than ample compensation. It seems the CSS WG agree, which is why the simple syntax is to become an official proposal; I hope the WebKit team accept the proposal and implement it soon.

It was suggested that I also compare these with Internet Explorer’s Gradient filter, but that’s a browser-specific implementation that has no chance of becoming a standard, so I didn’t feel it was suitable for this article; perhaps in a future extension.

Update: Just after I finished this article, Mozilla Hacks published an in-depth look at the new syntax.

Since then, however, the CSS WG have discussed a different syntax, and a resolution was passed to add this to the Image Values module. Mozilla have decided to implement the new syntax, which is simpler than WebKit’s but less flexible.

In this article, which will be split into at least two parts, I’m going to compare the two syntaxes.

Throughout both parts, I will be referring to the following demo page; you’ll need to be using Safari 4, Chrome, or Firefox 3.6beta3+ in order to see it working:

CSS Gradients comparison: Mozilla & WebKit.

The first and most noticeable difference is that the Mozilla implementation uses two properties – –moz-linear-gradient and –moz-radial-gradient – whereas WebKit use only a single property – –webkit-gradient – with two type values: linear and radial. That should become clearer as I progress.

Please note that I’ve tried to use the simplest syntax possible for all examples, but there may be occasions where I’ve slipped up. Feel free to correct me.

Linear gradients

The Mozilla syntax accepts three different properties: start point, angle of direction, and colour stops. WebKit’s also takes three (excluding type: linear, as mentioned previously): start point, end point, and colour stops.

So a simple left-right gradient change (Linear 1) between two colours in Mozilla:

-moz-linear-gradient (left, green, yellow);

The left value sets the default position to the middle of the left-hand side (0deg, 0 50% or left center does the same); the line then goes horizontally out passing from green to yellow in equal proportion.

To get the same pattern in WebKit:

-webkit-gradient (linear, left center, right center, from(green), to(yellow));

The start point is at left center (I could use unit values or percentages as Mozilla does, but not an angle), the end point at right center, and it also passes from green to yellow in equal proportion.

We can tweak those values slightly to get a diagonal gradient from the bottom left corner (Linear 2); for Mozilla I specify an angle, for WebKit I set new start and end points:

-moz-linear-gradient(45deg,green,yellow);
-webkit-gradient(linear,left bottom,right top,from(green),to(yellow));

I’ll tweak those values again to make a bottom-top gradient with an extra colour (Linear 3):

-moz-linear-gradient(90deg,green,yellow,blue);
-webkit-gradient(linear,center bottom,center top,from(green),color-stop(0.5, yellow),to(blue));

The big difference here is that Mozilla distributes the three colours proportionally, whereas WebKit’s color-stop function requires that I set a stop point — I’ve used 0.5 here, although I could have used 50%. The from and to functions are shorthand for color-stop values 0 and 1 (or 100%), respectively.

I don’t have to distribute the colours evenly, however; by changing the value in the colour stop I can choose my own ratio. In the final example (Linear 4) I’ve set the yellow to begin 25% along the length of the gradient:

-moz-linear-gradient(90deg,green,yellow 25%,blue);
-webkit-gradient(linear,center bottom,center top,from(green),color-stop(25%, yellow),to(blue));

For Webkit I only have to update the color-stop value; for Mozilla, I have to specify it.

Conclusions

There are a few differences in the syntaxes for linear gradients, but they’re not major; Mozilla use an angle value, where WebKit use a point-to-point system. I’d say Mozilla’s is the easier to grasp purely because of its brevity, but it’s not that important. In the second part of this article I’ll talk about radial gradients, and it’s there that the differences in implementation become more pronounced.

Update: Part 2 of this article, about Radial Gradients, is now available.