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

Justus-bulk@Piater.name 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. :-)



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

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