Scribd
Upload
2 views

c5

The document discusses the evolution and features of HTML5, highlighting its embrace of common practices and new elements that enhance web development. It emphasizes the importance of understanding the specification, despite its sprawling nature, and acknowledges the ongoing challenges and politics within web standards. Ultimately, HTML5 represents a significant improvement in handling markup, while also extending the language to accommodate modern web applications and APIs.

Uploaded by

rama
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
2 views

c5

The document discusses the evolution and features of HTML5, highlighting its embrace of common practices and new elements that enhance web development. It emphasizes the importance of understanding the specification, despite its sprawling nature, and acknowledges the ongoing challenges and politics within web standards. Ultimately, HTML5 represents a significant improvement in handling markup, while also extending the language to accommodate modern web applications and APIs.

Uploaded by

rama
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

126 Part I: Core Markup

It is interesting that many developers are quite okay with the use of innerHTML but are
quick to deride the use of JavaScript’s eval() statement. In many ways, these are the same
concepts: the former provides direct access to the markup parser and the latter provides
direct access to the JavaScript interpreter. Regardless of the consistency of Web developers’
thinking patterns, the codification of innerHTML is quite a welcome change.
The embrace of common practices by HTML5 isn’t limited to innerHTML; the specification
supports all sorts of features, such as designMode features that allow for browser-based
WYSIWYG editing, commonly used DOM workarounds like insertAdjacentHTML(),
emerging DOM methods like getElementsByClassName(), more-esoteric DOM
specifications like ranges and selections, and more.
The specification also provides APIs for what it introduces. We explored just such an
API earlier in the chapter when we experimented with canvas scripting. Similarly, elements
like audio and video expose a number of properties such as volume and methods such as
play().
There is much to be discovered when reading the HTML5 specification closely. Consider,
for example, how browsers handle runaway script code. There really is nothing online that
defines how or when this is done, but the HTML5 specification actually starts to address
such problems (section 6.5.3.4):
User agents may impose resource limitations on scripts, for example, CPU quotas,
memory limits, total execution time limits, or bandwidth limitations. When a
script exceeds a limit, the user agent may either throw a QUOTA_EXCEEDED_
ERR exception, abort the script without an exception, prompt the user, or throttle
script execution.
If you take the time to read the specification, you will find many passages such as this
that offer hope that someday troubling corner cases in Web development will be reduced or
even eliminated. However, you might also get a sense that the aims of the specification are
a bit too grand. You can find bits and pieces of half-baked ideas about undo-redo handling;
subtle hints about important architectural changes, such as the management of history for
supporting Ajax applications; discussion of offline features and storage schemes; and
documentation of a variety of communication schemes, from interframe message posting to
full-blown Web Socket communication. In some cases, these diversion APIs will spawn their
own documents, but in other cases they just clutter the specification. The critics really do
have a point here.

Major HTML5 Themes


As we wind down the chapter, we need to take a look at some of the major themes of HTML5.
These are deep issues that you will encounter over and over again in the Web development
community. These are presented mostly to spur your thinking rather than to offer a definitive
answer, because HTML5 is quite a moving target.

HTML5 Today or Tomorrow?


The simple question that you must have about HTML5 is, can I use it yet? The answer is
yes. You can embrace the future just by adopting the simple <!DOCTYPE html> statement.
Of course, that isn’t very interesting, so your question really is, can I use any of the new
Chapter 2: Introducing HTML5 127

features now? The answer is again yes, but this time with some caution. To demonstrate
why caution is required, the following is a simple example of the use of HTML sectioning
elements, introduced toward the start of the chapter, but now with some style applied to the

PART I
new HTML5 elements used:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>HTML5 Today?</title>
<style type="text/css">
/* style up a few of the new elements */
article, aside, figure, footer, header,
hgroup, menu, nav, section { display: block;}

body > header {background-color: #930; color: white;}


body > footer {border-top: solid 5px black;}
h2 {margin-top: 0; font-style: italic;}
h3 {font-variant: small-caps;}
p {margin-left: 1.5em;}

section {border-top: dashed 2px black; padding-top: 1em;}

section > section h3 {margin-left: 2em;}


section > section p {margin-left: 3em;}

body > footer > p {text-align: right;


font-style: italic;
font-size: smaller;}
</style>
</head>
<body>
<header>
<h1>Welcome to the Future World of HTML5</h1>
<h2>Don't be scared it isn't that hard!</h2>
</header>
<!-- assume chapter 1 before -->

<section id="chapter2">
<header>
<h1>Chapter 2</h1>
</header>
<p>Intro to chapter here...</p>
<section id="newStrucreElements">
<header>
<h2>New Structural Elements</h2>
</header>

<h3>header Element</h3>
<p>Discussion of header element.</p>
<h3>footer Element</h3>
<p>Discussion of footer element.</p>
<h3>section Element</h3>
128 Part I: Core Markup

<p>Discussion of section element</p>


</section>

<section id="newFormElements">
<header>
<h2>New Form Elements</h2>
</header>

<h3>input type=date</h3>
<p>Discussion here...</p>

<footer>
<p>These ideas are from WebForms specification.</p>
</footer>
</section>
</section>

<section id="chapter3">
<header>
<h2>Chapter 3</h2>
</header>
<p>Massive element reference...</p>
</section>

<footer>
<p>Content of this example is not under copyright</p>
</footer>

</body>
</html>

O NLINE http://htmlref.com/ch2/html5today.html
Figure 2-7 shows the rendering of the example in two common browsers. Note that
Internet Explorer 8 and earlier has some trouble with the new elements.
To address Internet Explorer’s lack of support, we can introduce a small script that
creates the new HTML5 elements using the DOM createElement() method. Once IE
recognizes them as elements, it renders the markup and style fine, as shown in Figure 2-8.

<!--[if IE]>
<script type="text/javascript">
var html5elements = "abbr,article,aside,audio,canvas,datalist,details,
figure,footer,header,hgroup,mark,menu,meter,nav,output,progress,section,
time,video".split(',');
for (var i = 0; i < html5elements.length; i++)
document.createElement(html5elements[i]);
</script>
<![endif]-->

O NLINE http://htmlref.com/ch2/html5todayie.html
Chapter 2: Introducing HTML5 129

PART I
FIGURE 2-7 HTML5 works straightaway in many browsers, but not IE.

NOTE Because the preceding “shim” script uses condition comments to make it work in Internet
Explorer, it will not validate well. There are ways around this if you want to use browser
detection. The point of the script is to illustrate the ability to make HTML5 work everywhere.
You can expect that the code will change over time or other hacks will be introduced.

When moving beyond simple HTML5 semantic elements to interactive features, the
situation is a bit dicier. Certainly JavaScript can be used to simulate many features, but until
such features are solidly supported, you should proceed with caution.
Opponents of HTML5 throw out an estimated final version date of 2012 or even 2022 as
a reason to avoid the technology for now. Yes, indeed, some timelines suggest that HTML5
won’t be completely final until maybe 2022. Of course, plenty aspects of HTML5 are
130 Part I: Core Markup

FIGURE 2-8 Much of HTML5 can work everywhere!

implemented today, and it is more likely that preliminary versions of the specification will
be accepted at the time you read this. If you want to avoid using a specification until it is
100 percent complete, you should note that even HTML 4 has some open implementation
and testing concerns, so you might want to head back to earlier versions. Seriously, what
really should matter with a specification like HTML5 is whether you can use many of its
features. The answer to that question is clearly yes.

HTML5 as a Catch-All
HTML is part of a bigger world. A modern Web site or application really needs much more
than markup and must address style, script, media elements, network concerns, security
issues, user capabilities, and much more. Because of the environment in which it is found,
Chapter 2: Introducing HTML5 131

the HTML5 specification seems to touch all manner of topics. In this sense, its critics have a
point about its “everything and the kitchen sink” nature. However, it is impossible for
markup to live in a vacuum, so some overlap and environmental considerations are to be

PART I
expected.
Unfortunately, given that it looks like a catch-all specification, many people misunderstand
the technology and use the idea of HTML5 simply to refer to anything that is new in a Web
browser. HTML5 doesn’t talk about CSS properties. HTML5 doesn’t define Web fonts.
HTML5 doesn’t change HTTP. While the specification is huge, there is plenty outside of it,
so why is there such a misconception that it covers everything? Well, that’s the politics of
the Web at work.

HTML5: Web Politics as Usual


The Web is an interesting place technology-wise because the mob tends to rule. Very often,
well-defined specifications will be built only to be avoided or replaced by ad hoc specifications
that appear to spring out of nowhere. HTML5 tries to tame the mob and bring a bit of order
to the chaos, but that doesn’t come easily, particularly when politics and competition are
involved.
On the Web, there are those who promote openness, and those who promote new
proprietary features for their own browsers. Some will label such organizations good or
bad, and declare their technology the one true way over others. Such promotion of us
versus them can create loyal followers, but the author finds some of the discussion more
than a bit disingenuous.
Web technologies that were once maligned as proprietary Microsoft features, such as
innerHTML, contenteditable, Ajax XMLHttpRequest object, and more, have been quietly
absorbed into the open Web community. Other capabilities such as CSS transformations,
behaviors, Web fonts, and animations found in Internet Explorer—in many cases for the better
part of a decade—are also maligned as proprietary only to be reintroduced with slight syntax
differences by other browser vendors to hails of the progress of the open Web. “Today
proprietary, tomorrow standard” seems to be the rule of Web standards, and it would seem
that now HTML5 is doing its part to continue politics as usual.
Google has already begun a tremendous push to promote HTML5. The problem is the term
is basically being used as a comparison as to what a major competitor is not supporting, more
than a lucid discussion of the emerging technology. Unfortunately, from my observations,
when most people speak of HTML5, it is more as a code for open Web or even anti-Microsoft,
which reminds me of other misused terms of the last browser battles. Let’s hope that cool
heads prevail in the standards fights that will likely ensue.

HTML5: Imperfect Improvement


HTML5 is an imperfect improvement for an imperfect Web world. We simply can’t force the
masses to code their markup right. HTML5 doesn’t try to accomplish this fool’s errand but
instead finds a reasonable path of defining what to do with such malformed markup at the
browser level.
The HTML5 specification is too big. It’s a sprawling specification and covers many
things. However, it tries to document that which is ad hoc and make decisions about issues
left unsolved. Something is better than nothing.
132 Part I: Core Markup

The HTML5 specification is a work in progress. Writing a book about such a moving
target is more than a bit of a challenge. However, like the specification itself, something had
to be done. It will take too long to finish the specification, and in the meantime people want
to use some of the new elements that are already supported.
HTML5 will change the Web, but the old Web will likely live on. Thinking that HTML5
is going to take the world by storm, co-opting standard practices and usurping technologies
like Flash in short order, is fanciful. The old ways will continue to live on and it will be quite
some time before HTML5 ideas are even commonplace.
HTML5 won’t solve all the problems you encounter as a Web developer. In fact, a safe
prediction is that it will introduce even more trouble, particularly as we transition from the
old ways to the new. And although the standard is evolving quickly, there are bound to be
fights among browser vendors, multiple interpretations of the standards, and the typical
dance between innovation and specification conformance.

Summary
HTML5 is the future. Working with the messed-up markup that dominates the Web and
providing a definition of how user agents should parse the mess is a tremendous
improvement in Web development. Yet HTML5 doesn’t simply embrace the past; it extends
the language with many more elements and continues the move to more semantic markup.
While some markup purists may bemoan the resurgence of HTML traditions, the XML
future is not destroyed by HTML5. If you want to use lowercase, quote all attributes, and
self-close empty elements, go right ahead—that conforms to HTML5 as well. However,
HTML5 isn’t just about markup; it is also about metadata, media, Web applications, APIs,
and more. It’s a sprawling specification that will continue to evolve, but much of it is here
today, so get busy and embrace the future of markup now.
CHAPTER
3
HTML and XHTML
Element Reference

T
his chapter provides a complete reference for the elements in the HTML 4.01 and
XHTML 1.0 specifications. All known HTML5 elements at the time of this edition’s
writing are covered as well, but given the fluid nature of the specification, some
elements may have been omitted or syntax may have changed by the time of publication.
You are encouraged to proceed with caution when considering the HTML5 information
because, again at the time of this writing, the specification is in flux and few of the elements
discussed work natively in browsers. Proprietary features discussed in this reference also
should be treated with some caution. All the browser-specific elements and attributes
supported by Internet Explorer, Firefox, Safari, Chrome, Netscape, and Opera are presented.
Some elements presented in the reference might be deprecated, but they are included
nevertheless either because browser vendors continue to support them or because they may
still be found in use.

Flavors of HTML and XHTML


There are many versions of HTML and XHTML in existence (see Table 3-1). In the early
days, the specification of HTML was somewhat fluid, and browser vendors of all sizes
added their own elements. First the Internet Engineering Task Force (IETF) and later the
World Wide Web Consortium (W3C) set standards for HTML and its cousin XHTML.

133
134 Part I: Core Markup

Version Specification URL Description


HTML 2.0 www.w3.org/MarkUp/ Classic HTML dialect supported by browsers
html-spec/html-spec_toc.html such as Mosaic. This form of HTML supports
core HTML elements and features such as
tables and forms, but does not consider any of
the browser innovations of advanced features
such as style sheets, scripting, or frames.
HTML 3.0 www.w3.org/MarkUp/html3/ The proposed replacement for HTML 2.0 that
Contents.html was never widely adopted, most likely due to
the heavy use of browser-specific markup.
HTML 3.2 www.w3.org/TR/REC-html32 This version of HTML finalized by the W3C in
early 1997 standardized most of the HTML
features introduced in browsers such as
Netscape 3. This speficifcation supports many
presentation elements, such as font, as well
as early support for some scripting features.
HTML 4.0 www.w3.org/TR/html4/ The 4.0 transitional form finalized by the
Transitional W3C in December of 1997 preserves most
of the presentational elements of HTML 3.2.
It provides a basis of transition to Cascading
Style Sheets (CSS) as well as a base set of
elements and attributes for multiple-language
support, accessibility, and scripting.
HTML 4.0 Strict www.w3.org/TR/html4/ The strict version of HTML 4.0 removes most
of the presentation elements from the HTML
specification, such as font, in favor of using
CSS for page formatting.
4.0 Frameset www.w3.org/TR/html4/ The frameset specification provides a rigorous
syntax for framed documents that was lacking
in previous versions of HTML.
HTML 4.01 www.w3.org/TR/html401/ A minor update to the 4.0 standard that
Transitional/ corrects some of the errors in the original
Strict/Frameset specification.
HTML5 www.w3.org/TR/html5/ Addressing the lack of acceptance of the XML
reformulation of HTML by the mass of Web
page authors, the emerging HTML5 standard
originally started by the WHATWG group and
later rolled into a W3C effort aimed to rekindle
the acceptance of traditional HTML and extend
it to address Web application development,
multimedia, and the ambiguities found in
browser parsers. Since 2005, features now
part of this HTML specification have begun to
appear in Web browsers, muddying the future
of XHTML.

TABLE 3-1 (X)HTML Specifications Overview


Chapter 3: HTML and XHTML Element Reference 135

Version Specification URL Description


XHTML 1.0 www.w3.org/TR/xhtml1/ A reformulation of HTML as an XML

PART I
Transitional application. The transitional form preserves
many of the basic presentation features of
HTML 4.0 transitional but applies the strict
syntax rules of XML to HTML.
XHTML 1.0 Strict www.w3.org/TR/xhtml1/ A reformulation of HTML 4.0 Strict using XML.
This language is rule enforcing and leaves all
presentation duties to technologies like CSS.
XHTML 1.1 www.w3.org/TR/xhtml11/ A restructuring of XHTML 1.0 that modularizes
the language for easy extension and reduction.
It is not commonly used at the time of this
writing and offers minor gains over strict
XHTML 1.0.
XHTML 2.0 www.w3.org/TR/xhtml2/ A new implementation of XHTML that will not
provide backward compatibility with XHTML 1.0
and traditional HTML. XHTML 2 will remove all
presentational tags and will introduce a variety
of new tags and ideas to the language. Beyond
this brief description, which may certainly be
wrong by the time you read it, little can be said
about XHTML 2 with certainty other than, given
HTML5, its future is somewhat questionable.
XHTML Basic 1.0 www.w3.org/TR/2000/REC- A variation of XHTML based upon the
xhtml-basic-20001219/ modularization of XHTML (1.1) designed to
work with less-powerful Web clients such as
mobile phones.
XHTML Basic 1.1 www.w3.org/TR/xhtml-basic/ An improvement to the XHTML Basic
specification that adds more features, some
fairly specific to the constrained interfaces
found in mobile devices.

TABLE 3-1 (X)HTML Specifications Overview (continued)

Core Attributes Reference


The HTML and XHTML specifications provide four main attributes that are common to
nearly all elements and have much the same meaning for all elements. These attributes are
class, id, style, and title. Rather than replicating this information throughout the
chapter, it is summarized here.

You might also like