On Mon, Feb 1, 2010 at 1:00 PM, Luke Plant <l.plant...@cantab.net> wrote:
> > When Django makes a move with regards to HTML4/XHTML/HTML5...
>
> 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
>
>
> --
> "Trouble: Luck can't last a lifetime, unless you die young."
> (despair.com)
>
> Luke Plant || http://lukeplant.me.uk/
>
I don't think anybody could put it any plainer than that.
Thanks Luke.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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.
