It sounds like you want a template processor that works in terms of strings
or tag soup, instead of one that works in terms of XML. That's a totally
different beast than Kid.
I prefer Kid's XML oriented approach, because it's much easier and more
reliable to author and process templates in high-fidelity valid XML, using
modern XML tools, and let the serializer systematically deal with browser
compatibility problems, instead of scattering backwards compatibility
kludges and invalid XHTML throughout all my templates.
For example, it's valid for any XML tool to replace "<br />" with "<br/>",
or "<script></script>" with "<script/>", which will confuse some HTML
browsers. I would rather use real XML tools to write and transform valid XML
without worrying about stuff like that, and let the serializer perform those
backwards-compatibility transformations cleanly all in one place, instead of
meticulously editing invalid or quirky XML as text, without the benefit of
real XML tools.
If the Kid serializer is turning <script></script> into <script/>, then
that's a bug, which should be fixed. It's very easy to write your own
serializer, if there are any other HTML backwards compatibility quirks you
want to support. (Like the bizarre script and style commenting chevrons
mentioned in that xhtml article.)
Unfortunately (or fortunately for you if you really don't want to use XML),
there are many half-baked fly-by-night tag soup and regular expression based
template processors out there, which are totally incompatible with XML
tools. But in my opinion, fast-and-loose non-XML tag soup template
processors, like ASP, DTML and Smarty, cause many more problems than they
solve, make it difficult to support xhtml, and lock you into proprietary
non-XML tools (or simply aren't compatible with any tools at all, except
plain text editors).
-Don
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] On
Behalf Of Jeff Watkins
Sent: Thursday, December 29, 2005 10:47 AM
To: TurboGears
Subject: [TurboGears] Re: Combine TG and Subway?
I understand the difference between wire and infoset, but they're just
not relevant to me. If I write a document that contains:
<script src="..."></script>
I don't want my template processor to change that to:
<script src="..."/>
While I'm well aware that both forms are legal XHTML and are basically
the same, one works in all browsers and one doesn't.
So suggesting that I change the kid.outputformat to xhtml-strict
doesn't change the fact that KID will change my file for no good reason
and will therefore make it *not* work with all browsers. Whereas it
would have worked prior to processing (exempting the processing stuff).
Thanks for suggesting Hickson's article. I've read it, and while I
appreciate his concerns and look forward to the day when UAs actually
support XHTML instead of HTML4 with clever hacks, I don't need to make
a stand and refuse to publish anything as XHTML until they do. I'll
leave the ideology of the issue for others to worry about.
I actually agree with Kevin: it's a nice feature that Kid is able to
translate from XHTML to HTML4. It's just not a feature that I'm
interested in using. And naturally I expect a template processor to
modify the parts of my file that require processing -- that's what they
do. I just don't like it when it changes the parts that *don't* require
processing.
(Apparently, either Google is not delivering messages from this list or
my mail server is ignoring them. So if there are other messages which
are waiting for a response from me, I'll try to get to them as I can.)
