Firefox 4: CSS3 calc()

on June 10, 2010 by Paul Rouget

112 comments

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

Post a comment

Gary van der Merwe wrote on June 10th, 2010 at 5:39 am:

OMG – That will rock!!!!

Reply
iGEL wrote on June 10th, 2010 at 5:48 am:

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

Reply
1. Dan wrote on June 10th, 2010 at 1:07 pm:
  
  The -moz prefix is in place for CSS spec that is still in development.
  
  Reply
2. djmichaelb wrote on June 10th, 2010 at 3:32 pm:
  
  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?
  
  Reply
3. David wrote on June 10th, 2010 at 8:22 pm:
  
  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.
  
  Reply
Chemikk wrote on June 10th, 2010 at 5:49 am:

That is a great news!

Reply
Nicholas Wilson wrote on June 10th, 2010 at 5:50 am:

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.

Reply
Florent V. wrote on June 10th, 2010 at 6:14 am:

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

Reply
Florent V. wrote on June 10th, 2010 at 6:17 am:

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

Reply
Wladimir Palant wrote on June 10th, 2010 at 6:38 am:

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.

Reply
Marcio B D A wrote on June 10th, 2010 at 6:47 am:

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

Reply
John Griffiths wrote on June 10th, 2010 at 7:47 am:

just too cool for school!

very nice

Reply
Eli Grey wrote on June 10th, 2010 at 8:38 am:

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.

Reply
Pingback from Ajaxian » CSS calc() in the house on June 10th, 2010 at 8:51 am:

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

Reply
Lachu wrote on June 10th, 2010 at 9:07 am:

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

Thanks Mozilla!

Reply
Lachu wrote on June 10th, 2010 at 9:08 am:

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

Reply
Pieterv wrote on June 10th, 2010 at 9:14 am:

DO WANT!!!

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

Reply
Ivan Enderlin wrote on June 10th, 2010 at 9:49 am:

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

Reply
Ilia wrote on June 10th, 2010 at 10:42 am:

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

Reply
J. Weir wrote on June 10th, 2010 at 10:59 am:

Maybe?

#foo {
width: 200px;
}

.bar {
width : 50px;
}

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

Reply
1. Lachu wrote on June 11th, 2010 at 9:23 am:
  
  Dot in CSS means class of object. Better use ->
  
  Reply
2. T Rasmussen wrote on July 19th, 2010 at 7:07 am:
  
  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
  
  Reply
BTreeHugger wrote on June 10th, 2010 at 11:30 am:

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

Reply
Brian wrote on June 10th, 2010 at 11:56 am:

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

Reply
1. Chris wrote on June 10th, 2010 at 1:45 pm:
  
  That’s the thing that would make this *really* useful, yes.
  
  Reply
2. Rasmus wrote on June 10th, 2010 at 2:31 pm:
  
  I second that. It would rock!
  
  Reply
3. voracity wrote on June 10th, 2010 at 9:51 pm:
  
  This would be heaven if it worked (and worked smoothly), but I’m guessing it’s quite complicated to implement.
  
  Reply
Ms2ger wrote on June 10th, 2010 at 12:18 pm:

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

Reply
Alishah Novin wrote on June 10th, 2010 at 12:42 pm:

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

table {
position:absolute;
top:0px;
left:expression(document.body.clientWidth/2-oDiv.offsetWidth/2);
}

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

(http://msdn.microsoft.com/en-us/library/ms537634(v=VS.85).aspx)

Reply
1. Lachu wrote on June 11th, 2010 at 9:31 am:
  
  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.
  
  Reply
Davidmoreen wrote on June 10th, 2010 at 12:59 pm:

That is effing cool!

Reply
Zach Bailey wrote on June 10th, 2010 at 1:21 pm:

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.

Reply
Herberth Amaral wrote on June 10th, 2010 at 1:27 pm:

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

Reply
Y-Love wrote on June 10th, 2010 at 1:59 pm:

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

Reply
badanalogist wrote on June 10th, 2010 at 2:00 pm:

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

Reply
mario wrote on June 10th, 2010 at 2:21 pm:

Isn’t this what Netscapes’ JSSS was for?

Reply
Anon wrote on June 10th, 2010 at 2:24 pm:

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.

Reply
Alex Penny wrote on June 10th, 2010 at 2:40 pm:

I’ve been waiting for this for so long!

Reply
Thierry Koblentz wrote on June 10th, 2010 at 2:58 pm:

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

I have a question about this example though:

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

Reply
Oscar Godson wrote on June 10th, 2010 at 3:07 pm:

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

Reply
1. Magne Andersson wrote on June 11th, 2010 at 1:44 am:
  
  Mozilla used the calc() property specified in the CSS3 spec, so surely they went after the spec?
  
  Reply
2. Matias Larsson wrote on June 11th, 2010 at 4:46 am:
  
  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.
  
  Reply
Pingback from Firefox 4: CSS3 calc() ✩ Mozilla Hacks – the Web developer blog : Popular Links : eConsultant on June 10th, 2010 at 3:22 pm:

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

Reply
Matthew W wrote on June 10th, 2010 at 3:46 pm:

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.

Reply
1. indie wrote on June 11th, 2010 at 2:24 am:
  
  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.
  
  Reply
unscriptable wrote on June 10th, 2010 at 4:49 pm:

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.

Reply
1. Magne Andersson wrote on June 11th, 2010 at 4:00 am:
  
  Did you write boobs instead of noobs the second time, intentionally? ;p
  
  Reply
Sumanth Nelluru wrote on June 10th, 2010 at 5:42 pm:

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

Reply
Erik Kallevig wrote on June 10th, 2010 at 5:49 pm:

osm!

Reply
Georg Saus wrote on June 10th, 2010 at 6:10 pm:

min, and max operators

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

Reply
hova wrote on June 10th, 2010 at 7:17 pm:

http://msdn.microsoft.com/en-us/library/ms537634(VS.85).aspx

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

Reply
Rob wrote on June 10th, 2010 at 8:01 pm:

Needs more jquery

Reply
Daniel wrote on June 10th, 2010 at 8:16 pm:

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.

Reply
1. Josh wrote on June 11th, 2010 at 9:00 am:
  
  ‘mod’ or % is a standard operator in programming. Its behavior is described at the following Wikipedia article:
  
  http://en.wikipedia.org/wiki/Modulo_operator
  
  I have yet to find a programing language which had it perform in any other capacity.
  
  Reply
  1. Daniel wrote on June 14th, 2010 at 10:54 pm:
    
    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.
    
    Reply
    1. Josh wrote on June 15th, 2010 at 5:40 am:
      
      ‘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.
      
      Reply
Sam Watkins wrote on June 10th, 2010 at 8:26 pm:

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.

Reply
Thierry Koblentz wrote on June 10th, 2010 at 9:50 pm:

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.

Reply
Klamsi wrote on June 11th, 2010 at 12:18 am:

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.

Reply
Russell Bishop wrote on June 11th, 2010 at 2:11 am:

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!

Reply
Frédéric Delorme wrote on June 11th, 2010 at 2:41 am:

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

Reply
Marco Jardim wrote on June 11th, 2010 at 3:26 am:

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.

Reply
Rob wrote on June 11th, 2010 at 3:30 am:

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

Reply
Sam wrote on June 11th, 2010 at 4:33 am:

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!

Reply
1. Magne Andersson wrote on June 15th, 2010 at 1:32 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”, per CSS WG.
  
  Reply
  1. Linda wrote on June 18th, 2010 at 1:07 am:
    
    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.
    
    Reply
El_Hoy wrote on June 11th, 2010 at 5:12 am:

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?

Reply
Allan wrote on June 11th, 2010 at 6:33 am:

Is it GREEK or WHAT?!??!!

Reply