4 ms·
From the code and a quick test it seems relatively resilient as it saves percentage of current viewport scroll, not absolute pixels.
by EstanislaoStan 2y ago
From the code and a quick test it seems relatively resilient as it saves percentage of current viewport scroll, not absolute pixels.
- teddyh 2y agoIn that case, what happens when you resize your browser window to be shorter or taller?
- kugurerdem 2y agoYou are on point, the extension starts to slightly malfunction if the user starts to resize the browser window vertically. This is because of the assumption that `(window.pageYOffset + window.innerHeight) / document.body.scrollHeight` will approximately equal 1 when the user has scrolled to the bottom of the page (which apparently, is not necessarily the case). Will address this issue ASAP. [1] Thanks for finding an edge case which I did not notice :) 1. https://github.com/kugurerdem/mark-scroll-positions/issues/1 https://github.com/kugurerdem/mark-scroll-positions/issues/1
- kugurerdem 2y agoAs discussed in the essay there are still some potential issues with dynamic pages. [1] Horizontal resizes might change the location of certain HTML elements, if the website is designed to be "responsive". This is a problem that I still need to address. Another issue arises with pages that can be dynamically appended (e.g., through comments) towards the bottom. In this case, simply making a calculation based on the previous percentage where the user marked the page fails. This is yet another problem that I need to address. However, the current jumping method seemed to be working fine for most of the sites I use, so I decided to release the app first and improve it along the way based on the traction it gets. 1. https://www.rugu.dev/en/blog/mark-scroll-positions/#3-deciding-on-how-to-implement-the-jump-functionality https://www.rugu.dev/en/blog/mark-scroll-positions/#3-decidi...