[email protected] wrote:
Exactly. And my suggestion to introduce some new 'box' markup was
precisely meant to provide hooks similar to HTML divs, so somewhere
else an appropriate layout could be attached to it.
"Somewhere else" being an XSLT stylesheet?
That, or CSS.
This would certainly be a
clean way of doing it, but for me it would not significantly improve
on the current situation. To me, a fundamental problem is that *many*
slides require *individual* layouts.
My expectation was that each slide models a given template, and a
flexible and minimal way to achieve that through markup was to associate
a template (by-name) with the foil, and then simply name the blocks,
such that the stylesheets (CSS, in my case) would attach layout
processing instructions to them.
To keep it minimally invasive, it could be restricted to be direct
children of foil/foilgroup, so no actual DB vocabulary would be
affected by it.
I think it can make a lot of sense to add an extra wrapper, as I did
in my example markup. It does not make it any more invasive, perhaps
even less because in the worst case, all you need to do is change the
existing docbook grammar to allow the new container elements as
children of <foil>. All syntax variants and complicated XSLT are only
ever associated with new elements, with hardly any need to change XSLT
of existing elements.
Another advantage of this approach is that you can push semantics up
to the container element, making the markup more orthogonal: no need
to tell both blocks that they are "left" and "right", add <threecol>
and <relative> layout, etc.
OK, but that really requires that layout semantics are fully captured in
the (docbook extension) markup, while in my case it was not, i.e. it's
left to the CSS to decide how to lay out those blocks.
Whether that's a bug or a feature is another point of contention. :-)
Regards,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
