When Can You Use New HTML and CSS in Production?

Posted: 22 Aug 2013 05:30 AM PDT

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.

The post When Can You Use New HTML and CSS in Production? appeared first on Vanseo Design.