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.

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.

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.

Implementation is spotty at the moment; Firefox 3.5 supports it, as does Safari for iPhone (although not on the desktop, AFAICS). But it’s so simple to use, I’ve no doubt it will be adopted rapidly.

I’ve put together a small demo of the GeoLocation API in action; it uses data from the Arts Council England website, so visitors from outside of England won’t get any meaningful results from this, I’m afraid. Visitors from England will probably get best results using a mobile device (such as an iPhone).

First, the JavaScript function tests that the browser supports the API:

var hasGeoLocation = navigator.geolocation ? true : false;
if (hasGeoLocation === true) { ... }

If so, it requests the current position from the browser using the getCurrentPosition method (the user will have to give permission for this) and passes the result into a function:

navigator.geolocation.getCurrentPosition(function(position) {
    getJSON(position.coords.latitude,position.coords.longitude);
});

This result is used in the latitude and longitude attributes of the coords object, which I then use for the rest of my function (using jQuery’s getJSON function to mine microformatted data from the map page of the Arts Council England website, transforming it using Optimus, then parsing it back into HTML for my demo).

There’s a lot more to this, of course; the API is quite extensive, covering altitude and heading as well as lat/long, and there’s a massive amount of geotagged data available (Flickr photos, for example). Hopefully my demo serves as an example of how easy it is to make the move into the mobile space.