[Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[Jeremy Shaw]

On Sat, Sep 4, 2010 at 12:19 PM, David Menendez <dave at zednenem.com> wrote:
> HTML and XHTML are not encodings of anything. They are markup
> languages defined using SGML and the XML subset of SGML. There are
> multiple HTML definitions of varying popularity, and the fact that we
> can pass some XHTML documents to a web browser expecting HTML and get
> acceptable results is consistent with the fact that we can pass HTML
> 3.0 (never implemented by any popular browser) with minimal loss.

But what is the point? The w3c originally suggested serving xhtml as
text/html back in 2000
(http://www.w3.org/2000/01/xhtml-pressrelease.html.en), because they
believed that it would be an easy way for people to transition to
xhtml while the browsers caught up. Well, a decade later, ie still
doesn't support xhtml, so perhaps their recommendation should be
viewed in light of the fact that the web does not appear to be moving
to xhtml at any great speed.

Creating output that renders the same as both text/html and
application/xml is not a trivial task. For starters, the contents of
the <script> tag are treated as pcdata in html, and cdata in xhtml.
And it only gets worse from there...

So the choices are:

 1. only focus on getting the xhtml 1.0 served as application/xml
working correctly, and ie users get nothing..

 2. create xhtml 1.0 that would work correctly if served as
application/xml, but serve it as text/html, and ignore that fact that
some stuff might not be rendering correctly when treated as text/html.

 3. create xhtml documents which render correctly whether served as
application/xml or text/html, but then only serve them as text/html
anyway

 4. forget about how the xhtml documents render as application/xml,
and only focus on how they render as text/html.

Now, I think that options 1 and 2 are not even worth considering.

Option 4 seems silly. If you are going to create xhtml that does not
really work correctly when actually served as xhtml, then why create
xhtml in the first place. This is really just html masquerading as
xhtml. Why not actually create valid html and serve it as text/html,
instead of creating purposely broken html?

Option 3 requires extra work (and also means that you will never be
able to upgrade to xhtml 1.1 or xhtml 2.0). The idea of serving xhtml
1.0 as text/html was supposed to be a transitional measure. But if you
intend to do it forever.. that is not very transitional.

What benefit do you get by creating xhtml 1.0 that also happens to
render correctly as html ? What is the use case ? Seems that a vast
majority of the usage is going to be viewing the content in web
browsers. For that purpose, text/html seems superior, due to it being
supported in a much wider variety of browsers. No browser will
actually even try to render it as  xhtml since it is being served as
text/html.

It seems that the only advantage of xhtml served as text/html is that
it is easier to process the output. But, is anyone actually going to
do that? Haddock has been around for a long time.. has anyone had a
need to do that so far? And even then, is processing it via an xml
parser really better than using tagsoup ?

Mark suggested that it was easier to achieve multi-browser
compatibility using xhtml instead of html, but I am quite certain he
is mistaken. There are really three different rendering modes found in
browsers:

 1. standards mode
 2. quirks mode
 3. xhtml mode

By serving xhtml content as text/html, he is getting browsers to use
quirks mode instead of standards mode. That *can* sometimes lead to
better browser compatibility. He is never invoking the xhtml rendering
mode. If the aim is simply to trigger quirks mode, there is no need to
use xhtml to achieve that.

- jeremy