[email protected] wrote:
How about the following proposal, which builds on your ideas and
accommodates both of our use cases:
With respect to current docbook-slides,
- Introduce a single new element called <layout> with (all optional)
attributes "master" (in analogy to FO page-master, corresponding to
a CSS class) "name" (corresponding to a CSS ID selector; is this
really needed? Or use the XML "id" attribute instead of "name"?) and
some layout attributes that are inspired by CSS property names.
- Change the docbook-slides content model such that <layout> can be a
child of <foil>. More generally, <layout> should probably be allowed
in many other places where block-level elements are allowed.
- Allow <layout> and existing block-level docbook elements as children
of <layout>. (Or perhaps there is no need for nested <layout>s?)
OK, this would work. I see two main differences between our two proposals:
* Your layout element may nest (it may appear wherever block-level
elements are expected).
This is certainly more flexible than my proposal, I just didn't have
the boldness to go this far. :-)
* Your layout element plays two roles at once:
- It provides a handle to specify layout (as my 'blocks'), by means
of the 'name' attribute.
- It provides a handle to associate a template with it, by means of
the 'master' attribute.
I'm not sure whether mixing the two is really necessary. It might be
clearer to only have them use 'name', but add the optional 'master'
attribute to the top-level foil (or foilgroup) element.
Also, with that semantic simplification in mind, I like the name 'block'
better than 'layout', as it better captures the elements intent. (You
can apply a specific layout to it, as much as you can style it. That's
capabilities typically associated with blocks in general.)
- The stock stylesheets might come with a default template for
<layout> that does nothing in particular, and translates any layout
attributes present into appropriate CSS, XSL-FO etc. One might also
provide several default templates for commonly-used layouts (<layout
master="twocol">), which would require reserving master names.
For HTML, I think the mapping is trivial: blocks / layouts map to divs
(the name attribute to 'class'), and for the foil's 'master' attribute
gets mapped to 'class', too. Everything else is then up to the CSS
author. Similarly for xsl-fo: As the new elements provide hooks to
better control layout and style, but doesn't define specific semantics,
it is up to docbook-xsl customization layers to provide XSL template
specializations to produce the desired output.
- It would be easy to write custom XSLT templates (and associated CSS
for XHTML output) for recurring layouts selected via the "master"
attribute. Your custom XSLT template for two-column layout might
expect exactly two children of the <layout> element, which the
template puts into the left and right columns, e.g. by generating
appropriate <div>s and CSS:
I agree. However, due to the desired flexibility there can't be any
non-custom processing expectations associated with blocks / layouts
(other than the generic mapping to 'divs' in case of HTML), so any such
extensions have to be provided by users, and can't be incorporated into
the stock docbook-xsl stylesheets.
Regards,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
