Without JavaScript

It used to be an accepted practice that your web page should work even for those of your visitors who for whatever reason do not have JavaScript enabled in their browser. Consider: HTML is supposed to define the content of the page, CSS is supposed to define its appearance, and JavaScript is supposed to define how it interacts with your visitor. Each should build on what comes before. If you follow that approach then your web page will still be readable even if all your visitor receives is the HTML. In any case your visitor has control over the CSS and JavaScript and can either disable them or override them with their own whenever they wish. All you can guarantee that your visitors will receive as you have defined it is the content of the HTML.

Unfortunately, this is no longer considered to be essential. Many previously professional web developers have abandoned professionalism by deciding to create web pages that will break if JavaScript is disabled. Their web pages will only work if their visitor has JavaScript enables and if their visitor has their browser settings arranged the way that the amateur web designer has designed their page to work with. So now their web page is broken for many visitors when JavaScript is enabled and also broken when JavaScript isn't enabled, there is no easy selection that these visitors can make that will allow the web page to work.

One of the worst of these groups of unusable web pages are those that use browser sensing. Even apart from the fact that browser sensing was obsolete by the time Internet Explorer Three was released, and that unless you list millions of different browsers your browser sensing is incomplete, browser sensing is testing a field that is entirely under the control of the owner of the browser. Your visitor can change the field being tested to contain any value at all in most browsers. That browser sensing is a poor technique is well illustrated by the default values that most browsers insert into the field to start with. Even IE3 inserted Mozilla into the field so that code performing browser sensing would hopefully misidentify IE3 as Netscape 2 and so not break. The same has applied only more so to more recent browsers many of which try to fool the stupid browser sensing code into mis-identifying the browser so that the script that the browser is perfectly capable of running can actually be run rather than arbitrarily being prevented from running by the stupid browser sensing code. Browsers even allow you to set the value that selected web pages will see when performing browser sensing so as to make it a bit easier to get around this type of JavaScript. None of these scripts have been tested for the case where the useragent field is not one of the defaults in the few browsers they decided to support (and this includes the possibility that they will break when the next version of any of the tested browsers is released).

Another group of often unusable web pages are those that don't use unobtrusive ways to attach the JavaScript. Instead of having all of the scripts in external files linked to the page using a few script tags, these pages have JavaScript code jumbled with the HTML. Even those that don't actually embed the JavaScript into the HTML often have the script itself exposed in global scope. Given that a web page owner does not have full control over what scripts will try to run in their web page, these pages where the script is exposed can easily break if ever other scripts are attached to the page that make use of the same global variables for a different purpose. Again these pages have not been properly tested.

Yet another group of web pages that will be broken for some visitors are those that include a form in the HTML without any server side code to process the form. These forms rely on JavaScript being enabled in order for the form to work. Even if the decision has been made to not provide a version of the form processing for those with JavaScript turned off, how difficult would it be to have that form generated by JavaScript and so not appear at all for those without JavaScript. Unless the form is the only thing on the page, omitting it when it is broken would still leave visitors without JavaScript with the rest of the page content to look at.

Each of these groups (and others I haven't mentioned) produce web pages that are broken when JavaScript is disabled. Their authors are generally aware of this. What they overlook is that their page is also often broken for those who do have JavaScript enabled. Unless you spend all your time testing your script in each new browser as it is released, there is no guarantee that it will work in all the new browsers. Unless your script is completely unobtrusive you cannot guarantee that there will not be something added to the page by your visitor's browser that will conflict with your script. So it is also certain that the page will be broken for some visitors who have JavaScript enabled. As even the most unobtrusive script you can write still has to have some exposure that could potentially conflict, the only way to be certain that your page will work for everyone who has JavaScript enabled is to make sure it works with JavaScript disabled so that those for whom the page is broken with JavaScript enabled can turn JavaScript off for your page and so still be able to use it that way.

Yes, there are a few web based applications being developed where having JavaScript enabled is essential for the application to be able to work. Requiring JavaScript to be enabled for these web applications is a completely different circumstance to requiring JavaScript to be enabled on all web pages. The vast majority of web pages are not applications that need JavaScript to function. That so many people today just assume that JavaScript is enabled, that the useragent is set to one of the three or four main browser defaults, and that their script is not going to clash with anything else in the way the browser is configured is ridiculous when you consider how easy it would be in most of those instances to write the page so it works without JavaScript.

 

This article written by Stephen Chapman, Felgall Pty Ltd.

go to top

FaceBook Follow
Twitter Follow
Donate