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] GSoC 2011 project idea: DocBook Slides 5.0

Em 25-02-2011 14:55, Stefan Seefeld escreveu:
> I think it's important that the slides vocabulary is a super-set of 
> the existing DocBook, to allow users to incorporate existing document 
> chunks into their slides.
Actually, in my opinion it isn't a superset (some normal DB elements 
aren't applicable) neither a subset (there will be presentation-specific 
elements) but has as big intersection with normal DB as possible. If you 
want to talk in terms of set theory... :)
> However, I also recognize that this medium has particular requirements 
> that run somewhat against the main philosophy of DB: a clear 
> separation between content and style. Arguably, for presentations, 
> style *is* content.
Yes, this is a bit contradictory. I think it's better to talk about 
content, structure and style, where structure is somewhere between 
content and style. It's more than content but it isn't the concrete 
style at all, e.g. sectioning or in normal DB <footnote> specified that 
its content will be rendered at the bottom of the page, so it's not just 
content but not a concrete style either. It's structure. I intend to add 
content and presentation-specific structure elements but keep the style 
elements minimal. If a given slide of the presentation has a different 
style (transition, animation, etc.) it will be necessary to distinguish 
it so the markup has to add support for them but imho it should be kept 
minimal in the markup and mostly done in the stlysheets. E.g. assigning 
classes to particular slides but only define the rendering of the given 
class in the parametrized stlysheets. In this manner, it would not 
violate so much the original philosophy. We already use such in normal 
DB, like setting the role attribute of personname to "family-given".
> Thus, I think one area where an updated slides vocabulary may grow 
> some new elements is support for styling. In the simplest case that 
> could mean additional hooks that styling info may be attached to (via 
> CSS, javascript, or whatever else is used to apply styles to the final 
> slides).
Yes, I'm thinking of something similar with hooking but keeping the 
formatting info in the stylesheet parameteres as much as possible.
> Following last year's work on a new "API documentation profile", I 
> believe the best way forward is to turn the existing slides extension 
> into a proper DB5 extension profile, where such additions can more 
> easily be supported.
I have also been thinking whether to make an individual schema or an 
extension. Is last year's work available somewhere so that I can take a 
look how it was done?
> Thus, a good starting point would be to collect ideas about what 
> limitations DB slides users perceive and what additional markup might 
> be needed to support them.
That's why I posted this mail to collect ideas and feature request, so 
please users, share your thoughts!


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