Footnote Link Question

[cupofjoe]

Tthe book I'm working on has a lot of footnotes. I have the footnotes at the back of the book and you can get to them by clicking a link from the text and it goes to the relevant footnote.

So when I get to the foootnotes, you can click a link back to where you were reading. My issue is that when you click back, it brings up your previous text at the very top of the page.

Is there something I can do where the text will be exactly where it was before I went to the footnotes?

I'm using the simple ID/anchor code.

The problem is more of an annoyance than anything. I've read ebooks before with footnotes, but I don't remember this being a problem (maybe it was, just don't remember it).


Thanks!

[theducks]

Reading devices may not be precise:

the return Link needs to include the anchor
filename.xhtml#note1 says go to where id="note1" exists in filename.xhtml

Your device may throw you into the (ADE) 'block' that contains that id, rather than ON that id

[eschwartz]

As a simple link, it must point to a specific location. Sometimes the linkback refers to the exact location, sometimes to the beginning of the paragraph that referenced the footnote... but either way, it must link to a specified place.

There is no javascript in ebooks so you cannot use "javascript:history.back()" as the link. On the other hand, some ereaders provide their own back button.

[cybmole]

the better e-readers e.g. Kindle voyage pop the footnote up on an overlay screen, so there's no risk of losing your place & none of this go back palaver to worry about.
[I confess I don't know what the under the bonnet code is for that. for me it just works so I read on & don't worry ]

I appreciate that's no great help if you are writing a book to sell for all current readers, but that's the way the hardware is evolving..

[Notjohn]

Originally Posted by theducks

Reading devices may not be precise:

the return Link needs to include the anchor
filename.xhtml#note1 says go to where id="note1" exists in filename.xhtml

Your device may throw you into the (ADE) 'block' that contains that id, rather than ON that id

In my Fire HD tablet, the return link generally takes me to the first character at the top of a page, so all I see is the footnote number. Sometimes, having read the footnote, I'd like to see the sentence again! So I am inclined to put the return anchor at the beginning of the sentence.

[rubeus]

A code snippet would be gelpful to check fiorst if there is any misspelling in the reference or id. At a frist glance it sounds like you mistyped the ID, clicking back throws you to the page, but as the reader cant find the ID you're on top of the page. Those broken links will not be pointed out as broken.

[DiapDealer]

Originally Posted by rubeus

At a frist glance it sounds like you mistyped the ID, clicking back throws you to the page, but as the reader cant find the ID you're on top of the page.

They're not talking about being taken back to the very top of an individual html page.They're describing how the target ID/anchor often becomes the top of the "page" on many readers after following the return link. It's expected (if slightly disappointing) behavior. This is exactly why many choose to put the return ID at a point before the original footnote link. It's probably never going to return to the exact screen it left (unless you use the "back" functionality provided by some readers/apps instead of the explicit return link), but it's a good idea to back up the return anchor to the beginning of the current sentence or paragraph so there's a bit of context when returning.

In short: what the OP and others are describing is not an error in the html or a bug (as others have already explained). What they want can't be achieved (from the perspective of epub creation alone). The link goes where the link goes (as others have pointed out). The choices are: to deal with it; move the return anchors to a point before the original footnote link; or to make use of a reader/app that has a built-in "back" feature or pop-up footnote feature.