The last week or two, I’ve been looking at some not quite ready for production css in the css shapes module and the css exclusions module. While neither is ready just yet, you might want to use them as soon as possible. Other things like flexbox are much closer to being ready. It begs the question how do we know when it’s ok to adopt new html or css techniques?
Note: This post includes an audio version. If you don’t see the audio above, Click here to listen.
I don’t think there’s ever a clear line where on one side you can’t use the new and on the other you can. The decision is more nuanced and I think worth a look at some of what you should think about when deciding.
Specs
Some will tell you that you can’t use new html or css until the spec is finalized. I remember when html5 was first making the rounds some forum posters would point out the 2022 finalization date as though adding a single html5 tag before that date suggested you didn’t know what you were doing.
Specs for css and html usually have far future dates for recommendation. It doesn’t mean you can’t use anything in the spec until that date. Browsers don’t implement everything in a spec all at once. They implement parts of the spec over time. CSS 2.1 was finalized in 2011, but I know I’ve been safely using many aspects of it since about 2003.
Some parts of that 2.1 spec you couldn’t use right away and some you could. It’s the same with css 3 today and will be the same with css 4 tomorrow. The spec doesn’t really tell you when it’s ok to use something.
If we can’t use the spec as arbiter where do we turn?
Browsers
The truth is we can start using html and css the moment browsers support them. That might mean using vendor prefixes and it might mean slight variation from browser to browser, but if a browser supports something and we use that something, it’ll work in that browser. It doesn’t mean we should use it, but we certainly can as long as we understand the potential downside.
For example IE10+ currently supports css grids. It’s something I suspect a lot of designers will use in the future. Unfortunately no other browser currently supports css grids so unless your entire audience is using IE10+ you want to avoid it in production.
Better is to wait until there’s enough support across browsers to justify whatever new technology you want to use. The good news is browsers are quicker at updating and adopting plenty of new things. Not all, but many.
Of course, an update in the latest version of a browser doesn’t do much to change how an older version works. Until the day all browsers follow Chrome’s model with automatic upgrades in the background and until everyone is using those browsers, we’ll need to consider older versions when deciding if we should adopt something new.
Browser adoption creates a range of dates for when we can use something. As soon as one browser supports something in a spec, we can start playing around and experimenting with it. Once enough older versions that can’t support it fall out of use we can feel safe in using the technology everywhere.
We don’t need to wait until every last person can see the new and shiny before using it in production, though. People still visit this site using IE 5.0 which is 14 years old and counting. I have no plans to specifically consider it in any design here or elsewhere.
When enough browsers and versions support something we can start realistically thinking about using it. Enough isn’t all though, so it means we need to figure out how to make the new code work in older versions of some browsers and let’s face it that usually, though not always, means older versions of IE?
Polyfills
One option is the use of polyfills. They programmatically add the ability to use some html or css in a browser that doesn’t have support yet. While a browser may not have implemented support for some html or css, you can write code that does the same thing. You use the html and css as though the browser supports it and the polyfill does the rest.
Remy Sharp offered a good definition a few years ago
A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively.
Polyfills are meant to be temporary solutions in the sense that only the browsers that need them ever see them. As more and more browsers support new css and html the polyfill is removed for those browsers.
It’s not the best idea to add polyfills for everything, but if there’s something you want to use that isn’t supported everywhere, a polyfill may exist. Sometimes the polyfill you want doesn’t exist. It still doesn’t mean you can’t use something new.
Will it Break Your Site?
Even if there’s no way to get something to work in an older browser you might be able to safely use it. You want to ask yourself a couple of questions.
- Will it break your site in some browsers?
- If so, are you willing to build an alternate solution for those browsers?
Are you using the new to enhance a part of the design, perhaps a transition when hovering over a link? That probably isn’t crucial to your design. If some browsers don’t support the transition, so what? They’ll get a quick change instead of one transitioned over time.
We should be delivering a minimum experience that works everywhere and once we are we can enhance for more capable devices. As long as those enhancements don’t break the minimal experience, we’re good to go.
On the other hand if it’s something fundamental to the layout of your design and the whole thing falls apart without that bit of technology, you might want to rethink using it.
If you decide you still want to use the new you have to decide if you’re willing to develop an alternative for those browsers that can’t support it. For example if you wanted to build a site using css grids, you could, as long as you don’t mind developing an alternative layout for everything outside of IE10+ Probably not something worth doing now, but certainly something you could do.
Summary
Somewhere in between the first browser supporting some new html or css and every browser in use supporting it, is the point where we can start using it in production. That point isn’t absolutely rooted in the ground and your decision to use the new or not will come down to you and the specifics of your project.
Ask yourself
- What browsers and versions do you need to support?
- What browsers and versions do and don’t support the new technology?
- Do solutions like polyfills exist for those that don’t have support?
- Does the new technology break the minimum experience in some browsers?
- If so, are you willing to develop an alternate solution for those browsers?
As long as you’re developing a minimum experience that works for everyone, it’s ok to enhance that experience for some and not all. If the new technology is layout critical and you’re willing to provide an alternate solution for non-supporting browsers it’s also ok.
Otherwise it’s probably best to wait a little longer.
Download a free sample from my book, Design Fundamentals.
This was always one big question I had when I first started out to learn about HTML and CSS and it persists on till this day.
One of the things I always wanted to try out was to play with flexbox. I didn’t do so because there were still browsers who didn’t support it. I even went far enough not to use rems because IE9 don’t do rems.
Nowadays I find that I’m relaxing on my own criteria and trying things out as they go.
Often, I’ll try out these new tricks on side projects that doesn’t have any implications for actual work.
Sorry I didn’t reply sooner Zell.
I felt the same way. For a long time I wanted to wait till any browser that couldn’t use something fell out of use. I also wasn’t crazy about using polyfills for everything.
Lately I’ve been trying to think deeper about it. I still don’t want to use polyfills for every little technique, but I’ve been trying to think about what the potential downside of using something really is.
I think flexbox is very close. An update to the polyfill and I’d jump in and start using it. It solves a couple of major problems that I can’t wait to use it in production.
Yup I have to agree that flexbox is extremely close and I’ll like to jump into playing with it. Maybe I’ll use it for my next personal design just to test it out and have some fun with it.
I guess my main problem against using things that were seemingly “not supported” was largely due to fear previously. What if it broke? What if I don’t know how to do this?
Luckily, I’ve pretty much gotten over this problem since then, and I’m looking forward to learning new stuff when it comes to technology. (Especially when it doesn’t concern and real clients)
Right now the browsers not supporting flexbox are Opera Mini and IE9 and below. If you don’t need to support those browsers you can use flexbox now.
This discussion is making me wonder how those browsers would render a page developed with flexbox. Depending on how they do, you might be able to develop a layout that still works fine. I may have to test that and see what happens.
I understand the fear of breaking the site. The thing is if you understand how non-supporiing browsers will deal with code they don’t support you may not break the site. There have been lots of hacks over the years that would target one browser and be ignored by other browsers and developers used them for a long time.
Have you experimented with flexbox at all? If you do, you’ll probably want to use it even more.
To be honest, I haven’t experimented with Flexbox at all. It seemed to be too complicating for me and I avoided it knowing that IE9 didn’t support it.
I’m pretty sure there are polyfills to handle IE9 though, and I’d love to get my hands on it on the next thing I code (for myself)
It really isn’t that hard to work with. You’ve probably already seen my post on the latest flexbox spec. I created a demo, that I think might only work in Chrome, but it did work there. Grab the code and start modifying it.