0% found this document useful (0 votes)
12 views4 pages

0 The Story of HTML5

The document discusses the evolution of HTML, particularly the transition from XHTML to HTML5, highlighting the challenges and failures of XHTML 1.0 and 2.0. It emphasizes the emergence of HTML5 as a solution to the limitations of previous standards, driven by the need for a more developer-friendly and backward-compatible web language. The document concludes by explaining that HTML is now considered a living language, allowing for continuous updates and feature additions without the need for version numbers.

Uploaded by

cachbueno1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
12 views4 pages

0 The Story of HTML5

The document discusses the evolution of HTML, particularly the transition from XHTML to HTML5, highlighting the challenges and failures of XHTML 1.0 and 2.0. It emphasizes the emergence of HTML5 as a solution to the limitations of previous standards, driven by the need for a more developer-friendly and backward-compatible web language. The document concludes by explaining that HTML is now considered a living language, allowing for continuous updates and feature additions without the need for version numbers.

Uploaded by

cachbueno1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Manitoba Institute of Trades and Technology

Software Development
Introduction to Web Development SD-100
Andre Specht

The story of HTML5

If HTML were a movie, HTML5 would be its surprise twist.


HTML wasn’t meant to survive into the 21st century. The official web standards organization,
called the W3C (short for World Wide Web Consortium), left HTML for dead way back in 1998. The
W3C pinned its future plans on a modernized successor called XHTML. It took a group of
disenfranchised rebels to resuscitate HTML and lay the groundwork for the features that you’ll explore
in this course.
As you know, HTML is the language you use to write web pages. The basic idea of HTML - that
you use elements to structure your content - hasn’t changed since the Web’s earliest days. In fact, even
the oldest web pages still work perfectly well in the most modern web browsers (including several
browsers that didn’t exist at the time, like Firefox and Chrome).
Being old and successful also carries some sizable risks - namely, everyone wants to replace you.
In 1998, the W3C stopped working on HTML and attempted to improve it with an XML-powered
successor called XHTML 1.0.

XHTML 1.0: getting strict

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:

<h1>The life of a <i>duck</i></h1>

And you accidentally swap the final two tags:

<h1>The life of a <i>duck</h1></i>

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.

XHTML 2: the unexpected failure

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.

HTML5: back from the dead


At about the same time (starting in 2004), a group of people started looking at the future of the
Web from a different angle. Instead of trying to sort out what was wrong (or just “philosophically
impure”) in HTML, they focused on what was missing, in terms of the things web developers wanted
to get done.
After all, HTML began its life as a tool for displaying documents. With the addition of JavaScript,
it had morphed into a system for developing web applications, like search engines, e-commerce stores,
mapping tools, email readers, and a whole lot more. And while a crafty web application can do a lot of
impressive things, creating one isn’t easy. Most rely on a soup of handwritten JavaScript, one or more
popular JavaScript toolkits, and a web application that runs on the web server. It’s a challenge to get all
these pieces to interact consistently on different browsers. Even when you get it to work, you need to
mind the duct tape and staples that hold everything together.
The people creating browsers were particularly concerned about this situation, and a group of
forward-thinking individuals from Opera Software (the creators of the Opera browser) and the Mozilla
Foundation (the creators of Firefox) lobbied to get XHTML to introduce more developer-oriented
features. When they failed, Opera, Mozilla, and Apple formed the loosely knit WHATWG (Web
Hypertext Application Technology Working Group) to think of new solutions.
The WHATWG wasn’t out to replace HTML, but to extend it, in a seamless, backward-
compatible way. In fact, the earliest version of its work had two add-on specifications called Web
Applications 1.0 and Web Forms 2.0. Eventually, these standards evolved into HTML5.
By 2007, all the excitement was in the WHATWG camp. After some painful reflection, the W3C
decided to disband the group that was working on XHTML 2 and work on formalizing the HTML5
standard instead. At this point, the original HTML5 was broken into more manageable pieces, and many
of the features that had originally been called HTML5 became separate standards.

HTML: the living language

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.

You might also like