Answering Front-end Developer Interview Questions: “What does a doctype do?”
tldr; While doctypes initially worked to help the browser understand what version of XML document you were using, the official recommendation is to use standards mode, which is signified simply by using <!DOCTYPE html>. All other namespace collisions in XML can be subverted by using the xmlns attribute. But don’t leave out the doctype! It’s still required for all HTML documents. (Remember, the doctype is the very first thing the browser should receive.)
First, some background.
An incredibly popular repository started by Darcy Clarke has recently come to the forefront of developer news. Officially adopted under the HTML5 Boilerplate organization repository, the Front-end Developer Interview Questions repo is now the second most starred in that repository, only out-paced by H5BP itself.
At Whiteboard, we want to constantly challenge ourselves, so we are going to go through these questions one by one and learn from them. As the repository doesn’t answer the questions posed (despite the many requests for them to do so), I’ve decided to share some answers to questions in that repository. As a disclaimer, everyone’s answers to these questions may look different, and there’s still a massive amount of subjectivity in this field.
What I used to think doctype did
This question is in the “HTML” section. First, I’ll break down what I thought doctype did before doing research.
My initial understanding of doctype was two-fold.
- First, to provide developers with an understanding of what specific standard that document adheres to. For example, a doctype adhering to XHTML or HTML 4 is fundamentally different than a doctype that adheres to the latest HTML standard. Doctypes aren’t limited to HTML documents, as they are also used in SVGs.
- I initially believed doctypes acted as a signal to the browser as to what standards the following document adheres to, so that the browser can render that document properly. Doctypes define a standard and provide namespace rules so that the browser knows what behavior to use if there is a collision in the naming of elements. For example, you are probably familiar with link tags in HTML (<link>), but did you know that the same element markup is something different when placed inside of an SVG? I thought doctypes help disambiguate between these two specifications.
As it turns out, I was entirely wrong.
What doctype actually does (which is basically nothing)
While the doctype does instructs the browser as to what version of HTML is being written, the official recommendation is to use standards mode, which allows for a future-safe doctype. From W3.org:
DOCTYPEs are required for legacy reasons. When omitted, browsers tend to use a different rendering mode that is incompatible with some specifications. Including the DOCTYPE in a document ensures that the browser makes a best-effort attempt at following the relevant specifications.
In other words, leaving it out might cause old browsers to regress to older ways of rendering that they have since improved. However, all browsers render properly when using <!DOCTYPE html>. Unless, for some reason, you want to utilize older versions of HTML, this doctype is the only one you will ever use. Important note: don’t stop using the standardized version of doctype. While it doesn’t have a specific function other than to ensure browsers use standards mode, it can’t be omitted without potential negative consequences.
But what about the SVG <link> example?
While it is true that SVG implements a number of elements that have collisions, doctypes were never intended to handle situations where multiple document specifications were being parsed in the same document. Instead, you should use the xmlns attribute (XML namespace). In the case of SVG, a proper SVG looks something like this:
<svg xmlns="http://www.w3.org/2000/svg">
<!-- SVG-specific tags here -->
</svg>Conclusion
Don’t stop using doctype. And, don’t take your previously gained knowledge for granted. Things change fast, and even when you are “right,” whatever you were right about yesterday may change tomorrow. There’s no way to maintain the most current version of knowledge all the time about everything you’ve learned in the past, so when in doubt, trust the docs more than yourself. (Unless the documentation is poor… then rewrite the documentation.)
Originally published at whiteboard.is.
