[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] Webhelp: My adventures therein
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:tabasko@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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]