2

Recently I have started experimenting with some of the newer W3C specifications such as WebGL and the Web Audio API that are not yet widely supported in browsers. As I want my page to look professional, I need a way to treat the unsupported browsers gracefully.

Now I was wondering:

  • Is there a standard or a guideline that details what a person should see when their browser does not support a certain page?
  • Are there any pitfalls I should look out for when implementing a not-supported-message?
  • And considering the extremely fast pace browsers release new, updated versions, how can I ensure that my script still works in future browser versions that actually do have the previously unsupported feature without blocking them?
Qqwy
  • 4,709
  • 4
  • 31
  • 45
  • Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see [ask] – gnat Oct 01 '13 at 11:34
  • 2
    Similar question on UX: http://ux.stackexchange.com/questions/29449/what-are-some-best-practices-for-displaying-an-unsupported-browser-warning-in – RMalke Oct 01 '13 at 11:40

1 Answers1

6

1st Question: Is there a standard or a guideline that details what a person should see when their browser does not support a certain page?

I would advise giving a proper message to the user, and give him his options (Like downloading a supported browser)

2nd question: Are there any pitfalls I should look out for when implementing a not-supported-message?

3rd question: And considering the extremely fast pace browsers release new, updated versions, how can I ensure that my script still works in future browser versions that actually do have the previously unsupported feature without blocking them?

If anything, do not detect the browsers, detect the features. If you need WebGL, than create a script that will actively look for the WebGL APIs, and run if they are present, and will not if they are not present.

You cannot really protect yourself for the future browser, if they break the API, they break it, and there is nothing you can do about that. However, if a new browser version brings official W3C WebGL api support to it's users, you should be able to run on it provided that your detection method look for the feature, and not the browser's version.

Claude Houle
  • 171
  • 3
  • 5
    +1 for "do not detect the browsers, detect the features". Only detect the browser if there's a specific implementation quirk you need to work around. – Avner Shahar-Kashtan Oct 01 '13 at 13:05