HTML 5
Suno Ano
any information on HTML 5. I found
http://github.com/rhec/django-html5 though. Can anybody tell me
if there are any plans with regards to HTML 5 in Django and if
so, what are they?
Things like the <video> feature [0] would we great to have even
if HTML 5 isn't done yet.
Jonas Obrist
template stuff and can already be done with django.
Suno Ano
Jonas> purely template stuff and can already be done with django.
Sure, let me rephrase, any plans on template tags or filters to for
example make use of the <video> feature? Or any other HTML 5 goodness
[0] for that matter?
Jonas Obrist
> Sure, let me rephrase, any plans on template tags or filters to for
> example make use of the <video> feature? Or any other HTML 5 goodness
> [0] for that matter?
>
> [0] http://diveintohtml5.org/detect.html
>
>
I'd like to see using the new input types (eg <input type="email"> for
email form fields). Since this doesn't break any backwards compatibility
it shouldn't hurt to include this.
<audio> and <video> are something for the templates though in my
opinion. I don't see how or why django should add this.
Florian Apolloner
> email form fields). Since this doesn't break any backwards compatibility
> it shouldn't hurt to include this.
valid html/xhtml will stop beeing valid; eg this document doesn't
validate without a html 5 doctype:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
<title>Test</title>
</head>
<body>
<form action="." method="post">
<div>
<input type="email">
</div>
</form>
</body>
</html>
Russell Keith-Magee
> I've looked at the users and devel mailing list but didn't find
> any information on HTML 5. I found
> http://github.com/rhec/django-html5 though. Can anybody tell me
> if there are any plans with regards to HTML 5 in Django and if
> so, what are they?
We don't currently have any plans, other than "Yes, we need to do
something about that". There were some initial discussions during the
1.2 development phase, but they didn't result in any concrete
decisions.
> Things like the <video> feature [0] would we great to have even
> if HTML 5 isn't done yet.
This isn't really in scope for what Django needs to handle. Django is
a server-side framework with a templating framework for producing
client-side content. If you want to use a <video> tag, then you put
one in your template.
When Django makes a move with regards to HTML4/XHTML/HTML5, we will be
addressing content types, tag closing (i.e., </input> or <input />,
depending on the content type), and the new family of input elements
that are available (e.g., using type="email" if it is available).
Yours,
Russ Magee %-)
Suno Ano
Russell> do something about that". There were some initial discussions
Russell> during the 1.2 development phase, but they didn't result in
Russell> any concrete decisions.
I see, I have not been aware any such discussion took place plus,
searching through the mail archives, issue tracker and wiki, there had
also been no sign of any such discussions/work in this regard. I just
wanted to know the status on HTML 5 which I now do.
>> Things like the <video> feature [0] would we great to have even if
>> HTML 5 isn't done yet.
Russell> This isn't really in scope for what Django needs to handle.
Russell> Django is a server-side framework with a templating framework
Russell> for producing client-side content. If you want to use a
Russell> <video> tag, then you put one in your template.
I agree, <video> was not a good example from to ask for,
http://diveintohtml5.org/detect.html#input-types would certainly makes
more sense.
Russell> When Django makes a move with regards to HTML4/XHTML/HTML5, we
Russell> will be addressing content types, tag closing (i.e., </input>
Russell> or <input />, depending on the content type), and the new
Russell> family of input elements that are available (e.g., using
Russell> type="email" if it is available).
Sure, maybe this thread might lead to some of that already :-)
Karen Tracey
I see, I have not been aware any such discussion took place plus,
searching through the mail archives, issue tracker and wiki, there had
also been no sign of any such discussions/work in this regard. I just
wanted to know the status on HTML 5 which I now do.
There have been discussions on this mailing list before. See for example:
http://groups.google.com/group/django-developers/browse_thread/thread/bbf75f0eeaf9fa64
(You probably want to search on things broader than just HTML5. That one I found searching in the Google groups interface on XHTML, since I recalled previous discussions of better support for HTML4/5 that also mentioned the current built-in bias towards outputting XHTML.)
Karen
Luke Plant
> Russell> We don't currently have any plans, other than "Yes, we
> need to Russell> do something about that". There were some initial
> discussions Russell> during the 1.2 development phase, but they
> didn't result in Russell> any concrete decisions.
>
> I see, I have not been aware any such discussion took place plus,
> searching through the mail archives, issue tracker and wiki, there
> had also been no sign of any such discussions/work in this regard.
> I just wanted to know the status on HTML 5 which I now do.
There was this ticket - not much of a discussion, but I think I was
reflecting the general consensus at that point:
http://code.djangoproject.com/ticket/12488
It does come up if you search the tracker for HTML5, as do various
other tickets and pages.
Luke
--
"Trouble: Luck can't last a lifetime, unless you die young."
(despair.com)
Luke Plant || http://lukeplant.me.uk/
Luke Plant
Here are my current thoughts on that issue - in a slightly overstated
tone... :-)
== XHTML as text/html is just fine ==
I happen to agree with Simon Willison's post a while back that said
that XHTML has 'lost', and HTML4 is a better option for new projects.
However, I contend that:
Django's behaviour (outputting XHTML) combined with the normal usage
(serving as text/html) isn't causing anyone *any* real problems. Loads
of people are doing it, and browsers handle it just fine.
(I have read and re-read Hickson's article [1], and can't find any
real problems that affect us. You only have problems if you try to
switch to application/xhtml+xml, which is easy to solve: don't do
that).
Of course, I'm discounting as 'problems' things like personal
preferences and clients who insist on both HTML4 and valid documents.
In practice, the choice between HTML4 and 'XHTML as text/html' makes
no real difference to end users. It's just a holy war for developers,
and developers' tools.
Simon brought up that it makes us look out of date, and I agree, but
so what? Switching back to HTML4 is driven by the same kind of
purity-beats-practicality, fashion-conscious silliness that made us
all switch to XHTML in the first place. (As a matter of interest,
www.bbc.co.uk uses XHTML, and after trying to validate a dozen major
sites that I visit regularly, it happens to be the only one that
validates. That probably says something - while the switch to XHTML
may have been misguided in the first place, those who did so had high
ideals and actually cared about validation, and so wrote their tools
and systems accordingly. You are more likely to be able to generate a
valid web page if you depend on an XHTML stack).
On the other hand, if we were outputting HTML4, it might cause
*genuine* problems - e.g. if you need XHTML in order to mix in MathML
or SVG on some pages.
In short: XHTML is not entirely pointless for some use cases, but
there is definitely something much more pointless: switching perfectly
functioning XHTML code to HTML4 just because the web fashion gurus say
so. I've already wasted enough of my life doing things like that.
== Multiple output formats is hard and nasty ==
The fundamental problem here is the need to output in multiple markup
languages. (The fact that HTML4 and XHTML are so similar doesn't
actually help us - we have to recognise that they are different
languages. The only attempts so far to produce code that outputs both
have been as ugly as sin, IMHO). However, Django simply does not work
at the level of abstraction that would allow multiple output
languages. We encourage the use of templates where developers must
write raw XHTML. We have gobs of internal code that builds up XHTML
as strings. This means that the design of *everything* in our output
is oriented to a *single* markup language, and that language is XHTML.
We have never attempted to be markup agnostic.
Changing that assumption in an elegant way would require changing
*everything* to use a markup agnostic output tree, which you would
then render with different 'writers'. (I'm thinking something like
the way Pandoc and docutils work). We would basically be throwing
away the entire template system and all templates, and much more
besides.
Every other attempt to fix this is just patching up lots of different
symptoms, and it gets ugly very quick, both for us and for Django
developers.
In turn, that solution would mean that re-usable apps would end up
choosing either HTML4 or XHTML, because writing code that supports
both would be so painful. (If we have trouble convincing designers to
write "<br />" instead of "<br>", what chance do we stand with "<br {%
selfclosing %}>" ?) Supporting multiple doctypes will produce a Babel
situation. We *have* to pick a common language if we want the re-
usable app market to thrive, and we have already done so - it's XHTML.
As well as templates, there are many other bits of code that hard-code
XHTML problems, such as various plain text to HTML formatters, both
inside and outside the Django code base. This even includes Django
dependencies - docutils outputs XHTML, and there doesn't seem to be a
way to output HTML4, short of writing our own 'writer'.
I have several bits of code that would require a lot of work to make
them output HTML as well as XHTML, and would require coupling to the
template system or something equally nasty.
In fact, one bit of code is impossible to fix - it is related to a
text editor in django-cms, and outputs XHTML when the data is saved.
To be able to fix it, I need to know what doctype the HTML will
eventually end up in, which is impossible.
The only fix for stored, user provided HTML is to run it all through a
template filter that rewrites content according to the doctype, which
is obviously a big performance hit. This is just highlighting another
reason why you cannot simply switch between these two formats, and we
shouldn't pretend that you can.
Does anyone know of any framework that works on the same level of
abstraction as Django (i.e. with developers writing raw HTML) and has
a nice solution to this problem? If not, I'd suggest that we are
chasing a fantasy. Even if we get it 90% of the way there, we're still
going to have loads of complaints about the 10% -- which is fair
enough - if you care about validity, "90% validity" counts for exactly
nothing. And we will also inflict the pain of
fragmentation/complaints on the authors of third-party apps.
== HTML5 will save us anyway ==
Finally, once HTML5 becomes established, the problem goes away. All
our output is HTML5 compliant (you can use both XHTML and HTML style
tags in HTML5). The HTML5 spec has acknowledged that having two
subtly different and incompatible formats is a bad idea, and has
basically said "Let's just redefine both flavours as HTML and be
done."
== Conclusion ==
We should just ignore this whole issue for now, and simply switch to
HTML5 doctypes in our provided templates at some point. That's
basically what Ian Hickson suggests in his updated article.
From then on, things get much better, because backwards compatibility
rules are well-defined.
If people complain, wanting HTML4, tell them:
- Tough. Django produces XHTML. What real world problem are you
trying to solve by using HTML4? If it's just a case of some
internal standard, then point out that the de-facto standard for
Django apps is XHTML, and you gain a lot by fitting in with that
standard. All our libraries also output XHTML (e.g. docutils)
- OR - live with invalid documents. Almost every single major
website out there does so, and no-one notices. (Seriously, outside
of your own websites and w3.org, how many valid HTML pages can you
find?)
I'm saying this as the guy who wrote a Django middleware/app that
validates all outgoing HTML - an app I still use it. Some spot checks
on various sites of mine indicate that I'm doing better than 99.99% of
the web, in that I rarely have any invalid documents.
But to worry about being able to instantly switch to the doctype-du-
jour -- or rather *last years'* doctype-du-jour -- *as well* as having
HTML validity - that's not being a perfectionist, it's called OCD, and
I'm drawing the line there.
Regards,
Luke
[1] http://hixie.ch/advocacy/xhtml
Joshua Russo
Leo Soto M.
[...]
>
> Changing that assumption in an elegant way would require changing
> *everything* to use a markup agnostic output tree, which you would
> then render with different 'writers'. (I'm thinking something like
> the way Pandoc and docutils work).
If anyone wants to play with that idea, I suggest to look at the HAML
syntax: <http://haml-lang.com/tutorial.html>. The way it uses
indentation for closing tags (just like Python) and CSS syntax for
making it concise is very clever.
Just saying...
--
Leo Soto M.
http://blog.leosoto.com
Luke Plant
Another possibility is the way that Genshi does it. You write an XML
template, and have the choice to render XML style or HTML style.
Presumably this isn't an (easy) option for us though, because we don't
have an XML based templating system. For us to do the same just
amounts to post-processing.
Luke
--
"In your presence there is fullness of joy; at your right hand are
pleasures forevermore" Psalm 16:11
Luke Plant || http://lukeplant.me.uk/