As
the bedrock to the web, HTML has evolved in many ways from its birth in
1991. While the markup language has had its share of ups and downs, the
advent of what’s being called “HTML5” is a welcome and much anticipated
addition of new semantic capabilities and valuable APIs.
HTML5
is a series of new elements, updates to existing elements and new
JavaScript APIs available through contemporary web browsers. In order to
best describe what HTML5 is, perhaps starting with a few attributes of
what HTML5 is not will help draw the most clear picture.
HTML5 is not the next iteration of XHTML.
In fact many of the rules that you are accustomed to from your
familiarity with XHTML are now changed in HTML5. The promise of XHTML’s
standards compliance and strict validation may be music to the ears of
all of us as software developers, but the pragmatic outcome of broken
layouts and validation errors bubbling up to users created an unforeseen
outcome - programmatic perfection does not translate into a usable web.
XHTML simply isn’t a long-term standard.
The
real world of the web contains scores of ill-formed HTML largely
created by tools and people with less exacting standards than the
conscientious web developer. While this may sound bad, the non-code
enthusiasts are often tasked with creating content for the web and have
no inclination to worry about whether or not every HTML attribute has a
value in their markup, for instance.
HTML5
moves beyond the utopian dream of strict compliance to a schema and
places the highest value on the user of the website over the HTML
craftsman.
“HTML5” no longer exists. In
a strict sense, the term “HTML5” is a misnomer as there are no longer
standalone versions of HTML. In the earliest incarnation of HTML5, there
existed a notion of the next version of HTML being termed HTML5. The
label of “HTML5” took hold in the market and started being used almost
as an umbrella term for “the latest thing” in web development. Recently,
Ian Hickson announced in his blog post, HTML is the New HTML5 (http://blog.whatwg.org/html-is-the-new-html5),
the standards document once known as “HTML5” is now being maintained
under the auspices of the plain name “HTML” as a fluid specification.
The reasoning behind this is because HTML5 became a blanket term for
many different technologies and browser vendors are implementing
different parts of the standard. Therefore, the notion of “detecting
HTML5” or “supporting HTML5” represents faulty thinking. Rather than
looking for HTML5 in its totality, developers are better served by
detecting the individual functionality required from HTML for an
application.
So
if HTML5 isn’t XHTML plus some new dazzling features, what is it?
Simply put, HTML5 is the new HTML standard that includes most of the
features and capabilities of HTML4 along with new semantic markup plus a
number of new JavaScript APIs.
For
clarity’s sake, this article still refers to the combination of markup
enhancements and new JavaScript APIs as HTML5 in order to easily
identify new technologies.
Semantic Markup
The
value of Semantic markup on the web cannot be understated. When you
consider many of the changes related to semantic markup you may realize
that seemingly very little is different. While changing a DIV to a
SECTION may not seem revolutionary, the underlying value is found in the
page’s ability to more clearly describe the intent of the containing
content with new tags over the old ones. Pages that contain inherent
meaning will ultimately perform better in search engines, are easier to
parse on the client and easier for external machines on the web to
interpret and understand.
The
semantic changes are a product of established design patterns. The
contributors to the HTML5 specification include companies like Google,
Microsoft, Apple, all the top browser vendors and literally hundreds of
other organizations. These contributors analyzed the vast array of
markup on the web and looked to create new HTML elements that reflect
the intent of current makeup on the web.
So
while new elements may not seem earth-shattering, the value is to give
more intrinsic meaning to your HTML documents which creates a more open
and usable web. Table 1 lists many of the HTML elements introduced in HTML5.
JavaScript APIs
If
the first part of the equation of HTML5 is the markup, then the second
half is represented by the new JavaScript APIs. In fact, the more you
begin to develop applications in HTML5, the more you realize that most
of the new functionality is in the updated scripting abilities of the
browser.
While browser support for each script API is diverse among the browser landscape, Table 2 describes the promise of each API once fully supported.
Browser Support and the New Age of “Browser Wars”
In
the early days of the web the browser landscape was akin to the Wild
West. Each browser vendor, in an attempt to gain the most market share,
began quickly implementing new features often using proprietary APIs.
This fragmentation in the market created a situation where websites
might only work correctly in a single browser or development teams were
forced to replicate programming efforts in order to provide the same
functionality for different browsers. In short, the situation was a
lose/lose proposition for both web developers and website users.
The
end of the browser wars emerged with the rising influence of the Web
Standards Project which worked hard to get browser makers to agree to
work within the established standards.
So
the distinction today about the push and pull toward complete support
for HTML5 is that each browser maker is implementing against the same
standard. Long gone are the days where in order to implement the same
functionality on a page you had to code for the Netscape API as well as
the Internet Explorer API. Now the APIs are known and standardized, the
dance now is just compensating for the time when a user’s browser may
not have the capabilities of the standard.
To best aid you in reliably developing applications in HTML5 there are two resources that are invaluable:
| & | To Use or Not To Use: SECTION or DIV? Determining the difference between when to use the SECTION element over a DIV may seem a little confusing at first. A valuable rule of thumb to help you decide which element is appropriate is to ask whether or not the element you need to add to the page is intended to establish a logical group around content or if it’s merely being added to support styling of the page. In the case of logical grouping, use the SECTION. To support styling needs, use a DIV. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
0 comments:
Post a Comment