Browser Support for evergreen websites

I first used CSS when building a website involved taking a static image, chopping it up and reassembling it in order that it would hopefully cope with the fact that there might be more or less text than the designer expected. “Pixel perfect” meant “this website looks like this graphic”. Designers reacted in horror that users might increase their text size. Browser compatibility ranged from “Best Viewed in Internet Explorer” badges to the development of two separate sites, one for each browser in order to ensure the same design was shown to each.

As we came out the other side of the browser wars, trying to develop one site for all browsers, we realised that we needed to offer old browsers such as Netscape 4 an alternative. We used the fact that Netscape 4 didn’t understand imported stylesheets to offer it simpler styles. We countered the pushback from our clients and peers by explaining that it was ok if websites didn’t look the same in each browser, the important thing was that the content and the functionality was there and usable.

When responsive design came along I hoped this might end the “must look the same” argument for ever. How can anyone demand that the site “looks the same” on a phone screen, an old PC, a high-end Mac with a Retina screen … a watch? Yet it seems, here in 2017, we are having the same argument. An argument that is being given weight by polls such as this one, where the three options boil down to:

  1. I believe that users still choose to “update their browser” and those that do not are holding back the web.
  2. I don’t use rounded corners either.
  3. I have outsourced my CSS knowledge to Bootstrap.

There was a time when option 1 was relatively true, users had the choice as to whether to update their browser and many didn’t. There are still certain users who cannot update – often those in corporations who are using versions of Windows too old to have a newer version of IE. There are also going to be users out there who are using very old machines and software.

Today however, the majority of our browsers are evergreen, they update frequently without asking the user and new features – often quite major ones – silently appear. If I built a site today that uses shape-outside to curve text around an image, Firefox users are going to see squared off text around that floated image. Chrome users will get the curved shape. As Firefox are currently implementing Shapes, at some point in the near future Firefox users will find their browser has updated underneath them, my website will suddenly look that little bit more finessed to them, yet I won’t have shipped any code.

Reframing Browser Support

I’m mid relaunch of my product Perch – we have to get our UI to work back to IE9. Until we launched Perch I spent my career building client websites. I know all too well the constraints of shipping client work to people who just want things to look the same. However our jobs are often to educate the people we work with and for. Reframing browser support for evergreen browsers is possible, just as many of us used the Yahoo! Graded Browser Support charts to reframe the conversation in the past.

Some would advise just doing what you believe is best and avoiding the conversation. The problem with that approach is that if it leaves the site looking very different in one browser to another, you may be left explaining yourself, or having to do unpaid work to “correct” the matter if the client is unhappy. I always felt it far better to be open about things that might cause a visible difference and “just do” those things that were best practice but they wouldn’t know about one way or the other.

Your boss or client may be unaware of the way that browsers update. They may have been told by someone who knows about computers that it is important their site is compatible with all browsers. They have equated compatible with “looks the same”. You can challenge that. Look at your analytics data, look at browser release schedules and see what is going to land in the next releases. Check out the Can I Use stats for your location, and present the information to your boss or client.

Explain the benefits of using something new – whether that be performance, the ability to achieve a layout you couldn’t otherwise, or time-saving now and in the future. Explain how the ‘fallback’ is acceptable and that over time more users will grow into the newer design without you needing to ship any more code. This is the reality of design in a world of evergreen browsers. Grid is a very unusual case in that we are going to see support land in two, perhaps three browsers at more or less the same time. More usually there will be a delay due to the differing priorities of vendors.

Most clients would not like to think that their investment will be out of date in a year or two. You can use that to explain how quickly browsers move these days and that by having some features there that will very soon have widespread support will help in ensuring the site remains fresh and is still using modern methods in two years time. If your client is cost sensitive explain how these features can save money in terms of easing maintainability; if they worry about SEO explain how making sure the site is fast is one of the most important things you can do; if the visual design is key then you have plenty of things to show that just can’t be achieved without newer techniques.

Also, remember that you don’t need to throw everything out and only use a very new layout method such as Grid or even Flexbox. Start small, finesse your forms or navigation with these methods, add some little touches. Not every site needs all the new shiny throwing at it, most will benefit from some elements from newer specifications. You can learn just as much about Grid by using it to tighten up a floated UI, as you can by turning your whole site over to it.

We don’t have 99% browser support for border-radius, or for pretty much anything introduced in the last few years. If you think you need 99% support to use any CSS you probably had best stop using CSS altogether.

Don’t give up on your own professional development

Response 3 in that poll was to wait until Bootstrap or Foundation support Grid Layout. This to me is perhaps the saddest response at all, and not because I think these things are inherently bad. We are using Foundation ourselves for some of our Perch marketing sites. Using a framework is not always bad, outsourcing your understanding of the basic languages of front-end development to one is definitely bad. You are tying your own future to that framework, and you can be sure that in a year or so something else will come along that everyone moves to. Don’t be the person left clinging to the one thing you know as everyone else moves on.

Whether using a framework or having to write old-fashioned CSS, if you are stuck with a legacy project or client who demands an IE6-era approach to your work don’t give up on new web platform features. You might not be able to use them in production today but learn them, play with them, build personal projects. The new layout methods are fantastic for prototyping. Learn Grid while prototyping features, even if you need to recode the final design. But please don’t stop learning, the web moves far too fast for you to leave your future career in the hands of a dinosaur.

10 Comments

Abdellah February 10, 2017 Reply

You can use CSS grid in production today !
Only in Electron apps though 🙂

Jenny Veens October 31, 2017 Reply

Grid fallbacks and overrides cheatsheet buff.ly/2A1mZ56 #AEASF

Marissa Douglass October 31, 2017 Reply

Why you probably don’t need a CSS Grid-based grid system #AEASF buff.ly/2xABtam

Riley Jones 💯 💯 October 31, 2017 Reply

Why you probably don’t need a CSS Grid-based grid system #AEASF buff.ly/2xABtam

Leave a Reply