::fibreculture:: The HTML5 Language

[stephen at melbpc.org.au]

Hi all,

The W3C group have just released two significant docs regarding HTML5 ..

--
HTML5: Edition for Web Authors

A vocabulary and associated APIs for HTML and XHTML

Editor's Draft 22 January 2011

This specification defines the 5th major revision of the core language of 
the World Wide Web: the Hypertext Markup Language (HTML). 

In this version, new features are introduced to help Web application 
authors, new elements are introduced based on research into prevailing 
authoring practices, and special attention has been given to defining 
clear conformance criteria for user agents in an effort to improve 
interoperability.  <http://dev.w3.org/html5/spec-author-view>
--

and ..

--

HTML5 differences from HTML4

W3C Working Draft 13 January 2011

HTML5 defines the fifth major revision of the core language of the World 
Wide Web, HTML. "HTML5 differences from HTML4" describes the differences 
between HTML4 and HTML5 and provides some of the rationale for the 
changes. <http://dev.w3.org/html5/html4-differences>
--

And, here's a primer on HTML4-HTML5 differences ..

--

Web Developer Basics: Differences Between HTML4 And HTML5 

By David Fiedler <www.htmlgoodies.com/primers/html/article.php/3921271>

Now that we've seen how to use some of the newer whiz-bang features of 
the draft HTML5 standard, it's time to take a few steps back and take a 
look at some of the other differences between HTML4 and HTML5. 

This article is intended to be a useful overview, not an exhaustive 
reference, but remember that things are still and always changing. The 
complete, up to date list of all the technical differences may always be 
found on the W3C's site.

The first thing you should know is that, perhaps for the first time, the 
development of a language standard is acknowledging the real world. 

In order to keep file compatibility with the current standard - which is 
technically HTML 4.01 - the brave decision was made to separate the way 
the web browser renders files from the way we, as developers, must write 
them. 

So the browser, or "user agent", must still process HTML4 constructs like 
the center element, because there will still be millions of files on the 
Internet that happen to use it. 

But we won't be writing any more HTML with center; it's simply being 
dropped from the language (use CSS instead). This compatibility goes both 
ways: older browsers can (and will) simply ignore HTML5 code without 
screwing things up. 

No More Frames

This is great news to those of us who slogged through the 1990s. To be 
exact, the elements frame, frameset, and noframes are being removed from 
the language, as well as acronym, applet, basefont, big , blink, center , 
dir, font, isindex, strike , tt and u. All of these can be handled using 
CSS. (Stephen: here's one CSS primer/demo: <http://www.csszengarden.com>)

You'll also have to learn to get along without using tables for layout; 
while tables themselves are still part of HTML5, they're not intended for 
placing pixels any more. 

Here's what the spec says: 

"Tables must not be used as layout aids. Historically, some Web authors 
have misused tables in HTML as a way to control their page layout. This 
usage is non-conforming, because tools attempting to extract tabular data 
from such documents would obtain very confusing results." 

So all the attributes that let people create those perfectly laid-out, 
tinted tables are gone, like align, bgcolor, border, cellpadding, 
cellspacing, height, nowrap, rules, valign, and the big one: width. 

The mantra: use CSS instead. 

I've been trying my best to break it to you slowly, but frankly, all 
presentational elements are coming out of HTML5. 

My advice: learn lots more CSS, until you can quote chapter and verse in 
your sleep. 

Good News

The good news is that even though this is a big change, it's a change for 
the better. 

Browsers of the future (just another month or two!) will become more 
powerful because of the move towards the cloud, so that they'll be able 
to handle more on their own. 

We've already seen that with things like Ajax, and now with video/audio 
embedding and such, it will be far easier for us to code in a 
straightforward manner and let the browser figure out the details. 

For instance, new structure elements include article, aside, figcaption, 
figure, footer, header, hgroup, nav, section, and summary, all of which 
refer to the structure of the document itself and leave rendering to the 
browser. 

There are still some new elements that deal with text on a detailed 
level, however: you'll code wbr when you think it's possible to do a line 
break, but the browser will decide for you. 

Another hint element is bdi, used to mark an area where bidirectional 
text formatting can be done (primarily for mixing left-right and right-
left languages in a single document). 

Its complement, bdo, lets you explicitly override and force a particular 
directionality. 

For even more slick internationalization, the elements ruby, rp, and rt 
are included for ruby annotations, which are meant for pronunciation aids 
rather than for Ruby On Rails programmers. 

The more high-level new elements include things like canvas, meant for 
specifying an area for drawing a bitmapped graphic on the fly, such as a 
data graph or game graphic; meter is a placeholder for a numeric 
measurement of an expected size (and is eerily similar to format in 
ancient FORTRAN), while progress is its graphical counterpart, to be used 
where you want a progress bar. 

Last, but not least, there are the multimedia elements such as audio, 
video, source and embed.
--

Cheers,
Stephen