Peter-Paul Koch: Object detection

If you want to use an advanced bit of script, you first have to check whether a browser supports the objects you want to use. This page explains how to do it.

De a lenyeg:

If you want to know whether the browser that views your page supports certain objects you want to use in your code, you should never EVER use a browser detect.

Instead, we simply look if the browser supports the object (method, array or property) we want to use. Let’s continue with the mouseover example. This script relies on the document.images array, so first and foremost we’ll have to detect if the browser supports it. This is done by

if (document.images)
{
do something with the images array
}

Another common detect is for window.focus. This is a method (a command by which you tell JavaScript to do something for you). If we want to use the method, we’ll have to check first if the browser supports it.

Note the correct way of doing this: you ask for the method without brackets. This code

if (window.focus)

means: “If the focus method is supported”, while this code

if (window.focus())

means: “If you can put the focus on the window” and assumes that focus is supported. If it isn’t, this line of code creates errors. The brackets () actually execute the focus command, which is not what we want in this case. So we check it without the brackets (see if it exists) and only when the browser passes the check we actually execute the command by adding brackets:

if (window.focus) window.focus()

So the whole point is that if you want to use the array document.images, first check if it is supported. If you want to use the focus method of the window, first check if it is supported.

If you always use object detection, your scripts will never generate any error messages, although they might not work in certain browsers.

Tommy Olsson: Graceful Degradation & Progressive Enhancement

Itt van a teljes cikk, de lenyeg:

The premise for graceful degradation is to first build for the latest and greatest, then add handlers for less capable devices.
…
Another common occurrence in sites built from the graceful degradation point of view is the noscript element. You provide some feature based on JavaScript and add a more basic version for user agents that do not support JavaScript or have client-side scripting disabled.
…
There is one problem with noscript, though. I may use a browser that supports JavaScript and has it enabled, but there could be a company firewall that strips incoming JavaScript for security reasons. In this case the noscript element will not be rendered (because my browser supports scripting) but the JavaScript code that should create the menu won’t be applied either, because it gets stuck behind the firewall.

Progressive enhancement starts at the opposite end from graceful degradation: begin with the basic version, then add enhancements for those who can handle them.
…
The most common occurrence of progressive enhancement is probably the external CSS style sheet.
…
This is progressive enhancement: it works for everyone, but users with modern browsers will see a more usable version.