This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
Re: Chunked documents inside frames
- From: Bob Stayton <bobs at caldera dot com>
- To: Jens Stavnstrup <js at ddre dot dk>, docbook-apps at lists dot oasis-open dot org
- Date: Mon, 04 Feb 2002 10:53:28 -0800
- Subject: Re: DOCBOOK-APPS: Chunked documents inside frames
- References: <Pine.LNX.4.44.0202041022470.4901-100000@ares.ddre.dk>
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