To have more space available for the content, it is common practice for web apps to hide the address bar. This is done by programmatically scrolling the page. Since the introduction of the "Reader" functionality in iOS 5, the address bar contains an additional button when the browser detects "enough" content (see http://mathiasbynens.be/notes/safari-reader for details). When this button is present, the address bar does not hide for about 3-5 seconds. During this period of time, the content below the address bar (in our situation the whole header) is not visible.
- Prevent the Reader button from showing up. As mentioned above, the Reader functionality kicks in based on content length. It can be fooled by hiding the main content initially and showing it again after about 150 ms (assessed using some trial-and-error). The drawback is, obviously, that the content is not visible for 150 ms. Additionally, it is a dirty hack and every update on Apple's side could break it. Lastly, the Reader functionality is very convenient and it is bad practice to disable a "standard feature" like this.
- Wait for about 3-5 s before moving the header. By programmatically triggering the scrolling but adding a top-padding to the body, the header can be pushed down so it is still visible. After about 3-5 seconds (when the address bar is expected to vanish), we remove this padding. The problem is, that this delay is rather arbitrary. Again, every update on Apple's side could break this approach.
- Do not hide the address bar initially. We do not really need the additional space unless the menu is expanded. Therefore it is a possible solution to hide the address bar "on demand" (e.g., when expanding the menu).
I suggest leaving the Reader button alone and not hiding the address bar initially but rather on demand.
- google.com: no Reader button, hiding the address bar initially
- mobile.twitter.com: dito
- m.cnet.com: Reader button, hiding the address bar initially --> described issue arises