CSS3 Features That You Can Finally Start Using
tutorialzine.com
tutorialzine.com
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).
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.
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.
[1] https://code.google.com/p/html5shiv/ [2] http://selectivizr.com/ [3] https://github.com/scottjehl/Respond [4] https://code.google.com/p/css3-mediaqueries-js/
Now if you work for a businesses that only allow IE broswers then good luck.
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.
Don't bother getting animations to work in IE6, but make sure your site runs okay without them. The latter is doable.
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.
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.
Many of the large insurance companies still hit my corporate site with IE6.
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.
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?
> And not only are height and width affected by
> padding+borders, they are affected in different ways,
> respectively
https://bugzilla.mozilla.org/show_bug.cgi?id=435426
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.
http://dev.w3.org/csswg/css-regions/
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...).
edit: formatting
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.
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.
Modernizr's no-flexbox detection, plus javascript polyfills where needed, work very well. The polyfill is an amazingly useful invention.
Its a whole layout algorithm, I'd love to use this! Last I heard a flexbox polyfill was barely a concept. Please, my good man, link to the repo!
Edit: I hoped the parent meant something new but I think he means https://github.com/doctyper/flexie
"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. :(
Bah, humbug.
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:
#elem
{
display: flex;
flex-flow: row nowrap;
}
#elem
{
display: -ms-flexbox;
-ms-box-orient: horizontal;
display: -webkit-box;
display: -moz-box;
display: -ms-flexbox;
display: -webkit-flex;
display: flex;
-webkit-flex-flow: row nowrap;
-moz-flex-flow: row nowrap;
-ms-flex-flow: row nowrap;
flex-flow: row nowrap;
}
.no-flexbox #elem
{
display: -webkit-box;
display: -moz-box;
-webkit-box-orient: horizontal;
-moz-box-orient: horizontal;
}
Works fine on Safari 6.x, you just need to add the prefix -webkit.
In most other cases all authors really want is `box-sizing: border-box` (which works in IE8+).
calc() will obviously have some niche uses though, and given the creativity of the industry I'm sure some neat tricks will rise out of it.
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?
https://daneden.me/animate/ (Animate.css)
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]? :)
I'd kill for the ability to do variables in CSS like LESS and SCSS.