Re: [docbook-apps] TOC issues with DocBook WebHelp

[David Cramer <david@thingbag.net>]

On 08/28/2013 02:02 AM, Tracy Huang wrote:
> If you got a solution for #2, I would really love to know and have a
> try. I am still very curious about why this issue does not exist in
> http://doc.neodoc.biz/user/content/apbs03.html. And from the source file
> it indicates it uses DocBook XSL-NS Stylesheets V1.75.2, but when I
> downloaded V1.75.2 I found there is even no webhelp folder under it
> (another mystery for me). Besides, its performance is much better than
> mine. Any idea why? Is Web server settings the only reason? Or is there
> something else I should pay attention to? Or should I try the latest
> snapshot from http://snapshots.docbook.org/ to see if any difference?

I didn't realize it wasn't happening before and I'm not sure what
changed. I suspect the Neodoc stuff started from some pre-release
version of webhelp

Regarding performance, In general, if you host it on a CDN, it will
perform better. But the stock webhelp served off a modest cloud server
seems fine: http://snapshots.docbook.org/xsl/webhelp/docs/ch01.html

But I know we could clean up the js and css (combine things to reduce
the number of GETs and minimize the js).

Let me know if what you find and if there are changes we should make in
the webhelp.

Regards,
David
>  
> Thanks again for your help!
> Tracy
> 
> 
> 2013/8/28 David Cramer <david@thingbag.net <mailto:david@thingbag.net>>
> 
>     Hi Tracy,
>     Regarding #1, it sounds like this bug (which I haven't looked into yet):
>     http://sourceforge.net/p/docbook/bugs/1301/
> 
>     Regarding #2, I can see why that would happen: while the help system may
>     look like a frameset, the toc tree is actually reproduced on every page.
>     When you click on a link to go to a new page, we have js that does
>     things like open nodes in the toc tree to the same state they were in
>     before (based on a cookie) and restore the search term from the previous
>     page if you were on the search tab (again from a cookie). We don't have
>     any code that would restore the vertical scroll to the same state it
>     was. I did experiment with solutions at one point and was going to make
>     it so that it scrolls so that the page you landed on is at the top or at
>     least visible as a next-best-thing to preserving the scroll state, but I
>     got distracted before I finished that.
> 
>     Let me know if #1 helps and if there are any side effects to removing
>     it. I believe it was there to ensure that when you clicked on a link to
>     an anchor in a page, the corresponding heading didn't end up under the
>     top banner.
> 
>     Regards,
>     David
> 
> 
>     On 08/27/2013 03:02 AM, Tracy Huang wrote:
>     > Hi All,
>     >
>     > I am looking for help with the two TOC issues that I have with my
>     > DocBook WebHelp, compiled using DocBook xsl ns 1.78.1, Ant 1.8.4, and
>     > Saxon 6.5.5.
>     >
>     >
>     >
>     > Issue 1: In my WebHelp TOC, there are several TOC entries (of the same
>     > level) linking to the different anchors of the same html page (this is
>     > controlled by the default toc and chunk parameters), but only the
>     first
>     > click from these TOC entries will reload the html page and scroll
>     to the
>     > right anchor of the page, all the subsequent clicks neither reload the
>     > html page, nor scroll the html page to the right anchor, and the html
>     > address in the browser address bar don’t change (although a different
>     > html address can be viewed when hovering on the TOC entry), unless you
>     > switch to a different html page, and then back to it, and then
>     again the
>     > first click will scroll to the right anchor of the page, the rest
>     clicks
>     > just have no effect at all.
>     >
>     >
>     >
>     > Issue 2: In WebHelp TOC again, everytime when you click a TOC
>     link, the
>     > TOC pane will refresh and then go to the top of the TOC pane, and will
>     > not re-locate to the current selected TOC link. If you have a TOC
>     which
>     > is really long, you will have to scroll the TOC to re-locate the TOC
>     > link every time, which is not user-friendly.
>     >
>     >
>     >
>     > These two issues could be reproduced on this WebHelp:
>     >
>     http://www.appeon.com/support/documents/appeon_online_help_v1.5test/development_guidelines/index.html.
>     >
>     > To reproduce issue 1: visit the above address, expand the TOC tree by
>     > clicking Best Practice -> iOS mobile apps vs. PB desktop apps, and
>     then
>     > click any entry under it, for example, Screen Size, the html page
>     on the
>     > right page does not move all.
>     >
>     > To reproduce issue 2, visit the above address, expand the TOC tree
>     so it
>     > is longer than one page, scroll to the bottom of the TOC tree, click
>     > Index. It goes to the top of the TOC tree, instead of staying at the
>     > bottom where Index is.
>     >
>     >
>     >
>     > I have googled for solutions but with no luck. But I found another
>     > DocBook WebHelp sample which has no such TOC issues, what's more, its
>     > performance is much much better (anybody know why?). If you are
>     > interested, take a look at
>     > http://doc.neodoc.biz/user/content/apbs03.html#d4e2030.
>     >
>     >
>     >
>     > I am not sure if these are bugs or configuration issues. Can
>     anybody help?
>     >
>     >
>     >
>     > Regards
>     >
>     > Tracy
>     >
> 
>