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.

I recently read Peter Morville’s fantastic book, Ambient Findability, which defined really well the motivation to use semantic descriptions for links: they give the target page aboutness.

Simply defined, aboutness is the quality of meaning; what something is about is defined by its aboutness. To extend an example from Morville’s book, let’s regard a web page which contains W.H. Auden’s poem, Funeral Blues:

He was my North, my South, my East and West,
My working week and my Sunday rest,
My noon, my midnight, my talk, my song,
I thought that love would last forever; I was wrong

Although we know that the poem is about death, the word itself doesn’t appear in the poem; so how could a search engine that indexed the page know what it was about, and return it in the results of a search on that topic?

In order to gain some context, the search engine will look at the text of the links to that page*; so a link with the text ‘read more’ will provide no context whatsoever, whereas a link with the text ‘W.H. Auden’s poem about death’ provides aboutness.

And it’s not just for our link text that semantics are important; the same principle applies with HTML — your markup gives aboutness to your content. So if you’re a front-end coder, be sure to at least use appropriate container elements (the HTML5 Doctor can help with this), and if you want to go further take a look at the likes of Microformats and RDFa.

* Search engines look at more than this, of course, but this is the most obvious example.

The four demos shown to date display different (although related) aspects of the API, showing first multiple file uploads, then a drag and drop upload interface, next adding progress information (although this doesn’t work for me), then reading EXIF data from a JPEG image. You can imagine how these combined would be used for native drag and drop uploading to Flickr, for example.

The File API plays a big part in integrating the browser more tightly with the OS, particularly when combined with the drag and drop functionality, and I’m sure it’s only a matter of time until the other browsers implement this. Congratulations to the Firefox team for their work on this, and hacks.mozilla.org for some great demos.

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.

Earlier this month a group of high-profile developers—including Dan Cederholm and Jeffrey Zeldman—got together to discuss the spec and declare their support (albeit with some caveats) for the direction it’s moving in. Although I’m not comfortable with the self-aggrandising name they chose—the HTML5 Super Friends—their support is a positive move and their concerns have already made an impact in the September updates to the language.

It must be noted, however, that the ‘Super Friends’ concentrated on the markup language, while another aspect (the drag and drop module) has been roundly savaged in a strongly-worded attack by QuirksBlog’s Peter-Paul Koch.

Many browsers now have HTML5 implemented to varying degrees (Opera 10 is first with HTML5 Forms, for example), so if you haven’t already, it’s time to start learning. A List Apart gave a concise introduction, and the document highlighting differences from HTML4 is also a good starting point.

But if you want advice, the best thing you can do is see the Doctor.

Over the weekend one of the most popular stories on Delicious.com was teaching the use of lazy CSS hacks, the type of which I thought everybody was convinced enough to do away with; the star and underscore hacks for targeting IE6 & IE7, the hacks which we’ve been saying (for years) shouldn’t be used anymore.

Disregarding the ‘rights’ and ‘wrongs’, and the validation argument — some of my stylesheets don’t validate, and there are good reasons for that — I’d like to give a few other reasons why using this method is not a good idea.

First and foremost, maintainability; separating out the rules for outdated browsers with conditional comments leaves your standards-compliant stylesheets clean and easy to manage; you don’t have to wade through multiple rules looking for the ones you need. IE6 & IE7 styles are safely out of sight.

Second, and one of the core arguments for not using hacks, is future-proofing; using a hack like this in the main stylesheet could lead to a situation in the future where a new browser — or new version of a current browser — could render this hack incorrectly. It may not be likely, but can you guarantee no future browser will not render strangely when interpreting these rules?

As well as practical reasons not to use hacks, there is one good moral reason: to not be lazy. Writing the syntax for conditional comments takes less than a minute, and while using hacks means there is some reduction in the number of characters required, complex stylesheets can contain dozens — or even hundreds — of rules, and adding those hacks for each rule will mean you end up using almost as many characters as you would with conditional comments.

It’s pretty disheartening to see comments that suggest standards are just for people who want to sell books or conference tickets; standards are to make the jobs of web developers easier. Even the lazy and bone-headed ones.

Starting with the latter, I today discovered that Jeffrey Veen’s new company, Small Batch Inc., has started touting a new licensing service for web fonts. It’s called TypeKit and, while details are scarce, it seems to be a server to host web fonts with some Javascript magic to not make them downloadable to end users.

It’s an intriguing solution to the problem I mentioned before, even if I’m not convinced it is the right solution; without knowing the specifics, it seems to me there are two fairly obvious sticking points:

First, how do we develop the site using the font if the license is only for the production server? Will there be a special development license, or will we have to buy a copy of the font and then an extra licensing fee?

Second, what about server latency (will there be a long lag until the fonts appear?) and uptime (how irritating will it be if the server is constantly falling over?).

I look forward to seeing how those issues are addressed. I personally don’t see a problem in the current/forthcoming Safari/Firefox implementation — but then, I’m not a type foundry.

It’s Google’s I/O event this week, and they’re making a big deal about supporting some of the new HTML5 syntax — principally, the video element, an example of which is on this YouTube mock-up (Firefox 3.5, Safari 4, or Chrome 3 required).

So stable is the new element that video site dailymotion.com have announced that they have converted 300,000 of their videos to use it, and the open video codec Ogg Theora. With all of the main non-IE browsers about to launch their implementation, adoption will hopefully be pretty rapid.