Of course, the humor here lies in the fact that IE has had dynamic CSS calculations since IE 5, but is now in the process of removing them – just as they are being standardized in other browsers.
For example [1]:
<div style="left:expression(document.body.clientWidth/2-oDiv.offsetWidth/2);">Content</div>
These expressions (or "dynamic properties") essentially evaluated JScript embedded inside a stylesheet and provided some handy hacks to get around otherwise-painful bugs. This included simple math calculations as described in the Mozilla post, but also more complex transformations such as varying the style of an element based on the current day (or other JS-retrievable information).
Funny to see Mozilla phasing this in just as Microsoft phases something similar out [2].
The problem with Microsoft's implementation is that it allowed any Javascript to be executed -- so CSS became a vector for XSS attacks (one of the early MySpace worms was based on this feature). This implementation only allows very basic math, and is so is inherently a lot safer.
Completely agree - Mozilla's scaled-back implementation, which appears to be closer in line with the standards track - is much safer and marks a better approach anyway (several at MS have been openly recommending against using dynamic attributes for some time now).
It's moves like this among vendors that force us to think about that line between "experimentation and innovation" vs. implementing "proprietary features."
As NathanKP mentioned below, we'd all do well to push vendors to come back together toward standard implementations across all popular browsers. Here's hoping.
While calc() is nice, I rather have vars or defs so I can declare a color once and use it everywhere so if I decide to change the color I just change it in one place at the top.
Fortunately, you can use a pre-processor like SASS for that -- however, calc() allows you to do calculations at runtime which cannot be done in a pre-processor.
or use any of the various scripting languages (php, python, perl etc) to serve the css. Problem solved. Just do this behind a cgi or similar for development, and then just run it and save the output as a static file for production.
It's not like variables in a plain text string are a hard thing, for goodness sake.
I'm pretty sure anyone here will realise this - it's just that it would be better if it were implemented in the spec, I'm amazed that colour definitions aren't in CSS3.
The calc() function is part of the CSS3 /Values & Units/ module[1] which is currently in Last Call status[2]. Here[3] are the status definitions that apply to CSS3. It doesn't make sense to remove the moz prefix until the standard is (probably) done changing.
In addition, mozilla's implementation of it is still in flux (since it's not done) and using the non-extension terminology for an in-development feature is a great way to convince people to use it and then screw them over when you change it.
Also, I found out about all this because you asked. So thanks for causing me to learn something new today :)
I believe they do this for CSS3 features where the spec is still in flux (Note that CSS3 is still in development, at least if Wikipedia is to be believed.)
The specific reason is that using an anonymous name for a specific implementation means that pages written only to that implementation will instantly break when it's standardized differently - hence explicitly identifying your browser's version of an unfinished standard is a form of goodwill.
It is also nice when different browsers interpret the spec differently. If both Chrome and Firefox had a feature named the same, but requiring different number of arguments, it would be a problem... Eventually it will get sorted out (hopefully).
It's better to use a different attribute than other browsers until it becomes a standard. That way, you don't get unexpected behavior (READ: IE6 box model bugs that annoyed so many people) when it is finally standardized.
Most of CSS3 has a ways to go until it becomes a standard, so Mozilla uses its own attribute to reflect its unique implementation/interpretation of what is there currently.
I'm glad the mod operator is included, to make it easy to divide a page into n equally-sized blocks depending on some other parameter. I wonder if calc() will integrate with counters or otherwise allow the use of variables, or if that will remain the domain of JavaScript (I like having my pages work 100% without JavaScript if it's possible, to avoid NoScript issues). I guess I'll have to read the spec.
For example [1]: <div style="left:expression(document.body.clientWidth/2-oDiv.offsetWidth/2);">Content</div>
These expressions (or "dynamic properties") essentially evaluated JScript embedded inside a stylesheet and provided some handy hacks to get around otherwise-painful bugs. This included simple math calculations as described in the Mozilla post, but also more complex transformations such as varying the style of an element based on the current day (or other JS-retrievable information).
Funny to see Mozilla phasing this in just as Microsoft phases something similar out [2].
[1] http://blogs.msdn.com/b/ie/archive/2008/10/16/ending-express...
[2] http://msdn.microsoft.com/en-us/library/ms537634(VS.85).aspx...