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, 4 Feb 2002, Bob Stayton wrote:

Bob,

Thanks


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


That is the way, I have done it so far.


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

I have not noticed that template, but will look into it. Now the big 
queuestion is if the misceallanous browsers respect this attribute. 

However, this will not immediately solve my problem. When showing 
a chunked document inside a frame, most references to other chunks, should 
and will be rendered in the same frame. The problem occurs, whenever 
there is a reference to the root chunk (Usually when clikking in Up in the 
first chunk of a chapter or using the Home link). Then I don't wan't to 
show the associated document in the same frame, but redraw the whole 
window (e.g. show different document in the top frame)

I know or can relatively easy figure out how to do this. I just dont like 
to modify Norms stylesheets to much, but prefere to implement a relatively 
think layer on top of Norms work, utilizing as many build-in handles as 
possible.


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

I used the condition attribute for this, and added three lines to the 
ulink template to implement this behaviour. However, I think it would be 
more appropiate to use the type attribute, you mentioned.

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


Already created in another frame, and exactly the reason, why I would like 
to avoid having it here. 


Regards


Jens








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


Powered by eList eXpress LLC