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

[Justus-bulk@Piater.name]

DavePawson <davep@dpawson.co.uk> wrote on Wed, 21 Jan 2009 15:45:21
+0000:

> Tables are for tabular data. Go read W3C accessibility guidelines.
> Tables are not for visual layout all over the screen.
> CSS does that nicely without messing with accessibility.

It's the *HTML rendering* that has to be accessible, not the *DocBook
source*.

This discussion about accessibility and the appropriateness of tables
for layout is irrelevant here. I did not propose to use tables for
layout; I proposed new markup that borrows layout semantics (not HTML
code) from tables.

(Actually, I *did* implicitly and inadvertently propose to use HTML
table code by suggesting the reuse of table-related XSLT
templates. Here your point is well taken, Dave, and I withdraw that
suggestion. Slide layout templates should indeed avoid using HTML
tables as much as possible.)


Stefan Seefeld <seefeld@sympatico.ca> wrote on Wed, 21 Jan 2009
10:52:31 -0500:

> Oh I see. I guess Justus was suggesting a way to emulate (part of) the
> desired layout capabilities by means of existing markup.
> I agree that tables are a bit hackish (as they are in most cases in HTML).

Not quite. I suggested a way of achieving (part of) the desired layout
capabilities by means of new, dedicated markup with associated
rendering expectations that borrow from table layout semantics.

> 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? 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. I don't want to write a
customization layer for each presentation, containing individual
layout details for many of the slides. The only way I currently see to
coerce docbook-slides into a presentational system is to pull
presentational markup into the XML source.

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

Justus