[ANN] Genshi 0.3.2 released

8 views
Skip to first unread message

Christopher Lenz

unread,
Oct 12, 2006, 9:29:18 AM10/12/06
to gen...@googlegroups.com
Genshi 0.3.2 - October 12, 2006
===============================

We're proud to present the latest release of the Genshi: 0.3.2.

Genshi is a Python library that provides an integrated set of
components for parsing, generating, and processing HTML, XML or
other textual content for output generation on the web. The major
feature is a template language, which is heavily inspired by Kid.

You can download the new release here:

<http://genshi.edgewall.org/wiki/Download>

Please don't hesitate to report any issues you may find with this
release:

<http://genshi.edgewall.org/newticket>

For questions, comments and user discussions, please use the Genshi
mailing list:

<http://genshi.edgewall.org/wiki/MailingList>


What's New:
-----------
* Exceptions from templates now contain the absolute path to the
template file when a search path is used. This enables tracebacks
to display the line in question.
* The template engine plugin now provides three different types:
"genshi" and "genshi-markup" map to markup templates, while
"genshi-text" maps to text templates.
* Fixed the namespace context used by XPath patterns in py:match
templates. The were erroneously using the namespace context of
the elements being matched, where they should rather use the
context in which they were defined.
* The contents of `<script>` and `<style>` elements are no longer
escaped when serializing to HTML but declaring the XHTML
namespace in the template.
* Improved error message raised when using the `py:for` directive
on an object that is not iterable (ticket #60).
* Fixed the XPath function `starts-with()` which was always
returning true (ticket #61).


Acknowledgments
----------------
A big thank you to everyone who tried Genshi and provided feedback,
reported bugs and/or contributed patches!

Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/

Graham Higgins

unread,
Oct 12, 2006, 2:52:34 PM10/12/06
to gen...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 12 Oct 2006, at 14:29, Christopher Lenz wrote:

> Please don't hesitate to report any issues you may find with this
> release:

Hi Chris,

Thanks for all the hard work, I'm finding Genshi's error reporting a
big improvement over Kid. I switched my TG project over to (markup,
originally) several weeks ago.

I just easy_install -U genshi on a developing project and am seeing
the following error message on previously-okay templates:

'pop(): dictionary is empty' <bound method ...

Did I miss some upgrade destructions?

Cheers,

Graham.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iQCVAgUBRS6O81nrWVZ7aXD1AQI82AP/d8QakMgWXkFUG17RyoDcBowR4ylCdZN0
mp+xon5fTtCRj+3AKfOAPvyvNC5ahglRRGM0HshS1FsaEoSHpKMv8bXT0nl4/O6/
WH4Z+XKL/4ouCWMUqrCd1h9ATP/DqL/dlXCup/NyScmx6389iTJ24JhlXQH9td3j
kYUy/pRqF2I=
=o37N
-----END PGP SIGNATURE-----

Christopher Lenz

unread,
Oct 12, 2006, 2:57:46 PM10/12/06
to gen...@googlegroups.com
Hi Graham,

Am 12.10.2006 um 20:52 schrieb Graham Higgins:
> I just easy_install -U genshi on a developing project and am seeing
> the following error message on previously-okay templates:
>
> 'pop(): dictionary is empty' <bound method ...
>
> Did I miss some upgrade destructions?

I don't think any changes should be necessary, but of course the
devil always hides in the details. :-P

Can you post the complete stack trace for that error?

Graham Higgins

unread,
Oct 12, 2006, 5:04:06 PM10/12/06
to gen...@googlegroups.com

On 12 Oct 2006, at 19:57, Christopher Lenz wrote:

> I don't think any changes should be necessary, but of course the
> devil always hides in the details. :-P
>
> Can you post the complete stack trace for that error?

A caveat, this may be nothing to do with Genshi at all. I'd forgotten
that I was running the 0.4dev svn code, so lord knows what
easy_installing the 0.3.2 release actually did, I'm afraid I didn't
pay much attention. Anyway: in order to check, I cleared out the
0.4dev code and easy_installed the 0.3.2 code --- with the same
problem. I then deleted the 0.3.2 code, svn up'd to the 0.4dev code
and again, same problem.

I'm using the expanded TG trace and it seems it is my macros.html
template is generating this error.

URL: http://ono.bel-epa.com:8085/
File '/Library/Frameworks/Python.framework/Versions/MacPython2.4/lib/
python2.4/site-packages/Paste-0.9.8dev_r5670-py2.4.egg/paste/
evalexception/middleware.py', line 293 in respond
return_iter = list(app_iter)
File '/Library/Frameworks/Python.framework/Versions/MacPython2.4/lib/
python2.4/site-packages/CherryPy-2.2.1-py2.4.egg/cherrypy/
_cpwsgi.py', line 75 in wsgiApp
environ['wsgi.input'])
File '/Library/Frameworks/Python.framework/Versions/MacPython2.4/lib/
python2.4/site-packages/CherryPy-2.2.1-py2.4.egg/cherrypy/
_cphttptools.py', line 72 in run
self._run()
File '/Library/Frameworks/Python.framework/Versions/MacPython2.4/lib/
python2.4/site-packages/CherryPy-2.2.1-py2.4.egg/cherrypy/
_cphttptools.py', line 105 in _run
self.main()
File '/Library/Frameworks/Python.framework/Versions/MacPython2.4/lib/
python2.4/site-packages/CherryPy-2.2.1-py2.4.egg/cherrypy/
_cphttptools.py', line 254 in main
body = page_handler(*virtual_path, **self.params)
File '<string>', line 3 in index
File '/Users/httpd/GrayWork/Python/TurboGears1.0/turbogears/
turbogears/controllers.py', line 276 in expose
output = database.run_with_transaction(
File '<string>', line 5 in run_with_transaction
File '/Users/httpd/GrayWork/Python/TurboGears1.0/turbogears/
turbogears/database.py', line 246 in so_rwt
retval = func(*args, **kw)
File '<string>', line 5 in _expose
File '/Users/httpd/GrayWork/Python/TurboGears1.0/turbogears/
turbogears/controllers.py', line 293 in <lambda>
mapping, fragment, args, kw)))
File '/Users/httpd/GrayWork/Python/TurboGears1.0/turbogears/
turbogears/controllers.py', line 330 in _execute_func
return _process_output(output, template, format, content_type,
mapping, fragment)
File '/Users/httpd/GrayWork/Python/TurboGears1.0/turbogears/
turbogears/controllers.py', line 73 in _process_output
mapping=mapping, content_type=content_type,fragment=fragment)
File '/Users/httpd/GrayWork/Python/TurboGears1.0/turbogears/
turbogears/view/base.py', line 126 in render
return turbogears.util.adapt_call(engine.render, **dict(info=info,
format=format, fragment=fragment, template=template, mapping=mapping))
File '/Users/httpd/GrayWork/Python/TurboGears1.0/turbogears/
turbogears/util.py', line 163 in adapt_call
return func(*args, **kw)
File 'build/bdist.darwin-8.7.0-Power_Macintosh/egg/genshi/plugin.py',
line 78 in render
File 'build/bdist.darwin-8.7.0-Power_Macintosh/egg/genshi/core.py',
line 146 in render
File 'build/bdist.darwin-8.7.0-Power_Macintosh/egg/genshi/output.py',
line 85 in __call__
File 'build/bdist.darwin-8.7.0-Power_Macintosh/egg/genshi/output.py',
line 488 in __call__
File 'build/bdist.darwin-8.7.0-Power_Macintosh/egg/genshi/output.py',
line 436 in __call__
File 'build/bdist.darwin-8.7.0-Power_Macintosh/egg/genshi/core.py',
line 207 in _ensure
File 'build/bdist.darwin-8.7.0-Power_Macintosh/egg/genshi/
filters.py', line 331 in __call__
File 'build/bdist.darwin-8.7.0-Power_Macintosh/egg/genshi/
filters.py', line 330 in __call__
File 'build/bdist.darwin-8.7.0-Power_Macintosh/egg/genshi/
template.py', line 1355 in load
File 'build/bdist.darwin-8.7.0-Power_Macintosh/egg/genshi/
template.py', line 986 in __init__
File 'build/bdist.darwin-8.7.0-Power_Macintosh/egg/genshi/
template.py', line 801 in __init__
File 'build/bdist.darwin-8.7.0-Power_Macintosh/egg/genshi/
template.py', line 1010 in _parse
KeyError: ('pop(): dictionary is empty', <bound method Root.index of
<bel.controllers.Root object at 0x22ebc30>>)

None of the templates for this (index) page references a dictionary
but the default now=time.time() is being passed in by the controller.
My understanding is that unreferenced key-value pairs are ignored.

Cheers,

Graham.


gjhi...@googlemail.com

unread,
Oct 12, 2006, 8:12:43 PM10/12/06
to Genshi
FWIW, I reverted to 0.3.1 and the page renders without error.

Christopher Lenz

unread,
Oct 13, 2006, 3:48:36 AM10/13/06
to gen...@googlegroups.com
Hey Graham,

Am 12.10.2006 um 23:04 schrieb Graham Higgins:
> On 12 Oct 2006, at 19:57, Christopher Lenz wrote:
>
>> I don't think any changes should be necessary, but of course the
>> devil always hides in the details. :-P
>>
>> Can you post the complete stack trace for that error?
>
> A caveat, this may be nothing to do with Genshi at all. I'd forgotten
> that I was running the 0.4dev svn code, so lord knows what
> easy_installing the 0.3.2 release actually did, I'm afraid I didn't
> pay much attention. Anyway: in order to check, I cleared out the
> 0.4dev code and easy_installed the 0.3.2 code --- with the same
> problem. I then deleted the 0.3.2 code, svn up'd to the 0.4dev code
> and again, same problem.

[snip]

Okay, I found the problem and have checked in a fix (both trunk and
0.3.x):

<http://genshi.edgewall.org/changeset/356>

As the log message indicates, this is probably due to a namespace
being redeclared in your template, or a prefix rebound to a different
URI. The workaround would be to avoid that ;-) Also because Genshi's
handling of namespaces is still a bit fragile at this point.

I'll probably be pushing out a 0.3.3 release with this fix. It'd be
great if you could verify it actually fixes your problem.

Thanks,

Graham Higgins

unread,
Oct 13, 2006, 10:50:09 AM10/13/06
to gen...@googlegroups.com

On 13 Oct 2006, at 08:48, Christopher Lenz wrote:

> Hey Graham,


> Okay, I found the problem and have checked in a fix (both trunk and
> 0.3.x):
>
> <http://genshi.edgewall.org/changeset/356>

Thanks for that.

> As the log message indicates, this is probably due to a namespace
> being redeclared in your template, or a prefix rebound to a different
> URI. The workaround would be to avoid that ;-) Also because Genshi's
> handling of namespaces is still a bit fragile at this point.

Lux fiat. The macros file did have multiple namespace declarations
(sorry about that, I should learn never to paste in haste):

<div xmlns:py="http://genshi.edgewall.org/" py:strip="">
<div xmlns:py="http://genshi.edgewall.org/" py:def="rubric"
py:strip="">
[ ... ]
</div>
<div xmlns:py="http://genshi.edgewall.org/" py:def="ageconcern"
py:strip="">
[ ... ]
</div>
</div>

I removed the namespace declarations from the children:

<div xmlns:py="http://genshi.edgewall.org/" py:strip="">
<div py:def="rubric" py:strip="">
[ ... ]
</div>
<div py:def="ageconcern" py:strip="">
[ ... ]
</div>
</div>

And that works, just as you predicted.

> I'll probably be pushing out a 0.3.3 release with this fix. It'd be
> great if you could verify it actually fixes your problem.

I'm now in better control of my eggs (as they say).

Using the latest svn (0.4dev-r364), the "pop()" error has gone away
but meta and link tags aren't being closed.


Cheers,

Graham.


Christopher Lenz

unread,
Oct 13, 2006, 11:08:23 AM10/13/06
to gen...@googlegroups.com
Hi Graham,

Am 13.10.2006 um 16:50 schrieb Graham Higgins:
> Using the latest svn (0.4dev-r364), the "pop()" error has gone away
> but meta and link tags aren't being closed.

Can you elaborate?

The handling of empty/closing of tags depends strongly on what kind
of serialization method you're using...

Serializing to HTML would produce:
<meta ...>

while serializing to XHTML would produce:
<meta ... />

and finally, serializing to XML would produce:
<meta .../>

Cheers,

Graham Higgins

unread,
Oct 13, 2006, 12:05:35 PM10/13/06
to gen...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 13 Oct 2006, at 16:08, Christopher Lenz wrote:

>> Using the latest svn (0.4dev-r364), the "pop()" error has gone away
>> but meta and link tags aren't being closed.
> Can you elaborate?

The page renders but styling and JS is lost (in Safari, at least)
because I'm using an XHTML1.0 Transitional doctype and all of the
(previously) self-closed tags are now unclosed, including IMG.

> The handling of empty/closing of tags depends strongly on what kind
> of serialization method you're using...

Ah, damn, whilst extremely apposite (I'm in another discussion on
that very subject) it also complicates things. Bear with me while I
explain, on the principle that the more you know about what I've
done, the sooner you'll be able to point out that I've brought this
all on myself :-)

Serialization was one of things I had to guess at when switching from
Kid to Markup. I used to follow the TG example for kid presented in
the TG config/app.cfg file:

> # The following kid settings determine the settings used by the kid
> serializer.
>
> # One of (html|xml|json)
> # kid.outputformat="html"

The Markup (now Genshi) example is silent on the matter and grepping
through the source suggests that there's no corresponding
genshi.outputformat attribute, so I assume that i) config settings
aren't supported and ii) (therefore) the default serialization is
being used.

I suppose this is as good an opportunity as any to enquire as to what
the default serialization is for Genshi, are there options other than
text/plain and do you have any recommendations for how the default
serialization might be set in a TG configuration file, a la those for
Kid?

> Serializing to HTML would produce:
> <meta ...>
>
> while serializing to XHTML would produce:
> <meta ... />
>
> and finally, serializing to XML would produce:
> <meta .../>

I'm hoping for XHTML, I'm expecting <meta .../> and that's what 0.3.1
provided. I'm fairly sure that I'm serving pages as text/html.

[But in order to be absolutely certain, I would need to dig around in
the TG/CherryPy code to find out what the default is, if there isn't
one set in config/app.cfg and if the serialization isn't explicitly
set in the TG @expose decorator. I've seen the pages rendered in IE,
so I can bravely infer that it *isn't* being served as application/
xhtml+xml, else IE would kindly offer to download the page instead of
rendering it.]

Cheers,

Graham.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iQCVAgUBRS+5VFnrWVZ7aXD1AQLUMgP/XLLVG4GUAB/5taA3oJc2/pU2dJiF+T0Z
K9gKf0LwIE+38q/aoMNRu9cX/CMXW6ZjfzX7CbCV8DkSbZIPJCZGI5CWgENzmln/
mAyOdzOt4ykwU0Zf/3gNSGYqdhrpG1yBj70+NJzSxjtcCjUVL4ud/SQu7iljXW2f
l7++0t8lKQg=
=pqo5
-----END PGP SIGNATURE-----

Graham Higgins

unread,
Oct 13, 2006, 12:29:01 PM10/13/06
to gen...@googlegroups.com

On 13 Oct 2006, at 17:05, Graham Higgins wrote:

> are there options other than text/plain

Yes Graham, there are ("use the Source, Luke"):

> @param method: determines how the stream is serialized; can
> be either
> "xml", "xhtml", "html", "text", or a custom
> serializer
> class


Cheers,

Graham.


Christopher Lenz

unread,
Oct 13, 2006, 12:34:05 PM10/13/06
to gen...@googlegroups.com
Hey Graham,

Am 13.10.2006 um 18:05 schrieb Graham Higgins:
> On 13 Oct 2006, at 16:08, Christopher Lenz wrote:
>
>>> Using the latest svn (0.4dev-r364), the "pop()" error has gone away
>>> but meta and link tags aren't being closed.
>> Can you elaborate?
>
> The page renders but styling and JS is lost (in Safari, at least)
> because I'm using an XHTML1.0 Transitional doctype and all of the
> (previously) self-closed tags are now unclosed, including IMG.

Browsers don't care whether specific empty elements such as <meta>,
<link>, <br>, or <img> are unclosed or self-closed as long as you're
sending out your responses as text/html. Because the HTML spec
defines their content model as EMPTY, they are basically implicitly
closed. The DOCTYPE doesn't matter here.

<script> elements are different BTW, they *need* to be closed by a
separate end tag, and the HTML and XHTML serializers should enforce
that, as for all other non-EMPTY elements.

>> The handling of empty/closing of tags depends strongly on what kind
>> of serialization method you're using...
>
> Ah, damn, whilst extremely apposite (I'm in another discussion on
> that very subject) it also complicates things. Bear with me while I
> explain, on the principle that the more you know about what I've
> done, the sooner you'll be able to point out that I've brought this
> all on myself :-)
>
> Serialization was one of things I had to guess at when switching from
> Kid to Markup. I used to follow the TG example for kid presented in
> the TG config/app.cfg file:
>
>> # The following kid settings determine the settings used by the kid
>> serializer.
>>
>> # One of (html|xml|json)
>> # kid.outputformat="html"
>
> The Markup (now Genshi) example is silent on the matter and grepping
> through the source suggests that there's no corresponding
> genshi.outputformat attribute, so I assume that i) config settings
> aren't supported and ii) (therefore) the default serialization is
> being used.
>
> I suppose this is as good an opportunity as any to enquire as to what
> the default serialization is for Genshi, are there options other than
> text/plain and do you have any recommendations for how the default
> serialization might be set in a TG configuration file, a la those for
> Kid?

The default serialization method employed by the template engine
plugin, and thus what you get when using Genshi in TurboGears is
"html". Thus it's no wonder you're <meta> tags aren't getting closed.
But as I said above, that shouldn't make a difference as long as
you're serving as text/html. In fact, the XHTML serializer is
explicitly designed to produce output that works with both text/html
and application/xhtml+xml.

In 0.3.2, the plugin doesn't support any configuration options. But
that wouldn't actually make a difference in TurboGears 1.0, because
it doesn't actually pass any engine-specific config options to the
plugin anyway :-( Here's hoping that's going to be addressed soon in
TG. Kevin?

In trunk, I've added a number of configuration options. See:

<http://genshi.edgewall.org/changeset/359>

and:

<http://groups.google.com/group/genshi/browse_thread/thread/
8727f16edfce4727#3ee98255f84e4dcf>

As a workaround, you should be able to use the 'as_format' parameter
of the @expose decorator, and set that to "xhtml". At least if I read
the TG docs correctly. Of course you'd need to do that on every
method :-P

>> Serializing to HTML would produce:
>> <meta ...>
>>
>> while serializing to XHTML would produce:
>> <meta ... />
>>
>> and finally, serializing to XML would produce:
>> <meta .../>
>
> I'm hoping for XHTML, I'm expecting <meta .../> and that's what 0.3.1
> provided. I'm fairly sure that I'm serving pages as text/html.

I'm pretty sure nothing changed about self-closing vs empty tags in
serialization between 0.3.1 and 0.3.2, so I have no idea why the
output you're seeing has changed. Maybe it hasn't and it's just a
different problem with your CSS/JS references :-P

Shannon -jj Behrens

unread,
Oct 13, 2006, 5:13:13 PM10/13/06
to gen...@googlegroups.com

See also: http://groups.google.com/group/genshi/browse_thread/thread/8727f16edfce4727/41ebf4fb695f454a#41ebf4fb695f454a
http://webkit.org/blog/?p=68

Happy Hacking!
-jj

--
The one who gets the last laugh isn't the one who did the laughing,
but rather the one who did the writing.

Graham Higgins

unread,
Oct 14, 2006, 3:35:54 PM10/14/06
to gen...@googlegroups.com

On 13 Oct 2006, at 17:34, Christopher Lenz wrote:

> Browsers don't care whether specific empty elements such as <meta>,
> <link>, <br>, or <img> are unclosed or self-closed

I was trying to indicate that whatever was unclosing previously-
closed elements wasn't restricted to the head.

> The default serialization method employed by the template engine
> plugin, and thus what you get when using Genshi in TurboGears is
> "html".

> it doesn't actually pass any engine-specific config options to the
> plugin anyway

1. Setting genshi.outputformat="xhtml" in the TG config file *is*
effective because TG constructs the format value from the config
setting plus the selected template engine and passes that as the
value of "format" (although you are technically correct, it isn't an
engine-specific option):

format = turbogears.config.get("%s.outputformat" % enginename, "html")

So, in my configuration, Genshi has been receiving format="xhtml" by
default and has been dutifully rendering as XHTML.

> In trunk, I've added a number of configuration options. See:
> <http://genshi.edgewall.org/changeset/359>

That was my mistake, using the trunk.

> As a workaround, you should be able to use the 'as_format' parameter
> of the @expose decorator, and set that to "xhtml".

The Genshi code in the trunk seems to output only html, irrespective
the of value of format, which is why my self-closed markup gets
unclosed. I had a casual look at the Genshi source but couldn't
immediately see why it's ignoring an explicitly-passed format value,
0.3.x and earlier releases respect the format value and render XHTML
appropriately.

0.3.x won't run without a search_path being set, something I can't do
in TG, so I served my purposes by changing line 1298 of template.py to:

self.search_path = ["%(current_dir_uri)s"]

but clearly, that's not a generic answer.

> I'm pretty sure nothing changed about self-closing vs empty tags in
> serialization between 0.3.1 and 0.3.2,

Possibly not but I was contrasting 0.3.1 and the trunk. I should have
started with 0.3.x as you originally suggested.

I can now confirm that duplicate namespace declarations are handled
without fault by 0.3.x.

Oh, I found one other thing when trying to render as XHTML1.1, Genshi
apparently drops any xml prolog.

Cheers,

Graham.


Christopher Lenz

unread,
Oct 14, 2006, 4:41:34 PM10/14/06
to gen...@googlegroups.com
Hi Graham,

Am 14.10.2006 um 21:35 schrieb Graham Higgins:
>> The default serialization method employed by the template engine
>> plugin, and thus what you get when using Genshi in TurboGears is
>> "html".
>
>> it doesn't actually pass any engine-specific config options to the
>> plugin anyway
>
> 1. Setting genshi.outputformat="xhtml" in the TG config file *is*
> effective because TG constructs the format value from the config
> setting plus the selected template engine and passes that as the
> value of "format" (although you are technically correct, it isn't an
> engine-specific option):
>
> format = turbogears.config.get("%s.outputformat" % enginename, "html")
>
> So, in my configuration, Genshi has been receiving format="xhtml" by
> default and has been dutifully rendering as XHTML.

Ah, I didn't know that. Indeed the plugin in trunk was ignoring the
format parameter/option. This should be fixed now since:

<http://genshi.edgewall.org/changeset/369>

[snip]


> 3.x won't run without a search_path being set, something I can't do
> in TG, so I served my purposes by changing line 1298 of template.py
> to:
>
> self.search_path = ["%(current_dir_uri)s"]
>
> but clearly, that's not a generic answer.

Damn, that's definitely a bug that got masked on trunk. I'm looking
into it.

>> I'm pretty sure nothing changed about self-closing vs empty tags in
>> serialization between 0.3.1 and 0.3.2,
>
> Possibly not but I was contrasting 0.3.1 and the trunk. I should have
> started with 0.3.x as you originally suggested.
>
> I can now confirm that duplicate namespace declarations are handled
> without fault by 0.3.x.

Cool.

> Oh, I found one other thing when trying to render as XHTML1.1, Genshi
> apparently drops any xml prolog.

There are two answers to this one :-)

First, Genshi currently doesn't preserve or generate any XML
declaration. That should probably be addressed, but it isn't much of
a problem in practice.

Second, the XHTML serializer is really a serialization method that
tries to generate output that is valid XHTML 1.0 but also works as
HTML (when sent as text/html). An XML declaration in an otherwise
perfectly valid XHTML document automatically throws IE6 into quirks
rendering mode. Seeing how it is optional for XML documents, the
XHTML serializer is probably going to continue to omit an XML
declaration.

If you want *real* XHTML 1.1 output (which by definition breaks
compatibility with HTML), you should use pure XML serialization
(outputformat='xml'). Not that I'd recommend that, though :-)

Christopher Lenz

unread,
Oct 16, 2006, 5:50:39 AM10/16/06
to gen...@googlegroups.com
Am 14.10.2006 um 22:41 schrieb Christopher Lenz:
> [snip]
>> 3.x won't run without a search_path being set, something I can't do
>> in TG, so I served my purposes by changing line 1298 of template.py
>> to:
>>
>> self.search_path = ["%(current_dir_uri)s"]
>>
>> but clearly, that's not a generic answer.
>
> Damn, that's definitely a bug that got masked on trunk. I'm looking
> into it.

Okay, that bug should be fixed on trunk and in the 0.3.3 release.

Thanks,

Graham Higgins

unread,
Oct 20, 2006, 10:41:30 AM10/20/06
to gen...@googlegroups.com

On 14 Oct 2006, at 21:41, Christopher Lenz wrote:

>> Oh, I found one other thing when trying to render as XHTML1.1, Genshi
>> apparently drops any xml prolog.
>
> There are two answers to this one :-)
>
> First, Genshi currently doesn't preserve or generate any XML
> declaration. That should probably be addressed, but it isn't much of
> a problem in practice.
>
> Second, the XHTML serializer is really a serialization method that
> tries to generate output that is valid XHTML 1.0 but also works as
> HTML (when sent as text/html). An XML declaration in an otherwise
> perfectly valid XHTML document automatically throws IE6 into quirks
> rendering mode. Seeing how it is optional for XML documents, the
> XHTML serializer is probably going to continue to omit an XML
> declaration.

Understood about IE6 quirks mode. For this particular site, I'm
moving towards serving pages as application/xhtml+xml and will need
to handle output for IE explicitly, so perhaps I can persuade
CherryPy to prepend the xml prolog as appropriate.

I'll just note that the XML declaration is optional only for certain
character encodings:

"Note that in this example, the XML declaration is included. An XML
declaration like the one above is not required in all XML documents.
XHTML document authors are strongly encouraged to use XML
declarations in all their documents. Such a declaration is required
when the character encoding of the document is other than the default
UTF-8 or UTF-16."

Cheers,

Graham.


Christopher Lenz

unread,
Oct 20, 2006, 3:15:53 PM10/20/06
to gen...@googlegroups.com
Hi Graham,

Am 20.10.2006 um 16:41 schrieb Graham Higgins:
> On 14 Oct 2006, at 21:41, Christopher Lenz wrote:
>>> Oh, I found one other thing when trying to render as XHTML1.1,
>>> Genshi
>>> apparently drops any xml prolog.
>>
>> There are two answers to this one :-)
>>
>> First, Genshi currently doesn't preserve or generate any XML
>> declaration. That should probably be addressed, but it isn't much of
>> a problem in practice.
>>
>> Second, the XHTML serializer is really a serialization method that
>> tries to generate output that is valid XHTML 1.0 but also works as
>> HTML (when sent as text/html). An XML declaration in an otherwise
>> perfectly valid XHTML document automatically throws IE6 into quirks
>> rendering mode. Seeing how it is optional for XML documents, the
>> XHTML serializer is probably going to continue to omit an XML
>> declaration.
>
> Understood about IE6 quirks mode. For this particular site, I'm
> moving towards serving pages as application/xhtml+xml and will need
> to handle output for IE explicitly, so perhaps I can persuade
> CherryPy to prepend the xml prolog as appropriate.

Just out of curiosity, why are you planning to serve as application/
xhtml+xml?

But yeah, for now, prepending the XML decl yourself is the only
option with Genshi.

> I'll just note that the XML declaration is optional only for certain
> character encodings:
>
> "Note that in this example, the XML declaration is included. An XML
> declaration like the one above is not required in all XML documents.
> XHTML document authors are strongly encouraged to use XML
> declarations in all their documents. Such a declaration is required
> when the character encoding of the document is other than the default
> UTF-8 or UTF-16."

Hmm, that's a strage requirement when you consider that the Content-
Type header of the HTTP response should already specify the character
encoding. What spec is that from?

Furthermore, I see little reason to generate anything other than
UTF-8 these days...

That's not to say that the XML decl problem shouldn't be fixed in
Genshi, just that I don't think it's all that important in practice.

Karl Guertin

unread,
Oct 20, 2006, 3:40:02 PM10/20/06
to gen...@googlegroups.com
On 10/20/06, Christopher Lenz <cml...@gmx.de> wrote:
> Just out of curiosity, why are you planning to serve as application/
> xhtml+xml?

http://www.hixie.ch/advocacy/xhtml

Christopher Lenz

unread,
Oct 20, 2006, 3:48:21 PM10/20/06
to gen...@googlegroups.com

Yeah... well, then let me re-phrase :-P

Why are you planning to serve XHTML (using the proper MIME type) and
not just plain old HTML?
Still, just out of curiosity.

Karl Guertin

unread,
Oct 20, 2006, 4:02:39 PM10/20/06
to gen...@googlegroups.com
On 10/20/06, Christopher Lenz <cml...@gmx.de> wrote:
> Why are you planning to serve XHTML (using the proper MIME type) and
> not just plain old HTML?

That's a better question. IE doesn't support it at all and both the
gecko[1] and webkit[2] folks recommend against this for all but a few
special cases.

[1] http://www.mozilla.org/docs/web-developer/faq.html#accept
[2] http://webkit.org/blog/?p=68 (under "HTML is probably what you want")

Graham Higgins

unread,
Oct 20, 2006, 8:10:31 PM10/20/06
to gen...@googlegroups.com

On 20 Oct 2006, at 20:48, Christopher Lenz wrote:

Why are you planning to serve XHTML (using the proper MIME type) and  
not just plain old HTML?
Still, just out of curiosity.

It's for a number of reasons. 

1. Personally, it's time for me to bite this particular bullet, for the sake of competence.

2. The approach is limited to a particular site which I'm developing. XHTML-specific features are part of the subject matter (RDFa, microformats, XUL, etc.) and so I think consistency rather requires an appropriate MIME type.

3. What Karl said. I got bitten the other day by basically what Ian Hickson outlines. I failed to spot that a controller function was omitting to pass a value for the 'title' key used in a template dictionary, so I ended up with an empty self-closed <title/>. This caused Safari to render a completely blank page. It took a while for me to spot my error amidst the burgeoning rubric in the head. I posted a "WTF?" on a friendly list and someone noted that Safari rendered the page perfectly okay if it was served properly with the application/xhtml+xml MIME type. I think I can just about make out the writing on the wall, it's faint but it's there :-)

4. Karl observes: "IE doesn't support it at all and both the gecko and webkit folks recommend against this for all but a few special cases." As I mentioned above, this particular site is a special case. As far as IE is concerned, I'm afraid that have no interest in devoting precious time to supporting it, it's too far behind the curve to be considered relevant in this specific context. I was familiar with the webkit blog piece but thanks, Karl, for the pointer to the  gecko team piece, that was particularly useful.

(As Ann van Kesteren writes, "XHTML can be tough" but I think the use of power tools such as TG, Genshi and modern JS libraries provides an answer to most of the concerns so far expressed. Elsewhere, I read people referring to Kid and "XML sit-ups". I see that as being part of the same issue: there is significant gain to be achieved by having one's markup clean, correct, strongly-structured and, in the case of XHTML, capable of supporting semantic reasoning. I find the "XML sit-ups" can actually simplify my mental model of the content structure and processing. In programming style, I'm a "scruffy" not a "neat" but I have learned to exploit neatness when it's truly useful.)

5. It's where we're mostly headed eventually. Gotta start thinking seriously about mobile users and semantic web indexers. There's 10,000 ontologies out there already, says Swoogle[1].

6. Because I can ... because I like messing with stuff ... because I've been working in HTML for over a decade and that's long enough ... because people explicitly warn against it ... because HTML is "plain old" and I'm an inveterate seeker after novelty :-)

In this instance, it's horses for courses.

You also wrote:

I'll just note that the XML declaration is optional only for certain
character encodings:
"the XML declaration is ... is required when the
character encoding of the document is other than
the default UTF-8 or UTF-16."

Hmm, that's a strage requirement when you consider that the Content-
Type header of the HTTP response should already specify the character
encoding. What spec is that from?

That's from the W3C TR for XHTML1.0: <http://www.w3.org/TR/xhtml1/#C_1>

#C_9 of the same doc details changes in the batting order for character encoding: 

Historically, the character encoding of an HTML document is either specified by a web server via the charset parameter of the HTTP Content-Type header, or via a meta element in the document itself. In an XML document, the character encoding of the document is specified on the XML declaration (e.g., <?xml version="1.0" encoding="EUC-JP"?>). In order to portably present documents with specific character encodings, the best approach is to ensure that the web server provides the correct headers. If this is not possible, a document that wants to set its character encoding explicitly must include both the XML declaration an encoding declaration and a meta http-equiv statement (e.g., <meta http-equiv="Content-type" content="text/html; charset=EUC-JP" />). In XHTML-conforming user agents, the value of the encoding declaration of the XML declaration takes precedence.

[1] http://www.swoogle.com, ontology indexing engine.


Cheers,

Graham.



Graham Higgins

unread,
Oct 21, 2006, 7:38:50 AM10/21/06
to gen...@googlegroups.com

On 21 Oct 2006, at 01:10, Graham Higgins wrote:

> [1] http://www.swoogle.com, ontology indexing engine.

Tsk, tsk. That should have been: <http://swoogle.umbc.edu/>

Cheers,

Graham.


Reply all
Reply to author
Forward
0 new messages