If you're waiting for all browsers to implement these CSS3 features correctly, you'll end up never using them.
For example, CSS animations have been around for at least 2 years. 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.
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.
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, suddenly, 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 while providing a decent experience for IE (the main culprit).
It's entirely down to the kind of projects you're working on.
Most of my work experience is with agencies, so I've had a good mix of clients with new and legacy clients. Some industries have a large number of legacy users, whereas with some clients it's strange to see any IE, let alone an older version like IE7-8. A client I worked on a year ago had around 20% of users on IE6-7, and these were users in the UK and not in China or Russia. The explanation given by the client (who spend a lot of money on web analytics) was that many of their users were business-based, and a lot of companies in the UK are restricted to IE6-7 and Windows XP due to internal web software.
I used to be of the opinion that developers should support older browsers, and should gracefully degrade when used on legacy browsers. I think this was probably because I thought that things would change after a few years. Four to five years later, and IE7 (and IE8) are still a problem, and since corporate users won't get off of XP for a few more years I think enough is enough. I am happy to support older browsers when there is a business case for supporting them (i.e. there is an existing user base stuck on these browsers), but if you're working on a new project then IE9 should always be the minimum, and degraded view.
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 ...
"Mobile first" designs help here because you typically do a much simpler layout for mobile and then have your CSS to fancy things up hidden inside of an @media query. Phones and old browsers get the simple verision, modern browsers on large screens get the advanced version. http://js-mini-shell.nfriedly.com/ is an example of this - IE 8 and down get the simpler layout and no CSS animations.
In my opinion you shouldn't punish 96% of your users because of those 4%.
As others have mentioned you could use something like modernizer to take advantage of progressive enhancement. That way the users with modern browsers could benefit from newer technologies and the legacy users could still view your site properly.
It's more work but I think it is worth the effort.
IE6, really? Why not Mosaic? Those who use IE6 these days can be ignored. Put a big red banner on the site pointing them to normal browsers if you detect IE6 anywhere.
Mostly they should have been used to web not working properly. Also it's obvious that they do not care or are unable to install better browser.
What percentage of those 4% who use IE6 actually buy something? Is it worth supporting them? Or you could create an awesome site to sell your stuff more easily.
Yes, I can't even imagine who would normally use it, unless it's some weird static environment with ancient Windows installed which can't be upgraded or something the like. And probably in such case people should have alternative computers for normal browsing.
I had to use IE6 for real about a month ago. It wasn't a test. It was the only way I could figure out to get a relative's personal data off an old, damaged PC they hadn't used for years. I managed to get gmail to work in IE6 and email the important files to myself. There was no way I could have updated the browser on that thing; it was a miracle I could even run the browser it already had. Gmail actually made me click a button stating something like "I can not upgrade this browser" before it would let me in, but it worked.
If you have a website that does something useful for its users (and not just making a big, splashy presentation of the wonders of you) I like the idea of having a very stripped down fallback version with nothing but functionality that can be used on browsers with no CSS or Javascript at all. Sometimes even those of us who build websites and spend our days in dev versions of Firefox and Chrome have to use an obsolete browser to get some work done.
Likely the 4% are relying on IE6 because of intranet tech that was written eons ago when IE6 was new. And to upgrade would break that system. You may want to send out some help and let them know the new IE has a compatibility mode and they can set it to 6 and still have a *better browser http://msdn.microsoft.com/en-us/library/ie/hh920756(v=vs.85)...
I feel your pain. At my current gig, we target an IE8 minimum, which still severely limits which of these techniques we can use. Microsoft should be tremendously embarrassed by how bad their browser has been for so long.
At our company we also support IE8. I almost never touch the CSS and HTML files for that. I just load some polyfills that make IE8 more compatible [1][2][3][4]. It seems like magic, because those scripts give me support even for Foundation 4 out of the box ( they dropped legacy IE8 in v.4 ) and I don't have to think that much for websites such as caniuse, etc...
The downside is that most of the CSS work is done by javascript and if you are one of those IE8 users you will be unsatisfied with the pageload speed, but given the bad architecture of IE8 you will not be surprised by that fact. Although the pages using those polyfills work pretty good.
targetting IE8 doesnt mean your site do have to look the same way on IE and modern browsers.
Your site or apps must be functional on IE , doesnt mean you cant give modern browsers users a premium experience.
Now if you work for a businesses that only allow IE broswers then good luck.
I suspect, and of course this is a only my guess, that most of the people locked into IE6 are in work environments that aren't conducive to social browsing or online shopping limiting that 4%'s value.
Unless you are targeting a fairly specific type of corporate user/customer you probably want to consider adding some of the new jazzy client side stuff if you think it can improve conversions.
In the article, it's mentioned that there isn't great support for flexbox, which is only half true.
Using a combination of the older and new syntax (display: box and display: flex), you can already do quite a bit.
I've been using autoprefixer (https://github.com/ai/autoprefixer) 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."
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?
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.
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.
It's the only thing that makes sense if we want to allow that type of design on the web.
It appears: http://adobe-webplatform.github.io/css-regions-polyfill/ works fine in eg. Firefox - but their example page degrades horribly with javascript disabled -- but that shouldn't be insurmountable -- the easiest might be to simply patch the layout with an onLoad or something (have the static site show something similar either without columns, or using css-columns or something...).
SO much. Mainly a) lack of support for control over element breaking (I haven't gone really in-depth with the spec, but even the most obvious things are supported terribly) b) the weird behaviour of margin collapsing (and adding extra margins - WTF?!)
Just use tables. I know that everyone recommends against it, but IMO they are the only solution which works as expected. Everyone says they have a fancy workaround, but none of them works well enough. And besides, whats wrong with tables? Semantic HTML is hip again :-)
Please, show, how do you make tables that work like CSS columns, i.e. reflow the content to fill the specified number of columns. Unless you hardcode content for each TD, but what the point then?
And that's exactly what's wrong with tables (semantic purity aside)—they shackle you content to one specific structure, meanwhile using CSS for layout you can move your blocks around more or less freely.
Exactly. Instead of just resorting to tables, I'd be much more likely to resort to a couple of DIVs which would involve less markup and be less semantically incorrect. But the whole point is that I don't want to have to decide, on an article-by-article basis, exactly where my break between two columns should actually be.
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.
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.
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.
The good news here is that IE11, Chrome, Firefox and Safari all support the newest Flexbox standard. It's pretty simple to bring in IE10 support with the older syntax.
Forget about the older box layout in Firefox that was built for XUL and earlier implantations in WebKit and gecko. Those have some horrible and surprising bugs and incompatibilities.
Ah, good catch. It's 5.1 that doesn't support it at all. I was working on a new feature last week, and it looked great on Firefox and Chrome (my main dev browsers), but both my boss and UX designer use Macbooks so when I asked them to check it out they both said it's broken. It was because I was working quickly and didn't put in all of the backward compatibility hacks yet. So, my memory was a bit fuzzy about which versions supported what, exactly.
"Flexie enables the 2009 Flexbox model. You're probably looking for the updated spec. There is currently no polyfill for the new spec."
There's a bunch of caveats and it was finicky when I played with it. The beauty of flexbox is that you can throw complex layouts at the browser and it would handle it natively, this seems more for simple pages and didn't work out for me back when I tried it. :(
I may have overstated IE7 support; sorry. I just tested my site using IE10's developer tools to simulate older versions (which isn't a perfect simulation, but I don't have VMs available atm). IE10 renders perfectly. IE8 and IE9 in their respective Browser Mode and Document Standard Mode, are usable but not rendered the way they're supposed to be. Somewhat graceful degradation for those two. IE7 is rendered completely incorrectly, but the main functionality is still usable. For IE7-9, my UI design has a switch for one main feature that can be turned off, which would fix most of the brokenness. It's a side-panel navigation and tools area that's collapsible. Making it fixed, and also getting rid of a fixed footer, simplifies the layout a lot for the older browsers.
I had looked at Flexie too. I think, because I'm making sure to include the 2009 syntax along with the current syntax everyplace I can, Flexie would allow IE7-9 to work better for me. Not perfectly, but better. That might've been my other option, besides turning the more advanced layout stuff off. But I just reviewed my code and I don't have Flexie anywhere, so I'm not currently using it. (This codebase is used to generate webapps for clients, so adding Flexie could be something that's done case-by-case if a client requires IE7-9 support.)
BTW, here's an example. To make an element a Flexbox container, instead of using this:
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 upgrade 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!
Is it just me, or is every insightful I come across where I nod vigorously whilst reading it turns out to be by either Mathias Bynens (seriously, that guy is everywhere!) or porneL?
> you can usually solve this problem by applying padding to a element that has box-sizing: border-box set.
And what if your element is already using padding/a border for something else and you don't want to have to fill your DOM tree with loads of pointless levels of wrapper elements?
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.
i run Ubuntu as well (13.10, Dual Core 1.1GHz - though i set the clock to 800MHz, Intel HD) and nothing unusual happened when the animations were being displayed - if a shitty Intel chip can run the animations - i can't help and wonder you tweaked something you weren't suppose to?
What was your CPU time? I run GKrellM so I notice when something starts hogging the CPU, the animation did play just fine, should it take 90% CPU time to run an animation on modern hardware? That was the point of my post. That CPU usage costs me money.
i've installed GKrellM and i got around 23% of cpu load when the animations were displayed
- clock set to 800MHz [set via indicator-cpufreq]
- mind you during the "test" lost of things were running to
if the CSS3 animations got up to 90% on YOUR hardware - where does that leave the rest of us [i.e. shitty intel HD card owners]? :)
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.
If you're waiting for all browsers to implement these CSS3 features correctly, you'll end up never using them.
For example, CSS animations have been around for at least 2 years. 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.
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.
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, suddenly, 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 while providing a decent experience for IE (the main culprit).