Hi, Changing
$('html,body') to $('#content') seemed to work for us. Regards, Robert On Wed, Nov 2, 2016 at 6:13 PM, Sebastian Holder <s.hol...@levigo.de> 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:taba...@telerama.com] > > Gesendet: Dienstag, 9. September 2014 02:45 > > An: docbook-apps@lists.oasis-open.org > > 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: docbook-apps-unsubscr...@lists.oasis-open.org > For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org > >