Modernizr on the server-side

The modernizr-server library is a way to bring Modernizr browser data to your server scripting environment.

There are a host of emerging techniques for adjusting web content to suit different types of browsers.

The current vogue seems to be to do as much of it as possible on the client-side: media queries, progressive enhancement, adding CSS body classes, and so on.

These are all cool, and hit a resonance with those who deal entirely with the front-end of a web site, and who prefer CSS (and a little Javascript) to Python, Ruby, PHP and the like.

In my opinion, this approach won’t always cut it. I’ve already pointed out that the users of radically different devices might want downright different things. Sometimes the differences between browsers are just too great to be able to deal with once the page has reached the client. And dealing with structural changes to a site’s information architecture based on browser capabilities gets messy, fast.

(Imagine if my site had a conditional a ‘photo upload’ feature that I wanted to place in the site’s menu for mobile devices that supported it. Do I have to feature test <input type=’file’> on every page, simply so I can add or remove nodes from the menu’s DOM? Ugh.)

So anyway, sometimes it’s far better to have had the server emit the best content in the first place – or at least as close as possible.

With this in mind, I’ve a new project called modernizr-server.

Modernizr itself is a great way to find out about your user’s browser capabilities. However, you can only access its API on the browser itself, which means you can’t easily benefit from knowing about browser capabilities in your server logic.

To address this, the modernizr-server library is a way to bring Modernizr browser data to your server scripting environment. For example, in PHP:



    print 'The server knows:';
    foreach($modernizr as $feature=>$value) {
        print "<br/> $feature: "; print_r($value);


The server knows:
canvas: 1
canvastext: 1
geolocation: 1
crosswindowmessaging: 1
websqldatabase: 1
indexeddb: 0
hashchange: 1

Exactly the same feature detection is available through this (PHP) API on the server as is available through the (Javascript) API on the client.

Currently, there is only a PHP implementation of the server-side API, but other languages would be easy enough. Stay tuned to the project for more (and let me know what might be a priority, or fork!).

For instructions on how to use, and information about how it works, you’re encouraged to consult the readme. Also this is a young project, so please use in high-traffic production environments with due caution.

Your feedback is welcome! Hope it’s helpful.