Re: supporting both formats html5 & xhtml5 re: http://www.w3.org/html/wg/html5/#xhtml5

On Dec 20, 2007 7:30 PM, Dean Edridge <dean@55.co.nz> wrote:

> Preston L. Bannister wrote:
> > On Dec 19, 2007 3:36 AM, Dean Edridge <dean@55.co.nz
> > <mailto:dean@55.co.nz>> wrote:
> >
> >     /[snip]/
> >     I don't think that support for XHTML5 should be optional. Specifying
> >     that user-agents may support only one format, but supporting both is
> >     "encouraged" is insufficient and will only lead to a lack of
> >     support for
> >     XHTML5 like we had with XHTML1 [1]
> >
> >     We've been down this road before where support for
> >     application/xhtml+xml
> >     was only an "opt in" for user-agents. That's the main reason we have
> >     less than 100 valid XHTML websites today. [2]
> >     People wont be able to use XHTML5 if there's no support for it.
>


> > This could also be taken as a clue - that XHTML on the web may not be
> > very relevant.
>
> That's a very bold suggestion to make. You obviously think you know all
> the possible uses of the web from now until eternity.



I'm suggesting that you don't. Millions of people use XML everyday. Do
> you really feel comfortable telling those people that they can't use
> those technologies on the web too?



Millions of people use web pages - not HTML or XHTML.  In the browser XHTML
offers no advantage over HTML.

In *eternity* my original background in Physics is more relevant than
software :).  In software, yes, I do spend a fair amount of time predicting
the future - at least in general outline, in very specific domains.  To a
fair extent the future is indeed predictable, and I've done moderately well
at such predictions.



> I don't think that you know what the benefits are... that's why it's
> better to keep a open mind and give people more options for the future.
>


The advantage to XHTML lies in server-side XML-based processing pipelines,
not in the browser.  Once you come to that realization, then you have to ask
whether a server-side rendering to HTML is in fact the *more* optimal
choice.


> Generally, having two ways of doing the same thing usually is cause of
> > wasted effort.  We need HTML to be well-defined and well-implemented.
> > We do not really /need/ XHTML on the web,
>
> How would you know this? Can you see what the world will need in the
> future?
>


Yep.  Some predictions are not hard - at least in this *very* specific
domain.  We have lots of experience in the field of software, and some
predictions based on out past collective experience are easy.  We need a
well-defined and well-supported lowest-level language for communicating the
structure of a web page from a server to the browser.  HTML is that
representation.  We do not need more than one.



> > and we do not need the HTML specification to /require/ XHTML.
>
> Yes we do. It's not a HTML specification anyway. It's a HTML and XHTML
> specification. This is why the spec should never have been called HTML5.
>


Yes.  Clearly we disagree.

HTML5 is - I hope - meant to be the sum of our collective experience for the
use and implementation of the representation of web pages in support of web
applications.  Clearly an HTML5 document could be serialized as XHTML.
Whether there is significant value in teaching each and every *browser* to
parse and serialize XHTML is ... at least dubious.

Based on my own experience, and after listening to the the html@w3c group
many months, my conclusion is that XML as the representation for HTML in the
browser, is a notion that has no value.  (Admittedly as a strong believer in
*strict* and *rigorous* as a practice I was indeed seduced for a time by
XHTML.)  In fact I suspect that mention of XML/XHTML could be entirely
excised from from the HTML5 specification.