"Behind the Scenes"
|March 2012||The monthly newsletter by Felgall Pty Ltd|
No Longer Deprecated
Professional programmers including web developers know what the word 'deprecated' means. They know that they need to stop using commands that are labelled as deprecated straight away and to start updating old code that used those commands because of the limited life that those commands now have.
The same is not true of the vast majority of people writing HTML. I was going to say 'web designers' but professional web designers probably do know what deprecated means. Unfortunately the vast majority of people writing HTML do not and even now continue to write HTML using tags that have been deprecated since 1997.
It is for this reason that those developing HTML 5 have had no option but to suggest a redefinition of a part of HTML 4. Those tags that were deprecated in HTML 4 way back in 1997 which by the fact that they were deprecated should not be allowed at all in HTML 5 (since deprecated means that they are to be removed completely in the next version) are now to have that part of the HTML 4 standard rewritten to downgrade their status to 'obsolete'.
Changing HTML 4 to mark the unnecessary HTML 3.2 tags as obsolete rather than deprecated allows those tags to be retained as obsolete tags in HTML 5. This is necessary to compensate for the fact that even though they were flagged to be removed from HTML 5 way back in 1997, that so many people continue to use them for new web pages that a large portion of the web would cease to function correctly if what was advised in 1997 were to actually be carried out.
Consider a couple of examples where web developers have had to deal with deprecated commands. When PHP 4 was released there were a number of commands in PHP 3 that were flagged as deprecated. Each of these deprecated commands had a better alternative that was introduced in PHP 4 (just as each of the tags that HTML 4 deprecated from HTML 3.2 had a better way to achieve the same result in HTML 4). Professionals using PHP 4 knew that the life of those deprecated commands was now limited and so immediately stopped using them in new code. While they may not have started rewriting the old code immediately, they would have definitely started doing so when PHP 5 was released as that indicated that the remaining life of PHP 4 itself was limited. All professionally written code would have been converted to get rid of the commands deprecated in PHP 4 (and possibly even some of those deprecated in PHP 5) prior to the death of PHP 4 and the upgrade to PHP 5 effectively becoming mandatory. Many will have completed the changes earlier and will have therefore been able to upgrade to PHP 5 earlier (some even as early as when it was first released).
By downgrading the status of tags from deprecated to obsolete the HTML 5 standard will allow people to create web pages that consist of a jumbled mess of HTML 3.2, 4, and 5 tags all in the same page. This will cater for those creating web pages who have no idea of what HTML actually is.
There is one thing missing from HTML 5 though at this point. With HTML 4 there is more than one doctype available to use. The strict doctype indicates that only HTML 4 tags are used and that the tags are used in a way that follows the HTML 4 rules. The validator on seeing this doctype will validate that the code actually does follow most of the HTML 4 rules (note that there are some rules that are too hard for the validator to test and so just because the validator says it is valid HTML 4 doesn't mean that it actually is - for example one rule that it doesn't test for is that an input tag is wrapped inside a block level tag that in turn is wrapped inside a form tag). The alternative HTML 4 transitional doctype indicates that the page still contains HTML 3.2 tags that are yet to be rewritten to follow the HTML 4 rules and so the page is validated as if it were HTML 3.2 but also recognising any HTML 4 tags that did not exist in HTML 3.2. With the current doctype proposed for HTML 5 there is no way for the validator to tell what version of HTML is being used as that tag is valid for any version of HTML except HTML 1. Since the version of HTML is unknown the validator would only be able to validate whether or not the tags used exist in any version of HTML. While this might be suitable for those who don't know what HTML is and therefore don't validate their HTML anyway, there is a definite need for a way to positively identify that the web page is written to the latest standard and does not use obsolete tags. Hopefully this will be catered for by the time that HTML 5 is actually released by introducing a new doctype that will validate that no tags flagged as obsolete in HTML 5 have been used.
One final thing to consider with this is that it is not only those tags from HTML 3.2 that have been marked as deprecated in HTML 4 and so have been obsolete since 1997 that would need to be considered as obsolete for the purpose of that validator. There are also one or two tags in HTML 4 that have been proposed to be flagged as obsolete. It doesn't even end there. HTML 5 proposes formally recognising a number of tags that started out as proprietary tags in one browser but which are now recognised by all browsers as valid HTML 5 tags. In many cases these tags provide the same functionality as other tags (eg. iframe and embed both perform the same function as the object tag that was introduced in HTML 4) and so these tags too should be considered as obsolete since a better alternative was introduced in 1997.
Most surprising of all is where HTML 5 proposes introducing two new ways to do exactly the same thing (for example the 'required' attribute and 'pattern="^.+$"' attribute both mark an input field as requiring something to be entered into it. The second of these is in fact the more flexible of the two proposals since by replacing the dot with \S you can treat a field containing nothing but whitespace characters as being empty.) In cases like this presumably either the superfluous attribute will be dropped before HTML 5 becomes a standard or if too many people actually incorporate it into their web pages while HTML 5 is still a working draft then they will need to flag it as obsolete in the final standard.
Already there are people who add unnecessary / into their HTML and use the XHTML validator because it applies stricter rules that produce better HTML. Hopefully with HTML 5 a way of validating HTML properly that takes into account the obsolete and unnecessary tags and attributes will be provided. Of course since IE8 will be long dead before HTML 5 does become a standard there is a possibility that all the professionals will have switched to using XHTML instead of HTML for all their pages long before HTML 5 is finished so perhaps the distinction between strictly valid web pages and anything that works web pages will be able to be made on that basis.
Lots more updated pages this month and only a few new ones - marked (*). Quite a few of the expanded pages were originally written to answer specific questions and have now been updated to cover any changes since I first answered as well as expending on the information. While the original problem was probably solved long ago there is always the possibility of others having similar problems. I will continue working through the shorter pages expanding them where it makes sense to do so over the coming months as well as adding new pages when I can.
The following links will take you to all of the various pages that have been added to the site or undergone major changes in the last month.