On Sep 26, 6:50 am, Jerome Leclanche <adys...@gmail.com> wrote:
> This is a non-issue.
<personal opinions follow>
Obviously I disagree - this is a tiny thing that has bugged me ever
since newforms. It's also something I find myself constantly
apologising to front-end developers about, who for the most part love
the Django template language.
After 9 years In the marketplace, I think XHTML has pretty much lost.
It turns out that XML serialisations of HTML aren't nearly as useful
as people thought they would be (running an XML parser against the web
won't get you anywhere fast, and there are plenty of excellent HTML
parsing libraries now), and strict XML error handling is completely
unsuitable for the practical considerations of the web. HTML 5 is the
final nail in the coffin - the refocusing of the W3C on that over
XHTML 2 is an acknowledgement that XML is no longer the future of the
Web. I actually think Django's XHTML output makes us look a bit out of
date.
> Correct me if I'm wrong, but <br /> is valid html syntax. It's parsed
> as valid by every html parser, and I'm positive this is the entire
> point of xhtml: staying backwards-compatible with html.
If you want backwards compatibility you need HTML 5, not XHTML.
HTML 5 is backwards compatible - it even goes as far as specifying the
error handling routines that browsers should take when faced with
invalid code (routines that have been reverse-engineered from existing
browsers) and properly specifying all of the APIs that browsers
support but were never actually part of a specification, such as
XMLHttpRequest and innerHTML.
XHTML 1.0 is kind-of backwards compatible, but it's a bit of a fudge.
It's really meant as a transitional stage between HTML 4 and the
stricter XHTML 1.1. As an example of a fudge, the <br /> self-closing
tags actually mean something different in SGML (HTML's parent
language) - they're a short-hand feature called Null End Tags which
should technically result in extra > signs appearing in the text, but
thankfully no browser actually supports enough of SGML for that to be
a problem.
The moment you start serving XHTML with the correct content-type
(application/xml+html) all sorts of nasty things happen - in addition
to strict error handling the way the JavaScript DOM works
fundamentally changes - document.getElementsByTagName becomes
getElementsByTagNameNS for example.
XHTML 1.1 backwards incompatible - the spec forbids the use of the
text/html content-type and insists on application/xhtml+xml or
application/xml, which breaks completely in IE and causes other
browsers to use strict error handling (which you really, really don't
want).
XHTML 2.0 was completely backwards incompatible (tags were removed,
new incompatible tags added), a major factor in the W3C ending
official work on it.
> That said, I'm not against a {% doctype %} tag or anything. However, I
> do think having an xhtml default is a Good Thing due to its backwards
> compatibility.
I see XHTML as a dead end, so I'd personally prefer to switch to an
HTML 5 default - but the {% doctype %} thing makes switching to HTML 5
painless enough that I wouldn't mind the existing XHTML behaviour
remaining as the default (purely to avoid causing issues with existing
applications).
> I'm also not entirely fond of the idea of having 100
> different language outputs in Django. Why stop only after xhtml and
> html?
Because Django is a Web framework, and XHTML and HTML are the key web
languages. I don't think we need to worry about support for those two
leading to a slippery slope.
Cheers,
Simon
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
