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.

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.

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.

I’ve put together a very rough demo of what you can do with these new rules; you’ll require a recent build of Firefox 3.6 or Webkit to view it. Try resizing the window to different dimensions, and see how it changes.

Here’s an explanation of how I did it:

The first div has a radial gradient applied to it using the background-image property:

background-image: -moz-radial-gradient(center, 10px, center, 480px, from(#aedae5), to(white));
background-repeat: no-repeat;

The positional values (center and pixel values) instruct where to start the radius from, and where to end it; in my example, I’m starting 10px from the center and radiating out to 480px. The second values (from, to) set the start and end colours for the gradient. All of these declarations accept many more values than I’ve shown here.

Mozilla’s implementation differs from the Webkit proposal in a few significant ways, the most obvious being that Webkit uses a single rule (–webkit-gradient) with a type value (linear or radial), whereas Mozilla use two rules (–moz-linear-gradient and –moz-radial-gradient). Mozilla’s implementation also tiles unless background-repeat is set to no-repeat.

The Mozilla Dev Center page explains the differences in more detail. Having just used both in building this demo, I have to say that the Mozilla implementation is more logical a little easier to learn.

The second part of my demo uses multiple backgrounds on the internal div to display Foxkeh behind the cut-out letters:

background:
url('images/ff3_6.png') no-repeat 50% 50%,
url('images/foxkeh.png') no-repeat 50% 50%;

The stack is calculated in descending order, so the first value takes precedence over the second.

Finally, to make sure that my letters always fill the screen, I’ve used background-size to stretch the image over its containing element:

-moz-background-size: 100% 100%, auto;

I’ve used two comma-separated values to match the multiple backgrounds above; the first value stretches the background image to 100% of its container, the second keeps Foxkeh at his natural size.

If you plan to use these declarations you may also be interested in image rendering; however, that’s beyond the scope of this post.

It’s good to see Mozilla being more experimental, and nice for us to have new declarations to experiment with. I hope that Mozilla and Webkit agree on a common implementation of gradients, so that the proposal becomes accepted more quickly.

Using it is pretty simple:

div {
background-image: url('image.png');
-moz-background-size: 80%;
}

This, along with multiple background-images, is going to go a long way towards cleaning up mark-up and prettifying the web.