Mozilla

Firefox 4: CSS3 calc()

on June 10, 2010 by

in CSS

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 {
  width:75%;
  margin-right: 1em;
}
#b {
  width: -moz-calc(25% - 1em);
}

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

input {
  padding:2px;
  border:1px solid black;
  display:block;
  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:

112 comments

Comments are now closed.

  1. Vladimir Carrer wrote on June 11th, 2010 at 8:06 am:

    My CSS Framework Malo http://code.google.com/p/malo/ can definitely use this new cool feature!

  2. Thany wrote on June 11th, 2010 at 8:08 am:

    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)

    1. David wrote on June 14th, 2010 at 10:55 pm:

      Because CSS3 is not finalised. In the mean time, you can use the vendor specific implementations
      http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(CSS)#General_notes
      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.

      1. Thany wrote on July 19th, 2010 at 11:49 pm:

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

        1. okonomiyaki3000 wrote on February 15th, 2011 at 9:56 pm:

          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.

    2. Magne Andersson wrote on June 15th, 2010 at 1:31 am:

      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”.

  3. Lachu wrote on June 11th, 2010 at 9:27 am:

    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.

  4. HB wrote on June 11th, 2010 at 9:44 am:

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

  5. nemo wrote on June 11th, 2010 at 11:03 am:

    Klasmi, box-sizing: border-box

    well, -moz-box-sizing for Firefox.

    But that doesn’t help in all situations.

  6. carol wrote on June 13th, 2010 at 8:07 am:

    http://tools.css3.info/selectors-test/test.html 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!

    1. Magne Andersson wrote on June 13th, 2010 at 10:03 am:

      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: https://bugzilla.mozilla.org/show_bug.cgi?id=558569. So far, the author hasn’t changed it.

  7. Pingback from Firefox 4: CSS3 cals() ✩ Mozilla 웹 기술 블로그 on June 14th, 2010 at 8:47 pm:

    [...] 원본: http://hacks.mozilla.org/2010/06/css3-calc/ [...]

  8. @acarback wrote on June 16th, 2010 at 9:50 am:

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

    1. Drum Boom wrote on June 18th, 2010 at 1:15 am:

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

      1. Magne Andersson wrote on June 18th, 2010 at 2:04 am:

        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?

        1. Drum Boom wrote on June 18th, 2010 at 8:45 am:

          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

          1. Magne Andersson wrote on June 18th, 2010 at 8:51 am:

            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.

          2. Drum Boom wrote on June 18th, 2010 at 9:37 am:

            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.

          3. Magne Andersson wrote on June 18th, 2010 at 9:51 am:

            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?

  9. Drum Boom wrote on June 16th, 2010 at 10:14 pm:

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

    1. Magne Andersson wrote on June 18th, 2010 at 2:04 am:

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

  10. Arnold wrote on June 17th, 2010 at 5:53 am:

    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.

    1. Magne Andersson wrote on June 18th, 2010 at 2:02 am:

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

      1. Ryan wrote on July 19th, 2010 at 7:29 pm:

        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 http://www.thecssninja.com/demo/css_calc/

  11. Dan wrote on June 18th, 2010 at 8:01 am:

    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.

    1. Magne Andersson wrote on June 18th, 2010 at 8:47 am:

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

      1. Dan wrote on June 18th, 2010 at 9:49 am:

        Well, here for example: https://developer.mozilla.org/en/Writing_Efficient_CSS

    2. Boris wrote on June 24th, 2010 at 9:56 am:

      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.

  12. tbx wrote on June 20th, 2010 at 4:25 am:

    nice! this library also brings some nifty CSS ideas:

    http://fadeyev.net/2010/06/19/lessjs-will-obsolete-css/

  13. Witek wrote on June 22nd, 2010 at 6:50 am:

    -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.

  14. nemo wrote on June 23rd, 2010 at 6:46 pm:

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

    Are you writing an addon?

  15. rene wrote on July 7th, 2010 at 4:08 pm:

    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);

  16. Darrell Estabrook wrote on July 8th, 2010 at 7:35 am:

    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)?

    1. Dan wrote on July 10th, 2010 at 2:25 am:

      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.

  17. Ant Gray wrote on July 11th, 2010 at 12:08 am:

    Will this work? ↓

    calc(10% * 5%)

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

  18. Pingback from Prøv Firefox 4 Beta! « MozillaDanmarks blog on August 12th, 2010 at 6:22 am:

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

  19. Stevo wrote on September 1st, 2010 at 7:54 am:

    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 :-)

  20. ivanhoe wrote on September 6th, 2010 at 9:38 am:

    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.

  21. Andy wrote on September 10th, 2010 at 3:46 am:

    Hey guys, what’s the deal with https://bugzilla.mozilla.org/show_bug.cgi?id=363249#c83 ? Is it just temporary as part of an internal redesign/refactor?

  22. Andy wrote on September 10th, 2010 at 9:37 pm:

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

    http://lists.w3.org/Archives/Public/www-style/2010Sep/thread.html#msg233

  23. Pingback from Web Designer Notebook » The Wonderful calc() Function on June 13th, 2011 at 3:36 pm:

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

  24. Pingback from 55 Best CSS3 Tutorials 2011 | Web Development | iDesignow on July 12th, 2011 at 10:16 am:

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

  25. josi wrote on April 4th, 2012 at 12:38 am:

    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.

  26. Pingback from 85 The Most Useful CSS3 Tutorials | Bashooka on April 14th, 2012 at 4:02 am:

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

1 2

Comments are closed for this article.