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:<br><br>* <a href="https://bugzilla.wikimedia.org/show_bug.cgi?id=32917">https://bugzilla.wikimedia.org/show_bug.cgi?id=32917</a> - <span id="summary_alias_container">
      <span id="short_desc_nonedit_display">It&#39;s difficult to tap into the search box</span></span><br>* <a href="https://bugzilla.wikimedia.org/show_bug.cgi?id=31524">https://bugzilla.wikimedia.org/show_bug.cgi?id=31524</a> - s<span id="summary_alias_container"><span id="short_desc_nonedit_display">ection links on file pages scroll too far down</span></span><br>
<br>My &#39;absolute&#39; branch resolves this by removing the &#39;position: fixed&#39; floating toolbar and letting it scroll off the page:<br><a href="https://github.com/brion/Wikipedia/commits/absolute">https://github.com/brion/Wikipedia/commits/absolute</a><br>
<br>This lets us drop the event handlers that screw up the search field focusing, because we don&#39;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.<br>
<br>It also provides more screen space for reading, which is a big plus in portrait orientation where a toolbar eats proportionately more screen space.<br><br><br>The downside is that if you&#39;ve scrolled down on the page, you have to scroll back up to get to the search field etc.<br>
<br>This is pretty much how the stock web browsers on iOS and Android work, however, so I don&#39;t think it&#39;s such an awful thing to do. Any objections? Preferences on making things sometimes auto-pop up?<br><br>-- brion<br>
<br>