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

On Dec 21, 2007 11:51 PM, Ben Boyle <benjamins.boyle@gmail.com> wrote:

> On Dec 21, 2007 10:36 PM, Preston L. Bannister <preston@bannister.us>
> wrote:
> > 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.
>
> An interesting point, but I think this is highly dependent on whether
> you are publishing information primarily for browsers. Personally I
> like a combination of atom and html, both generated from a single
> source of data (for which I prefer XML). HTML is for the browsers,
> atom for feed readers and other (potential) consumers/aggregators. I
> use XHTML within Atom (personal preference to avoid CDATA where I
> can).
>


Hmm - yes, I agree.  The web-fragment embedded in XML (of which Atom is an
excellent example) does indeed call for an XML representation of HTML. You
could get by with CDATA but ... this strikes me as inelegant and less
versatile.

We need to be a shade careful about calling this XHTML.  This use-case calls
for a (large) subset of HTML, but it is not necessary - and probably not
desirable - to have full HTML represented.  Seems I've seem a few examples
in recent months exploring what should be left out (from Sam Ruby?).  The
term XHTML means a lot more to some folk than is called for by this
use-case.



> I do agree: "the advantage to XHTML lies in server-side XML-based
> processing pipelines"
>
> I don't specifically need browsers to support XHTML - I certainly
> don't need the specification to mandate any compliance. When I stop to
> think about it, browser support for XML+XSLT (including HTML output)
> would be more valuable (to me) than XHTML support. One day, if/when it
> is well established in UAs and AT. Until then, it seems beyond the
> scope of this WG but an interesting topic ~:)
>


Yes, the use of XML+XSLT in the browser is interesting, and once shipped a
feature to customers that made heavy use of XSLT.  On the other hand, I
suspect that in future the data going across the wire is more likely to JSON
- not XML - and future solutions are more likely JSON+Javascript. JSON tends
to be leaner on the wire, and more readily useful in the browser. The number
of cases where XML+XSLT proves suitable is probably shrinking.

The above is largely outside the scope of this working group, aside for
establishing the irrelevance of XML.  :)