Altova Mailing List Archives


[xml-dev] Has HTML5 saved XHTML?

From: Jesper Tverskov <jesper.tverskov@-----.--->
To: xml-dev@-----.---.---
Date: 8/21/2011 10:48:00 AM
Has HTML5 saved XHTML?

1.
XHTML is probably the biggest failure of W3C. XHTML 1.0 was a
reformulation of HTML as XML. The idea was that HTML was dead or at
least deprecated, and that XHTML was the future bringing XML and
Draconian error handling to the web.

2.
XHTML 1.0 was a bridge from old world to new world. According to the
spec, we were allowed to serve XHTML 1.0 as "text/html". XHTML 1.1,
only to be served with mime-type "application/xhtml+xml", was the
final bridge to the brave new world of XHTML 2.0. No more HTML.

3.
XHTML 2.0 never made it to standard. No XHTML 2.0 feature worth
talking about ever made it to be implemented in a major browser. For
almost 10 years XHTML blocked the development of the web with its too
ambitious or badly implemented plans with no following: Too strict for
a world that seldom use validation, too little backward compatible,
too few new features.

4.
No web designer except in the margins ever served XHTML 1.0 or 1.1
with mimetype "application/xhtml+xml" (I did). Even XHTML 1.0, on the
surface implemented by millions, served with "text/html", was seldom
well-formed and far less valid. Actually it was most often completely
broken Tag Soup. The truth is that the original nice XHTML intentions
are as close to a complete disaster than you can ever get.

5.
Who has the courage to add XHTML to the list of failed specs in the
Wikipedia article about XML?  And likewise to update the article about
XHTML to what we know now?

6.
In comes the HTML5 initiative waking the death. Not HTML but the
original XHTML pipe dream was the one to die. The perspective is now
that XHTML 1.0/1.1/2.0 is a dead end. Many HTML5 advocates don't give
a damn about XHTML5. They only pay lip service to it. Sugar coating to
make it easier for some to swallow that HTML again rules the waves
even in the spec.

7.
The perspective is not that HTML5 is deprecated in the long run and
that XHTML5 will take over one day. The perspective is rather, that we
finish off even the lip service about the XHTML5 track next time
around. Who cares, no one is using it.

8.
But has HTML5 in a sense rescued XHTML? HTML5 uses the XHTML
namespace. XHTML is now allowed as a subset of HTML5. We only need a
schema that can validate the XHTML subset of HTML5 and we, the XML
community, are probably better off than before. HTML5 supports XHTML
as a subset of HTML5 parsed with HTML parser much better than the old
XHTML 1.0 "text/html" hack.

9.
We also have XHTML5 and polyglot XHTML5. We only need to start using
them (I do). IE9 finally supports "application/xhtml+xml". All major
browsers today use incremental rendering of XML webpages. Now under
the "HTML5" brand, it is much easier to use XHTML and the web is on
the move again, still young and exciting.

Cheers
Jesper Tverskov
http://www.xmlplease.com

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.