Re: [TAG post:] "HTML 5's proposed basis in DOM/JS skews web control and monetization..."

Maciej Stachowiak wrote:
> 
> Hi Steven,
> 
> On Sep 13, 2009, at 9:06 PM, Steven Rowat wrote:
> 
>> Greetings,
>>
>> Please forgive the cross-list reference, but I believe this short 
>> essay I placed in the TAG (Technical Architecture Group) list is 
>> potentially of interest for many HTML 5 WG members (and others 
>> concerned with the future of HTML 5).
>>
>> "HTML 5's proposed basis in DOM/JS skews web control and monetization 
>> towards corporations and away from individual authors/researchers, to 
>> the detriment of society."
>>
>> http://lists.w3.org/Archives/Public/www-tag/2009Sep/0028.html
> 
> I'd like to make a few points in reply to your concerns:
> 
> 1) Although HTML5 is defined in terms of a DOM, it is not defined in 
> terms of JavaScript. The DOM is a language-independent API and abstract 
> model. Authors writing simple, script-free markup do not need to 
> understand the details of the DOM.
> 
> 2) Many aspects of the HTML5 spec's style are challenging for anyone but 
> experts on the technology. We're expecting that additional works, both 
> from the Working Group and from third parties, will present the material 
> in a more accessible way. Some things we're working on include a 
> markup-only authoring-only spec which uses much less jargon[1], and an 
> authoring guide which takes a more how-to approach[2]. At least one 
> professionally written highly approachable book is already in the works[3].
> 
> 3) In addition, HTML5 has many features that should be greatly 
> beneficial to everyday authors, expert or not. New structural tags like 
> <nav> and <header> make it more clear how to build the basic structure 
> of a Web page. New form controls and interactive elements, such as 
> <input type="date"> amd <details>, will provide easy access to 
> functionality that today take heaping big piles of JavaScript. And new 
> elements for media (<video> and <audio>) and dynamic graphics (<canvas>) 
> will enable everyday authors and hobbyists to easily do things that in 
> HTML4.01 require plugins or even whole external development environments 
> with their own programming languages. For these reasons and more, many 
> Web design gurus like the general approach of HTML5[4]. Many authors 
> have blogged about their experiences with adopting HTML5, one example is 
> here[5].
> 
> 4) Finally, a word on tone. Your post presents the HTML5 effort as a 
> corporate plot to make things harder for individual authors 
> deliberately, to extract monopoly profits. Casting things that way is 
> unlikely to lead to constructive conversation. When you use hyperbole 
> like that, people tend to stop listening to each other and get in 
> defensive mode. Many volunteers have contributed their time and effort 
> to HTML5, and I suspect they won't like being portrayed as corporate 
> stooges. I advise you to find constructive ways to express your 
> concerns. Many of us would like to do everything we can to make HTML5 
> approachable to authors. Everyone from amateurs writing in a text 
> editor, to professional designers, to consumers using simplified visual 
> design tools, to corporations planning massive enterprise deployments, 
> to citizen-journalists using ready-made blogging platforms. If you feel 
> these goals are not being met, I would encourage you to focus on 
> concrete problems and specific improvements we can make. That kind of 
> feedback is much more likely to move things forward.
> 
> I encourage you to read over the materials I linked, and think about 
> ways we can make the language more accessible to everyday authors.

Let me add that there are multiple significant efforts underway to make 
available robust implementations under liberal and business friendly 
licenses of the HTML5 parsing algorithms.  Currently I know of 
implementations in Java, JavaScript, Python, Ruby, and C#:

   http://wiki.whatwg.org/wiki/Implementations

Producing a robust and fully conforming XML parser is beyond the ability 
of many developers, including myself; yet we routinely depend on XML 
parsers for integral portions of our critical applications.  The hope is 
to bring this same level of compatibility and interoperability to HTML.

People can, and will, be able to parse HTML5 with simple regular 
expressions with the same level of fidelity that that they can parse 
HTML4 today.

If anything the current underspecified state, with HTML4, is worse in 
that it excludes people who wish to produce fully interoperable 
implementations as they not only do they need to implement HTML5(*), 
they need to undertake the additional effort of reverse engineering 
multiple browser implementations in order to do so.

> Regards,
> Maciej
> 
> [1] http://dev.w3.org/html5/markup-spec/
> [2] http://dev.w3.org/html5/html-author/
> [3] http://diveintohtml5.org/
> [4] http://www.zeldman.com/superfriends/
> [5] http://www.alexgdesign.co.uk/articles/redesign-using-html5-css3/index.html

- Sam Ruby

(*) The name HTML5 is the correct name for this standard, but has one 
unfortunate side effect: some people presume that it is a different 
standard.  New tags (such as video and canvas) work just fine in HTML4 
content on browser that support these new elements.  The definitions of 
the parsing and the DOM that are present in HTML5 more closely match 
reality -- even today -- than the descriptions in HTML4.

Received on Monday, 14 September 2009 10:34:01 UTC