[whatwg] several messages about HTML5

[Ian Hickson]

On Mon, 19 Feb 2007, Vlad Alexander (xhtml.com) wrote:
>
> Why do we need X/HTML 5? When did this need become apparent?

HTML started as a document language for scientist to share their
work. It evolved over time; for example the <img> element was added,
forms were added, WYSIWYG features were added, and then removed in
favour of CSS, and so forth. In the last few years, the Web has
evolved yet again, reaching a much more dynamic state than it had
before (pundits refer to this as "Web 2.0"). The HTML5 effort is about
maintaining and evolving HTML5 to address the needs of 21st century
Web authors.

   http://www.whatwg.org/specs/web-apps/current-work/


> X/HTML 5 is currently in Working Draft stage. What is the tentative 
> timetable for moving X/HTML 5 through the standards approval process 
> towards Recommendation stage?

We're trying a new spec design model with HTML5, where certain parts
of the spec can be considered "done" before others. This is because we
have parts of the spec that are very mature, with multiple
implementations, test suites, and active use, and we have others that
are very new, and very much in flux.

Right now this isn't very obvious; members of the community are
working on a system that will annotate the spec live, though, so you
can see what parts are stable are what parts are not. Other members of
the community have also worked on a page that lets you pick what
changes to the spec you want to see, so that you can, say, only see
changes to stable parts of the spec that affect Firefox.

   http://html5.org/tools/specification-diff

All this makes it hard to give a real timetable. Some parts of the
spec are already done and actively used -- for example Yahoo! Pipes
makes use of the <canvas> feature of HTML5. Historically, the point at
which specifications have been branded Recommendations has been
somewhat arbitrary. For example, HTML4, which reached the
Recommendation stage in the late 90s, is still being developed and
fixed. Not all parts of HTML4 are implemented in browsers, some parts
of HTML4 are known to be wrong but have no errata, and so forth. A big
part of the work on HTML5 is actually just fixing HTML4 problems.

HTML5 is being developed completely in the open, by the way. Anyone
can take part. See http://www.whatwg.org/ for links to our forums, IRC
channel, blog, FAQ, wiki, mailing lists, etc.


> X/HTML 5 introduces new markup constructs such as sectioning elements, 
> enhancements to the input element, a construct for dialogs, a way to 
> mark up figures, and much more. Can you briefly describe these new 
> constructs and the reason they were added?

We're trying to use a much more scientific process with the
development of HTML5 than is usually used for new specifications. So,
for example, many of the new sectioning elements (for marking up
navigation blocks, articles, sections, footers, headers, and so forth)
were based on a study of several billion documents done by Google,
where we saw that these were the sectioning elements most used by
authors.

   http://code.google.com/webstats/

Some of the other features, like the scoped stylesheet feature that
allows <style> elements to be put in the document itself with the
content in such a way that only that content is styled, were added
based on feedback from authors.

In fact, everything in the spec is subject to feedback from Web
designers and Web browser implementors. Since we know the spec will be
useless without the buy-in of both those groups, a lot of effort is
being spent on trying to collect their opinions.

One of the other new features in the draft is <datagrid>, which is a
tree view / list view control with built-in support for AJAX-backed
data stores, so you can do something like the typical Webmail view of
all your tens of thousands of e-mails, but instead of only showing 20
at a time, you can just scroll through all of them, without having to
actually download them all until they're needed.

We also have client-side storage APIs (implemented by Firefox, I
believe), offline indicators so you can write applications that detect
when they're going offline, drag-and-drop APIs compatible with those
implemented by IE and Safari, various networking APIs for both safe
cross-domain cross-frame communication, and for client-server two way
communication. Of course there's no way to know which will actually
survive, we've already cut several features because they just weren't
important enough.

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'