[Seaside] <head>, <body>, and css

Sat, 30 Mar 2002 14:10:32 -0800 (PST)

So as I said in my last email, we've been playing a bit with CSS support.
Two parts of that were easy - add support for the <link> element, and add
a macro that generates css "id" attributes corresponding to the sea:id of
each dynamic element (this could be improved by some kind of
subcomponent-specific prefix to avoid name clashes, but it's ok for now).

However, as we started to insert <link> tags and <style> blocks, we
realized that adding something to the <head> of a seaside page was not
always a simple operation.  The particular case I've run into is that the
application we're currently working on has, as many probably do, a common
"frame" component that always sits at the top level (this isn't actually
using framesets, understand, just that it is physically framing the rest
of the application), and the real action happens in its subcomponents.
This means, however, that anything that goes in the <head> has to go in
the frame, not in the subcomponents.  There's thus no way for a particular
subcomponent to contain style information specific to itself.

The solution I've adopted, for now, is to explicitly encode knowledge of
the html/head/body structure into seaside's templates.  Templates are now
rendered in two passes - first, the head section for each subcomponent is
rendered together in a single head block, and then the body section of the
template is rendered in the normal way.  Thus, any subcomponent anywhere
in the page can contribute something to the head block.

This has broader implications than just CSS, of course - subcomponents can
now affect the title of the page, force a redirect, and so on.  Which
seems like a Good Thing, in general.  However, I'm not so keen on the
complexity this adds - it's one more thing developers, designers,
documentors, have to keep in mind.

Anyone have any thoughts on how useful this would be to them, and how ugly
they find the special treatment of the head block?

Avi