Re: Write-up about semantics in HTML5 from A List Apart

The ways in which XML is meant to be extensible are only partially relevant.
If you are mainly interested in static documents, XML could be a good
solution. The last several years have been all about increasingly dynamic
applications. Behaviors are added via script to extend what HTML can do.
Presentation is modified via CSS (sometimes with assist from script). What
present-day leading-edge application writers are doing, in effect, is
extending HTML. Those same writers spend a lot of time coming up with
work-arounds to cope with the fact that HTML was not well-designed for
extension, and is not cleanly extensible.

HTML is perfectly fine as a starting point. With a good model for extension,
(think of HTML as kind of a funny way of writing Lisp S-Expressions), you
can get all the headroom you need, and can be entirely backwards compatible.

The problem with the HTML5 standard is an effort to do too much with
pre-defined declarative markup. This path is doomed to be both too much (a
gigantic "standard", much of which is seldom used), and too little (for the
needs of particular applications). Much better would be to define a
minimalist core (less than HTML4) with a well-defined extension mechanism.
The HTML4 dialect would be common set of extensions, loaded as needed by the
browser.

On this mailing list, it seems that my point of view is very much in the
minority. For the article it appears I am not alone.

One of my favorite stories is how Niklaus Wirth chose to keep or discard
Modula-2 compiler optimizations. He would compile the new compiler, then
re-compile the new compiler sources with the new compiler. If the
compilation took less time, he would keep the new optimization. Not a
perfect metric - but pretty good. It is easy to add new features that
*seem*like a good idea, and end up with lots of seldom-used bulk (and
bugs). You
need a metric for selecting things to leave out.

The metric in the IETF is (or was) "rough consensus and working code", and
that worked pretty well. The Standard C group used something similar, to an
*excellent* result. The Standard C++ group spend years inventing new things
not backed by practice, and left a mess. This HTML5 group (and WHATWG) seem
to have a very hard time leaving things out.

The HTML5 standard is in effect adding whole new libaries of behavior, with
no firm notion (outside opinion) whether the new libraries will prove useful
to web application developers. Better to design HTML as extensible, then
only incorporate behaviors into the base when they prove overwhelmingly
popular with developers in actual use.

Might even be faster than the HTML5 standardization process. :)



On Tue, Jan 6, 2009 at 8:56 AM, Justin James <j_james@mindspring.com> wrote:

>
> We can't please all of the people all of the time. The only solutions (that
> I can think of) to the problem that is at the root of this are things that
> are, for better or worse, solved by XML, not HTML. Those who know me, know
> that personally I highly dislike XML on a lot of level. But frankly, the
> "X"
> stands for "Extensible" and the "HT" in "HTML" stands for "Hypertext". If
> you want to do something other than "Hypertext", use XML.
>
> J.Ja
>
> > -----Original Message-----
> > From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
> > Behalf Of Boris Zbarsky
> > Sent: Tuesday, January 06, 2009 11:00 AM
> > To: public-html@w3.org
> > Cc: john@westciv.com
> > Subject: Re: Write-up about semantics in HTML5 from A List Apart
> >
> >
> > Since there's no sane way to comment on that article without
> > registration, I'd just like to point out that the author basically
> > proposes using the <input type=""> model for everything.  This runs
> > into
> > serious issues with DOM APIs.  For example, if a @structure can be
> > tossed on to any element, and having structur="header" implies some
> > sort
> > of DOM API (e.g. getting the heading level), then all HTML elements
> > have
> > to expose this DOM API.  This leads to all sorts of methods and
> > properties floating around that at best do nothing most of the time
> > until some magic attributes are set.
> >
> > It also means that implementation is complicated because semantics can
> > change on the fly via setAttribute.  I view this as highly undesirable.
> >
> > -Boris
>