Change how the current page is calculated in the reader

[RiceKirby]

It's a small and not very important improvement, but I decided to suggest anyway.

Currently, the reader's current page seems to be calculated by the first image visible to on the screen (even if only a small fraction of it), so we get awkward moments like this:

Spoiler

What I suggest is to change that logic by having the current page being calculated by the image with the higher percentage of its area visible.
So in the example above, Page 1 would have about 3% of its area visible, while Page 2 has 99% and all other pages have 0%, so the reader would mark the current page as 2 instead of 1.

I use this format on an userscript for another site and personally I think it works very well. It basically gets the getBoundingClientRect() from each image loaded and uses the height to calculates how much is on/off-screen to find which one has the highest percentage of visible area.

 

[Teasday]

I'm not sure this would be a great idea, it doesn't make intuitive sense to me. If you go directly to a page, it's going to be aligned to the top, not just wherever >50% of the page is visible, and to me those behaviors should be consistent with one another. In some cases it's likely that the first page is a small credits page and gets immediately "turned" as soon as you scroll, which seems weird. Turning to the next page when the actual next one is just over 50% visible would skip it entirely.

 

[RiceKirby]

If you go directly to a page, it's going to be aligned to the top, not just wherever >50% of the page is visible, and to me those behaviors should be consistent with one another.

This doesn't really break consistency, since usually the page has its highest percentage shown exactly when it's aligned to the top. The 'skip to page' can be kept as it is and will hardly have any difference.

In some cases it's likely that the first page is a small credits page and gets immediately "turned" as soon as you scroll, which seems weird. Turning to the next page when the actual next one is just over 50% visible would skip it entirely.

That would need a page to be really small to happen, since its 50% would be smaller than an average page's 50%, so it would be filled more easily. And even then, by the point that happens, it means the other page is already dominating the view area.
If anything, the opposite is more likely to happen, with a really small page turning the page counter too early when it comes after a bigger one (but still would require really small pages to occur), but maybe in these cases an extra check for minimum height or something could be used.

It's a quite simple implementation, so I think it's at least worth a few internal tests to see how it feels for yourself. At least when I tested, it felt intuitive because it's closer to how an human perceive it, focusing on the main page they are looking at the moment.