"Finally Start Using"??<p>If you're waiting for all browsers to implement these CSS3 features correctly, you'll end up never using them.<p>For example, CSS animations have been around for at least <i>2 years</i>. Only Firefox and Webkit browsers supported them and you had to rely on vendor-prefixed properties, but animations were exciting enough for me to start experimenting with them as soon as I could.<p>There is permanent rant towards "fancy" CSS3 features that haven't reached a "W3C standard" status yet. But a website experience doesn't need to be visually consistent across browsers. If you're using a plain hexadecimal color code as a replacement for rgba, it's ok. If your intro is animated in Chrome but not IE, it's ok too. If your last paragraph has a margin that the pseudo-element :last-child should have canceled, it's ok as well.<p>Front-End developers have waited more than a decade for CSS improvements. You can't wait for a unified browser environment to start implementing them. I'm surprised by this article's tone, as if today, <i>suddenly</i>, everything changed. No way: browser support is a permanent process. Don't wait for that perfect day because it will never come. Just start having fun with CSS3 <i>while</i> providing a decent experience for IE (the main culprit).
Roughly 4% of our users still use MSIE 6 (some report that they need to due to their restricted work environment). I need a good reason to risk 4% of our revenue for some eyecandy, or a good fallback mechanism (difficult if my layout relies on calc(), for example). HTML/CSS is a sad story ...
In the article, it's mentioned that there isn't great support for flexbox, which is only half true.<p>Using a combination of the older and new syntax (display: box and display: flex), you can already do quite a bit.<p>I've been using autoprefixer (<a href="https://github.com/ai/autoprefixer" rel="nofollow">https://github.com/ai/autoprefixer</a>) for a few months now, building simple flexboxes all over the place with the attributes from the new spec, and have only run into one or two little issues that I can generally hack away.
From the article: "The standardization bodies have probably had their reasons, but it doesn’t feel at all intuitive to have the CSS width and height of an element affected by its padding and borders."<p>And not only are height and width affected by padding+borders, they are affected in different ways, respectively. It's just weird. Does anybody have any insight into what the standardization bodies' reasons were?
I'm still waiting on decent attr() support.<p><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=435426" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=435426</a><p>In an ideal world, instead of attr() and calc(). I'd like a simple pure functional language to calculate values for CSS properties. Properties defined by such a system could be efficiently cached and recalculated as required. Easy Parallel evaluation would be a bonus too.<p>I'd like to be able to do things like define a path as a mathematical function and then have an <UL> that evenly spaces <LI> items along that path. Preferably without requiring the browser to be specifically aware of the concept of a path.
There's a brief mention in passing, but the lack of good support for CSS columns is really frustrating. I have a requirement on a project that I'm working on for columns, but they just cannot be satisfactorily implemented in CSS alone, in any browser. Apart to resort to JavaScript instead.
A bunch of those demos don't work on the Android browser. I also happen to know that calc() doesn't work on Safari 6.x, among others.<p>I've been updating my webapp software to use flexbox-based layouts, and I have to use a fair number of calc() styles to get the layout I want. (The newer css grid layouts would probably work better, but for now flexbox is the best available.) I've found that a combination of old and new flexbox syntax, Modenizr's flexbox detection, and javascript code that detects whether or not calc is available and runs a method to simulate all of my calc() styles when it isn't, is all necessary to give me good browser compatibility. IE7 and IE8 work surprisingly well, Safari 5 on Windows and 5+ on Mac work, Mobile Safari 5 on the original iPad 1 works, and Mobile Safari 6+ on newer iPads and iPhones work. Firefox, Chrome, and IE9+ work great as well, of course.<p>It's a lot of additional effort, but it's worth it and definitely doable if you need the browser support and you want to use modern techniques.
Modernizr is a great way to be able to start using some of these features with legacy browsers. I actually have to battle with some of my customers to <i>upgrade</i> to IE8 (and not to set the group policy that forces "compatibility mode").
Calc() is a huge deal. For non-business oriented applications where IE8 may still be in use, calc() is going to be a god damn lifesaver. I replicate the function in javascript all the time, no longer!
There are soo many pointless uses of calc()… in this example `margin: 0 20px` gives identical result.<p>In most other cases all authors really want is `box-sizing: border-box` (which works in IE8+).
I run Ubuntu on my PC, it's an i7 8 core machine with nVidia GTX 660 and the latest tested Restricted driver from the repository. That animation drove my CPU aggregate by top to 90% usage. I clicked the Edit button and while the code was showing the CPU activity dropped back to minimal.
Calc is the most interesting item here in my opinion and the browser support.
<a href="http://caniuse.com/calc" rel="nofollow">http://caniuse.com/calc</a><p>I'd kill for the ability to do variables in CSS like LESS and SCSS.
Pet peeve: Default z-index makes elements farther down in the code display on top of elements higher up in the code. With multiple backgrounds, the first listed has the highest z-index.