Webhelpers doctype
Michael van Tellingen
I was looking at the modeltags feature in the new webhelpers. Unfortunately it only renders tags in XHTML mode. Since I prefer not to use that (see http://webkit.org/blog/68/understanding-html-xml-and-xhtml/) i've added a flag to the webhelpers.html.HTMLBuilder to render it as HTML.
I'm not entirely happy with how I did it, but it does work. Perhaps the cleanest way is to subclass the HTMLBuilder in an XHTMLBuilder which renders the tags as xhtml tags and an HTML(4)Builder which renders the tags as html 4 strict tags.
Regards,
Michael van Tellingen (mvt)
Ian Bicking
> Hi there,
>
> I was looking at the modeltags feature in the new webhelpers.
> Unfortunately it only renders tags in XHTML mode. Since I prefer not to
> use that (see
> http://webkit.org/blog/68/understanding-html-xml-and-xhtml/) i've added
> a flag to the webhelpers.html.HTMLBuilder to render it as HTML.
We decided this was the easiest way as the code produced is both valid
HTML and XHTML. It produces warnings when validated as HTML, but no
errors, and I don't think any clients have problems with it when parsing
it as HTML.
Specifically, all empty tags (br, input, etc) get a trailing />, making
them valid XHTML. All other tags always have open and close tags, which
are equivalent in HTML and XHTML (i.e., it never produces <script />).
--
Ian Bicking : ia...@colorstudy.com : http://blog.ianbicking.org
Mike Orr
The problem of two formats cascades through the simplest helpers to
the complex functions that depend on them. Do you pass an argument
through all of them to choose the output style? How do you know
whether your arguments are HTML or XHTML? It's the same problem
caused by the str/unicode split in Python: the dilemma cascades up to
every function that uses strings. Are my arguments str or unicode or
mixed? Should that affect my output, or should I just ignore the
problem? If I ignore it my users will get UnicodeDecodeError or
UnicodeEncodeError whenever a string contains non-ASCII characters.
It gets worse if you have a Unicode subclass, as
WebHelpers/Genshi/Quixote do to implement start HTML escaping. It
works great if your arguments are Unicode, but what if they're str and
contain non-ASCII characters? This came up last week when
redirect_to() blew up because url_for() was returning a literal, which
it shouldn't have. (Literal is a Unicode subclass, but redirect_to()
can't accept Unicode.)
If you want a choice of well-formed HTML or well-formed XHTML, use
Genshi. It does this natively.
From one of the talkbacks in the article:
"""
I've argued with Anne, Faruk and other webheads on this topic often
enough. The problem is that at one time the "guru's", I use the term
loosely, compelled us to use XHTML and now we're back to HTML.
Somebody make there mind up! The fact is, and this post actually
suggests this already, is that it doesn't really matter that much.
Just as long you make an informed choice. Writing XHTML is fine just
be aware of the pitfalls.
"""
That's the situation we're left with. Write XHTML but serve it as
text/html. Then when XHTML or HTML 5 get implemented in all browsers,
we can simply switch the default doctype and avoid reformatting our
templates. I really wish HTML 5 would just be implemented now, both
so it can blow XHTML away and also because it provides standard
calendar tags and navigation tags, which will eliminate some of the
need for custom Javascript.
I also feel kind of deceived that the XHTML mantra said it would lead
to a brave new world but instead it has fallen flat. I started
reformatting my <br /> as <br> to be valid but ended up switching them
back on the off-chance it'll avoid reformatting work someday.
In the meantime, the main rule for serving XHTML as HTML is, as Ian
alluded to above: use the minimized syntax only on tags that can never
carry content: <br /> <img />. But if the tag can carry content,
use the non-minimized form: <script></script>. Otherwise browsers
will think it's still open and they'll misinterpret the following
HTML, often with spectacularly bad results.
--
Mike Orr <slugg...@gmail.com>