Feature Articles

Sort by:


  1. saving data with localStorage

    This post was written by Jeff Balogh. Jeff works on Mozilla’s web development team.

    New in Firefox 3.5, localStorage is a part of the Web Storage specification. localStorage provides a simple Javascript API for persisting key-value pairs in the browser. It shouldn’t be confused with the SQL database storage proposal, which is a separate (and more contentious) part of the Web Storage spec. Key-value pairs could conceivably be stored in cookies, but you wouldn’t want to do that. Cookies are sent to the server with every request, presenting performance issues with large data sets and the potential for security problems, and you have to write your own interface for treating cookies like a database.

    Here’s a small demo that stores the content of a textarea in localStorage. You can change the text, open a new tab, and find your updated content. Or you can restart the browser and your text will still be there.

    The easiest way to use localStorage is to treat it like a regular object:

    >>> = 'bar'
    >>> localStorage.length
    >>> localStorage[0]
    >>> localStorage['foo']
    >>> delete localStorage['foo']
    >>> localStorage.length
    >>> localStorage.not_set

    There’s also a more wordy API for people who like that sort of thing:

    >>> localStorage.clear()
    >>> localStorage.setItem('foo', 'bar')
    >>> localStorage.getItem('foo')
    >>> localStorage.key(0)
    >>> localStorage.removeItem('foo')
    >>> localStorage.length

    If you want to have a localStorage database mapped to the current session, you can use sessionStorage. It has the same interface as localStorage, but the lifetime of sessionStorage is limited to the current browser window. You can follow links around the site in the same window and sessionStorage will be maintained (going to different sites is fine too), but once that window is closed the database will be deleted. localStorage is for long-term storage, as the w3c spec instructs browsers to consider the data “potentially user-critical”.

    I was a tad disappointed when I found out that localStorage only supports storing strings, since I was hoping for something more structured. But with native JSON support it’s easy to create an object store on top of localStorage:

    Storage.prototype.setObject = function(key, value) {
        this.setItem(key, JSON.stringify(value));
    Storage.prototype.getObject = function(key) {
        return JSON.parse(this.getItem(key));

    localStorage databases are scoped to an HTML5 origin, basically the tuple (scheme, host, port). This means that the database is shared across all pages on the same domain, even concurrently by multiple browser tabs. However, a page connecting over http:// cannot see a database that was created during an https:// session.

    localStorage and sessionStorage are supported by Firefox 3.5, Safari 4.0, and IE8. You can find more compatibility details on, including more detail on the storage event.

  2. new CSS3 properties in Firefox 3.5 – nth-*

    Firefox 3.5 supports several new CSS3 selectors. In this post we’ll talk about four of them: :nth-child, :nth-last-child, :nth-of-type and :nth-last-of-type.

    Each of these is called a Pseudo-class and can be used to apply styles to existing selectors. The best way to describe how this works is with some examples.


    This pseudo-class lets you apply styles to groups of elements. The most common use case is to highlight odd or even items in a table:

        background-color: #E8E8E8;

    A live example (works in Firefox 3.5):

    Row 1
    Row 2
    Row 3
    Row 4

    But you can also use it to apply styles to groups of more than two using a special notation. The documentation for this rule is pretty obtuse but basically the “3″ in the example splits the number of elements into groups of three and the “+1″ is the offset in that group. There are more examples in the spec as well.

    tr:nth-child(3n+1) {  background-color: red; }
    tr:nth-child(3n+2) {  background-color: green; }
    tr:nth-child(3n+3) {  background-color: blue; }

    A live example (works in Firefox 3.5):

    Row 1
    Row 2
    Row 3
    Row 4
    Row 5
    Row 6


    The :nth-last-child pseudo-class works exactly like the :nth-child pseudo-class except that it counts elements in the opposite direction:

    tr:nth-last-child(3n+3) {  background-color: red; }
    tr:nth-last-child(3n+2) {  background-color: green; }
    tr:nth-last-child(3n+1) {  background-color: blue; }

    Example (works in Firefox 3.5):

    Row 1
    Row 2
    Row 3
    Row 4
    Row 5
    Row 6


    The :nth-of-type pseudo-class uses the same kind of syntax as the other elements here but allows you to select based on element type.

    div:nth-of-type(odd) { border-color: red }
    div:nth-of-type(even) { border-color: blue }

    Example (works in Firefox 3.5):

    I should be red!
    I should be blue!


    Much like :nth-last-child, :nth-last-of-type is the same as :nth-of-type except that it counts in the opposite direction.

    These four properties allow you to do interesting things with style and element groups and we hope that they make it easier to style your pages.

  3. opacity in Firefox 3.5

    This is a very short post, but it’s worth putting up because it shows how browser features go from a vendor-specific implementation to a fully supported standard.

    In Firefox 3.5 we no longer support the Mozilla-specific CSS property -moz-opacity. Developers wanting to set the opacity of an element should use the standard opacity property instead.

    We introduced the opacity property way back in Firefox 0.9 and -moz-opacity was deprecated. And with Firefox 3.5 we’ve finally removed it.

    A long road for a simple property, but it’s worth mentioning so people understand the time scale for these kinds of features and how they relate to standards.

  4. debugging painting with MozAfterPaint

    This was originally posted by Robert O’Callahan in the Mozilla web-tech blog. It’s an interesting feature in Firefox 3.5 and is worth repeating here as part of our 35 days effort.

    In addition, Thomas Robinson has created a very handy bookmarklet for debugging painting on a page you’ve loaded in the browser.

    Due to popular demand, we’ve created a very experimental API for Firefox 3.5 to fire an event every time content is repainted. The event is is called MozAfterPaint and is fired at the document, bubbling up to the window. The event offers two attributes, clientRects and boundingClientRect, which tell you what was repainted, using the same objects and coordinate system as the getClientRects and getBoundingClientRect methods.

    This is very useful for Firefox extensions and other “chrome” code that might be using the canvas.drawWindow method to capture the contents of windows. It might also be useful for tools like Firebug. But it’s also potentially useful for regular content, for example if you want to add some lightweight JS instrumentation to a page to measure what gets painted by Firefox, and when.


    • This is Gecko-only. Do not use this for actual functionality on public Web pages – although I’m not sure why anyone would, so I don’t currently see this as a candidate for standardization.
    • For security reasons, regular Web content is only notified of repainting that occurred in its own document – repainting caused by IFRAMEs is not reported to untrusted listeners attached to the IFRAME’s ancestors. (Listeners added by “trusted” content such as Firefox chrome are notified of all repaints to the window, however.)
    • Currently the event might fire before the actual repainting happens. This shouldn’t matter much, and we’ll fix that at some point.
    • If your event handler does anything that triggers repainting, such as changing the style of an element, you will probably trigger an infinite loop. The browser should stay responsive but your machine will contribute to global warming.
    • Repainting of areas scrolled outside the viewport is reported, but repainting of areas scrolled outside overflow:auto elements and the like is not reported.
    • Repainting in windowed plugins (i.e. most plugins in Windows and GTK) is not reported.
  5. XHR progress and rich file upload feedback

    This demo is by Olli Pettay (smaug) with help from Austin King.

    A common limitation on the web today has been a rich file upload widget for web applications. Many sites use Flash or a desktop helper applications to improve the experience of uploading files.

    Firefox 3.5 bridges one of these gaps allowing a better progress indicator to be built. Many developers don’t realize that they can use Firefox’s File object (nsIDOMFile) and XMLHttpRequest together to accomplish file uploads. This demo will feature an upload widget that gives the kind of rich progress feedback that users have come to expect, as well as fast and easy multiple simultaneous file uploads.

    Progress Indicators

    It’s always a good idea to expose feedback that your application is hard at work for them, and when the current action is expected to finish. The two main types of progress feedback are:

    • indeterminate progress – some activity just happened
    • deterministic progress I’m 40% done, I’m 42% done… etc

    Deterministicsaidwhat? The Demo

    We’ve created a simple file upload / download page that demonstrates the progress bar:

    The demo is host at and requires Firefox 3.5 beta4 or later. It demonstrates how to do multiple simultaneous file uploads without posting a form or leaving the current page. For each file upload / download we display the current speed, % complete, and bytes transmitted. We’ll go over a few key snippets of the code which are used in the screenshot above. Please click through the the demo and view source for the full code example.

    The page contains two HTML inputs, one type="file" and one type="button". The form is never actually submitted, instead we add an onclick handler to the button:

    <input type="file" id="file">
    <input type="button"
              value="Upload file using XHR">

    In the startXHR function, we create an XMLHttpRequest and add an event handler to the XHR request to listen for the new ‘progress’ event. With this ProgressEvent’s lengthComputable property, we will know if we are dealing with an indeterminate or deterministic progress. The object also gives us loaded and total bytes.

    var xhr = new XMLHttpRequest();
    xhr.onprogress = function(evt) {        
    if (evt.lengthComputable) { = evt.loaded; =
            Number(evt.loaded/k).toFixed() + "/"+ Number( + "kB";
    if (evt.lengthComputable) {
        var loaded = (evt.loaded /;
        if (loaded < 1) {
            var newW = loaded * width;
            if (newW < 10) newW = 10;
       = newW + "px";

    Now we need some data to send. We grab the contents of the file directly from the input by id:

    var files = document.getElementById("file").files;
    if (files) {
       var file = files.item(0);

    And the last step is to start the request:"POST", "cgi-bin/");
    xhr.overrideMimeType('text/plain; charset=x-user-defined-binary');

    These methods would also work with xhr.upload.onprogress.

    Notice the use of the sendAsBinary method on the XMLHttpRequest object and getAsBinary on the File object. Starting with Firefox 3 you’ve been able to get at the contents of a file on the client side without form submission. This is quite useful for moving beyond the limitation of tranditional file input and form submissions. It is also part of an up and coming W3C standard for FileUpload.

    A related method that the nsIDOMFile provides is the getAsText method which returns a DOMString suitable for slicing, dicing, and displaying.

    Here is an example usage, not used by the demo:


    So that’s the gist of the code. Check out the demo and view it’s source.

    Feedback In User Interfaces

    Exposing system feedback to users improves perceived performance. We
    can’t always determine how long something will take, so at a minimum we
    can show indeterminate progress.

    During file uploads and file downloads (assuming the server gives us Content-Length) we do indeed know the total number of bytes. Firefox 3.5’s Progress Events support adds a progress event so that we can show actual upload/download progress.

    Traditionally XMLHttpRequests were difficult to get deterministic progress back from. In theory, you could give it callbacks and watch for status code updates and textual message updates, but in practice they turn out to be not very useful. In the past, if a deterministic progress meter was important, you’d have to make a second XHR request to poll for progress.

    Enter Progress Events

    The W3C has a working draft for Progress Events 1.0 which we include in Firefox 3.5. Firefox has added a key new DOM ProgressEvent progress event, as well as the loadstart event. The other existing events included: error, abort and load.

    These same events are also available for uploads and downloads. The progress event gives us the following properties:

    • lengthComputable – true or false, is the size of the request known?
    • loaded – number of bytes received so far
    • total – number of bytes expected for entire request

    The Contract

    When you’re looking at the properties of those progress events, certain rules apply that you can depend on. They are:

    • The total property will be 0 when lengthComputable is false.
    • The loadstart event is always signaled only once.
    • The progress event is fired off zero or more times after loadstart.

    And that’s it. Go forth and improve file uploads with Firefox 3.5 goodness.

  6. color correction for images in Firefox 3.5

    Back in Firefox 3, we introduced support for color profiles in tagged images, but it was disabled by default. In Firefox 3.5 we were able to make the color correction process about 5x faster than it was in Firefox 3 so we’ve enabled support for color correction for tagged images.

    Most images on the web are untagged. If you don’t know the difference between tagged images and untagged images the odds are good are you won’t notice this change. However, we suggest that you read on to learn about what it might mean for you if you want to include them and how future Firefox releases might change the interactions between CSS colors and images.

    What’s a color profile?

    People who spend a lot of time taking photographs or any kind of high-resolution color printing will understand that many output devices – LCDs, CRTs, paper etc – all have very different interpretations of what various colors mean. For example, uncorrected red will look very different on an LCD vs. a CRT. You can see this if you set up two very different monitors next to each other and the operating system doesn’t do color correction – colors will look more washed out in one of them vs. the other.

    JPG and PNG images both have support for color profiles. These color profiles allow Firefox to take colors in the image and translate them into colors that are independent of any particular device.

    While images contain color profiles it’s also important to note that output devices like monitors also have color profiles. As an example an output device may be better at displaying reds than blues. When you’re getting ready to show something that’s “red” on that device it might need to be converted from the neutral #ff0000 value to #f40301 in order to show up as red on the screen.

    What this means is that there are actually two conversions that take place with color profiles. The first is to take the original color information in the image and, using the color profile, convert it into a device-independent color space. Then once it’s in that independent space you convert it again using the output device’s color profile to get it ready to display on the output device.

    So what about CSS colors?

    It’s important to understand how color profiles work and how they are converted to properly understand how CSS interacts with these color spaces.

    In Firefox 3.5 we consider CSS colors to already be in the device output’s color space. Another way of saying this is that CSS colors are not in the neutral color space and are not converted into the output device like tagged images are.

    What this means is that if you have a tagged image where a color is expected to match the CSS that’s right next to it, it won’t. Or at least it’s likely that it won’t on some output device – maybe not the one that you happen to be using for development. Remember that different output devices have different color profiles. Here’s an example of what that looks like:

    In Firefox 3, this will look like one contiguous block of purple. In Firefox 3.5 and Safari you will notice that there’s a purple box within a purple box (unless your system profile is sRGB.) This is because the image is color corrected while the surrounding CSS is not.

    This is where the statement about the future comes in. In a future release of Firefox we are likely to make it possible for people to turn on color correction for tagged images and CSS. You can test this setting today by changing the pref listed on the page on color correction on the Mozilla Developer Center to “Full color management.” In that case untagged images should continue to work as we will be rendering both CSS and untagged images in the sRGB color space.

    Image support and tools

    PNG’s can be tagged in three different ways. First they can have an iCCP chunk that contains the associated ICC profile. Second they can be explicitly tagged as sRGB using a sRGB chunk. Finally, they can contain gAMA and cHRM chunks that describe the image’s gamma and chromaticies. Using any of thse methods will cause Firefox to color correct the image.

    You can remove all of the color correction chunks resulting in an untagged image using pngcrush:

    pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB infile.png outfile.png

    Alternatively, you can use TweakPNG and delete the gAMA, cHRM, iCCP and sRGB chunks by hand.

  7. better security and performance with native JSON

    The JavaScript Object Notation (JSON) mechanism for representing data has rapidly become an indispensable part of the web developer’s toolkit, allowing JavaScript applications to obtain and parse data intuitively, within scripts, with lightweight data encapsulation. Firefox 3.5 includes support for JSON natively by exposing a new primitive — window.JSON — to the top level object.

    Native “out of the box” support for JSON comes to the web courtesy of the ECMAScript 5th Edition (PDF link to specification), other aspects of which will also be supported by Firefox 3.5. Presently, native JSON is supported by Firefox 3.5 and IE8, with a strong likelihood of other browsers supporting it soon as well.

    Native JSON support has two advantages:

    1. Safety. Simply using eval to evaluate expressions returned as strings raises security issues. Also, the native JSON primitive can only work with data. It can’t be used to parse objects with method calls; attempting to do so returns an error.
    2. Performance. Parsing JSON safely, using third-party scripts and libraries, is likely to be slower than native JSON parsing within the browser.

    Let’s look at some examples.

    A JSON API for search results might look like this:

    Assume that you obtained var data
    as a string from a server
    For convenience we display this search
    result on separate lines
    var data = ' { "responseData":
    {"results": [

    Such a resource could be returned by a simple HTTP GET request using a RESTful API.

    Using native JSON, you could do something like this:

     Obtain a handle to the above JSON resource
     This is best and most conveniently done
     via third-party libraries that support native JSON
    if (window.JSON) {
        var searchObj = JSON.parse(data);
        for (var i=0; i++; i < searchObj.responseData.results.length) {
            if (searchObj.responseData.results[i].SafeSearch) {
                var img = new Image();
                img.src = searchObj.responseData.results[i].url;
                // ... Insert image into DOM ...

    You can also stringify the object back to the string:

    // Back to where we started from
    var data = JSON.stringify(searchObj);
    // data now holds the string we started with

    Of course, to really enable the power of JSON, you’ll want to retrieve JSON resources from different domains, via callback mechanisms like JSONP. Many web developers are unlikely to use the JSON primitive directly. Rather, they’ll use them within libraries such as Dojo and jQuery. These libraries allow for the retrieval and direct parsing of JSON resources from different domains, and add a great deal of syntactic sugar to the process of callbacks and DOM insertions.

    The native JSON primitive works with the popular json2.js library (which correctly detects if native JSON is enabled), so developers can seamlessly use JSON parsing on browsers that don’t support native JSON. As of this writing, Dojo and jQuery have committed to supporting native JSON:

  8. a short introduction to media queries in Firefox 3.5

    This post is by Eric Shepherd, who leads Mozilla’s documentation project at the Mozilla Developer Center.

    In this day and age, it’s important for web content to support rendering on an increasingly wide variety of devices. Not only do users expect to use your content on their home computer, or read it printed on paper, but they want to use it on handheld devices, cell phones, and assorted other gadgets that have distinct capabilities, both in terms of performance and in terms of display fidelity.

    CSS 2 introduced the notion of media types, which allow you to specify different style rules based on what type of device the content is being rendered onto. For example, you can include a specific style sheet when your content is being rendered for printing like this:

    <link rel="stylesheet" media="print" href="print.css">

    This was a good first step; however, this doesn’t provide the ability to fine-tune the rendering of your content based on things such as device resolution, aspect ratio, or whether the content is being viewed in portrait or landscape orientation.

    Firefox 3.5 supports media queries — a new feature of CSS 3 — which make it possible to define much more precisely what styles to apply under what circumstances.

    This works by establishing queries that look at the values of various media features. There are a large number of these, including color depth, rendering area width and height, pixel resolution, whether or not the display is color, and so forth. You can find a complete list in the Mozilla Developer Center article on media queries.

    Media queries are quite powerful, but very easy to use. Take a look at the example web page I put together for this article.

    The example page uses two style sheets, which are specified using the following rules:

    <link rel="stylesheet" media="all and (orientation:portrait)"

    This one uses the media query all and (orientation:portrait) to indicate that the portrait.css style sheet should be used if the content is being rendered in a display area (such as the window in Firefox) is taller than it is wide.

    <link rel="stylesheet" media="all and (orientation:landscape)"

    This one specifies that the landscape.css style sheet should be applied when the content is being rendered on a surface that is wider than it is tall.

    What’s very cool about media queries is that they are evaluated every time the display mode changes; for example, if you open the example page and start resizing the window, you’ll find that when the window is wider than it is tall (i.e., it’s in landscape orientation), the toolbar is located on the left side of the page.

    When you resize the window so that it is in portrait orientation, the toolbar moves to the top of the window. This is done live while you’re resizing the window.

    If you look inside the landscape.css file, you’ll find that there are some media queries used there, as well, that override the style of the <body> element based on the width of the window. By default, the body text is 14 pixels tall.

    @media all and (min-width: 600px) {
      body {
        font-size: 16px;

    However, this media query indicates that if the window is at least 600 pixels wide, the font size for the body text should be increased to 16 pixels.

    @media all and (min-width: 700px) {
      body {
        font-size: 20px;

    Similarly, this media query makes the body’s font size 20 pixels when the window reaches at least 700 pixels wide. And another, similar media query makes the font even larger when the window is at least 800 pixels wide.

    So as you resize the window, you’ll see that not only does Firefox automatically switch between the portrait.css and landscape.css style sheets as the window’s width changes, but while rendering using the landscape.css style sheet, the styles change based on exactly how wide the window is, too.

    Another great use for this is to adjust the number of columns your content is displayed in based on the width of the display area.

    Media queries are currently supported by Firefox 3.5, Safari 3, and Opera 7 and later, with successive versions often adding support for additional media features.

    You can get details about which media features Firefox supports in the MDC article on media queries. Opera 9.5′s media features support is outlined near the bottom of this article. I wasn’t able to find specifics on WebKit’s media queries support.

    Media queries offer a great way to improve how your content looks on a variety of devices; using appropriate queries, you can render differently based on screen size, resolution, and more, thereby optimizing your content no matter how the user is accessing it.

  9. DOM selectors API in Firefox 3.5

    The Selectors API recommendation, published by the W3C, is a relatively new effort that gives JavaScript developers the ability to find DOM elements on a page using CSS selectors. This single API takes the complicated process of traversing and selecting elements from the DOM and unifies it under a simple unified interface.

    Out of all the recent work to come out of the standards process this is one of the better-supported efforts across all browsers: Usable today in Internet Explorer 8, Chrome, and Safari and arriving in Firefox 3.5 and Opera 10.

    Using querySelectorAll

    The Selectors API provides two methods on all DOM documents, elements, and fragments: querySelector and querySelectorAll. The methods work virtually identically, they both accept a CSS selector and return the resulting DOM elements (the exception being that querySelector only returns the first element).

    For example, given the following HTML snippet:

    <div id="id" class="class">
        <p>First paragraph.</p>
        <p>Second paragraph.</p>

    We would be able to use querySelectorAll to make the background of all the paragraphs, inside the div with the ID of ‘id’, red.

    var p = document.querySelectorAll("#id p");
    for ( var i = 0; i < p.length; i++ ) {
        p[i].style.backgroundColor = "red";

    Or we could find the first child paragraph of a div that has a class of ‘class’ and give it a class name of ‘first’.

    document.querySelector("div.class > p:first-child")
        .className = "first";

    Normally these types of traversals would be very tedious in long-form JavaScript/DOM code, taking up multiple lines and queries each.

    While the actual use of the Selectors API methods is relatively simple (each taking a single argument) the challenging part comes in when choosing which CSS selectors to use. The Selectors API taps in to the native CSS selectors provided by the browser, for use in styling elements with CSS. For most browsers (Firefox, Safari, Chrome, and Opera) this means that you have access to the full gamut of CSS 3 selectors. Internet Explorer 8 provides a more-limited subset that encompasses CSS 2 selectors (which are still terribly useful).

    The biggest hurdle, for most new users to the Selectors API, is determining which CSS selectors are appropriate for selecting the elements that you desire – especially since most developers who write cross-browser code only have significant experience with a limited subset of fully-working CSS 1 selectors.

    While the CSS 2 and CSS 3 selector specifications can serve as a good start for learning more about what’s available to you there also exist a number of useful guides for learning more:

    Implementations in the Wild

    The most compelling use case of the Selectors API is not its direct use by web developers, but its use by 3rd-party libraries that already provide DOM CSS selector functionality. The trickiest problem towards adopting the use of the Selectors API, today, is that it isn’t available in all browsers that users develop for (this includes IE 6, IE 7 and Firefox 3). Thus, until those browsers are no longer used, we must use some intermediary utility to recreate the full DOM CSS selector experience.

    Thankfully, a number of libraries already exist that provide an API compatible with the Selectors API (in fact, much of the inspiration for the Selectors API comes from the existence of these libraries in the first place). Additionally, many of these implementations already use the Selectors API behind the scenes. This means that you can use using DOM CSS selectors in all browsers that you support AND get the benefit of faster performance from the native Selectors API implementation, with no work to you.

    Some existing implementations that gracefully use the new Selectors API are:

    It’s important to emphasize the large leap in performance that you’ll gain from using this new API (in comparison to the traditional mix of DOM and JavaScript that you must employ). You can really see the difference when you look at the improvement that occurred when JavaScript libraries began to implement the new Selectors API.

    When some tests were run previously the results were as follows:

    You can see the dramatic increase in performance that occurred once the libraries began using the native Selectors API implementations – it’s quite likely that this performance increase will happen in your applications, as well.

    Test Suite

    To coincide with the definition of the Selectors API specification a Selectors API test suite was created by John Resig of Mozilla. This test suite can be used as a way to determine the quality of the respective Selectors API implementations in the major browsers.

    The current results for the browsers that support the API are:

    • Firefox 3.5: 99.3%
    • Safari 4: 99.3%
    • Chrome 2: 99.3%
    • Opera 10b1: 97.5%
    • Internet Explorer 8: 47.4%

    Internet Explorer 8, as mentioned before, is missing most CSS 3 selectors – thus failing most of the associated tests.

    As it stands, the Selectors API should serve as a simple, and fast, way of selecting DOM elements on a page. It’s already benefiting those who use JavaScript libraries that provide similar functionality so feel free to dig in today and give the API a try.

  10. shadow boxing with -moz-box-shadow

    Another fun CSS3 feature that’s been implemented in Firefox 3.5 is box shadows. This feature allows the casting of a drop “shadow” from the frame of almost any arbitrary element.

    As the CSS3 box shadow property is still a work in progress, however, it’s been implemented as -moz-box-shadow in Firefox. This is how Mozilla tests experimental properties in CSS, with property names prefaced with “-moz-”. When the specification is finalized, the property will be named “box-shadow.”

    How it works

    Applying a box shadow to an element is straightforward. The CSS3 standard allows as its value:

    none | <shadow> [ <shadow> ]*

    where <shadow> is:

    <shadow> = inset? && [ <length>{2,4} && <color>? ]

    The first two lengths are the horizontal and vertical offset of the shadow, respectively. The third length is the blur radius (compare that to the blur radius in in the text-shadow property). Finally the fourth length is the spread radius, allowing the shadow to grow (positive values) or shrink (negative values) compared to the size of the parent element.

    The inset keyword is pretty well explained by the standard itself:

    if present, [it] changes the drop shadow from an outer shadow (one that shadows the box onto the canvas, as if it were lifted above the canvas) to an inner shadow (one that shadows the canvas onto the box, as if the box were cut out of the canvas and shifted behind it).

    But talk is cheap, let’s look at some examples.

    To draw a simple shadow, just define an offset and a color, and off you go:

     -moz-box-shadow: 1px 1px 10px #00f;


    simple box shadow

    (Each of the examples in this article are live examples first, followed by a screen shot from Firefox 3.5 on OSX).

    Similarly, you can draw an in-set shadow with the aforementioned keyword.

    -moz-box-shadow: inset 1px 1px 10px #888;


    inset box shadow

    With the help of a spread radius, you can define smaller (or bigger) shadows than the element it is applied to:

    -moz-box-shadow: 0px 20px 10px -10px #888;


    box shadow with spread radius

    If you want, you can also define multiple shadows by defining several shadows, separated by commas (courtesy of Markus Stange):

    -moz-box-shadow: 0 0 20px black, 20px 15px 30px yellow, -20px 15px 30px lime, -20px -15px 30px blue, 20px -15px 30px red;


    multiple box shadows

    The different shadows blend into each other very smoothly, and as you may have noticed, the order in which they are defined does make a difference. As box-shadow is a CSS3 feature, Firefox 3.5 adheres to the CSS3 painting order. That means, the first specified shadow shows up on top, so keep that in mind when designing multiple shadows.

    As a final example, I want to show you the combination of -moz-box-shadow with an RGBA color definition. RGBA is the same as RGB, but it adds an alpha-channel transparency to change the opacity of the color. Let’s make a black, un-blurred box shadow with an opacity of 50 percent, on a yellow background:

    -moz-box-shadow: inset 5px 5px 0 rgba(0, 0, 0, .5);


    box shadow with RGBA

    As you can see, the yellow background is visible though the half-transparent shadow without further ado. This feature becomes particularly interesting when background images are involved, as you’ll be able to see them shining through the box shadow.

    Cross-Browser Compatibility

    As a newer, work-in-progress CSS3 property, box-shadow has not yet been widely adopted by browser makers.

    • Firefox 3.5 supports the feature as -moz-box-shadow, as well as multiple shadows, the inset keyword and a spread radius.
    • Safari/WebKit has gone down a similar route as Firefox by implementing the feature as -webkit-box-shadow. Multiple shadows are supported since version 4.0, while neither inset shadows nor the spread radius feature are supported yet in WebKit.
    • Finally, Opera and Microsoft Internet Explorer have not yet implemented the box shadow property, though in MSIE you may want to check out their proprietary DropShadow filter.

    To achieve the biggest possible coverage, it is advisable to define all three, the -moz, -webkit, and standard CSS3 syntax in parallel. Applicable browsers will then pick and adhere to the ones they support. For example:

     -moz-box-shadow: 1px 1px 10px #00f;
     -webkit-box-shadow: 1px 1px 10px #00f;
     box-shadow: 1px 1px 10px #00f;

    The good news is that the box-shadow property degrades gracefully on unsupported browsers. For example, all the examples above will look like plain and boring boxes with no shadow in MSIE.


    The CSS3 box-shadow property is not yet as widely available in browsers (and therefore, to users) as, for example, the text-shadow property, but with the limited box shadow support of WebKit as well as the full support provided by Firefox 3.5 (as far as the current status of the feature draft is concerned), more and more users will be able to see some level of CSS box shadows.

    As a web developer, you can therefore use the feature, confident that you are giving users with modern browsers an improved experience while not turning away users with older browsers.

    Further resources