A healthy choose your browser page #39

nimbupani opened this Issue Jun 24, 2011 · 39 comments


None yet

A lot of demos have nasty "download IE9" or "download Chrome" or "download other browser" placeholder text when viewed on browsers that do not support a selection of features.

The idea is to create a site that would render the correct list of browsers that support the features required for the demo. e.g. http://chooseyourbrowser.com/history+transitions+webGL would give you a polite message with a list of all browsers that support these features (not just one).

get.webgl.org does this very well (and a lot of webGL demos use it).

Easier for demo creators to link to rather than face flack for openweb unfriendly unsupported pages.


I'm working on a solution for this at the moment.

Rough work done to date:
http://addyosmani.com/gyazo/c6bf2.png (default view)
http://addyosmani.com/gyazo/c5220c9.png (support tables)
http://bit.ly/rciv9x (autocomplete features known)
http://addyosmani.com/gyazo/d5a5.png (if feature unlisted, enter what something custom and read specs will just do a google search)

(needs a lot more love, but it'll get there) :)

Users are able to select features via an autocomplete input based on pulled data from caniuse.com. Support tables will however be designed better (might provide different views of the data) but are being correctly output per feature at the moment.

A sharable URL is generated so that you can easily let people know what features are required for a demo and I might have links to go download particular browsers once the rest has been wrapped up.

Any more ideas to contribute, feel free to let me know.


OMG that looks exactly like what I wanted. Thank YOU @addyosmani!


No worries! :) I'll ping back once I have a demo up somewhere you can try out.


Cool addyosmani! When you shared the code, please say something, I'm also interested in this issue.


This is (finally) almost ready. Will post to a repo once the code cleanup has been done.


Great! Can't wait to see it. ;)

2011/11/3 Addy Osmani <

This is (finally) almost ready. Will post to a repo once the code cleanup
has been done.

Reply to this email directly or view it on GitHub:

paulirish#39 (comment)


addy did this go online?


@Paul Not yet! I'll probably post it up when I'm back from travels at the
end of November.

Supported-browsers is pretty rad, but doesn't let you select what browser
features you need/tie them in with current support :)

On Mon, Nov 7, 2011 at 6:46 PM, Paul Irish <

+cc @tpodmani && http://supported-browsers.com/

Reply to this email directly or view it on GitHub:

paulirish#39 (comment)

Addy Osmani

Developer at Aol | jQuery Core [Bug Triage/Docs/Learning site] teams member
Blogger at: http://addyosmani.com

tpodmani commented Nov 8, 2011

supported-browsers.com is still in "Beta" and this is "lite" list generator.
In near future, there will be more options for advanced users.

I would like to show you when it will be nearly finished...


What are your thoughts on auto-generating the list by crawling the website, or something similarly automated? I could definitely help with that if it's a feature people would use.


yoshokatana i'm curious about that but in the end you'd need to parse the entire site (html/css/js) .. if you're up to that task then sureee :)


Hypothetically this could work with public-facing webapps/sites. I'm trying to figure out the best way to do it, though.

Looks like the best way would be to render it server-side with phantom.js. I'll investigate.

RonnyO commented Jan 15, 2012

@yoshokatana, IMHO crawling and detecting features in use isn't the way to go.
A lot of times, browser support policy is a result of a decision (for dev/qa/business reasons) and not just out of a which-browser-supports-what equation.


Just a reminder: I have most of the work for this lazyweb done. Just waiting for a free weekend to cleanup the code and push somewhere. Will update when there's news!


plz do, addy.

IMHO this is one of the things that helps advance aggressively cool edge feature browser demos while still honoring the open web's commitment to ubiquity.

also. you can post ugly code, too. :)


Addy, yes please post the ugly code so others can clean it up and have it up ASAP!


@paulirish @nimbupani will try my utmost to get this out this weekend :)


Divya started a thread with Jon and I but I wanted to take things back here where I have less of a chance of blocking progress. Also she spoke with @simurai on the design, so cc'ing him.

Divya listed out the following things as target areas

  • How to use home page as JSON & HTML, API w/ feature slugs, API options
  • "mobile" or "nomobile" option? Some demos are made for phone use only, some for desktop only, so if we can allow that choice it would be great.
  • I think the html that is returned shouldn't be intrusive so I
    suggest something like this:
    • Based on the browser the request is being made from, you send back the latest version of that browser that supports all the feature set that is required. E.g. these are the replies if someone is using.. chrome stable,
      for Firefox, and
      for Opera
    • If no version of the browser supports the feature, return something
      like this

Also we've been talking about how this makes a lot of sense to mostly a Modernizr plugin. I agree that's very wise. in the next comment i'm gonna take a stab at what the API is like..


@paulirish Do you have a link to the thread with Jon? So far this actually looks really solid. Great work @jonathantneal :) One comment I would make is that where possible I would avoid forcing people to learn how to use the API (e.g caniuse/feature1+feature2.json etc - even if it does look fairly simple atm (consider confusion about features with multiple words in the name)) - the approach I was going to take with my version was just letting them type in the features they wanted, add them to the current view and generate the link to the feature (imo, more user friendly, but others may disagree) :)


@addyosmani I completely agree. I think it would just be a matter of creating an interface that would use the same data.json object to generate the urls in a friendly way for people.


Also, we've been talking about this as a webservice. Not as something end users would ever visit.

Use case: My HTML5 App

  • I wrote an app. it requires localstorage, canvas, classList, and css's calc()
  • If the current user doesn't have a browser that's capable enough, I want to tell them how to do fix that
  • Upfront in my code, I detect a bunch of features, if any of them fails, I want to show a dialog on my page about this.
  • I am going to handle the dialog myself, so I just need some JSON. I'm gonna use handlebars to mash it against a template and toss into my DOM
  • I'm using Modernizr and gonna use this handy modernizr plugin..

Use case: My Web Audio API demo

  • I made a demo that uses webrtc. Oh shiiiiit
  • I am not using modernizr and the featuer detect is if (navigator.getUserMedia) ...
  • I am lazy and want the HTML tossed into my page quickly.

we're working out some

APIs ideas here


Using the API with Modernizr plugin (and json payload)

    features : 'localstorage canvas classlist csscalc' ,
    // this callback only executes if above features have a falsy value
        var html =  _.template(tmpl,data).render()

}) // return value is the result of testing the above features

Using the API w/o Modernizr plugin (and html payload)

if (!navigator.getUserMedia){

    var script = document.createElement('script');
    script.src = '//example.com/api/html/webrtc?callback=showDialog';

function showDialog(data){
    $('<div>').html(data.html).dialog(); // thx jquery UI



more at http://sandbox.thewikies.com/caniuse/


The next challenge is to figure out what's in the data payload.

  • image URLs?
  • how to represent supporting browsers (stable, beta, etc)
  • do we customize it based on the UA of the browser asking?

(and if anyone has other ideas about the earlier stuff, chime)



irae commented Feb 3, 2012

This is looking very nice!

This could probably generate a lot of side projects, so why not include something more in the package? =)

The project repo could have an static generator, that outputs all the images and javascript needed as a drop-in. The browser and feature list could be compiled to local json files and have some kind of versioning identifier. The API response could return just that everything is still valid instead of the hole presentation layer for the page. There are some nice advantages about this design:

  • high traffic sites would not hit so much the API
  • cron scripts could keep the info updated, hitting the API only once a day
  • integration with build scripts for static hosted sites (jekyll, octopress, etc)
  • mobile version could be compressed and compiled alongside the site scripts for better performance and less requests

Anyone likes the idea?


Good news, everyone! The API has been updated to deliver an extremely relevant payload.

Two major improvements are:

  • The JS / HTML / XML payload is very small.
  • Agent detection shares good news about browser support, available upgrades, or alternatives.
simurai commented Feb 3, 2012

Would it be possible that the message can be customized as an optional parameter? Or even show some custom HTML? You know.. for example games wanna show a sad character with custom text, like this:

Sad Om Nom


@jonathantneal I've been playing around with creating some demos based on https://github.com/jonathantneal/caniuse and I just wanted to check: is combining features in http://sandbox.thewikies.com/caniuse/x+y.html stable at the moment? I ask because when I pass through certain tests (e.g touch - or even a fake test like 'touchs'), it still outputs the congratulations message:



@addyosmani try looking at the available features @ http://sandbox.thewikies.com/caniuse/features.js


@jonathantneal awesome. thanks!


@jonathantneal, i think we should probably output something like "we are unable to tell which browsers support the requested features" or something so devs know immediately something is amiss, or maybe it should be a debug option >_> #scopecreep.


@simurai you could possibly do that with the javascript object that will be returned. Is that sufficient?


@paulirish has opened this up for further discussion @ https://github.com/h5bp/caniuse/issues/4


https://github.com/h5bp/caniuse has this project now.

check out the issue tracker and please get involved!

we're alpha testing this out on http://mothereffinganimatedgif.com/ and its great!

@paulirish paulirish closed this Feb 17, 2012

Looks like the above repo link is broken. It's over at https://github.com/h5bp/html5please-api

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment