Hmm, content insets hidden under top and bottom toolbars would be perfectly fine.
But why is the bottom one visible? And only the bottom one — analogously, why don’t we ever see a similar white area on top? There also is a top bar, which needs such an inset.
If the content height ≤ the available area, then there’s no scrolling involved, so no inset needs to take up additional vertical space, leaving less space to the actual content (my very first screenshot). In this case, if there is an inset, it should be hidden under the bottom bar, freeing up these pixels for the content, without a scrollbar.
If the content height > the available area, then I shouldn’t be able to scroll so far as to pull the inset from under the bottom bar.
But like I say, my main issue is that I cannot create a rectangle that occupies the whole height of the available area:
I cannot create a rectangle of height of the cyan line without scrollbars.
I can only create a rectangle of height of the purple line without scrollbars.
Your complaints are valid, and I’ll need to revist this area in the future anyway when more of the desktop’s reviewer gets integrated into the mobile clients.
@michalrus In my debugging of a similar issue disabling the bottom bar fixes the issue but obviously suboptimal if you want the bottom bar (I think it’s a bottom bar inset and since that’s rendered outside the reviewer web view it can’t be changed by card js?)
While keeping bottom bar, I used 100 dvh instead of vh which fixed the scroll issue but you do still have that gap above the bottom bar.
I tried that instead of calc(100vh - something), but—at least on iOS—the dvh seems to be constantly changing while you scroll… And then elements referencing 100dvh are flickering. So this solution won’t work for cards that don’t fit on a single screen.
