Web standards

W3C, WASP, A List Apart, Open Web, OpenSource, Evolt, WSG, QuirksMode, W3QC, Accessify

Unobtrusive JavaScript

June 30, 2008 Posted by

As a designer, you can’t just hope that your active JavaScript is functioning well – some people disable scripts by default, because they put a heavy load on their Internet connection. This makes sense because loading a larger script can severely delay the loading of a single page. This is the reason why you should think of an unobtrusive JavaScript when you are designing a website.
You can meet people, however, who don’t see the need for such an approach. In the end, it is much easier to assume that all users support JavaScript, and this effort for a small group of Internet users is just a waste of time. Fortunately, the number of people who see an unobtrusive JavaScript as something more than a slogan. For those who don’t much on this issue, I suggest a few points to consider when designing a website:

  1. Avoid erroneous assumptions – it is worthwhile to test your site with JavaScript disabled, and if something is not working properly, it’s the result of the erroneous assumption that all users have the JavaScript enabled in their browsers;
  2. You have to design your HTML code logically – both before or during the coding you should preplan all possible interactions between HTML and JavaScript;
  3. Avoid bloated scripts – you want to use CSS, where possible; using JavaScript is slower and often unnecessary, especially if it is just about the visual aspect of an element;
  4. You must understand both browsers and users – It is worth examining whether the huge opportunities offered by JavaScript match the capabilities of the popular browsers as well as the needs of users; it so often happens that fancy interfaces with JavaScript disabled fail;
  5. It is necessary to understand the nature of events – you want to dig into the JavaScript documentation in order to learn the event handling, which will allow you to separate the script from HTML;
  6. You should avoid conflicts – it is worth examining whether the use of two different libraries / scripts will not cause errors in the entire service; it’s good to optimize the existing code;
  7. It is necessary to take into account the future of the service – you want to write scripts, so that the next encoder or developer does not have a problem with the existing coments and annotations.

Leave a Reply

You must be logged in to post a comment.