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. Gary van der Merwe

    OMG – That will rock!!!!

    June 10th, 2010 at 05:39

  2. iGEL

    Some questions about the -moz prefix:
    1. At which point will interpret CSS3 without the -moz prefix?
    2. If you do, will you still interpret the prefixed version?
    3. Which declaration will win, if you interpret both? -moz or the normal version?
    4. Why do you interpret some CSS stuff like opacity without prefix?

    From my point of view, you should drop the -moz prefix as early as possible. It leads only to bigger files and errors, if you have to declare things for times (IE filter, Mozilla, Webkit and standard for opera).

    June 10th, 2010 at 05:48

    1. Dan

      The -moz prefix is in place for CSS spec that is still in development.

      June 10th, 2010 at 13:07

    2. djmichaelb

      OMG I couldn’t agree with you more. WHy do they insist on using -moz or -webkit… they could just implement the native version surely since no-one else uses it yet anyway??

      Didn’t IE actually allow you to do this with their custom programing tags in CSS? It was BS and bloated, but the idea behind it was the same. Anyway, all I can say is bravo, about 15 years overdue and I wonder why it’s taken so long to get round to?

      June 10th, 2010 at 15:32

    3. David

      They follow the regular cascading rules of CSS.

      If you look at most examples using border-radius, you’ll see that they specify the vender specific rules first, then move to the standard border-radius rule. The last one will override the previous rules if the browser supports it. Otherwise, it will use the vendor specific rule.

      You’d want to do the same here with width, and provide a general width rule for browsers that don’t support calc, and then vendor specific rules, and finally the standard rule.

      June 10th, 2010 at 20:22

  3. Chemikk

    That is a great news!

    June 10th, 2010 at 05:49

  4. Nicholas Wilson

    I should just like to point out that for the first example we can currently do that rather easily using box-sizing. Set the width of #a to 75%, #b to 25%, add the offset as a border or padding, then use box-sizing: padding-box. This works right now on IE8, Fx1 etc. Mixing units is a new capability though which will be useful.

    June 10th, 2010 at 05:50

  5. Florent V.

    Although this will be quite useful when it lands in web browsers, i would like to remind readers that you don’t need this feature most of the time. There are workarounds for most cases. Sometimes the workaround is actually simpler than using calc(), for instance in the second example you can drop the `width` property and it will Just Work™.
    There’s also the `box-model` CSS3 property, which has relatively wide support already and might be a better solution in some cases.
    Of course those are welcome additions. :)

    June 10th, 2010 at 06:14

  6. Florent V.

    Hum, i meant `box-sizing`, not `box-model`, obviously. ^^

    June 10th, 2010 at 06:17

  7. Wladimir Palant

    I think web developers are salivating already :)

    iGEL: I’m not an expert on CSS but:
    1. From what I remember, the specification in question has to enter “Candidate Recommendation” phase at which point no major changes are expected. Also, Mozilla’s implementation has to conform to the current specification – at that point the prefix can be removed without hurting interoperability. Until then it is still a feature that might be subject to change.
    2. For some time, certainly. Occasionally it will be removed however (I think it usually took a year or two in the past).
    3. Both forms are treated the same, so your question basically boils down to – if a CSS property is specified twice, which one will win? From what I remember: the last one in the current block.
    4. opacity is part of the CSS 3 Color module which is apparently further advanced than CSS3 Values and Units module. Before that it was -moz-opacity for quite a while, then both forms were supported – now -moz-opacity is no longer supported IMO.

    June 10th, 2010 at 06:38

  8. Marcio B D A

    Wow! Calcs in CSS is my dream coming true! =O

    June 10th, 2010 at 06:47

  9. John Griffiths

    just too cool for school!

    very nice

    June 10th, 2010 at 07:47

  10. Eli Grey

    The most important use still can’t be done in Firefox 4, which would be using calc() to get measurements relevant to the vh and vw units. Please support vh and vw in Firefox 4.

    June 10th, 2010 at 08:38

  11. […] effervescent Paul Rouget shows us the CSS calc() goodness that has a bug going for […]

    June 10th, 2010 at 08:51

  12. Lachu

    CSS calc is less evil than IE’s Java Script container.

    Thanks Mozilla!

    June 10th, 2010 at 09:07

  13. Lachu

    I think, that -moz-max and -moz-min aren’t an evil and it’s 99% satisfied.

    June 10th, 2010 at 09:08

  14. Pieterv

    DO WANT!!!

    The absence of this feature in css has puzzled me ever since I started learning CSS.

    June 10th, 2010 at 09:14

  15. Ivan Enderlin

    Hey guys :-),

    Two things:
    * is it possible to combine these functions, like: witdh: -moz-max(-moz-calc(5% – 2.5em), -moz-calc(21px * 2))?
    * does the function -moz-calc() support flex box model, like: width: -moz-calc(42px + 1fx)?

    Thanks :-).

    June 10th, 2010 at 09:49

  16. Ilia

    I want this now :)
    This is very very cool.

    June 10th, 2010 at 10:42

  17. J. Weir


    #foo {
    width: 200px;

    .bar {
    width : 50px;

    .zoo {
    width: -moz-calc(#foo.width – .bar.width)

    June 10th, 2010 at 10:59

    1. Lachu

      Dot in CSS means class of object. Better use ->

      June 11th, 2010 at 09:23

    2. T Rasmussen

      I would like to see something like this in calc().

      Like this:
      #foo { width:-moz-calc(500px – padding); }
      .bar { padding:2em; }
      This has 500px-4em width

      July 19th, 2010 at 07:07

  18. BTreeHugger

    FINALLY. The one thing that MS’s CSS expressions were really useful for. But how are cases like division by zero handled?

    June 10th, 2010 at 11:30

  19. Brian

    What about references to other boxes? #itemId.width?

    June 10th, 2010 at 11:56

    1. Chris

      That’s the thing that would make this *really* useful, yes.

      June 10th, 2010 at 13:45

    2. Rasmus

      I second that. It would rock!

      June 10th, 2010 at 14:31

    3. voracity

      This would be heaven if it worked (and worked smoothly), but I’m guessing it’s quite complicated to implement.

      June 10th, 2010 at 21:51

  20. Ms2ger

    Ivan: IIRC, you could use width: -moz-max(5% – 2.5em, 21px * 2).

    June 10th, 2010 at 12:18

  21. Alishah Novin

    To those who were unaware, IE5-7 had expressions in CSS, in which you could supply JavaScript:

    table {

    It’s great to see that as Mozilla begins to implement mathematical expressions, the IE8 team has decided to deprecate dynamic properties…


    June 10th, 2010 at 12:42

    1. Lachu

      Yes, but expression are JS expresion. Putting a Java/Ecma Script expressions into CSS are very bad and an evil idea.

      Most users are disable JS expressions, but before this web developers decided to split look-behavior-content. JS expressions in CSS are very bad idea.

      June 11th, 2010 at 09:31

  22. Davidmoreen

    That is effing cool!

    June 10th, 2010 at 12:59

  23. Zach Bailey

    Please just implement SCSS. These sorts of machinations are next to useless for all but the simplest stylesheets without being able to define re-usable variables/constants.

    June 10th, 2010 at 13:21

  24. Herberth Amaral

    I got only one word for this: CARALHO! (HOLY SHIT, in Portuguese).

    June 10th, 2010 at 13:27

  25. Y-Love

    Thank you for this. It’s about damn time :)

    June 10th, 2010 at 13:59

  26. badanalogist

    @Ivan Enderlin, my thoughts are along similar lines, but “dystopian” ( :-D ) – is CSS the new client side Perl ? – so many ways of getting confused while trying to figure out what the other guy wrote so cryptically?

    June 10th, 2010 at 14:00

  27. mario

    Isn’t this what Netscapes’ JSSS was for?

    June 10th, 2010 at 14:21

  28. Anon

    This would be nice, especially considering that the text box I’m typing this comment in goes outside the tan colored box it’s supposed to be in. Granted, I have JavaScript turned off.

    June 10th, 2010 at 14:24

  29. Alex Penny

    I’ve been waiting for this for so long!

    June 10th, 2010 at 14:40

  30. Thierry Koblentz

    Being able to combine different units in the same computation is way cool.

    I have a question about this example though:

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

    I understand that the width is in there only for the sake of this example, but what about -moz-calc(100% – 2 * 3px) ?

    The way I understand how this works, I’d expect to see it written like this:
    -moz-calc(100% – 6px)

    6px being 4px for padding + 2px for border.

    Or am I missing something?

    June 10th, 2010 at 14:58

  31. Oscar Godson

    Doesn’t anyone else think it’s hilarious this is JUST NOW being talked about in Firefox when IE has had it forever? (same with shadows, gradients, opacity, etc). Sure IE didnt use the “spec”, but neither is Firefox or WebKit in any of these.

    Just ironic…

    But great idea, and will be very helpful

    June 10th, 2010 at 15:07

    1. Magne Andersson

      Mozilla used the calc() property specified in the CSS3 spec, so surely they went after the spec?

      June 11th, 2010 at 01:44

    2. Matias Larsson

      Unfortunately the shadows you were able to do with IE filters looked like crap and if I’m not mistaken the IE filter opacity went berserk on text anti aliasing?

      The “new” Firefox and Webkit css-features actually look good.

      June 11th, 2010 at 04:46

  32. […] post: Firefox 4: CSS3 calc() ✩ Mozilla Hacks – the Web developer blog 10 June 2010 | Uncategorized | Trackback | | Stumble it! | View Count : 0 Next Post […]

    June 10th, 2010 at 15:22

  33. Matthew W

    Something like but allowing arbitrary javascript (CSS expressions) has been in IE for a long time. It can cause some nasty rendering slowdowns and crashes.

    Here’s hoping the FF implementation is speedy and doesn’t allow people to shoot themselves (or the browser!) in the foot. Only allowing a limited set of arithmetic expressions is a good start, although I do wonder whether it might be possible to send the rendering engine into a tailspin using contradictory expressions, or expressions which require some kind of high-complexity constraint satisfaction approach to solve.

    June 10th, 2010 at 15:46

    1. indie

      The reason IE crashes and burns all the time is the exact reason you cite and attribute to CSS. Incorrectly. “Arbitrary JavaScript” and CSS have nothing in common. There is a reason IE sucks so much.

      CSS links control one thing only, and that is focus. JavaScript commandeers one thing only via it’s Evilness, and that is FOCUS.

      June 11th, 2010 at 02:24

  34. unscriptable

    Wow. This is a horrible idea. I mean, I kinda love it for the extemely few use cases where it’s needed, but OMG the potential for css noobs to create tightly-coupled maintenance nightmares just jumped to a whole new level.

    99% of the use cases where boobs will want to use this would be better solved by choosing the correct box flow and box sizing, rather than hard-coding a neighbor’s metrics, for instance.

    June 10th, 2010 at 16:49

    1. Magne Andersson

      Did you write boobs instead of noobs the second time, intentionally? ;p

      June 11th, 2010 at 04:00

  35. Sumanth Nelluru

    We’re finally seeing calcs in CSS, great to hear.

    June 10th, 2010 at 17:42

  36. Erik Kallevig


    June 10th, 2010 at 17:49

  37. Georg Saus

    min, and max operators

    In addition to -moz-min and -moz-max?

    June 10th, 2010 at 18:10

  38. hova

    It’s like I’m in a time-warp or something

    June 10th, 2010 at 19:17

  39. Rob

    Needs more jquery

    June 10th, 2010 at 20:01

  40. Daniel

    One thing: how is ‘mod’ defined? I looked at the linked spec, but couldn’t find any definition for what it does.

    It’s a pet peeve of mine when languages have a mod operator but fail to define what it actually means. This usually leads to some really, really obscure bugs.

    June 10th, 2010 at 20:16

    1. Josh

      ‘mod’ or % is a standard operator in programming. Its behavior is described at the following Wikipedia article:

      I have yet to find a programing language which had it perform in any other capacity.

      June 11th, 2010 at 09:00

      1. Daniel

        No, it’s *not* standard. That’s the problem. Did you even read the page you linked?

        ‘mod’ is based on ‘modulo’, a mathematical relation which states:

        (a divides b mod c) implies (n*b + c = a) for some Integer n

        The ‘mod’ used in programming gives you the value of c given a and b.

        First problem is that there are *infinitely many* functions which satisfy this condition. Thankfully, pretty much everyone has picked between two such possible functions. These are “truncated division” and “floored division”. Note that they give *different results for the same input*.

        The problem is that *both* of these are called ‘mod’ by different languages. Therefore, simply saying “mod” doesn’t actually tell you how “a mod b” is evaluated.

        Hell, C (prior to C99) and C++ don’t specify it *AT ALL*. From memory, you could get pretty much any result out of ‘%’ in those two provided it satisfies the above relationship and it’d be valid.

        So no, it’s *not* standard and it *should* be specified. If it isn’t, you’re just opening the door to “implementation defined” behaviour which is always a complete nightmare to deal with.

        June 14th, 2010 at 22:54

        1. Josh

          ‘mod’ is literally short for ‘modulo’ also known by the sign %. The page I linked actually states that while the internal representation may vary, the math AND the result is the same. Different languages may the sign from the numerator or denominator but the numerical result is exactly the same.

          June 15th, 2010 at 05:40

  41. Sam Watkins

    I find that CSS is overcomplicated, buggy, inconsistently implemented and inadequate for layout, so I continue to use tables for most layout. It’s simpler, and works better.

    June 10th, 2010 at 20:26

  42. Thierry Koblentz

    ok, I’ll answer my own question.
    The 3 pixels used in -moz-calc(100% – 2 * 3px) have to be the 2px padding + the 1px border.
    More complicated than it has to be, but I agree that it is perfect as an example.

    June 10th, 2010 at 21:50

  43. Klamsi

    On the one hand a very nice feature, but in many cases it only workarounds a broken CSS spec.

    – There is no way to specify what is meant by 100%
    – There is no inner-width and outer-width
    – …

    And the next trial seems not to be to fix these things, but to give a calculator to calc the right behaviour for your own.

    June 11th, 2010 at 00:18

  44. Russell Bishop

    This seems like an excellent development for CSS; I’ve wanted this functionality in lots of situations before, and have probably resorted to using some .js instead.

    Can’t wait to test this!

    June 11th, 2010 at 02:11

  45. Frédéric Delorme

    What an amazing feature ! How many time have I spent hours to solve this kind of CSS design issues ! Thanjks to CSS3 and Firefox4 (and the Moz Fund :)

    June 11th, 2010 at 02:41

  46. Marco Jardim

    Actually Klamsi, if you use box-sizing: border-box; or -moz-box-sizing: border-box; you don’t need to use calc at all, because with 100% is 100% width of the parent container, even if you apply paddings, borders and whatnot.

    June 11th, 2010 at 03:26

  47. Rob

    Didn’t Microsoft implement something like this, I don’t know in like 1998?

    June 11th, 2010 at 03:30

  48. Sam

    What’s up with always using -moz – is this CSS3? Same with Webkit… I assume they’ll call it -webkit-calc?!

    Why should I have to write my CSS 2x for 2 browsers? Why not just name it calc, things like this should be made global. Don’t get me wrong, I love this idea and I actually could of used it today if it existed in CSS2. Why not start using global names, make agreements together. This is the only thing that annoys me when it comes to CSS!

    June 11th, 2010 at 04:33

    1. 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”, per CSS WG.

      June 15th, 2010 at 01:32

      1. Linda

        This might be an RFE in itself, but can we have a way to ‘override’ the need for a “moz-” prefix? I.e. Can we have something like:
        -mozdefine(calc, moz-calc)…
        That way we can just write ‘calc’ in our code now — and if calc becomes a standard, we won’t have to change our code. If it doesn’t, no loss, as we would have either have to stick with moz-calc or have to change to from moz-calc to ‘calculate’ (or whatever keyword was accepted) — but this way, if calc wins and is compatible with moz-calc — we win — and our code just works.

        June 18th, 2010 at 01:07

  49. El_Hoy

    Will mozilla enable parent selectors?… (meaning to select the parent div of a child:
    div < em # select all 'divs' that contains an 'em'

    I wanted it and I have seen it in forums, are there plans to implement it?

    June 11th, 2010 at 05:12

  50. Allan

    Is it GREEK or WHAT?!??!!

    June 11th, 2010 at 06:33

  51. Vladimir Carrer

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

    June 11th, 2010 at 08:06

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

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

  54. HB

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

    June 11th, 2010 at 09:44

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

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

  57. […] 원본: […]

    June 14th, 2010 at 20:47

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

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

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

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

  62. tbx

    nice! this library also brings some nifty CSS ideas:

    June 20th, 2010 at 04:25

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

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

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

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

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

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

    August 12th, 2010 at 06:22

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

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

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

  72. Andy

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

    September 10th, 2010 at 21:37

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

    June 13th, 2011 at 15:36

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

    July 12th, 2011 at 10:16

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

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

    April 14th, 2012 at 04:02

Comments are closed for this article.