W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > September 2009

[Bug 7546] New: "HTML 5" Editor's draft misnamed and disastrous for HTML content-authors unless refactored into HTML (main) and DOM API (appendix).

From: <bugzilla@wiggum.w3.org>
Date: Tue, 08 Sep 2009 19:38:32 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-7546-2486@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7546

           Summary: "HTML 5" Editor's draft misnamed and disastrous for HTML
                    content-authors unless refactored into HTML (main) and
                    DOM API (appendix).
           Product: HTML WG
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: major
          Priority: P2
         Component: HTML5 spec bugs
        AssignedTo: dave.null@w3.org
        ReportedBy: steven_rowat@sunshine.net
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org, public-html@w3.org


Abstract: 

It's been clearly stated that HTML 5 is being re-specified in terms of the DOM
(as opposed to HTML 4). This is a top-level change, and I believe that unless
it is managed carefully it will cause serious problems for the entire web, for
the following two related reasons: 1. "HTML 5" specified in terms of the DOM
becomes in effect a Javascript Implementation Specification, not an HTML
specification: calling the current document "HTML 5" is then misleading. 2.
This so-called "HTML 5" specification becomes unreadable by average HTML 4
authors unless they can master the DOM, shifting control of the web towards
Javascript specialists (who are usually corporate) and away from those who use
plain HTML (and are usually individual authors). Solution:
Refactor the "HTML 5" specification into a self-consistent plain-language HTML
section and a DOM (Javascript) appendix. 


Details:

the simplest definition of the DOM I can find is this from Wikipedia:

"...the Document Object Model is the way JavaScript sees its containing HTML
page and browser state."

http://en.wikipedia.org/wiki/Document_Object_Model

The editor of HTML 5, Ian Hickson, said in an interview:

"The main advantage of defining the HTML DOM APIs and the HTML elements in the
same specification is that we donít let stuff fall through the cracks."

http://www.webstandards.org/2009/05/13/interview-with-ian-hickson-editor-of-the-html-5-specification/

However, to me it seems that the current interweaving of DOM and HTML in the
HTML 5 specification (Editor's, August 25, 2009) appears hideously complex to
those who do not use the DOM/Javascript (like myself), and thus becomes
unreadable by average HTML 4 authors, shifting control of the web towards
Javascript specialists. 

Based on the above interview, it's probably accurate to say that the reason
"HTML 5" has been produced is in order to specify Javascript use by user-agents
('middlemen'), not HTML document production by document authors. It seems
worthwhile noting that all the co-chairs and editors of "HTML 5" are employees
of the largest software corporations: Microsoft, Google, IBM, and Apple.

Thus it's natural that it has evolved to be readable primarily by those
conversant in browser scripting; but I call attention to the fact that this
means there will be a danger that Javascript specialists (corporate), rather
than HTML authors (individuals), will now obtain control of the latest
developments in web usage.

I do not see this as a good thing. I believe it is a major downgrading of the
inclusiveness of the Web.


SUGGESTED SOLUTION:

Refactor the existing "HTML 5" document as follows:
  1. Remove almost all references to the DOM from the specification proper, and
place them in an appendix, or in a second fully separate section, possibly
published separately.
  2. Make the leading section, containing new HTML 5 elements and changes from
HTML 4, a fully self-consistent document that can be readable and understood by
anyone conversant in HTML 4 (or plain language, at best; like the HTML 4
specification). At no place should understanding even of the existence of the
DOM, much less its attributes, be presumed.

I will re-quote Mr. Hickson's goal for the HTML DOM:

"The main advantage of defining the HTML DOM APIs and the HTML elements in the
same specification is that we donít let stuff fall through the cracks."

It seems feasible to me to obtain this goal by separately specifying everything
currently in the HTML 5 DOM, while at the same time not forcing those who don't
use it (HTML authors) to be wading through it when they don't want or need to. 

Otherwise, what falls through the cracks might be the authoring of HTML pages
itself. And then, what use would there be for a DOM to manipulate what isn't
there?


Steven Rowat


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 8 September 2009 19:38:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 September 2009 19:38:47 GMT