Rant — Web Fluff

So what's so bad about images, animations, plug-ins, Javascript, frames and cookies?  Read on to find out …


In a nutshell, they are often a waste of bandwidth.  As a visitor to a web site which is riddled with unnecessary images, you waste your time, money and hard disk space downloading that junk.

All things in moderation: use images carefully and wisely, not to excess, and consider how your site performs when it's on the other end of a 33Kb/s modem connection.

When you do use images — and most sites will want to use some — take time to ensure that the operation of the site doesn't depend on the images.  As a web user who is conscious of how much bandwidth is being used by a "busy" page, I like to "surf" with loading of images turned off (if your browser gives you this option, you should try it some time — it can speed things up quite dramatically).  What I don't then want to come across is a page which just makes no sense without the images, when it would have taken just a small amount of effort to rectify this.

Most of these problems can be solved by adding the required ALT attribute to each "IMG" tag.  It's worth noting that, to form valid HTML, the "ALT" attribute should always be specified, and of course it should always contain something helpful.


In brief: they consume bandwidth (thus making the page load more slowly), they distract the user when they are trying to read the page, and they add precisely nothing of any value.  Most of the time.

As always, there are exceptions — sometimes animations are justified.  As always, take time to ensure that your page still works satisfactorily when the browser is set not to display animations.


My reasoning on this one isn't exactly watertight, but follows a general principle:

Most web pages manage — without compromise — to achieve their end via the use of the bread-and-butter file formats of the web: HTML for text, GIF/PNG and JPEG for graphics.  If an author uses other formats, chances are I would have to install a "plug-in" in order to be able to correctly access the content.

This is okay, as long as (a) I really want or need to access the information and (b) the format chosen actually adds something worthwhile, over and above what could have been achieved using good old HTML-and-graphics.  However, as an author you should be aware that, in making that decision, you are making extra work for me, because I now have to download the plug-in.

("But it's simple, it's all done for you", you say.  Well yes, but first it will distract me with some "download the plug-in?" message, which I have to confirm; then I have to wait while the plug-in downloads to my computer, and then it has to install itself, and finally I might have to reload the page, or possibly even the whole browser, in order to see the required content.  It takes time, effort, and distracts my attention.)

Besides, that's assuming there is a plug-in available for my browser.  If I happen to be using a less well known OS or browser, there might be nothing suitable, and I would never be able to see the contents of the file the author created.


As one of the more popular plug-ins, Macromedia Flash deserves a special mention.  Again, by all means use Flash if you want to, as long as (1) you make the same content available to non-Flash users, and (2) you allow Flash-enabled users easy access to the non-Flash version.

The logic much the same as above — frequently, the Flash content isn't actually useful, it's merely an attempt to impress.  However that attempt can soon fail if the author has been negligent. 

For example, Flash is often used to create a "splash" or "intro" screen which first-time users to a site must negotiate before they can get to the main site (and don't forget, there's a good chance they couldn't give a damn about the Flash bit, they just want to get to the useful content afterwards). 

Frequently there's a "skip intro" button of some sort which takes the user on to the next stage, past the Flash content.  Sometimes that button is part of the Flash movie itself.  This is all well and good for the users who can access Flash in the first place, but what about the rest?  What about users whose browsers don't show Flash? 

Alas for them, the author provided no means to progress past the Flash page.  If they're techo-savvy enough, their best bet is to take a few guesses as to the URL of the next page (/main2.html perhaps) and keep guessing until a decent-looking page with accessible navigation appears.

Finally, just a quick mention about providing Flash-enabled users an option to ignore the Flash parts.  Often a small chunk of Javascript will be used to attempt to determine whether or not the browser will be able to show Flash.  Depending on the outcome, one of two other pages will be navigated to (for example) — one for Flash, one for no-Flash. 

However it's polite to provide a means, from each "version" of the page, to access the other — a (non-Flash) link on the Flash version to access the non-Flash version, and vice versa.  This is also useful just in case the script made the wrong decision.  Of course, maybe the script never even ran — see below.


You know, Javascript per se isn't so bad.  My main point on the matter is this:

I want to be able to turn off scripting in my browser (or use a browser which didn't have scripting support in the first place), and still find the web site usable.

By all means, use Javascript if you want to.  Used correctly, and in moderation, it can enhance a web page, making it more intuitive, or making the use of a web site faster (for example, by requiring fewer page navigations). 

However, what I don't want to see is a web page which is unusable simply because the author didn't allow for users without scripting.

Additionally, it's a fact that the most-used web browser, Internet Explorer from Microsoft, has, since version 4, contained a great many security vulnerabilities.  It's also true that most of these bugs are to do with scripting (in that a successful exploit of the vulnerability requires some script to be run).

In January 2002, respected IE BugFinder-General Georgi Guninski said of the latest vulnerability he discovered:

Disable Active Scripting and never turn it on.  Better, do not use IE in hostile environments such as the internet.

That alone is a compelling reason for disabling Javascript (at least within Internet Explorer).

For all of those reasons, it's reasonable for people to expect to be able to use a web site in a non-script-enabled browser.  However, if the the author of a web site has been negligent in this respect, here are some of the kinds of things which often "go wrong".

"select" navigation menus

A drop-down list is used as a navigation device; the author intends that when you choose the required entry, the form is automatically submitted, thus taking the user to the appropriate page.

This would be implemented in HTML as a form containing just a "select" input (with an "option" item for each ment entry).  The "onchange" attribute of the "select" input submits the form on which it is placed (e.g. onchange="this.form.submit()")

For non-scripting users, the "onchange" code is ignored, so when they choose an item from the menu, the form is not automatically submitted.  However since the "onchange" script was the only means provided to submit the form, there is nothing the user can now do to make the navigation menu perform its intended task.

Sadly, Macromedia Dreamweaver, so beloved of many an HTML author, is only too happy to help to create such flawed devices.

Javascript errors

How often have we seen this one?  There you are, happily using some web site, doing nothing out of the ordinary, when up pops a "Javascript error" message.

If you can nevertheless continue and successfully do whatever you were try to do, that's not so bad — but it is annoying.

On the other hand, all too often the occurrence of the error prevents you from getting to where you were trying to go.

As I mentioned before, using Javascript can be a good thing — but if the script is written carelessly, it can easily cause errors, probably meaning that you would have been better off without the script in the first place.


You know what?  The issue of frames is a tricky one — there are decent arguments both for and against frames, both on the grounds that it makes the end-user experience better (and not just along the lines of "looks nicer").


The most compelling argument in favour of using frames is that it can result in smaller pages being transferred — i.e. less disk space, less data to transfer over the network, and therefore maybe faster load time.  The use to which frames are most commonly put is that of providing an unchanging "menu" or frame or other navigation device (usually on the left, or maybe at the top), whilst the "main" frame is used to show the content of each page.

When used in this way, the frames make it unnecessary for the user's web browser to re-fetch the menu on each and every page; once the frameset has first loaded, each subsequent page navigation within the site needs only to get the content of the "main" frame, without the "fluff" that often surrounds a site such as headers, footers, navigation bars, etc.

In this way, going from page to page is made faster.  Additionally, the content that isn't changing (menu etc) doesn't disappear and reappear (as it would have done were frames not used), thus not distracting the user.  In other words, the frames which don't change provide a solid visual reference point for the user as the frames which do change are loading.


The primary argument against using frames is the paradox of going from page to page (clearly, you're looking at different documents each time); yet at the same time, your browser shows you to be looking at the same URL all the time (i.e. the URL of the frameset).

Additionally, as you navigate through the web site, it's often necessary to change the content of more than one frame.  For example, consider a simple three-frame page, where the first frame is a navigation menu (e.g. "Products", "Downloads", "News", "About" etc), the second frame is the main "content" frame. The third frame is then used maybe as a secondary navigation device (e.g. within the "Products" section, it might show a list of product categories), or it might show links to pages which are related to the main page you're looking at (in the second frame).

When you then click on a link — you click "Products" in the first frame — the main (second) frame needs to change to show an overview of all products, and the third frame also needs to change, to show a list of product categories.

Now here's the catch: in HTML, there's no way for a single action to affect more than one frame.  A link can have a TARGET attribute which controls which frame changes when the link is activated — but that's only one frame.  The only answer is to use scripting (e.g. Javascript) to do the additional work to adjust the other frames.

So why is this bad?  Well for a start, the user might not have scripting enabled — see above.  But even if they have, then the script used is often poorly written, with the effect that the browser's "history" list is messed up. Because of the poor scripting, the "extra" frame changes which the script performs are erroneously considered by the browser to be part of the history list.

Thus, if you click once to change pages (and the script then changes another page in some other frame), you end up having to click "back" twice instead of just once to return to the first page.


This turned into such a big rant it's now on a page of its own.  So read on …