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] | [Elist Home]

Subject: Re: DOCBOOK-APPS: Chunked documents inside frames

On Mon, Feb 04, 2002 at 10:53:43AM +0100, Jens Stavnstrup wrote:
> Allthough,  I agree in principle, that the use of frames is a huge sin. 
> When frames are required, it would be 
> nice to have some control over the target attribute in the HTML element 
> "a". otherwise we will risk the effect of cascaded frames.

Frames have their place, and some control would be nice.
> This could be done by creating an empty template in chunk.xsl called 
> navig.target with one parameter direction (possible values 'prev','next', 
> 'up' and 'home'. The template could then be called from appropiate places 
> in e.g. the templates "header.navigation" and "footer.navigation" in the 
> file html/chunk.xsl

Frame behavior is pretty application specific, so your
solution would permit someone to write a custom template
to set a target attribute, right?  It would have to be 
called from the TOC-generating templates as well, as
TOCs are one of the most common uses for frames.  

BTW, did you know about the existing empty template
'user.head.content' that lets you add to your HTML
<HEAD> element?  It would permit you to add
a <BASE target="blah"> element to your TOC files
to point to a content frame.  
> Maybe a similar approach would be appropiate  for the template ulink in 
> htnl/xref.xsl

Control of Ulink targets would be very nice.
In our case, authors want control of which ulinks stay
in the current frame and which sprout a new window
(sometimes because they have their own frameset).
The unlink 'type' attribute is described as being "available for
application-specific customization of the linking
behavior".  So having a customizable template would
be very handy.
> Similar when using chunks indside frames, it is sometimes unessary to have 
> a root chunk, since that information is avalible in some of the other 
> frames, So e.g. with an noroot.chunk parameter, a chunked book document 
> will consists of a number of capter chuncks and posible subsection chunks 

So where does the overall table of contents come from?

Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
Caldera International, Inc.                 fax:   (831) 429-1887
                                            email: bobs@caldera.com

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

Powered by eList eXpress LLC