Hi Giovanni,
I haven't read your entire comment, but with your point eight will
break backwards compatibility. As far as I know is HTML5 supposed to
combine old and new. The problem with interfaces is that you can not
simply change them. That's just a fact we have to deal with.
jorgen
On Dec 21, 2008, at 7:12 PM, Giovanni Campagna wrote:
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