Thursday, June 10th, 2010
CSS calc() in the house
<p>
Finally. Don't make me jump to JavaScript to tweak the CSS when I want a relative calculation for a value.
The effervescent Paul Rouget shows us the CSS calc() goodness that has a bug going for Mozilla.
Some good simple use cases:
CSS:
-
-
/*
-
* Two divs aligned, split up by a 1em margin
-
*/
-
#a {
-
width:75%;
-
margin-right: 1em;
-
}
-
#b {
-
width: -moz-calc(25% - 1em);
-
}
-
-
/*
-
* Make sure input field won't overlap parent
-
*/
-
input {
-
padding:2px;
-
border:1px solid black;
-
display:block;
-
width: -moz-calc(100% - 2 * 3px);
-
}
-
-
/*
-
* combine different units!
-
*/
-
-
width: -moz-calc(3px + 50%/3 - 3em + 1rem);
-
A lot of JavaScript is about to get nuked. It would be cool to have a pre-processor that generates JS code for browsers that won't support the syntax so we can use this not in 5 years.
Related Content:
4.5 rating from 2 votes
WHOOHOO! :-)
Isn’t this a performance nightmare, which is the main reason IE dropped expressions? I think all of these types of calculations could be better achieved with a combination of box-model choice and better document structure.
@eyelidlessness I don’t see why it would be, at least not anymore. There’s already so much of this math going on behind the scenes that doesn’t put much of a strain on modern browsers.
(Smug side note: pretty much everything is a performance nightmare in IE.)
This rules.
It would however be largely unneccessary if we could say something like:
div.one
{
right: div.two; /*the right side of div.one is at div.two’s left side */
}
Standardize this. NOW. Seriously, I’m serious.
Would be more useful ig you could do something like :
100% – #divID.paddingLeft
Looking forward to wide acceptance of this addition. Calculations is one of those “doesn’t look shiny enough to get general attention but seriously kicks ass” features I can’t wait to start using.
I always thought this concept was good in IE (expressions). The problem was implementation. Hopefully Firefox is getting the implementation right so that it doesn’t drag performance the way expressions did for IE.
“box-sizing: border-box” in CSS3 will make this less useful, since padding and margin will be included in the width when that style is applied.
@eyelidlessness: Yup – and in box model choice and this will be excellent. I can certainly see your point about performance thought – there are going to need to be a lot of reflows and calculations for simple DOM manipulation, never mind resizing the window. Hopefully modern browsers will be more up to the task.
Although, now we’ve got css3 box-sizing option which solve a lot of those problems anyway. http://www.css3.info/preview/box-sizing/
I don’t see why
width:75%(which is already used all the time) would be significantly more computationally expensive thanwidth:calc(100% - 2em). Not to mention setting width by only specifying theleftandrightproperties.As long as they limit it to (percentage +- fixed value) it’ll work fine, it’s basically the same thing as box model changes. The big problem of IE’s expressions were that they allowed any javascript, which basically turned them into an arbitrary constraint solving system, whose solution was sometimes impossible (= javascript error), or very expensive to calculate.
For the input example it seems to make much more sense to use the box-sizing property.
Seems like a good idea though, as long as it doesn’t have the same performance issues as IE expressions.
css scaffold and similar framework solutions have already solved this (calculating) problem.. along with many others… (nesting being one of them)…
huh, I see now the author discontinued the project.. I wonder why
Use Less (http://lesscss.org/) or Sass (http://sass-lang.com/) , they have simple arithmetic calculation and some usefull function avaible for use in CSS. Good work, i wanted to create exactly similar langiuage like Less with nesting, inheritance and macros, but LESS just solved problem and is good one.
Oh, i see that Less can still not solve everything, becuase of relative width, in Less it is nonsensical to mix different units of measures, like 80% – 3em + 12px. So i think this calc() is quite interesting thing.