[whatwg] Thoughts on HTML 5

Sun Dec 21 10:50:36 PST 2008

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