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

Re: HTML/XML Task Force Minutes 18 January 2011

From: Kurt Cagle <kurt.cagle@gmail.com>
Date: Fri, 21 Jan 2011 09:01:24 -0500
Message-ID: <AANLkTin+bYRFWmpMSje3nQ3L7aF0zN9QmwJiUxKndU=5@mail.gmail.com>
To: David Carlisle <davidc@nag.co.uk>
Cc: Michael Kay <mike@saxonica.com>, public-html-xml@w3.org
The announcement of support for XHTML in IE9 was one of the reasons I had
for cheering the new release - I've been trying to make the case to
Microsoft to support text/xhtml+xml since IE6.

There's an interesting implication to this, however. Overall, I think the
audience for XHTML capabilities is somewhat different than that for HTML.
The requirements on HTML is that it may end up being viewed on any number of
browsers, that it has a long legacy trail, and the writers of that HTML may
very well not be inclined towards precision of expression - the summary that
Robin made earlier I think points this out particularly well.

XHTML, on the other hand, IS far more likely to be produced as part of an
XML tool chain, more likely to be part of an enterprise level application,
and what's more is as likely to be input or interim content as it is to be
output. It's increasingly becoming the language of choice for web-based CMS
systems (think Drupal, which has at least a weak XHTML mandate). I work with
large governmental agencies (National Archives and Library of Congress)
where multiple heterogeneous namespaces may very well be in the same
document, and where in many cases XHTML is seen as being only one of four or
five formats (DITA is becoming a major factor in this space for instance,
which, while HTML-like, is not HTML; similarly I'm seeing TEI being used
increasingly outside of the academic domain, and specifications such as
DocBook and NLM factor significantly as well, especially with the LoC).

I think one of the bigger concerns that I have with the HTML5 effort is that
XHTML5 tends to be addressed as an afterthought, despite these very real
differences in usage, and that in the rush to encode HTML5 there may be a
spillover effect locking what can be done with XHTML5 as well to a much
poorer subset of overall usage. There is very little information that I've
seen surfaced about how browsers that support XHTML5 differ in their parsing
from the HTML5 model, though it's evident that there is a difference.

For that reason I'd propose that this may very well be yet another use case
in this discussion - understanding the differences in rendering, in
description (I'd expect XHTML to have a schema, for instance), and in
inherent flexibility compared to HTML. Given the WHATWG process in driving
this, it may very well behoove the W3C to set up an XHTML5 WG that would
work closely with the HTML5 effort but address the broader XML community
issues as well, especially as certain technologies which have little
relevance to the HTML5 group but may very well have significance to
 specialized communities (XForms comes to mind, but MusicML is a good, if
somewhat less contentious, example as well) are more likely to see
development along that XHTML5 arc.

Such a process may also resolve one of the bigger chicken and egg problems
that I see already becoming a concern. HTML5 is conservative - it seeks to
entrench within the specification those elements that have either proven
themselves (such as video) or resolve long standing issues (such as the drag
and drop API or other jQuery-esque constructs). XHTML5 is progressive - it
has a clear-cut extension mechanism, it encourages alternative namespaces,
in short, it encourages experimentation. This means that it is an ideal
test-bed for testing new ideas, and a place where those ideas can evolve and
mature. It's not as encumbered by a large base, but now that the major
browsers all support it, it makes building text/xhtml+xml and
application/xhtml+xml applications feasible for general distribution (the
<IE9 embargo on that mime type has made it a non-starter for most companies
until now, but I see that changing).

Anyway, just my two cents worth. I see XHTML5 as being too important to not
have some kind of activity associated with it at the W3C, beyond simply a
few paragraphs in the HTML5 spec.

Kurt Cagle
XML Architect
*Lockheed / US National Archives ERA Project*

On Fri, Jan 21, 2011 at 4:20 AM, David Carlisle <davidc@nag.co.uk> wrote:

> On 21/01/2011 08:26, Michael Kay wrote:
>> I've been wondering the same kind of thing. In fact I've been wondering
>> - why exactly would I choose to serialize my content as HTML5 rather
>> than XHTML(5?), given that it's not hand-authored?
> Typical reasons including needing (or wanting) to include some boiler plate
> code (embedding some advert banner or calendar widget or something) and that
> code assumes html, or needing to submit the document to be served via some
> content management system that is going to serve it as text/html whatever.
> It may be that the solution in both cases is not to change the specs at
> all, but simply(?) get the relevant software updated to support xhtml, but
> they are the main reasons I see at present, along with supporting IE<9,
> which again could have the same solution (update the browser to IE>=9).
> David
> ________________________________________________________________________
> The Numerical Algorithms Group Ltd is a company registered in England
> and Wales with company number 1249803. The registered office is:
> Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
> This e-mail has been scanned for all viruses by Star. The service is
> powered by MessageLabs.
> ________________________________________________________________________
Received on Friday, 21 January 2011 14:02:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:27 UTC