W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2008

[whatwg] Thoughts on HTML 5

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Sun, 21 Dec 2008 19:12:04 +0100
Message-ID: <65307430812211012i7a297861k503054f9585e8bbc@mail.gmail.com>
Please Note: all the following is my personal humble opinion.

As I discovered lately, the main problem of HTML5 is its design oriented to
keep features that are distributed across browsers, that work or that are
simple way to solve big problem. Actually, they are a bunch of different
features somehow not integrated to the others.
Instead, programmer (please note, I use the word programmer, not author or
web designer) developing *new* application may more like a more structured
and logical organization, like XHTML modularization is.
HTML5 features, summed in big groups, are (in spec order):
1) common syntax for the most used datatypes.
2) additional DOM interfaces, which include HTMLElement - HTMLCollection -
HTMLFormsControlCollection - HTMLOptionsCollection - DOMTokenList -
DOMStringMap
3) Elements and Content Models
4) Element types: metadata - structure - sectioning - grouping - text -
editing - embedding - table - forms - interactive - scripting elements
5) User agent requirements
6) User Interaction
7) Communication
8) HTML Syntax

Some of these features can be achieved without any of HTML5, for example
1) use XMLSchema datatypes
2) you don't need HTMLElement: markup insertion, attributes querying can be
done using DOM3Core (that in latest browser are even more performant as no
parser is involved), events are far better handled by DOM3Events, styling is
included by CSSOM
you don't need collection either: just use appropriate DOMNodeLists, while
for DOMStringMap you may use binding specific features (all Object are hash
maps in ECMAScript3): it works this way even in HTML5
3) use XHTML2, which is extensible because modularized
4) metadata is better handled by XHTML2 Meta Attributes module, which fully
integrates the RDF module in any elements;
structure, sectioning, grouping are the same;
text is very similar: you don't have time, but you can have <span
datatype="xsd:date" content="2008-12-21">Today</span> as in HTML5 you have
<time value="2008-12-21">Today</time>; for progress and meter semantic you
can use role attribute (for styling you always use CSS); editing is the
same, but you have an attribute instead of an element, so you don't have the
issue that ins and del can contain everything, even a whole document (not
including <html>);
embedding is much more powerful as any element can be replaced by embedded
content;
tables are the same (you don't have tables API; but you can still use
DOM3Core);
XForms are actually more powerful than WebForms2, since you divide
presentation from data from action (that is implemented declaratively);
interactive elements are not needed at all: details is better implemented as
it is now (ECMAScript3 + CSS3), datagrid is just a way to put data in a tree
model: use plain XML for that; command and a in XHTML2 implemented in any
element using href attribute; menu is mostly an ul with some style;
scripting uses XMLEvents and handler: it looks the same, but it is different
as it is more event oriented (scripts are not executed by default, they're
executed when some event fires)
8) HTML syntax: as I said before, use XML for that

There are instead features that are indeed very useful to develop a web
application, but are not achievable using other means that HTML5:
1) some way to interact with object (please note: object, not embed: object
is for plugins, embed for content) : actually this can be done using
something like cross document messaging, assuming that object creates a new
browsing context (it already does if the target is text/html or
application/xhtml+xml), but we need a specification for message syntax
2) the binding specific global scope (that is, what object are available in
all scopes, if binding supports this); this is normally the window object,
but scripts use certain features only on their own browsing context, so that
may be moved from that to global scope, removing the whole window object
from scope (for current javascript you can write
window.window.window.window.window... and get the same as nothing)
3) the Window object (which includes window name, window location, cross
document messaging, dialog windows)
4) Protocol and Content Handlers
5) Session and Local storage
6) Database storage
7) Drag and Drop
8) WebSockets

What I am asking now is so to "modularize HTML". copy those features into
separate, interoperable modules, removing legacy features (like
window.on-whatever event listener)
A copy of those will remain in HTML5, because browser implement them at the
moment, and the HTML5 goal is that all browser implement the same things in
the same ways

Instead, some web developers in the future will think that a modularized and
less redudant API is more usable, like I personally do, and switch to that,
without mixing with HTML5: actually, I guess what a Database API does inside
HTML.

Best regards,
Giovanni Campagna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081221/7606ab4f/attachment.htm>
Received on Sunday, 21 December 2008 10:12:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:46 UTC