For the last decade or so, Web developers have been moving more and more towards standardization. With the advent and popularity of XHTML, we’ve all been encouraged to ensure that all of the elements we open are closed when we’re done using them, to use all lowercase type for entities and attributes (we could just as easily used all uppercase, but then we’d look like we were shouting in our code), explicitly define attribute values and more. We have come to a golden age in Web development.
Whenever we view the code from other Web sites, assuming it’s written in valid XHTML, it makes sense to most of us. We can tell specifically where paragraphs, divs, spans and other HTML elements begin and end. We have come a long way from the wild west days of the mid-nineties when anything could happen. Some of us are old enough and have been writing HTML long enough to remember the days when HTML was loose and fast and can also remember when browsers would do strange things when attempting to figure out where we really intended one element to end and another to begin.
Those days, however, came and went. XHTML made us all clean up our code, and it made it much easier and more sensible to create attractive, clean Web sites. With the proposal of HTML 5, however, we are very much in danger of returning to those days.
You will see a lot of articles online telling you that HTML 5, though it allows for implicit definitions, open-ended elements, mixed-case attributes and more, will not force you to code that way. Those posts are absolutely correct, but they’re not telling you the whole story. I liken the advent of HTML 5 to repealing the law on driving while intoxicated. Sure, if we were to do away with drunk driving laws, none of us would be forced to drink and drive. However, the fact that there would be no legal consequences for doing so would mean that a lot more people would most likely do so. The same goes for the abolition of the XML standards that have been introduced to Web markup languages.
Further, you will hear a lot of people tell you that XHTML will continue with HTML 5. They’ll explain that there’s no reason you can’t use XHTML formatting when writing in HTML 5. The problem with those statements is that they’re not exactly true. What is true, then?
You can write well-formed HTML, mimicking much of XHTML when developing in HTML 5. However, you cannot have self-closing tags like the line break (<br />) or the image tag (<img />). Instead, you will omit the trailing slash altogether and just have a hanging tag (<br> or <img>).I have since found out that the standards will allow this type of closing tag, but will not encourage it.
- If you really want to use strict XHTML code, you will have to adjust your server settings so that the document is served as an application/XML document instead of being served as text/html (no, you cannot simply adjust the doctype definition, you have to modify the MIME type on the server).
- In doing so, however, you will not be able to serve your pages to Internet Explorer, as it does not recognize the application/XML MIME type.
- In addition, if you serve the document as application/XML, your pages will no longer fail gracefully when an error is encountered. Instead, they will simply stop being rendered. Therefore, if a tag is typed incorrectly or an entity is not encoded properly, the page will stop loading rather than just moving on with messed up formatting.
With these issues in mind, and with a great fear of moving into a future when HTML code is just as sloppy as it was in 1995, I therefore propose the following adjustments to the HTML 5 specification.
- Continue to require all non-empty elements to be explicitly opened and closed.
- Continue to require all attribute definitions to be explicitly indicated. If necessary, support shorter names for attributes and their definitions. Supporting boolean true and false (or 0 and 1) for attributes that only accept two definitions would be a great improvement.
- For instance, something like sel=”1″ is much better than simply using selected all by itself.
- Continue to require all tags and attributes to be lowercase. Mixed case and all uppercase tags are quite simply unattractive.
I recognize that there is trepidation about introducing these XHTML values into the HTML specification, for fear that doing so will “break the Web.” However, the browsers already support old-style HTML, and will always be required to do so. Standardizing the HTML spec will not stop browsers from supporting old and invalid HTML. Many older HTML tags are already obsolesced by the HTML 5 spec, why should implicit attribute definitions and unclosed tags not also be obsolesced?
Instead of returning the Web to where it was a decade ago, you should use this opportunity to take what we’ve learned from XHTML and apply it to the HTML spec. There is absolutely no reason that HTML 5 should be a step backwards in standardization.
Further, I would posit that, even if the HTML spec were to include the proposal I have made above, developers could go back to using the old-style “spaghetti” code they used in the past. There is absolutely no reason, however, that that kind of sloppy code should validate against that spec. Instead, it should be discouraged.
I sincerely hope that, by the time the HTML 5 spec is finalized, some of the great standards introduced by XHTML will be brought back into the fold, and that we will continue to move forward into the future.
If it just does not seem possible to add these standards into an HTML specification, then I hereby call for a proposal to create a new markup language for the Web, using the old, comfortable elements found in the HTML spec, the standards and best practices introduced by XHTML 1 and potentially greater extensibility to allow for custom, valid elements; and that we work toward making that the next major standard in Web development.