0 The Story of HTML5
0 The Story of HTML5
Software Development
Introduction to Web Development SD-100
Andre Specht
XHTML has most of the same syntax conventions as HTML, but it enforces stricter rules. Much of
the sloppy markup that traditional HTML permitted just isn’t acceptable in XHTML. For example,
suppose you want to italicize the last word in a heading, like so:
When a browser encounters this slightly messed-up markup, it can figure out what you really
want. It italicizes the last word, without even a polite complaint. However, the mismatched tags break
the official rules of XHTML. If you plug your page into an XHTML validator (or use a web design tool
like Dreamweaver), you’ll get a warning that points out your mistake. From a web design point of view,
this is helpful - it lets you catch minor mistakes that might cause inconsistent results on different
browsers, or might cause bigger problems when you edit and enhance the page.
At first, XHTML was a success story. Professional web developers, who were frustrated with
browser quirks and the anything-goes state of web design, flocked to XHTML. Along the way, they
were forced to adopt better habits and give up a few of the half-baked formatting features found in
HTML. However, many of XHTML’s imagined benefits - like interoperability with XML tools, easier page
processing for automated programs, portability to mobile platforms, and extensibility of the XHTML
language itself - never came to pass.
Still, XHTML became the standard for most serious web designers. And while every- one seemed
pretty happy, there was one dirty secret: although browsers understood XHTML markup, they didn’t
enforce the strict error-checking that the standard required. That means a page could break the rules
of XHTML, and the browsers wouldn’t blink. In fact, there was nothing to stop a web developer from
throwing together a mess of sloppy markup and old-fashioned HTML content, and calling it an XHTML
page. There wasn’t a single browser on the planet that would complain. And that made the people in
charge of the XHTML standard deeply uncomfortable.
The solution was supposed to be XHTML 2. It was set to tighten up the error-handling rules,
forcing browsers to reject invalid XHTML 2 pages. XHTML 2 also threw out many of the quirks and
conventions it had inherited from HTML. For example, the system of numbered headings (<h1>, <h2>,
<h3>, and so on) was superseded by a new <h> element, whose significance depended on its position
in a web page. Similarly, the <a> element was eclipsed by a feature that let web developers transform
any element into a link, and the <img> element lost its alt attribute in favor of a new way to supply
alternate content.
These changes were typical of XHTML 2. From a theoretical point of view, they were cleaner and
made more sense. From a practical point of view, they forced everyone to change the way they wrote
web pages (to say nothing of updating the web pages they already had), without adding new
functionality to make all the work worth- while. And along the way, XHTML 2 dumped a few well-worn
elements that some web designers still loved, like <b> (for bold text), <i> (for italics), and <iframe> (for
embedding one web page inside another).
But perhaps the worst problem was the glacial pace of change. Development on XHTML 2
dragged on for five years, and developer enthusiasm slowly leaked away.
The switch from the W3C to the WHATWG and back to the W3C again has led to a rather
unusual arrangement. Technically, the W3C in charge of determining what is and isn’t official HTML5.
But at the same time, the WHATWG continues its work dreaming up future HTML features. Only now,
they no longer refer to their work as HTML5. They simply call it HTML, explaining that HTML will
continue as a living language.
Because HTML is a living language, an HTML page will never become obsolete and stop working.
HTML pages will never need a version number (even in the doctype), and web developers will never
need to “upgrade” their markup from one version to another to get it to work on new browsers.
Because HTML is a living language, new features (and new elements) may be added to the HTML
standard at any time. Some web pages may choose to take advantage of these features, and some
browsers may choose to support them. But features won’t be tied to a specific version number.
When web developers hear about this plan, their first reaction is usually unmitigated horror. After
all, who wants to deal with a world of wildly variable standards support, where developers need to pick
and choose the features they use based on the likelihood these features will be supported? However,
on reflection, most web developers come to a grudging realization: for better or worse, this is exactly
the way browsers work today, and the way they’ve worked since the dawn of the Web.
As explained earlier, today’s browsers are happy with any mishmash of supported features. You
can take a state-of-the-art XHTML page and add something as scandalously backward as the
<marquee> element (an obsolete feature for creating scrolling text), and no browser will complain.
Similarly, browsers have well-known holes in their support for even the oldest standards. For example,
browser makers started implementing CSS3 before CSS2 support was finished, and many CSS2
features were later dropped. The only difference is that now HTML5 makes the “living language” status
official. Still, it’s no small irony that just as HTML is embarking on a new, innovative chapter, it has finally
returned full circle to its roots.
CAREY, Patrick. (2017). New perspectives on HTML 5 and CSS (8th ed.). Cengage.