Firefox 4: CSS3 calc()

This article describes the CSS3 calc() value. This feature hasn’t landed yet in any Firefox tree but work to implement it is underway.

Firefox will support the CSS calc() value, which lets you compute a length value using an arithmetic expression. This means you can use it to define the sizes of divs, the values of margins, the widths of borders, and so forth.

Here is an example of a layout which would be tricky to setup without the calc() function:

* Two divs aligned, split up by a 1em margin
#a {
  margin-right: 1em;
#b {
  width: -moz-calc(25% - 1em);

This example makes sure an input text field won’t overlap its parent:

input {
  border:1px solid black;
  width: -moz-calc(100% - 2 * 3px);

One particularly powerful feature of the calc() function that you can combine different units in the same computation:

width: -moz-calc(3px + 50%/3 - 3em + 1rem);

The current implementation supports the +, -, *, /, mod, min, and max operators.

We’ll also support the min() and max() functions, which could be used like this:

div {
  height: -moz-min(36pt, 2em);
  width: -moz-max(50%, 18px);

For more details, see:

About Paul Rouget

Paul is a Firefox developer.

More articles by Paul Rouget…


  1. Vladimir Carrer

    My CSS Framework Malo can definitely use this new cool feature!

    June 11th, 2010 at 08:06

  2. Thany

    Why the -moz- prefix? This only forces developers to include de calc() twice: with prefix and without prefix. Is there any technical reason to require the prefix?

    (I know this also goes for border-radius, box-shadow, and others, but this article is about calc)

    June 11th, 2010 at 08:08

    1. David

      Because CSS3 is not finalised. In the mean time, you can use the vendor specific implementations
      So, yes, while the feature is experimental, you need to do your css for each vendor, and then the general rule at the end. If the browser supports the general rule, it will use it, otherwise it will fall back on the vendor specifc rule that it supports.

      June 14th, 2010 at 22:55

      1. Thany

        So there’s no technical reason why no prefix wouldn’t work ;)

        July 19th, 2010 at 23:49

        1. okonomiyaki3000

          To be more clear about the need for vendor prefixes, consider that (until the spec is finalized) each vendor may support a somewhat different (competing) version of any given feature. Each vendor’s version may have different syntax/behavior/etc. So, if there were no vendor prefixes, you often couldn’t write code using these ‘early adopter’ features that would work in more than one browser. The trade off is that you have to write a couple more lines of code.

          If you don’t like doing that, you should just wait until the spec is final.

          February 15th, 2011 at 21:56

    2. Magne Andersson

      As long as the implemented property is either defined in a specification that has not reached the “Candidate recommendation” status, or is vendor proprietary, a browser has to have the prefix. It’s the “law”.

      June 15th, 2010 at 01:31

  3. Lachu

    Może byś napisał, że powyższy news jest reklamą twojego bloga?

    Above comment are advertisement of Pingback’s blog. They don;t give a link, but suggest to view it. Pingback are suggest to view a translated version of this article, published on Creative Commons – Attribution.

    Sorry for my English.

    June 11th, 2010 at 09:27

  4. HB

    Nice, the flexibility of “expression” without the performance drama (presumably, given what’s in the spec).

    June 11th, 2010 at 09:44

  5. nemo

    Klasmi, box-sizing: border-box

    well, -moz-box-sizing for Firefox.

    But that doesn’t help in all situations.

    June 11th, 2010 at 11:03

  6. carol according to this test you miss only 2 test thus far one is
    :link failed 1 test out of 2
    and ;visited 1 out of two .might be a good idea to look into those since these are probably very small isse!

    June 13th, 2010 at 08:07

    1. Magne Andersson

      Actually, Firefox has passed all of those tests for a long time now. Pretty recently, a fix for a privacy issue related to :link and :visited landed which broke what is tested. The spec allows this, and it is implemented in both Gecko and Webkit so far. There is also a bug filed about updating the test to allow for this patch: So far, the author hasn’t changed it.

      June 13th, 2010 at 10:03

  7. […] 원본: […]

    June 14th, 2010 at 20:47

  8. No. Don’t do it. If we need calculations we should do it elsewhere.

    June 16th, 2010 at 09:50

    1. Drum Boom

      Than Who Needs This Crap in FF? Who will use calc in his css?

      June 18th, 2010 at 01:15

      1. Magne Andersson

        I will, along with many other people as you can probably see by reading the comments. What would you do if you need a height of 100% – 10px?

        June 18th, 2010 at 02:04

        1. Drum Boom

          What you’ve done before for this calc?
          Cross-browser compatibility has not been canceled. And until the normal support CSS3 will have at least 80% of users – you do not feel better by the fact that this possibility is in FF? I think that before CSS will work faster on the WEB KIT because the load on him is growing by leaps and bounds

          June 18th, 2010 at 08:45

          1. Magne Andersson

            I only understood half of your post, but to me it sounds like you are criticizing Mozilla for implementing this before other browsers. Someone has to be first, and others will follow.

            June 18th, 2010 at 08:51

          2. Drum Boom

            No, but I don’t like the -moz prefix , which apparently means that it is an internal standard, rather than conventional, If you some thing first – do this for future compatibility.

            June 18th, 2010 at 09:37

          3. Magne Andersson

            Can’t we get this settled once and for all? A CSS property must have a prefix until the spec where it is described in has reached “Candidate Recommendation” status, or is vendor proprietary. Mozilla can’t do anything about this, it is a decision taken by the CSS WG which must be respected. Do you understand?

            June 18th, 2010 at 09:51

  9. Drum Boom

    Is it fast? Who tested this feature(bug),
    I mean, is it faster than Java Script?

    June 16th, 2010 at 22:14

    1. Magne Andersson

      Since it is specifically made for these calculations, it should be, yes.

      June 18th, 2010 at 02:04

  10. Arnold

    Is this the feature first of it’s kind or this has been earlier implemented by any other browser before this.

    By the way thanks for the info.

    June 17th, 2010 at 05:53

    1. Magne Andersson

      Nope. Firefox is the first browser to support it, even partially.

      June 18th, 2010 at 02:02

      1. Ryan

        I’m not sure about that did you land your changes before IE9’s partial implementation? Check out this demo in IE9 or FF4 with calc support

        July 19th, 2010 at 19:29

  11. Dan

    It’s funny that this is coming from Mozilla. The same people that tell us that we should use CSS descendant selectors as little as possible because they’re so slow in Firefox. So, this right here ought to be fast, right? If not, better make the primitive stuff faster first, please. Thank you.

    June 18th, 2010 at 08:01

    1. Magne Andersson

      I’ve never noticed that they would be slow. Where, and when did they say that?

      June 18th, 2010 at 08:47

      1. Dan

        Well, here for example:

        June 18th, 2010 at 09:49

    2. Boris

      Dan, you misunderstood the “efficient CSS” page.

      Descendant selectors are slow compared to others in ALL browsers. If you want your CSS to be fast, you’ll avoid them. If you don’t care whether it’s fast, you’ll use them. Matching them is fast in absolute terms; the problems start when you have thousands of style rules. The target audience of the “efficient CSS” page originally (Firefox browser UI developers) have that many rules around. Most web pages don’t, so for them the issue doesn’t matter.

      June 24th, 2010 at 09:56

  12. tbx

    nice! this library also brings some nifty CSS ideas:

    June 20th, 2010 at 04:25

  13. Witek

    -moz prefix is needed, because -moz-calc is avialable right now, before CSS3 finalized. Many web developer will start using it (I hope without the additional rule without “-moz-” prefix), but when CSS3 and calc() will be standarized and finalized, it is highly probable that calc (without prefix) will have VERY DIFFERENT specification. This will mean that -moz-calc and calc after finalizing will mean DIFFERENT things. This is why it is NEEDED, and this is also the reason why web developers SHOULD NOT use both rules at the same time (untile there is no finalized calc statment). Any way, you could just detect webbrowser and send one CSS file with appropriate data. But even if you know it is firefox, you could possible WANT to send both -moz-calc and calc, because in., Firefox 4 it will something different than for example in Firefox 4.5.

    You can also use something like LESS or SASS, which not only simplifies such repeated rules (if you REALLY, REALLY, REALLY need, but you REALLY do not need), using mixins. It adds also other nice features like nesting, variables, functions.

    PS. Really nice development for CSS. About 5 years ago I was wondering, if I could write width: 100% – 20px; Tested, it do not worked, and just forogot about the idea :) Thanks.

    June 22nd, 2010 at 06:50

  14. nemo

    Dan, that article is specifically titled:
    Writing Efficient CSS for use in the Mozilla UI

    Are you writing an addon?

    June 23rd, 2010 at 18:46

  15. rene

    Well, this is gonna be very useful if you can make operations with colors too (like sass or less), will be cool something like:

    @xvar: #333;
    color: -moz-calc(@xvar + #111);

    July 7th, 2010 at 16:08

  16. Darrell Estabrook

    I have no problem with calculations within the style sheet since the purpose is to arrive at a value we would have entered in staticly to begin with (if we could know it).

    My beef in CSS3 is with mixing the Interaction Layer (i.e. “transition,” “animation,” etc.) with the Presentation Layer. We worked so hard separating the Presentation Layer from the Markup, why muddy it up again (especially when jQuery is so elegant and cross-browser)?

    July 8th, 2010 at 07:35

    1. Dan

      One could argue that often animation isn’t being used for much more than eyecandy.

      And how would it muddy up your markup? The CSS comes in it’s own file, right?

      If anything, the animation code is messing up your application logic.

      July 10th, 2010 at 02:25

  17. Ant Gray

    Will this work? ↓

    calc(10% * 5%)

    It would be much easier to create parallax effect with this.

    July 11th, 2010 at 00:08

  18. […] CSS-egenskaber og -selektorer som resize, any, calc og […]

    August 12th, 2010 at 06:22

  19. Stevo

    Great feature, can’t wait till it’s standard.

    Trying to balance pixel width borders with percentage width boxes is a real pain, this ought to make things loads easier :-)

    September 1st, 2010 at 07:54

  20. ivanhoe

    According to David Baron there is no plan to support calc() for background-position?!

    However I believe it would be really cool to have support for bg. positions too, as it would simplify using sprites a lot. It would allow us to have sprites positioned at easy to read offsets e.g. 0, 16px, 2 * 16px, 3 * 16px, etc.. which is a way cleaner and easier to update (just search & replace), than with pre-calculated values.

    September 6th, 2010 at 09:38

  21. Andy

    Hey guys, what’s the deal with ? Is it just temporary as part of an internal redesign/refactor?

    September 10th, 2010 at 03:46

  22. Andy

    Update: here’s the relevant www-style thread about dropping min() and max() in calc().

    September 10th, 2010 at 21:37

  23. […] Firefox 4: CSS3 calc() announcement on Mozilla Hacks […]

    June 13th, 2011 at 15:36

  24. […] Firefox 4: CSS3 calc() […]

    July 12th, 2011 at 10:16

  25. josi

    Has somebody tried:
    min-width: -moz-min(50px, -moz-max-content);
    I’ve done this to workaround an iceweasel misbehaviour and need this line for current firefox.

    April 4th, 2012 at 00:38

  26. […] Read Tutorial : Firefox 4: CSS3 calc() […]

    April 14th, 2012 at 04:02

Comments are closed for this article.