HTML5 and polyfills – one script to rule them all?

A common discussion about HTML5 and whether to use it, and touched on in the HTML5 Hurdles article, is usually about fallback support and making it work in every web browser. But do we really need that?

Polyfills

When it comes to making various things offered in HTML5 working in older web browsers, both new elements with connected functionality and HTML5 APIs, we have the option of using polyfills. It’s a smart approach which will make their existence automatically obsolete over time as people upgrade their web browser to later versions.

It’s a mindset I really approach, as opposed to writing your own libraries where you need to change the syntax from the default API one offered. I personally think respecting native APIs is important, both for code understanding and handover. Also, I don’t like introducing syntax dependency on a library/syntax if not completely necessary.

The beauty of conversation

While I think polyfills definitely play their part in offering HTML5 experiences for older web browsers, another thing I think it’s important to reflect on is whether we should really try and give the same experience for every web browsers. While polyfills are great, we’re giving all this extra JavaScript to already weak and slow web browsers (meaning mostly older versions of Internet Explorer), and even if they do manage to render things/make the APIs work I’m not convinced it is always for the best.

I think we need take the varying support and also speed of web browsers into consideration, and focus more on offering the best experiences for the latest web browsers who can give that. Same goes for mobile: while the technical support might be there, it doesn’t necessarily mean that the performance is up to the task.

Somewhere I get the feeling we have sort of missed out on one of the ideas of progressive enhancement, when we offer something basic for everyone and then enhance it for those web browsers which have better support. I think that offering a poor user experience on older/weaker web browsers can do more harm than good, and that those users would be better off with a basic well-working version instead.

I find the beauty of coding is like the beauty of conversation – it completely depends on who you are talking with. You adapt your words, sentences and topics through the interaction with the other person(s). Same with web browsers. Evaluate the support for code, performance and other upsides and shortcomings, and then deliver the best based on that.

Choose wisely

To summarize: I’m not saying that polyfills are the salvation, nor something to shy away from. But consider your specific situation: what are you building, how should it work and what is the best time, money and effort spent in creating that end user experience. There’s no ultimate solution for everything, but rather an opportunity to make each thing you work on as special as it can be.

Disclaimer: This blog post is based on talks I have had with Christian Heilmann, and consider that as an inspiration.

7 Comments

  • I still look at progressive enhancement as the first building block of any site/ webapp. The emerging technologies under the umbrella of HTML5, allows me to take progressive enhancement to whole new levels.

    I am, however, aware that for some situations, there’s no avoiding throwing progressive enhancement out the window, because the browsers simply have no native way of handling stuff like sensors in mobile agents.

    And, sometimes I think it’s fair to exclude obsolete/incapable user agents from the conversation … like the grownups waiting to have a conversation until IE6 ^h the kids have been put to bed 🙂

  • Good thoughts! I completely agree with you that polyfills isn’t always the best solution to support old browsers and that we sometimes should take a step back and look if we would be better of to build a simpler but well working solution for the older browsers.

  • Louis-Rémi says:

    I do agree with the necessity of a shift of mind from a “pixel perfect” to a “progressive enhancement” perspective. With the variety of browsers and screen-resolution out there, there’s no greater necessity to create beautiful and usable websites.

    But sometime progressive enhancement is not an option. What if I want to use vector graphics in my Web pages? It’s hard to simply answer “some user will see it, others won’t”.
    Sometime there is a simple and light-weight solution that can provide the same user experience to all of your visitors. It’s probably worth giving a try.
    Last but not least, sometime you’re stuck with a boss/client that has good or bad reasons to refuse progressive enhancement.

    I believe it is our responsibility as Web enthusiasts to advocate for best practices and encourage new trends to emerge. But we should also avoid letting some developers behind. Who has never heard things like: “CSS3 Transformation? I hope my client will never hear about that, I’m sure he’ll want it to work on IE6.”

    Louis-Rémi

  • As an author of a few polyfills (cssSandpaper, html5Widgets) I’m glad you wrote this post — I agree with it 100%

    Writing polyfills can be hard. I don’t know any polyfill offhand that works exactly like a native implementation of the official standard. This is not a slight to any polyfill author – it’s just the way it is. When I write a polyfill, it’s because I have a need and I want to know if it can be done. I get it as close as I need in order to do the work I do. I do try to get it as close as possible, but there are almost always technical limitations, and if the last 5% is going to take a *lot* of work, I’ll leave it until later.

    If a CSS3 text-shadow an HTML5 autocomplete widget is not important for the legibility or function of a page, I think there is nothing wrong with leaving it out in unsupported browsers. If a polyfill can be used without impacting performance or code maintenance, I see no problem with it — but I am still a fan of graceful degradation.

    Awesome post!

  • Paul Irish says:

    As the editor of the page o’ polyfills, I agree with this post 100%. 😉

    Making the decision to use a polyfill shouldnt be as simple as, “does it not have native support?” There are a lot more factors that weigh into it, (perf, speed, loading mechanism, value added).

    I think I’m writing an article soon (probably co-authored with codepo8) on this topic. Def needs some more thoughts. (Also fwiw I’ve spoken to Jason johnston (author of css3pie) about this and he agrees with this sentiment as well. 🙂

  • Robert Nyman says:

    Thanks for your comments!

    Morgan,

    Exactly, I feel the same way!

    Pelle,

    Yes, I too think that should be considered an option too.

    Louis-Rémi,

    If it’s possible to give the same user experience to everyone through polyfills, absolutely. But in many cases the performance, rendering is just not of sufficient quality.

    To be more specific: Use something like Raphaël that utilizes SVG and falls back to VML. Sometimes the VML rendering in IE is so hideous it just doesn’t make sense.

    Or font-face: Sure, we can use any font we want via font-face in CSS, but the font rendering in Windows, especially with some fonts, makes it illegible and it’s better to serve the user a standard font.

    With CSS Transformations and Transitions, those are great examples of when progressive enhancement makes sense. No transform or transition is vital for the end user; for those web browsers we can just switch between states in the CSS.

    ANd I think that should be the guideline: if the fallback/polyfill feature isn’t as good as the native one, and it isn’t functionality the end user must have to be able to use the web site, just serve them a more basic version.

    Zoltan,

    Thank you, glad we’re on the same page!
    Completely agree with what you say. 🙂

    Paul,

    Absolutely, and those are the factors I’m advocating that we evaluate before we use a polyfill just “because it’s there”.

    Good about Jason too. 🙂

  • […] HTML5 and polyfills – one script to rule them all? (Robert’s talk | April 7, […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.