Why Standards Get Updated

The programming and markup standards define the commands that can be used to write programs or markup documents. The commands it specifies are those that anyone creating the environment in which the program is to run or the document is to display need to recognise in order to process the program or document correctly. For many programming languages this might be a compiler. For web pages it is a web browser. So the standards for both HTML and JavaScript define those HTML tags and JavaScript commands that a web browser is required to understand and process correctly if the browser is to be considered to be compliant with the standards.

So the question that we are considering here is why there are multiple versions of each of those standards with a new version coming along every so often and replacing the old versions. For example, why do we now have PHP 5.4 instead of PHP 1 and why do we have ECMAScript 5.1 instead of JavaScript 1.0.

Well there are actually several answers to these questions.

As the new versions of these standards are released the languages generally become more powerful and more secure. At least that's what happens when the people who work on the standard know what they are doing. Of course no implementation is perfect and it may be discovered that a particular version of the compiler or web browser either doesn't implement the standard quite right or it has a security hole in its implementation that needs to be patched. So the environments in which the standards are applied are updated more frequently than the standards themselves are. With most of these standards only the last one or two major versions of the standard are actually supported and environments that support only older versions of the standards cease to be patched even if a major security hole is discovered. It is simply expected that those writing code will keep track of where the standards identify something as deprecated and will arrange to replace that code with the new equivalent as soon as possible so that when support for that command is completely removed in the following version of the standard that their code will no longer use the command that at that point no longer exists.

Unfortunately many of the people creating web pages do not have a clue as to how the standards are supposed to work. There are still many web pages out there written using versions of HTML and JavaScript that were replaced by a newer standard over fifteen years ago where the owners of the pages have made no attempt to update their pages to replace the commands that were flagged for removal. What's worse is that there are people out there who are still writing web pages to that standard and so are adding to the number of obsolete antiquated code references on the web. For this reason the HTML and JavaScript standards now no longer specify that commands are deprecated (which implies that they are about to cease to exist) but instead HTML merely flags some of them as obsolete. JavaScript has taken an alternate approach of adding a new command "use strict"; to indicate whether the page is written to follow the latest standard or still uses the old version.

So we end up with people arguing that because old versions of HTML and JavaScript still work, why switch to using the newer versions. Well the new versions have far better ways of doing things than the old version does and the new version also resolves many of the problems that many people encountered with the old version. The vast majority of problems that JavaScript beginners ask about on forums only occur because they have copied or been taught antiquated JavaScript. If they had been taught and were using the latest version properly then the problems they ask about couldn't even occur. It's somewhat like back when cavemen lived in caves and houses were invented. The cave is the old version of the standard and the house is the new version. The new version has many benefits over the old version but the caveman is familiar with his cave and actively promotes using caves to all those who haven't yet decided whether to live in a cave or a house.

The time saved in maintaining code that follows the latest standard will soon exceed the extra time needed to learn how to write to the latest standard properly and to create new code that way instead of jumbling things together the way that the earlier standard required. With languages that run in environments other than a web browser the people writing the standards and creating the environments to implement the standards realise the importance of keeping up to date with the latest standard. Only a few novices running these environments on their local computer even have the opportunity to continue using antiquated versions. Only with the web where the novices make up the majority of the people writing code has the situation arisen where new code is being written using long obsolete versions of the standards. Only with web browsers has it ben necessary to modify the standards to require that commands that should have been deleted long ago still need to be supported because there are simply too many places where those commands are still used.

As a result of this the commands that identify which version of the standard is being followed have become more important. The "use strict"; command in JavaScript identifies that the code within that scope needs to comply with the latest standard in order to run. Things are not quite so clear cut with HTML where an HTML 4 strict doctype identifies web pages following the HTML 4 standard while a transitional doctype indicates those pages using a mix of HTML 4 and the obsolete HTML 3.2. The doctype isn't even used properly by web browsers resulting in the proposed HTML 5 doing away with that SGML tag completely and replacing it with a shortened HTML doctype tag that does nothing to indicate what version of HTML the page contains. It's as if those responsible for the HTML standard have given up on trying to improve the language and are simply saying that any command that has ever been a part of HTML is now to be considered a valid HTML command - even those such as embed (which was only ever needed for the now long dead Netscape 4 browser) and iframe (which was only really needed for Internet Explorer 5 and earlier and which will become completely unnecessary once IE7 dies).

While the new HTML standards state what commands the browsers are required to support so that web pages written twenty years ago and not updated since will continue to work, they don't really provide the necessary guidance any more as to what commands should be used in new web pages. Effectively HTML now no longer has what is perhaps the most important reason why standards get updated - to remove those commands that ought never to have been there in the first place. The best we can do is to determine which of the new HTML 5 commands are ones that really ought to be added into the standard and put those on a list, specify an HTML 4 strict doctype and simply ignore any of the error messages that relate to commands on our list. Hopefully by the time that HTML 5 actually becomes the latest HTML 5 standard someone will have produced a proper validator that will tell you where you have used commands that still work but which should no longer be used - just as the jslint web site tells you when you have used JavaScript that might still work but which is not written in the best way.


This article written by Stephen Chapman, Felgall Pty Ltd.

go to top

FaceBook Follow
Twitter Follow