I like this better overall. Just the amount of screen real estate taken up by bars like it
usually leads to me getting frustrated while reading even when occasionally useful. If it
allows us to fix these bugs as well then I think it's more plus then minus.
I may have just missed something but I'm slightly confused about what you mean by
occasional auto pop ups?
Sent from my iPhone
Associate Community Officer
Product Manager - Fundraising
+1 415-839-6885 x6716
On Dec 23, 2011, at 11:29 AM, Brion Vibber <bvibber(a)wikimedia.org> wrote:
The floating, fixed-position header bar (header bar
always at the same place at top of the screen while other things scroll) causes a number
of problems in the app, including:
- It's difficult to tap into
the search box
- section links on file pages
scroll too far down
My 'absolute' branch resolves this by removing the 'position: fixed'
floating toolbar and letting it scroll off the page:
This lets us drop the event handlers that screw up the search field focusing, because we
don't need them to work around the bug where click events went through to the
background elements. It fixes the scrolling / reference / hashlink issue by getting the
header out of the way, so going to a position in the document actually shows it at the top
of the screen.
It also provides more screen space for reading, which is a big plus in portrait
orientation where a toolbar eats proportionately more screen space.
The downside is that if you've scrolled down on the page, you have to scroll back up
to get to the search field etc.
This is pretty much how the stock web browsers on iOS and Android work, however, so I
don't think it's such an awful thing to do. Any objections? Preferences on making
things sometimes auto-pop up?
Mobile-l mailing list