we put a lot of logic into how we recommend browsers

• no IE recommendation if you're on mobile or mac/linux
• no mobile browsers if you're on desktop
• it's conditional on what your current browser is (somehow..)

I think these are all very useful. we should document them on the homepage so people understand the value of the service

I really like this API. I was looking if something like this existed, and I am very glad it does.
However, I would like to show the user a small list of the features that the site they visit needs and their browser doesn't support, since I think it is good to keep visitors informed of the reasoning behind needing to switch browser to use the site.

What I propose is something like:

"This page uses the following features:
-WebGL
-WebAudioAPI
that are unavailable in your current browser. Please view this page in one of the following browsers:"

I would like this to be added as an optional way to present the message, with an option to turn it on in the API.

@tagawa please add yourself to the WITH list, you more than deserve it!

@tagawa thank you for all the great work you do maintaining this project, we really appreciate it! 👍

Right now it is pointing to @jonathantneal 's domain, but ideally we should put it on a CDN.

Seems this API doesn't work as intended, or has changed at some point.

Looking at http://api.html5please.com/ I've entered some HTML5 features to check for (I'm not using Modernizer), if I just enter the provided code into a test page then it doesn't actually display a list of browsers or logos as I was expecting it to.

I checked the html property on the object sent to the callback function, and other than a couple of <div> elements it was empty.

I then checked the provided link http://mothereffinganimatedgif.com/ to see what I was doing wrong (as that site is given as an example site) but I guess I wasn't doing anything wrong, because if I go to that site using Safari then you'll notice it doesn't work there either! See the following screen grab...

...notice it doesn't show any browsers listed, or any logos - nothing like the "In Action" section of the page http://api.html5please.com/ suggests it should.

Seems something has gone wrong or been updated and not checked.

Can someone advise if I'm doing something really stupid or if indeed there are issues with the API.

Thanks.

Accessing the URI http://api.html5please.com/canvas+webgl.json?callback=h5please&texticon&html&readable

returns {"supported":"unknown","html":""}

I tried the Modernizr version and it prints a log entry that indicates that it doesn't understand the feature "canvas+webgl."

You use this for HTML5 Please, so I guess it's something for this project, too.

(it's late so sorry if I've missed something in the index)

It appears that the content for Read More hasn't been fleshed out yet. Testing Chrome/Canary nothing happens when I click on 'read more' at the moment.

I'm assuming it's yet to be done, but figured an open issue might remind everyone :)

The URL Builder currently displays values in the picker that are already chosen.

We could remove them from the keywords-array and re-add them when they are deleted… or something.

A lot of the features that the widget generator (at api.html5please.com) suggests are not recognized by Modernizr. Examples:

• css-sel2
• css3-boxsizing
• mathml
• datalist

Could you make an option to the html5please call to offer Chrome Frame as an option?
For people who are working on bringing HTML5 to "internal" or "enterprise" apps, read IE678, they know their target audience and they know that they most likely do not have admin rights. This leaves Chrome Frame as the only option.

i think its time to make some test pages. using the JSON and mashing it against handlebars

or the HTML and tossing it into a jquery ui dialog

whatever we expect people to do with this service

that way we'll have demos to show and make sure our JSON data is ideal

Lets find a few HTML5 demos, apps that we can envision things for: http://www.dropmocks.com/ and chrome.angrybirds.com and .. mothereffinghsl.com

The generated widget code uses plus signs for separating features instead of spaces. Example:

features: "localstorage+filereader+draganddrop+svg"

Modernizr.html5please cannot split this using spaces:

opts.features.split(' '); (line 23 of modernizr.html5please.js)

Also, on line 46 of modernizr.html5please.js, parenthesis are missing which causes a wrong value for the url variable.

Even with these two issues fixed, my h5p-message shows undefined. (a.html is undefined.)

there's that.

punting this issue for as long as possible. :)

https://github.com/h5bp/html5please-api/blob/master/agents.json#L64

12 released today.

The history of this project is kind of displayed over here: paulirish/lazyweb-requests#39

If you have any general feedback or discussion, chime in here or file a new ticket.

The features field should be autocompleted from a list of features we support.

"upgrade" is a bit strong especially for unstable features. We should say "use".

All information about browsers should be presented without hover, because this is essential info that shouldn't be hidden.

Looks like the buttons are not clickable in Firefox on Linux.
See the discussion here

"Here is your widget" uses the async attribute on script without src.

"The defer and async attributes must not be specified if the src attribute is not present." says the spec. (It has no effect on inline scripts.)

The current beta version of Firefox [23] blocks mixed content when accessing a site through HTTPS. Requests made from a secure website to the API are considered to be mixed active content and are blocked by default. Any chance HTTPS will be available in the future?

Hi. Looking at the data provided in http://api.html5please.com/cssanimations.json it seems Opera is not mentioned as a browser that supports CSS3 animations. It's supported in Opera 12 (current version) - is this something that should be updated? Thanks.

bug from @benschwarz :

• click into features
• type can
• click canvas
• autocomplete guy goes away

It should reset to open and all things available until you blur out of the input.

Hi everybody!!!

The API is great, but as 90% of my users are spanish, it would be perfect if you could set the language of the html response into the request options (I don´t know if this is the right way to do it, or I should create my own html code from the json response).

If you need some help with the translation, just let me know. ok?

Regards,

David.

E.g. cors in Opera Stable tells me to download other browsers, but Opera Next supports Cors, ideally it should ask users to download that.

@paulirish can we have this ready and have it advertisable on the main page?

Was talking to @addyosmani that we would need some sort of server-side caching. A simple hash of the requested UA & request options might be sufficient?

Anyone knows enough PHP to pick this up :)

• Adjust space when there are no options (e.g. XML format)
• Autocomplete drop-down is fugly. Needs fixing.
• Builders section needs more tweaks.
• Test it in all mobile devices.
• Show the 'more info'
• Move html to be first option in format
• Make text&icon option to be default as button option.

Need to set correct response headers so that content is cached client side. This will ensure repeated requests to the html button wont incur more bandwidth.

Caching could also be turned on for the json / xml output aswell as the data wont be updated often

We are showing a lot of browsers that support certain features. However, most users are on a particular browser, and if a latest version of that browser supports the requested feature, only return that value. If there is no support for that feature among any version of the browser, return the list of other browsers that support that feature.

https://github.com/h5bp/html5please-api/blob/master/agents.json#L56

7.0 was released (on some platforms) today.

Currently it recommends all browsers mobile/desktop if request comes from Desktop agents. We should only recommend desktop browsers.

Likewise with mobile UAs.

The API lists iOS Safari among the suggested browsers. This doesn't look right to me, if the goal is to give the user links to browsers they can upgrade to.

There should be an option to limit results to desktop browsers only.

like

if (supportsStuff)
  initApp()
else
  makeAPIJSONPcall()

add after builder section.

Calling http://api.html5please.com/video+audio+webgl.json?callback=h5please&texticon as per the instructions results in:

{"supported":"unknown","html":""}

In fact it seems to be anything involving the webgl support.

"html": "­<style>....... </style><div class="caniuse">...."

This is invalid HTML. Why the ­? Since the next thing is a block box, it doesn't do anything anyway.

It should be more like:

"html": "<div class="caniuse"><style scoped>....... </style>...."

https://github.com/h5bp/html5please-api/blob/master/agents.json#L40

11.60 was replaced by 11.61... and 11.62 will be coming out sometime in the near future... updating files is fun!

the "output" section might be better if it had an example of the json within it
so you could see a real looking example of the current query

via @benschwarz

reported here https://twitter.com/#!/amberweinberg/status/170388403442032640

Yeah we can't show that on hover for those devices.. hmm

See agents.json

I don't know if this is intentional, but there's a ­ at the start of the API html output. This is causing an unnecessary blank line to appear before the widget in my page layout.

We're working with alexis behind caniuse to host this at api.caniuse.com but we've also discussed api.html5please.com and others.

If you have the resources to host an webservice like this chime in.

The "Here is your widget" boilerplate that uses Modernizr has this:

var ref = document.getElementsByTagName('script')[0]; var url = 'http://api.html5please.com/' + features.join('+') + '.json?callback=Modernizr.html5please.cb' + opts.options ? ('&' + opts.options) : ''; script.src = url; ref.parentNode.insertBefore(script, ref); return false; };

Does this even work? Scripts are generally marked as "already executed" and then don't want to execute again. Or what if the first script element is a data block (i.e. has a type="" attribute that causes the script to not be executed)? Also, "what if two scripts did this?" (http://blogs.msdn.com/b/oldnewthing/archive/2005/06/07/426294.aspx ).

Why not just create a new script element?

http://caniuse.com/jsonp.php I imagine is updated more frequently than when @Fyrd pushes it to his repo.

That true, alexis?

I think ideally the html should show nothing if the browser supports the features required. The intent is to get out of the way of users when not necessary. The prompt and html should only render if the features are not supported.

Agreed most users dont need to see them, but it can be frustrating that its not accessible at all.

proposal: http://paulirish.com/i/108a30.png

This would help to deal with the "what about safari/opera?" questions that we saw here: http://news.ycombinator.com/item?id=3602160

API details:
http://sandbox.thewikies.com/caniuse/
conversation and details here: https://etherpad.mozilla.org/supportedbrowsersapi

We are not finalized on what the JSON payload is.

We'd love to see some folks test our the API and apply to test pages. see #2

• can we use <dt><dd> combo for the API details?
• let's group options by HTML and JSON output. clarify that callback if your homeboy
• styling? should we style with caniuse's general flavor?
• add some In the Wild examples (which we don't have yet)
• btw i added a bunch of text to explain wtf this is. also some :target: styling

I'm not really sure how to use the HTML version since it's just a link. But @nimbupani said that information is still missing. Anyways.. maybe that's the plan or maybe it's too late, but would it be a good idea to make it like how Twitter buttons are used? Basically a wizard with a couple options that spits out a code snippet for people to paste onto their sites:

<div id="caniuse" data-support="audio+css-transitions" data-appearance="nocss+icon+text"></div>
<script> some code </script>

Then designers don't have to deal with JSON callback stuff. ;-)

Should the API even show Internet Explorer as an option to visitors that are using Windows XP with features that require IE9+?