HTML5 I

[munem15-4873]

HTML5: The Facts and the Myths

You can't escape it. Everyone's talking about HTML5. it's perhaps the most
hyped technology since people started putting rounded corners on
everything and using unnecessary gradients. In fact, a lot of what people
call HTML5 is actually just old-fashioned DHTML or AJAX. Mixed in with all
the information is a lot of misinformation, so here, JavaScript expert Remy
Sharp and Opera's Bruce Lawson look at some of the myths and sort the
truth from the common misconceptions.

Once upon a time, there was a lovely language called HTML, which was so
simple that writing websites with it was very easy. So, everyone did, and the
Web transformed from a linked collection of physics papers to what we
know and love today.
Most pages didn't conform to the simple rules of the language (because
their authors were rightly concerned more with the message than the
medium), so every browser had to be forgiving with bad code and do its
best to work out what its author wanted to display.
In 1999, the W3C decided to discontinue work on HTML and move the
world toward XHTML. This was all good, until a few people noticed that the
work to upgrade the language to XHTML2 had very little to do with the real
Web. Being XML, the spec required a browser to stop rendering if it
encountered an error. And because the W3C was writing a new language
that was better than simple old HTML, it deprecated elements such as

<img> and <a>.

A group of developers at Opera and Mozilla disagreed with this approach
and presented a paper to the W3C in 2004 arguing that, "We consider Web
Applications to be an important area that has not been adequately served
by existing technologies... There is a rising threat of single-vendor solutions
addressing this problem before jointly-developed specifications."
The paper suggested seven design principles:

1. Backwards compatibility, and a clear migration path.
2. Well-defined error handling, like CSS (i.e. ignore unknown stuff and
move on), compared to XML's "draconian" error handling.
3. Users should not be exposed to authoring errors.
4. Practical use: every feature that goes into the Web-applications
specifications must be justified by a practical use case. The reverse is
not necessarily true: every use case does not necessarily warrant a new
feature.
5. Scripting is here to stay (but should be avoided where more
convenient declarative mark-up can be used).
6. Avoid device-specific profiling.
7. Make the process open. (The Web has benefited from being
developed in the open. Mailing lists, archives and draft specifications
should continuously be visible to the public.)

The paper was rejected by the W3C, and so Opera and Mozilla, later joined
by Apple, continued a mailing list called Web Hypertext Application
Technology Working Group (WHATWG), working on their proof-of-concept
specification. The spec extended HTML4 forms, until it grew into a spec
called Web Applications 1.0, under the continued editorship of Ian Hickson,
who left Opera for Google.
In 2006, the W3C realized its mistake and decided to resurrect HTML,
asking WHATWG for its spec to use as the basis of what is now called
HTML5.
Those are the historical facts. Now, let's look at some hysterical myths.

Source: Smashing eBook􁴹Modern Web Design and Development