,

Choosing a DOCTYPE: XHTML vs. HTML

Aww, man! Not another lame blog entry
on the issue of HTML vs XHTML <!DOCTYPE>! Not only are there ten billion articles the same, it’s a really annoying topic, isn’t it? Ha! Well, I must admit, this most recent time I’ve come across another myself, I decided to read it, and I did gain a little insight into this issue which I hadn’t previously known. Read on… (if you can stomach it)

Why? Why! Why Do I Care About DOCTYPE!?

The question you (the reader; the student) should ask yourself is: Why, really, should I care about the doctype?.

One answer, generally speaking, is: “To author markup, mindful of current technology (i.e. browser capabilities) and how that technology may present, or better overcome accessibility issues for everyone, including the physically disabled, so that the resulting published media might be consumed by as many people as possible”

(Not unlike, for example, your local cable company invests people and money into bringing you an HD broadcast for your new HDTV, or likewise, the wheelchair accessible ramp you might see at the entranceway of so many public buildings, it is your responsibility as author to present content in an accessible manner.)

DOCTYPE selection, as a topic of study, hasn’t been in my focus for quite some time, but not because I have discounted its importance. I’ve been satisfied with the knowledge I gained years ago, when I first became aware of the emphasis on a change in the role of the webmaster, from authoring HTML markup for publishing web content, to a priority on authoring what has come to be known as Standards Compliant XHTML. The term, Standards Compliant refers to a particular standard of excellence in HTML source code; a diagram for proper HTML tag semantics, written as a recommended guideline for web content authors (i.e. code that will produce no errors when presented to the World Wide Web Consortium’s tool for the validation of HTML source structure and semantics).

What is a DOCTYPE?

Regard yourself a web developer, and never heard of a DOCTYPE? If you care about your reputation, you had better do some more research at the W3C before you publish anything else on-line. 😉

The DOCTYPE is, literally, the tag which should appear first (typically) in an HTML document. It is used to signify what is to come in the content of the document body. If the author wishes for his or her content to be properly interpreted by a user agent (e.g. a web browser), then it is necessary to declare the DOCTYPE. It is beyond the scope of this web log entry to discuss the specific details of DOCTYPE declarations, as there are several options available to content authors, each meant to enhance the interpretation of content by a user agent (that is, the software which will ultimately read the document content). More information about DOCTYPE declaration is accessible from the global authority on the subject of WWW content, the W3C (World Wide Web Consortium).

Meaning Amidst Madness

Are you frustrated by the DOCTYPE in HTML, XHTML, XML, etc? Have you gone around in circles, researching the subject of <!DOCTYPE> to better your compliance with Web Standards, only to find– in the end– you remain uncertain of what is the preferred practice (and, as a result, perhaps less confident in your own wherewithal)?

the W3C’s own article, Web Standards Do, although it doesn’t provide any cheat sheets, magical formulas, or anything else as an end-all, be-all solution one might seek, or even the <!DOCTYPE> list you might expect from a technical authority like the W3C. Instead, Web Standards Do offers an insightful viewpoint, authored by lead members of one of our planet’s most trusted authorities on the subject of contemporary Web Content Publishing, and Web Application Development. Web Standards Do covers not just <!DOCTYPE> selection as a point of what’s right or wrong, but through his so-called Seven virtues of Web Standards 道 (道), Olivier Théreaux offers a veritable archtype by which all web content publishers and web application developers, from hobbyists to professionals, students to intellectuals; the Web Engineers (both literally as Information Techologists, and metaphorically, as those who control the direction and momentum of a passenger or cargo train) individuals, and companies– who drive the proverbial train, carrying passengers, distributing goods, current, bleeding edge, and forthcoming web technology)

I’ve got good news for you! Web Standards Do, the article by from practice to production? I highly recommend reading Web Standards Do, for unlike so many others which tend to side-step what’s really at issue, Web Standards Do offers a rare glimpse at the reality of it all. Read this relatively down-to-Earth perspective, which presents a meaningful answer to the pervasive question: “why should I care about the <!DOCTYPE>?

What’s so Difficult about DOCTYPE Selection?

In practice, not everyone who authors web content is responsible for selecting a DOCTYPE. For example, an author might use a service such as [ read more ]

Google’s Blogger™, where he or she might have published thousands upon thousands of documents, and never yet seen or heard of the DOCTYPE declaration, yet the content is available and nothing seems to be broken in its absence.

Even in the case of Blogger content, however, a DOCTYPE is present in the resulting HTML document. Though your everyday blogger may know nothing of the DOCTYPE, it’s been built-into the HTML source-code by the developers who design web log templates. The Blogger™ user, for example, doesn’t need to think about validation or DOCTYPE semantics because the Google Blogspot™ developers have already made that choice for their users. Of course, not every web site is based on a Blogger™ template, or any of the countless other pre-fabricated content management systems like MySpace™ and Facebook™. Indeed, it is the honest web developer, the creative web designer, or the resident web master who faces the DOCTYPE issue.

In as sense, it’s as easy as the author is willing to make it. In other words, I (or you, or anyone out there actively publishing web content in XHTML / HTML markup) could use a single DOCTYPE for every document published. According to W3C information on relative issues, it is perfectly reasonable to be satisfied that the DOCTYPE we choose, regardless of our options, shall prevail as the best choice for our content. So long as the markup of the document in question conforms to the corresponding W3C Specification for that DOCTYPE, the chioce is (rather paradoxically) correct– or, at least, not incorrect, irrespective of the various HTML and

XHTML DOCTYPE options available (e.g. use <br> in HTML, and <br /> in XHTML to comply with W3C specs).

With the advancement of forgiving web browser technology, the matter has turned out in favor of the lazy, and the uneducated web content authors, but that it doesn’t grant license to author garbage, and call it valid markup. The truth is, no matter what DOCTYPE is used, the corresponding content will be viewable by every user (who has a normal sensory capacity) in most every user agent, the document layout will appear as the author wanted for its presentation, and because modern user-agents are so good at making allowances for bad markup, there will be little or no diminished content delivered to the person reading it. On the contrary, however, I could make up my mind to be very meticulous in my DOCTYPE selection, paying particular attention to whether the content of my document fits more into the category of XHTML, or HTML. Stand out from the crowd, and make an effort to actively select a DOCTYPE which best fits your content. Maintain your integrity in this regard, and you do well to set a good example for others– not to mention, you can be confident that your markup will likely be forward compatible.

It may be a matter of splitting hairs, but DOCTYPE selection is dependent upon the document content. “ Which came first: the Chicken, or the Egg? ”
If the author properly matches his or her content with the most fitting DOCTYPE, then he or she should have little to worry about. How does the author know which is the best fit? A good rule of thumb may be to ask oneself: “ Does my document more closely resemble XML, or HTML? ”

My personal choice, for the past few years, has been to use an XHTML Strict DOCTYPE, and to declare my MIME type as " application/xhtml+xml ", but according the some recent findings (including that which I’ve cited below), I’m beginning to get the feeling that some of my practices may be a bit off the mark. Is all of this talk simply for the purpose of having something to talk about, or is there really something meaningful in it all? It’s up to you to decide, really.

What Others are Saying about DOCTYPE:

Below, I’ve quoted an article I stumbled upon recently. The article focused on the question of whether to use an XHTML or an HTML DOCTYPE. [ read more ]

I found the article to be interesting because I didn’t realize that there is still so much question and confusion over what type of DOCTYPE an author should use. The following text is a summary statement taken from an article titled: DocTypes: HTML or XHTML, Which is best ?.

If you are happy that you are writing well formed, Semantic, standards based markup. then you really have a choice of two Doctypes:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

If you feel that you would like to adhere to the purists view then use HTML 4.01 it is a perfectly valid standard to write to and requires very little modification to transpose to an XHTML standard. If you wish to write to the stricter XHTML discipline then that is fine as long as you ensure that the code validates to that stricter standard, remember that if you serve up XHTML as text/html the tag soup
Parser will not tell you if your code contains errors, it will silently compensate for them. it is up to you to perform the independent validation to ensure the code is standards compliant.

Whatchu do


Leave a Reply

Your email address will not be published. Required fields are marked *