W3C home > Mailing lists > Public > public-html-xml@w3.org > January 2011

Re: Use cases

From: Kurt Cagle <kurt.cagle@gmail.com>
Date: Sun, 2 Jan 2011 15:41:03 -0500
Message-ID: <AANLkTimUGihjPLmvaQ_GGeNDKQpnDr=Hqvpr3vKkCQzp@mail.gmail.com>
To: John Cowan <cowan@mercury.ccil.org>
Cc: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, Julian Reschke <julian.reschke@gmx.de>, Norman Walsh <ndw@nwalsh.com>, public-html-xml@w3.org
>
> De facto, the vocabulary is expanded first and the standards process
> follows.  I happen to think that's a Good Thing: I much prefer
> retrospective to prospective standardization.  But standards should
> define a clean, non-ad-hoc way to expand the vocabulary rather than
> letting it happen under the table, which has been the history of HTML
> and has made it the collection of hacks we see today.


It's worthwhile looking at the evolution of XQuery and XSLT2 in that regard.
In both cases, the language tended to be limited in its extensibility
because, lacking a formalized mechanism for extension, people who had the
means to create their own processors established ad hoc mechanisms for
extensibility that locked in a given implementation. With the advent of a
formal extensibility mechanism in XPath2, project implementors could in fact
build extension libraries that utilized common interfaces but different
implementations of those interfaces, as was done with EXSLT, and more
recently is the subject of considerable success in building standardized
libraries for added functionality.

To me, HTML5 is taking a head in the sand approach towards extensibility -
by denying that it is in fact an issue, the assumption seems to be that
people will not in fact be interested in extending the language. Take a look
at projects such as Apache, Mozilla, Drupal, even Chrome, to see where that
assumption is routinely violated. Despite the intent of the HTML5 working
group, people WILL attempt to expand the language, and will do so in a way
that likely decreases the semantics of the core language, increases the
potential for security violations because of the need to be reliant upon
JavaScript, and, if anything, pushes people towards XHTML5 because such
extensibility IS possible in that context.

Provide an extensibility hook - something that standardizes the way that the
language is extended. XBL (2 or 2a) is obviously one way to do so, but even
there this should be something that is seen as a core characteristic of
HTML5, not a side-note. The webmasters will thank you for it, the code you
create will retain all of the benefits of declarative markup while still
enabling behavioral extensions, and it provides a mechanism for
experimentation that may result in new functionality when we get to HTML6 in
2020.

Kurt Cagle
W3C Web Forms Working Group Invited expert
Received on Sunday, 2 January 2011 20:42:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 2 January 2011 20:42:07 GMT