Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Webhelpers doctype
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Mike Orr  
View profile  
 More options Apr 28 2008, 7:16 pm
From: "Mike Orr" <sluggos...@gmail.com>
Date: Mon, 28 Apr 2008 16:16:47 -0700
Local: Mon, Apr 28 2008 7:16 pm
Subject: Re: Webhelpers doctype

On Mon, Apr 28, 2008 at 9:40 AM, Ian Bicking <i...@colorstudy.com> 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 <sluggos...@gmail.com>


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.