- From: Kurt Cagle <kurt.cagle@gmail.com>
- Date: Sun, 2 Jan 2011 15:41:03 -0500
- 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
- Message-ID: <AANLkTimUGihjPLmvaQ_GGeNDKQpnDr=Hqvpr3vKkCQzp@mail.gmail.com>
> > 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 UTC