HTML and CSS Reference
In-Depth Information
The word “doctype” often appears in all uppercase letters but it isn't actually case sensitive;
<!doctype
is
just as valid as
<!DOCTYPE
. The keyword “
html
” appears after the doctype opening, and is also case-
insensitive (
HTML
is the same as
html
), but its case should match the case of the root element, which we'll
cover next. This essentially tells the browser that the document it's reading has been authored in HTML
and not some other markup language.
In past versions of HTML and XHTML, the doctype included additional information telling the browser that
not only was the document an HTML or XHTML document, but which specific set of rules the document
conformed to, like this doctype for HTML 4.01 Strict:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "
http://www.w3.org/TR/html4/strict.dtd">
The doctype has been greatly simplified for HTML5 with an eye toward the future; now just declaring that a
document is HTML is sufficient. Browsers don't necessarily need to worry about which particular version of
HTML it is, as long as it's HTML. However, if you happen to be working with a document authored in a
specific older version, you should still declare that older version in your doctype. If your document relies on
features or elements specific to the HTML 4.01 Frameset version, for instance, you should declare an
HTML 4.01 Frameset doctype. If you're working with an XHTML document you'll need to declare an
XHTML doctype. All the markup examples you'll see in this topic conform to the rules of the HTML5
specification, at least as it stands as we write this in 2012; remember that the spec is still subject to
change.
The HTML5 doctype is quite modest indeed:
<!DOCTYPE html>
This must be the very first line of text in an HTML document for it to be considered valid and well formed
according to the HTML5 specification (only white space can appear before the doctype). Web browsers
will usually still render a document even if the doctype is missing, but they'll render it in a very different
way.
Doctype Switching and Rendering Modes
Some of the earliest browsers that supported CSS did so largely according to their own rules, rather than
following the standardized specifications (in their defense, some of the early CSS specs were pretty vague
to begin with). This inconsistency between browsers was a major stumbling block in the adoption of CSS
and web standards in general. A page might render perfectly in one browser and appear completely
broken in another.
As browsers improved their support for CSS—that is, moved toward an agreed standard for rendering web
pages—they were faced with a dilemma. Many websites had already been designed with built-in
dependencies on the inconsistent, inaccurate renderings of older browsers. Suddenly opting to follow the
rules could cause millions of web pages to seem “broken” in the latest version of a web browser when they
looked just fine the day before. The site didn't change overnight; only the browser's method of rendering it
did. An oft-repeated mantra among browser vendors is “don't break the Web.” As they implement new
features or improve support for emerging standards, they must still maintain backwards compatibility with
the content that already exists on the Web—even sites that were built poorly.
