by Tim Green » Wed Nov 15, 2017 8:04 am
Hi Dave,
Because of the way WebHelp must work, a number of things that are possible in "normal" web pages are not possible in WebHelp. Returning to the scroll position with the Back/Forward browser buttons is one of those things. A normal web page is a single static page that is managed entirely by the browser. Its scroll position is the normal position of that page, and only that page, in the browser window. This is always stored by the browser, so returning to it with the Back button is trivial.
A WebHelp page needs to handle a truly huge amount of data compared to a normal static web page and you need to use a lot of trickery to make it behave itself with reasonable performance: You have a table of contents and index, which can both have thousands of entries, a search page that needs to update with many pages of possible hits, and all the content of the current page as well. The user expects to be able to change the content of the current page immediately when they want to switch to another page, without having to reload all that additional material, which they also want to be updated accordingly. If all this was done in a single static page, browsing between topics in WebHelp would take several seconds (and it does on some systems).
What scrolls in a WebHelp page is not the entire page, which is the only thing the browser would keep track of. Instead, only the actual topic content within the page scrolls. Returning to that position would require additional scripting that would have to maintain a separate list of the current scroll positions of all the pages that have been visited, restoring the scroll position dynamically every time the user returns to the same page. This would be possible but a potential source of errors and would also add additional processing overheads to every page load, and would require a constantly-running polling loop to monitor the scroll position. That is not really a problem on desktop browsers, although I'm not a friend of constant polling if it can ever be avoided. However, on mobile browsers it can be a problem, among other things increasing battery consumption.
So far I've decided not to do this because I feel the disadvantages outweigh the benefits by a considerable margin.
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.