Hi,
Changing
$('html,body')
to
$('#content')
seemed to work for us.
Regards,
Robert
On Wed, Nov 2, 2016 at 6:13 PM, Sebastian Holder <[email protected]> wrote:
> Hi Mary, hi all,
>
> under
> https://sourceforge.net/p/docbook/bugs/1390/
> I have created a bug report (including one possible solution) for the
> issue with links to local (within-page) IDs. (see quote below)
>
> Best regards,
> Sebastian Holder
>
>
> --
> levigo solutions gmbh --------- ein unternehmen der levigo gruppe
> Bebelsbergstraße 31 Telefon: 07031 / 4161-20
> D-71088 Holzgerlingen Telefax: 07031 / 4161-21
> GF: Jürgen Maestling, Jörg Henne http://solutions.levigo.de/
> Registergericht: Stuttgart HRB 245 178 USt-ID: DE216017084
> -----------------------------
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Mary Tabasko [mailto:[email protected]]
> > Gesendet: Dienstag, 9. September 2014 02:45
> > An: [email protected]
> > Betreff: [docbook-apps] Webhelp: My adventures therein
> >
> > Hi, all.
> >
> >
> > Issues with links to local (within-page) IDs.
> >
> > We noted that within-page links did not work. We found the
> > messages on the docbook-apps list about this, and tried
> > commenting out the salient block in the "main.js" file. This
> > fixed the problem for most links within a page (those within "content".
> > (We tried using the fix in the later snapshot, but we didn't see any
> > difference.)
> >
> > We also noted another problem with generated links from the sidebar
> TOC.
> > If you were on a page like, say, "bk01.html" and tried to navigate
> > to "bk02ch01s04#id-4.1.3.4.6" (a totally made-up id value, but
> > the format is what we got), the correct page and local link would load
> > (that is, the new page would be scrolled to the local link), but the
> > sidebar disappeared, and the sidebar toggle would not bring it back.
> >
> > (Clicking the Next link followed by the Previous link would restore
> > it, but the direct navigation from the sidebar TOC always clobbered the
> > sidebar.)
> >
> > The problem only occurred with generated IDs. Navigating from the
> > sidebar TOC on "bk01.html" to "bk02ch01s04#using-passwords" worked
> > fine. Looking at the gross structure of the links in the sidebar
> > TOC revealed no differences. The difference had to be in the structure
> > of the values of the IDs.
> >
> > By default, the "object.id" template with "generate.consistent.ids"
> > set makes values like "id-4.2.6.3". I played around with these values
> > a bit and determined that changing the "dots" to "dashes" solved the
> > problem. That is, links with id values like "id-4-2-6-3" worked just
> > fine. (The original ids work fine within the content block; it's only
> > using them from the sidebar TOC that causes the problem.
> >
> > I could find no way to tell the "generate-id" function to alter this
> > structure, so I had to override "object.id" and do it myself. (The
> > problem appears to be in some piece of JavaScript, but I have not
> > attempted to find it. The browser follows the links fine.)
> >
> > For completeness, I put "." characters into a couple of our explicitly
> > provided IDs and the links to them. They then exhibit the same problem:
> > the sidebar does not appear when you traverse to such an ID. (This
> > was not a browser-specific problem, either.)
> >
> > Note: Unless you have "." in your explicit IDs or have set
> > "generate.consistent.ids" for some other reason, this issue wouldn't
> > affect
> > anyone who didn't generate the sidebar TOC separately like we did.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
