OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [docbook-apps] slides: how to balance presentation and content


Stefan Seefeld <seefeld@sympatico.ca> wrote on Wed, 21 Jan 2009
13:43:37 -0500:

> 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.

Yes. I like this, even though it covers only 90% of my needs.

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?)

I think this is not very invasive, easy to understand, but extremely
flexible:

- 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.

- 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:

  <foil>
    <layout master="twocol">
      <itemizedlist/>
      <layout>
        <mediaobject/>
        <mediaobject/>
      <layout>
    </layout>
    <layout master="footer"/>
  </foil>

  The same layout might be achieved more directly (and verbosely) in
  the following way, which for XHTML output would not require any
  custom XSLT (but would still require custom CSS) because the "left"
  and "right" could simply be passed through by the stock templates to
  the output XHTML as CSS class names:

  <foil>
    <layout master="left">
      <itemizedlist/>
    </layout>
    <layout master="right">
      <mediaobject/>
      <mediaobject/>
    </layout>
    <layout master="footer"/>
  </foil>

- It would be easy to layout individual slides, without requiring any
  custom XSLT or CSS at all:

  <foil>
    <layout top="2ex" left="10%">
      ...
    </layout>
    <layout bottom="10ex" right="10em" width="30%">
      ...
    </layout>
  </foil>

- Master and layout attributes might be combined, in which case the
  layout attributes would override the master style attributes,
  e.g. to achieve an asymmetric two-column layout.

- Nested <layout>s would behave as nested HTML elements and cascaded
  styles do in CSS.

Comments?

Justus


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]