1. quarterly developer survey update

    • by Alix Franquet • MDN, Survey • 2 comments

    We are inviting developers to give us feedback through quarterly surveys so we can better understand your needs. Your feedback is crucial to help us build the best platform, tools, and content.

    Last November, we asked web developers to take a 20 question survey to help build the Mozilla Developer Network (MDN). Thanks to the feedback from 5,054 developers reached via this blog, twitter, the Firefox 3.6 beta first run page, and word of mouth, we’ve drafted detailed plans for the MDN and we are now executing on them.

    In this post, you will find our new survey. Please take it and keep the feedback coming.

    We also want to share the results from the November survey.

    New Survey: Firefox 3.6 and Firebug 1.5

    Our March survey picks up from some of the themes we heard you say in the November survey. Many of you stressed the importance of development tools and expressed how it can be difficult to understand the Firefox development process and to give input. We designed this quarter’s (much shorter) survey specifically to ask for your feedback on Firefox 3.6 and on Firebug 1.5, both released in January.

    Here’s where you can take this new survey. We would also be very thankful if you could help us spread the word about it.

    November 09 Survey Results

    Here are some results from the November 09 survey:


    Web Developers’ Technology Preferences


    Browser usage

    “Firefox is a developer’s best friend”: it is most likely to be the first browser used by developers because it helps them be most productive. The combination of great tools (add-ons, in particular Firebug, but also the console) and standard compliance means that it’s faster to develop on Firefox first, then tweak the code to make sure it works everywhere. The open source nature of Firefox was also frequently cited as a reason to use it.

    Here is a word cloud generated from the praise for Firefox (thanks to wordle.net).

    Once a project is built, developers spend a lot of time testing their work in an average of 5 browsers. At the time of this survey (Nov 09), the top browsers tested for compatibility were Firefox 3.5, IE8, IE7, Chrome, and Safari. IE6 only came in 6th place with less than 50% of developers still testing against it. With more sites dropping support for IE6 each day, we expect this number to continue to decrease over time.

    At home, developers used on average 2 browsers, with the majority (80%) using Firefox, and a smaller number using Chrome (38%), or Safari (27%).

    A small portion of respondents (7%) mentioned Webkit browsers as a good alternative for development because of its speed and ease of use, of its standards implementation, and of the inspector tool, with the frequent caveat that it still felt too limited for complex projects.

    On the other hand, Internet Explorer (in particular IE6) was seen as slowing down web innovation and wasting developers’ time unnecessarily.


    Development Tools: Firefox Add-ons

    Firefox web development add-ons are cited as invaluable tools for development work. In fact, add-ons are seen by some respondents as the main reason to use Firefox. However, some blame them for slowing down Firefox. If this is happening to you, consider investigating which add-on is causing an issue, or using multiple profiles, one for development work, and one for every day browsing.

    While Firefox is often referred to as a developer’s best friend, Firebug is called “a must-have tool” and “essential”. Some even go as far as saying that “developing Websites without Firefox and Firebug is unimaginable” and “Firebug has changed the way I develop with CSS and Javascript.”
    Firebug plugins FirePHP, Page Speed, and FireCookie were often mentioned as great complements.

    In addition to Firebug, the most frequently praised add-ons were the Web Developer Toolbar and YSlow. Other add-ons mentioned include Live HTTP Headers, HttpFox, MeasureIt, ColorZilla, and GreaseMonkey.

    We’re working on improving developer tools for Firefox, for more details and to join the conversation, see Johnathan Nightingale‘s post on this topic.


    Development Tools: Others


    Learning more about the current Firefox development work

    The Hacks blog, @mozhacks twitter account, and about:hacks newsletter should be your primary sources of information for any Mozilla work that impacts web developers. However, if you wish to follow the Firefox development work even more closely, you can take a look at the list of current Firefox projects, test the latest developer preview, or even run the nightly builds.


    Firefox Feature Requests

    While there was much praise for Firefox throughout the survey responses, there were also many voices asking for performance and stability improvements. These improvements are currently under way, as you can see for example with the ongoing work on Firefox startup time and stability, and on JavaScript performance.

    There were also many requests to continue implementing HTML5 and CSS3 features. You can already enjoy some of the new features by trying out the latest developer preview build.


    Mozilla Developer Center Comments

    The Mozilla Developer Center was highly praised in the open comments. It is perceived as a key resource for web developers, especially for JavaScript, CSS, and DOM documentation. There were also quite a few requests to improve the site’s organization and search, add tutorials, and enable forums and comments, among other things. These are all being addressed in building the MDN.


    Providing Feedback to Mozilla

    Some of the comments in the November survey pointed out that it can be difficult to find the right place to give feedback to Mozilla and know that you’ve been heard. There are actually many ways to do so:

    In addition to the surveys we post, the Hacks team reads all comments on the hacks blog and all incoming tweets for @mozhacks. This is the best way for web developers to give feedback and ask questions. We’re here to help you and to relay your concerns to the appropriate team.

    Besides Hacks, here are some of the other feedback channels at Mozilla:

    • Hendrix is a general feedback form
    • Reporter keeps track of sites flagged through “Report broken website” in the Firefox Help menu
    • Bugzilla is the place to file specific issues or requests for improvement
    • Mozilla also has many developer forums you can join


    Profiles of Survey Respondents

    We received responses from 119 countries.

    Respondents worked in a variety of environments, but the majority were freelance developers, followed by in-house teams and agencies. Most worked both as front-end and back-end web developers.

    An overwhelming majority of respondents learned the skills they use for their web development work on their own: most were self-taught online, but 2/3 also learned offline through books and conferences.

    Many of the respondents are currently contributing to the Mozilla project by spreading the word about Mozilla, Firefox, or open standards, by running betas and nightly builds, and by supporting Firefox users. Many thanks for your participation!

    This concludes the November survey results, we look forward to your comments to this post, and to your feedback on Firefox 3.6 and Firebug 1.5 through our new survey.

  2. Mozilla developer preview (Gecko 1.9.3a1) available for download

    • by Alix Franquet • CSS, Firefox, HTML5, Performance, SVG, WebGL • 9 comments

    Editor’s note: Today, Mozilla released a preview of the Gecko 1.9.3 platform for developers and testers. Check out the Mozilla Developer News announcement reposted below.

    A Mozilla Developer Preview of improvements in the Gecko layout engine is now available for download. This is a pre-release version of the Gecko 1.9.3 platform, which forms the core of rich Internet applications such as Firefox. Please note that this release is intended for developers and testers only. As always, we appreciate any feedback you may have and encourage users to help us by filing bugs.

    This developer preview introduces several new features, including:

    and several other significant changes, including:

    • On Mac OS X, we render text using Core Text rather than ATSUI.
    • We rewrote major parts of the code for handling scrolling. See bug 526394 for details.
    • We rewrote the way a snapshot of a document is taken in order to print or print preview. See bug 487667 for details.
    • We made significant changes to table border handling. See bug 452319 and bug 43178 for details.
    • We made various architectural changes to improve Web page performance.

    More information on these changes is in the release notes, as well as the Upcoming Firefox features for developers article on the Mozilla Developer Center.

    Please use the following links when downloading this Mozilla Developer Preview:

  3. About:hacks newsletter – issue 2

    • by Alix Franquet • about:hacks, MDN • 3 comments

    Last week we sent out the second issue of about:hacks, Mozilla’s newsletter for web developers.

    Here are highlights from the topics covered in this new issue:

    If you do not subscribe to about:hacks, you will find the second issue in the archives. If you enjoy the content, consider subscribing to make sure you receive the third issue, coming in March.

    Finally, we’d love to get your feedback on the newsletter: what do you like, what would you change, what topics would you like us to cover. Please take a minute to fill out the feedback form.

  4. Firefox 3.6 feedback

    • by Alix Franquet • Firefox 3.6 • 76 comments

    Firefox 3.6 was released on Jan 21st and has already been downloaded more than 35 million times! It features a faster JavaScript engine, faster DOM performance and a bunch of new HTML5 features. Highlights for web developers include support for the WOFF font format, new CSS features like gradients and multiple backgrounds, drag and drop, File API, device orientation, and more. Want to see the full list? Look at our Firefox 3.6 for Developers page on developer.mozilla.org.

    We hope that you took the time to test Firefox 3.6 on your web sites before the release. If you didn’t, it’s not too late to let us know about issues. Here are a few problems that we’ve seen in the wild so far:

    • We’ve seen a couple of issues with the FCKEditor component, used widely on the web. It apparently doesn’t handle dates after 2009 properly (this is the first major browser release in 2010, a new decade!) and it also has some problems with document.readyState.
    • People who had the YSlow extension installed saw crashes with Firefox 3.6. YSlow has been updated to version 2.0.6 to fix the issue
    • Some Facebook apps were broken by a change we made to comply with the upcoming HTML5 standard. We updated element.getElementsByTagNameNS and document.getElementsByTagNameNS to no longer case-fold when doing tag name lookups. (We strongly suggest that you only use lower-case for tag names for many reasons, including this.) For more information, please see this note from Henri Sivonen about what’s changed. Facebook has since fixed the issue in their code, but other sites may also be tripping over this.

    We’re looking for feedback on any developer-facing regressions you’ve seen in 3.6 from 3.5. Please comment on this post if you have feedback.

  5. Firebug 1.5: a closer look

    • by Alix Franquet • Firebug • 15 comments

    Firebug 1.5 was released yesterday on addons.mozilla.org, where you can now download it. It’s compatible with the upcoming Firefox 3.6.

    If you’d like to take a more in-depth look at what’s new in Firebug 1.5, here’s a series of articles written by Firebug contributor Jan Odvarko (aka Honza):

    If you’ve had a chance to try the new Firebug, comment here or in the Firebug newsgroup and tell the team what you think!

  6. Firebug 1.5 released!

    • by Alix Franquet • Featured Article, Firebug • 24 comments

    Editor’s note: today the Firebug team released Firebug 1.5. Check out Rob Campbell’s announcement reposted below.

    I am very happy to be able to announce the release of Firebug 1.5.0 on addons.mozilla.org. This release represents a significant effort by the Firebug Working Group which saw the addition of some new faces over the last few months.

    Here’s a quick run-down of some of the new features:

    • Enhanced Inspector
    • More accurate Net panel timings
    • Break on HTML mutation
    • MathML and SVG namespace support
    • Break on XHR
    • Improved HTML editing
    • Persist buttons on Console and Net panel
    • Separate Computed CSS and Style subpanels
    • Many many bugfixes and stability improvements

    This is a huge release and these are just some of the highlights you’ll see in this new version. Please feel free to read the Firebug 1.5 release notes and John Barton’s blog post for more details.

    As always, if you encounter any problems, don’t be shy about filing a bug! We’ll be following up with quick point-releases if and when you find issues.

    Special shout-outs and thanks to Mike Ratcliffe for the Inspector improvements, Steven Roussey for HTML editor improvements, SVG and MathML namespace patches, Honza for being awesome and John Barton for his tireless contributions.

    If you’re new to Firebug, you might want to check out my introduction to Firebug screencast.

  7. JavaScript speedups in Firefox 3.6

    • by Alix Franquet • Featured Article, Firefox, Firefox 3.6, JavaScript, TraceMonkey • 85 comments

    This post was written by David Mandelin who works on Mozilla’s JavaScript team.

    Firefox 3.5 introduced TraceMonkey, our new JavaScript engine that traces loops and JIT compiles them to native (x86/ARM) code. Many JavaScript programs ran 3-4x faster in TraceMonkey compared to Firefox 3. (See our previous article for technical details.)

    For JavaScript performance in Firefox 3.6, we focused on the areas that we thought needed further improvement the most:

    • Some JavaScript code was not trace-compiled in Firefox 3.5. Tracing was disabled by default for Firefox UI JavaScript and add-on JavaScript, so those programs did not benefit from tracing. Also, many advanced JavaScript features were not trace-compiled. For Firefox 3.6, we wanted to trace more programs and more JS features.
    • Animations coded with JavaScript were often choppy because of garbage collection pauses. We wanted to improve GC performance to make pauses shorter and animations smoother.

    In this article, I’ll explain the most important JS performance improvements that come with Firefox 3.6. I’ll focus on listing what kinds of JS code get faster, including sample programs that show the improvements Fx3.6 makes over Fx3.5.

    JIT for Browser UI JavaScript

    Firefox runs JavaScript code in one of two contexts:content and chrome (no relation to Google Chrome). JavaScript that is part of web content runs in a content context. JavaScript that is part of the browser UI or browser add-ons runs in a chrome context and has extra privileges. For example, chrome JS can alter the main browser UI, but content JS is not allowed to.

    The TraceMonkey JIT can be enabled or disabled separately for content and chrome JS using about:config. Because bugs affecting chrome JS are a greater risk for security and reliability, in Firefox 3.5 we chose to disable the JIT for chrome JS by default. After extensive testing, we’ve decide to enable the JIT for chrome JS by default, something we did not have time to fully investigate for Fx3.5. Turning on the JIT for chrome should make the JS behind the Firefox UI and add-ons run faster. This difference is probably not very noticeable for general browser usage, because the UI was designed and coded to perform well with the older JS engines. The difference should be more noticeable for add-ons that do heavy JS computation.

    Option Fx3.5 Default Fx3.6 Default
    javascript.options.jit.chrome false true
    javascript.options.jit.content true true
    about:config options for the JIT

    Garbage Collector Performance

    JavaScript is a garbage-collected language, so periodically the JavaScript engine must reclaim unused memory. Our garbage collector (GC) pauses all JavaScript programs while it works. This is fine as long as the pauses are “short”. But if the pauses are even a little too long, they can make animations jerky. Animations need to run at 30-60 frames per second to look smooth, which means it should take no longer than 17-33 ms to render one frame. Thus, GC pauses longer than 40 ms cause jerkiness, while pauses under 10 ms should be almost unnoticeable. In Firefox 3.5, pause times were noticeably long, and JavaScript animations are increasingly common on the web, so reducing pause times was a major goal for JavaScript in Firefox 3.6.

    Demo: GC Pauses and Animation

    Demo.
    The spinning dial animation shown here illustrates pause times. Besides animating the dial, this demo creates one million 100-character strings per second, so it requires frequent GC. The frame delay meter gives the average time between frames in milliseconds. The estimated GC delay meter gives the average estimated GC delay, based on the assumption that if a frame has a delay of 1.7 times the average delay or more, then exactly one GC ran during that frame. (This procedure may not be valid for other browsers, so it is not valid for comparing different browsers. Note also that the GC time also depends on other live JavaScript sessions, so for a direct comparison of two browsers, have the same tabs open in each.) On my machine, I get an estimated GC delay of about 80 ms in Fx3.5, but only 30 ms in Fx3.6.

    But it’s a lot easier to see the difference by opening the demo in Fx3.5, watching it a bit, and then trying it in Fx3.6.
    In Fx3.5, I see frequent pauses and the animation looks noticeably jerky. In Fx3.6, it looks pretty smooth, and it’s hard for me even to tell exactly when the GC is running.

    How Fx3.6 does it better. We’ve made many improvements to the garbage collector and memory allocator. I want to give a little more technical details on the big two changes that really cut our pause times.

    First, we noticed that a large fraction of the pause time was spent calling free to reclaim the unused memory. We can’t do much to make freeing memory faster, but we realized we could do it on a separate thread. In Fx3.6, the main JS thread simply adds unused memory chunks to a queue, and another thread frees them during idle time or on a separate processor. This means machines with 2 or more cores will benefit more from this change. But even when one core, freeing might be delayed to an idle time when it will not affect scripts.

    Second, we knew that in Fx3.5 running GC clears out all the native code compiled by the JIT as well as some other caches that speed up JS. The reason is that the tracing JIT and GC did not know about each other, so if the GC ran, it might reclaim objects being used by a compiled trace. The result was that immediately after a GC, JS ran a bit slower as the caches and compiled traces were built back up. This would be experienced as either an extended GC pause or a brief hiccup of slow animation right after the GC pause. In Fx3.6, we taught the GC and the JIT to work together, and now the GC does not clear caches or wipe out native code, so it resumes running normally right after GC.

    Tracing More JavaScript Constructs

    In my article on TraceMonkey for the Fx3.5 release, I noted that certain code constructs, such as the arguments object, were not traced and did not get performance improvements from the JIT. A major goal for JS in Fx3.6 was to trace more stuff, so more programs can run faster. We do trace more stuff now, in particular:

    • DOM Properties. DOM objects are special and harder for the trace compiler to work with. For Fx3.5, we implemented tracing of DOM methods, but not DOM properties. Now we trace DOM properties (and other “native” C++ getters and setters) as well. We still do not trace scripted getters and setters.
    • Closures. Fx3.5 traced only a few operations involving closures (by which I mean functions that refer to variables defined in lexically enclosing functions). Fx3.6 can trace more programs that use closures. The main operation that is still not traced yet is creating an anonymous function that modifies closure variables. But calling such a function and actually writing to the closure variables are traced.
    • arguments. We now trace most common uses of the arguments keyword. “Exotic” uses, such as setting elements of arguments, are not traced.
    • switch. We have improved performance when tracing switch statements that use densely packed numeric case labels. These are particularly important for emulators and VMs.

    These improvements are particularly important for jQuery and Dromaeo, which heavily use arguments, closures, and the DOM. I suspect many other complex JavaScript applications will also benefit. For example, we recently heard from the author that this R-tree library performs much better in Fx3.6.

    Here is a pair of demos of new things we trace. The first sets a DOM property in a loop. The second calls a sum function implemented with arguments I get a speedup of about 2x for both of them in Fx3.6 vs. Fx3.5.

    Demo: Fx3.6 Tracing DOM properties and arguments


    DOM Property Set:

    Sum using arguments:

    String and RegExp Improvements

    Fx3.6 includes several improvements to string and regular expression performance. For example, the regexp JIT compiler now supports a larger class of regular expressions, including the ever-popular \w+. We also made some of our basic operations faster, like indexOf, match, and search. Finally, we made concatenating sequences of several strings inside a function (a common operation in building up HTML or other kinds of textual output) much faster.

    Technical aside on how we made string concatenation faster: The C++ function that concatenates two strings S1 and S2 does this: Allocate a buffer big enough to hold the result, then copy the characters of S1 and S2 into the buffer. To concatenate more than two strings, as in JS s + "foo" + t, Fx3.5 simply concatenates two at a time from left to right.

    Using the Fx3.5 algorithm, to concatenate N strings each of length K, we need to do N-1 memory allocations, and all but one of them are for temporary strings. Worse, the first two input strings are copied N-1 times, the next one is copied N-2 times, and so on. The total number of characters copied is K(N-1)(N+2)/2, which is O(N^2).

    Clearly, we can do a lot better. The minimum work we can do is to copy each input string exactly once to the output string, for a total of KN characters copied. Fx3.6 achieves this by detecting sequences of concatenation in JS programs and combining the entire sequence into one operation that uses the optimal algorithm.

    Here are a few string benchmarks you can try that are faster in Fx3.6:

    Demo: Fx3.6 String Operations


    /\w+/:

    indexOf('foo'):

    match('foo'):

    Build HTML:

    Final Thoughts and Next Steps

    We also made a lot of little improvements that don't fit into the big categories above. Most importantly, Adobe, Mozilla, Intel, Sun, and other contributors continue to improve nanojit, the compiler back-end used by TraceMonkey. We have improved its use of memory, made trace recording and compiling faster, and also improved the speed of the generated native code. A better nanojit gives a boost to all JS that runs in the JIT.

    There are two big items that didn't make the cut for Fx3.6, but will be in the next version of Firefox and are already available in nightly builds:

    • JITting recursion. Recursive code, like explicit looping code, is likely to be hot code, so it should be JITted. Nightly builds JIT directly recursive functions. Mutual recursion (g calls f calls g) is not traced yet.
    • AMD x64 nanojit backend. Nanojit now has a backend that generates AMD x64 code, which gives the possibility of better performance on that plaform.

    And if you try a nightly build, you'll find that many of these demos are already even faster than in Fx3.6!

  8. the new about:hacks newsletter

    • by Alix Franquet • about:hacks, Featured Article, MDN • 4 comments

    Yesterday, we published the first issue of about:hacks, Mozilla’s newsletter for web developers. If you asked to receive news and updates from Mozilla in our November survey, it should be waiting for you in your inbox.

    abouthacksheader

    About:hacks will be published monthly, and will include demos, tutorials, Firefox release information, the latest on web standards and developer tools, and updates on the Mozilla Developer Network.

    This first issue includes, among other things, a demo that combines Processing and multi-touch, an HTML5 video tutorial, a preview of Firebug 1.5 and Eventbug, and a sneak peek at what’s going on behind the scenes at Mozilla.

    We know you may already be reading the hacks blog, following @mozhacks on Twitter, and maybe even subscribing to mozhacks on YouTube, so we’ll make sure the newsletter is a good mix of original content and a recap of some of the most important things that happened in the previous month.

    This is why your feedback is very important: what did you like? what would you change? what would you like to see in the next issue? Let us know and we’ll make sure to write the newsletter you want to read!

    If you haven’t seen about:hacks, check it out, and if you like it, subscribe to get the next issue in January.

  9. css backgrounds in Firefox 3.6

    • by Alix Franquet • CSS, Firefox, Firefox 3.6 • 17 comments

    Firefox 3.6 allows you to do more with CSS backgrounds: you can use gradients, set a background size, and specify multiple backgrounds.

    Custom Background Size

    In Firefox 3.6, you can specify the size of a background image to scale it as a percentage of the element’s size, or to a specific length, using -moz-background-size.

    -moz-background-size:  <bg-size>[, <bg-size>]*

    Percentages. In this example, you can see the effect of setting a size using percentages. On the left, size is set to auto, which maintains the original size of the background image. In the center, size is set to 100%, which scales the background image to 100% of the area (horizontally), even if the original image was smaller than the background positioning area. On the right, size is set to 10%, which scales the image to 10% of the area. The background image is repeated by default.

    css_bgsize_autoto10_fxlogo

     .bg_example_left {
  background: url(http://demos.hacks.mozilla.org/openweb/resources/images/logos/firefox-48.png);
  -moz-background-size: auto;
}
 .bg_example_center {
  background: url(http://demos.hacks.mozilla.org/openweb/resources/images/logos/firefox-48.png);
  -moz-background-size: 100%;
}
 .bg_example_right {
  background: url(http://demos.hacks.mozilla.org/openweb/resources/images/logos/firefox-48.png);
  -moz-background-size: 10%;
}

    Here’s the same example (auto – 100% – 10%) using a different background image. In this case, the original is larger than the background area. As a result, specifying “auto” shows only a portion of the original, and you need to set a size of 100% to make the full image visible.

    css_bgsize_autoto10_flowers

    Horizontal and Vertical Scaling. It it possible to define a size for both horizontal and vertical scaling. Specifying only one size sets horizontal scaling (as in the examples above) and vertical defaults to “auto”. If a second size is specified, it is used for vertical scaling, as in the example below. On the left you can see an image with horizontal scaling of 100% and vertical defaulting to “auto”. On the right, horizontal is set to 100% and vertical is 30%, changing the original appearance of the image because of the change in proportions.

    css_bg_size_vert

      -moz-background-size: 100%;
  -moz-background-size: 100% 30%;

    Custom Size Demo. Try our interactive demo: select the size of a background on the fly. You’ll need the latest beta of Firefox 3.6.

    Multiple Backgrounds

    Firefox 3.6 also enables you to stack multiple backgrounds. This allows you to create cool effects by stacking a gradient on top of an image for example.

    Defining. To define multiple backgrounds, simply list them as follows, using the background CSS property:

    .foo {
  background: background1, background2, ..., backgroundN;
}

    The order in which you list the backgrounds matters: the first in the list will appear as the top layer, the last one as the bottom layer.

    Setting Properties. For multiple backgrounds, you can set the same properties you would for a single background, such as background-position or background-repeat. Define each background’s behavior by specifying a value for each property. The values need to be listed in the order in which you initially listed the backgrounds.

    So if you defined:

      background: background1, background2, background3;

    List the values in the same order for each property:

      background-position: background1_position, background2_position, background3_position;
  background-repeat: background1_repeat, background2_repeat, background3_repeat;

    Example. Here’s how to stack three different backgrounds: the Firefox logo, a linear gradient, and an image with flowers. If you’re running Firefox 3.6 beta, you can turn on and off any or all of the three backgrounds in our interactive demo.

    css_multibg

     .multi_bg_example {
  background: url(http://demos.hacks.mozilla.org/openweb/resources/images/logos/firefox-48.png), -moz-linear-gradient(left, rgba(255, 255, 255, 0),  rgba(255, 255, 255, 1)), url(http://demos.hacks.mozilla.org/openweb/resources/images/patterns/flowers-pattern.jpg);
  background-repeat: no-repeat, no-repeat, repeat;
  background-position: bottom right, left, right;
}

  10. css gradients in Firefox 3.6

    • by Alix Franquet • CSS, Feature, Featured Article, Firefox 3.6, Standards • 54 comments

    Firefox 3.6 includes many CSS improvements. In this post we’re going to show you how to use CSS gradients.

    If you are running the latest beta of Firefox 3.6, you should check out our interactive demo and take a look at the corresponding code. Use the radio buttons to switch different style options on or off.

    Backgrounds with CSS Gradients

    Using CSS gradients in a background allows you to display smooth transitions between two or more specified colors without having to use images. This in turn reduces download time and bandwidth use, looks better while zooming, and lets you create a more flexible layout.

    Firefox 3.6 supports two kinds of CSS gradients: linear (-moz-linear-gradient) and radial (-moz-radial-gradient).

    Linear Gradients

    To create a linear gradient, you’ll need to set a starting point and a direction (or angle) for the gradient and to define the color stops.

     -moz-linear-gradient( [<point> || <angle>,]? <stop>, <stop> [, <stop>]* )

    Starting Point. The starting point works just like background position. You can set the horizontal and the vertical positions as a percentage, in pixels, or using left/center/right for horizontal, and top/center/bottom for vertical. Positions start from the top left corner. If you don’t specify the horizontal or the vertical position, it will default to center.

    For example, here’s a linear gradient that starts at the center (horizontal) and top (vertical), and goes from blue to white:

    basic_linear_bluetop

      .linear_gradient_square {
    width: 100px;
    height: 100px;
    border: 1px solid #333;
    background: -moz-linear-gradient(top, blue, white);
  }

    One that starts left (horizontal) and center (vertical):

    basic_linear_blueleft

        background: -moz-linear-gradient(left, blue, white);

    And a gradient starting left (horizontal) and top (vertical):

    basic_linear_bluetopleft

        background: -moz-linear-gradient(left top, blue, white);

    Angle. As you can see above, if you don’t specify an angle, it is defined automatically based on the start position. If you would like more control over the direction of the gradient, you can set the angle as well.

    For example, the following gradients have the same starting point of left center, but the one on the right hand-side also has an angle of 20 degrees.

    linear_gradient_angle

        background: -moz-linear-gradient(left 20deg, black, white);

    When specifying the angle, remember that is it the angle between a horizontal line and the gradient line, going counter-clockwise. So using 0deg will generate a left to right horizontal gradient, while 90deg will create a vertical gradient from the bottom to the top.

    linear_redangles

        background: -moz-linear-gradient(<angle>, red, white);

    Color Stops. In addition to start position and angle, you should specify color stops. Color stops are points along the gradient line that will have the specified color at the specified location (set as a percentage or length). The number of color stops is unlimited. If you use a percentage for the location, 0% represents the starting point, and 100% is the ending point, but values above and below those can be used to achieve the desired effect.

    Here’s a simple example with three color stops. Because no point is specified for the first and last colors, they will default to 0% and 100%.

    linear_colorstops

        background: -moz-linear-gradient(top, blue, white 80%, orange);

    Colors will be evenly spaced if no position is specified.

    linear_rainbow

        background: -moz-linear-gradient(left, red, orange, yellow, green, blue);

    Transparency. Gradients also support transparency. This can be useful, for example, when stacking multiple backgrounds. Here’s a combination of two backgrounds: one image and one linear gradient from white to transparent white.

    linear_multibg_transparent

    .multibackground_transparent {
    background: -moz-linear-gradient(right, rgba(255,255,255,0), rgba(255,255,255,1)), url(http://demos.hacks.mozilla.org/openweb/resources/images/patterns/flowers-pattern.jpg);
}

    Radial Gradients

    The syntax for radial gradients is very similar to that of linear gradients:

     -moz-radial-gradient([<bg-position> || <angle>,]? [<shape> || <size>,]? <color-stop>, <color-stop>[, <color-stop>]*);

    In addition to the start position, the direction, and the colors, which you have already seen in linear gradients, radial gradients allow you to specify the gradient’s shape (circle or ellipse) and size (closest-side, closest-corner, farthest-side, farthest-corner, contain or cover).

    Color stops. Just like with linear gradients, you should define color stops along the gradient line. The following circles have the same color stops, but the gradient on the left defaults to evenly spaced colors, while the one on the right has a specific position for each color.

    radial_gradient_stop

     background: -moz-radial-gradient(red, yellow, #1E90FF);
 background: -moz-radial-gradient(red 5%, yellow 25%, #1E90FF 50%);

    Shape. Here you can see the difference between the two possible shapes, a circle (on the left) and an ellipse (on the right), both with a bottom left starting point:

    radial_circle_ellipse

     .radial_gradient_circle {
    background: -moz-radial-gradient(bottom left, circle, red, yellow, #1E90FF);
}
 .radial_gradient_ellipse {
    background: -moz-radial-gradient(bottom left, ellipse, red, yellow, #1E90FF);
}

    Size. The different options for size (closest-side, closest-corner, farthest-side, farthest-corner, contain or cover) refer to the point used to define the size of the circle or ellipse.

    Example: closest-side vs. farthest corner for an ellipse.
    The following two ellipses have different sizes. The one on the left is set by the distance from the start point (center) to the closest-side, while the one on the right is determined by the distance from the start point to the farthest corner.

    radial_ellipse_size

      background: -moz-radial-gradient(ellipse closest-side, red, yellow 10%, #1E90FF 50%, white);
  background: -moz-radial-gradient(ellipse farthest-corner, red, yellow 10%, #1E90FF 50%, white);

    Example: closest-side vs. farthest-side for a circle.
    The size of the circle on the left is determined by the distance between the start point (the center) and the closest side, while the one on the right is the distance between the start point and the farthest side.

    radial_circle_size

     background: -moz-radial-gradient(circle closest-side, red, yellow 10%, #1E90FF 50%, white);
 background: -moz-radial-gradient(circle farthest-side, red, yellow 10%, #1E90FF 50%, white);

    Example: contained circle.
    Here you can see the default circle on the left, and the version of the same gradient but contained on the right.

    radial_contain

     background: -moz-radial-gradient(red, yellow, #1E90FF);
 background: -moz-radial-gradient(contain, red, yellow, #1E90FF);

    Repeating Gradients

    If you would like to repeat a gradient, you should use -moz-repeating-linear-gradient and -moz-repeating-radial-gradient.

    In the examples below, four color stops are specified in each case, and are repeated indefinitely.

    repeating_gradients

     .repeating_radial_gradient_example {
    background: -moz-repeating-radial-gradient(black, black 5px, white 5px, white 10px);
}
 .repeating_linear_gradient_example {
     background: -moz-repeating-linear-gradient(top left -45deg, red, red 5px, white 5px, white 10px);
}

    Demo

    Check out our interactive demo of linear and radial gradients for more examples.

    Note that the gradient syntax has changed between Firefox 3.6 beta 1 and beta 2, so if you used gradients with beta 1, you may need to update your code.