On Mon, Apr 28, 2008 at 9:40 AM, Ian Bicking <[EMAIL PROTECTED]> wrote: > > Michael van Tellingen wrote: > > 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 />).
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 <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en -~----------~----~----~----~------~----~------~--~---
