Vendor prefixes, polyfills and former clients

Jeremy Keith’s recent post Polyfills and products asked an interesting question about handing polyfilled code to clients:

[Short term client projects] makes it very tricky to include a polyfill in our deliverables. We’d need to figure out a way of also including a timeline for revisiting that polyfill and evaluating when it’s time to drop it.

He continues on the related topic of vender prefixes in CSS:

It’s a similar situation with vendor prefixes. Vendor prefixes were never intended to be a long-lasting part of any style sheet. Like polyfills, they’re supposed to be used with an exit strategy in mind.

That’s harder to do at an agency where you’re handing over CSS to someone else.

As I see it, the practical solution is to make public the agency’s library of polyfills and mixins. Jeremy’s agency, Clearleft, already makes Clearless public, their library of LESS mixins.

Mixins/Vendor prefixes

As the library of mixins is updated, deprecated mixins should be left in place to output only standards compliant code:

.border-radius (@radius: 5px) {
  /* -webkit-border-radius: @radius; */
  /*    -moz-border-radius: @radius; */
             border-radius: @radius;

The generated CSS is clear of vendor prefixes but updating the code isn’t going to break sites trying to call non-existent mixins.

This presumes the use of a pre-processor for creating vendor prefixed code. Meh. Using mixins to remove obsolete code is the poster child advantage of pre-processors.


Deprecating polyfills is made easier by using yepnope – itself deprecated in favour of build specific files. The yepnope replacement loads a single file, such as script.js?yep=classList,selectivizr&nope=modernimages.

Again, an agency can make public their build library and remove any code as they deem it unnecessary. If a project doesn’t need a particular polyfill, it’s configured out from the start.

Client side

The client can choose to update these libraries as they wish, it’s a case of downloading and placing them on the server. They probably need to run a build script provided by the agency, the agency must make this a simple process.

Each twelve months the agency will email its former clients informing them the mixin and polyfill libraries have changed and they should update their site.

Some clients will follow the advice and upgrade, others will ignore it. The net affect is a better web, as fewer sites run unnecessary code.

By Peter Wilson

Peter has worked on the web for twenty years on everything from table based layouts in the 90s to enterprise grade CMS development. Peter’s a big fan of musical theatre and often encourages his industry colleagues to join him for a show or two in New York or in the West End.

Leave a comment

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.