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

[Stefan Seefeld <seefeld@sympatico.ca>]

Dave Pawson wrote:
> Stefan Seefeld wrote:
>> Dave Pawson wrote:
>>>
>>> Where to draw the line? Overlays and slides are javascript + html 
>>> surely? Same way that Norm added 'next slide' type javascript.
>> Indeed, incremental display (as well as overlays) is implemented 
>> using javascript. But it's still something a presentation author 
>> wants to specify in the markup. While it is clear that incrementals 
>> can be ignored in handouts, for all others they are media-independent 
>> (i.e. no matter whether you use HTML or some other fancy tool, you 
>> want to specify what 'next' stands for).
>
> I'm going to remain neutral on that till I understand it.
> Could you describe a rough outline of markup through to an overlay
> of a second list item being added to an existing list, perhaps, as
> an example?

I think I'm a bit confused now as to what the question is. What I'm 
asking for is a way to mark up slide ('foil') content in a way that 
allows me to incrementally build up the whole slide one step at a time. 
In the simplest case that may just be list items, but it could also be 
overlayed graphs, or even a mix of both (think of a set of subsequent 
figures, where the figure 'titles' are actually the list items, and the 
figure graphics are overlayed in a well-defined (aligned) way.



>
>>
>>>
>>> What markup are you thinking of for incremental lists?
>>> list continuation attributes? Semantic = continue numbering from
>>> previous-sibling::list?
>> I'm not sure. Just a means to indicate how the slide content is 
>> chunked for incremental display. (And sometimes it's not a simple 
>> linear chunking, for example when some content has to be kept in 
>> sync, such as list items and graphic overlays.)
>
> In which case I don't understand enough to suggest anything.
> Could you define it? Simple example first?

Right now I'm using this:

<itemizedlist role="incremental"> ...</itemizedlist>

to generate incremental lists. (S5's javascript will detect DOM nodes 
with class=incremental and process them appropriately.) While something 
like this certainly works (although I'd rather use another, dedicated, 
attribute instead of 'role'), something like keeping list items and 
overlayed graphics in sync is not so easy (it's not even supported by S5 
right now, but that's just a matter of programming ;-) )
I haven't thought this through yet myself, as I think it may be good to 
take the first step first...

>>
>> Yes, exactly. Well, it might be good enough to have an indicator 
>> (such as 'template' enumerator per slide, then use named blocks which 
>> content is put into. The template enumerator will then indicate how 
>> those blocks are layed out.) That seems to be similar in spirit to 
>> what presentational software such as powerpoint or openoffice offer.
>
> Which is a mile away from semantic or even presentational markup?
> It is exactly xsl-fo. Take this block, flow it into that position.

<foil template="my-two-column-template">
  <block name="left">
    <itemizedlist/>
  </block>
  <block name="right">
    <mediaobject/>
  </block>
  <block name="footer"/>
</foil>

I.e., I add block elements that have little more semantics than 'divs' 
in html. Their layout can then be described by means of 
'my-two-column-template' (which may trigger some chunk of CSS to be 
included with precise layout info for these blocks.

You are certainly right that to some extent this is what xsl-fo is 
about, but only at the top level, i.e. the page layout. The block 
content is just ordinary docbook. (Obviously the author has either to be 
careful not to overflow the boxes, or there needs to be some mechanisms 
such as automatic scaling to fit the content into the boxes. But that's 
no different from traditional docbook slides content.



Thanks,
       Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...