I'm really new to HTML5 for mobile. I use jQuery Mobile for my current app and I have some problems hiding the navigation bar.
I found this site: http://m.somethingborrowedmovie.warnerbros.com/. (I do not paste this link to promote the movie.)
I was just amazed by this HTML5 site. Does anyone have any idea of the method used to hide the navigation bar?
The menu is also really well done. Is there any framework to build apps like this one?
Try the following:
Add this meta tag in the head of your HTML file:
<meta name="apple-mobile-web-app-capable" content="yes" />
Open your site with Safari on iPhone, and use the bookmark feature to add your site to the home screen.
Go back to home screen and open the bookmarked site. The URL and status bar will be gone.
As long as you only need to work with the iPhone, you should be fine with this solution.
In addition, your sample on the warnerbros.com site uses the Sencha touch framework. You can Google it for more information or check out their demos.
Remy Sharp has a good description of the process in his article "Doing it right: skipping the iPhone url bar":
Making the iPhone hide the url bar is fairly simple, you need run the
following JavaScript: window.scrollTo(0, 1);
However there's the question of when? You have to do this once the
height is correct so that the iPhone can scroll to the first pixel of
the document, otherwise it will try, then the height will load forcing
the url bar back in to view.
You could wait until the images have loaded and the window.onload
event fires, but this doesn't always work, if everything is cached,
the event fires too early and the scrollTo never has a chance to jump.
Here's an example using window.onload: http://jsbin.com/edifu4/4/
I personally use a timer for 1 second - which is enough time on a
mobile device while you wait to render, but long enough that it
doesn't fire too early:
setTimeout(function () { window.scrollTo(0, 1); }, 1000);
However, you only want this to setup if it's an iPhone (or just
mobile) browser, so a sneaky sniff (I don't generally encourage this,
but I'm comfortable with this to prevent "normal" desktop browsers
from jumping one pixel):
/mobile/i.test(navigator.userAgent) && setTimeout(function
() { window.scrollTo(0, 1); }, 1000);
The very last part of this, and this is the part that seems to be
missing from some examples I've seen around the web is this: if the
user specifically linked to a url fragment, i.e. the url has a hash on
it, you don't want to jump. So if I navigate to
http://full-frontal.org/tickets#dayconf - I want the browser to scroll
naturally to the element whose id is dayconf, and not jump to the top
using scrollTo(0, 1):
/mobile/i.test(navigator.userAgent) && !location.hash &&
setTimeout(function () { window.scrollTo(0, 1); }, 1000);
Try this out on an iPhone (or simulator) http://jsbin.com/edifu4/10
and you'll see it will only scroll when you've landed on the page
without a url fragment.
The problem with all of the answers given so far is that on the something borrowed site, the Mac bar remains totally hidden when scrolling up, and the provided answers don't accomplish that.
If you just use scrollTo and then the user later scrolls up, the nav bar is revealed again, so it seems you have to put the whole site inside of a div and force scrolling to happen inside of that div rather than on the body which keeps the nav bar hidden during scrolling in any direction.
You can, however, still reveal the nav bar by touching near the top of the screen on apple devices.
Simple javascript document navigation to "#" will do it.
window.onload = function()
{
document.location.href = "#";
}
This will force the navigation bar to remove itself on load.
Related
I am struggling with PWA I made. I have the html meta tag viewport-fit=cover, which make sure that on phones with a pinhole camera or cutout, the app will stretch around it. When the pwa is added to the phones home screen and opened it works, but when I open a link and return to the "app" the whole camera area is a black bar and the content doesn't stretch around it anymore. Does anyone have a clue if there is a way to fix this behaviour?
I have only written one PWA. The whole App was one javascript file with one html page. Stepping through the app, did not change pages as the url remains constant. Therefore the back arrow does nothing on it. You have to code that action yourself.
In this case, something is not getting initialised again.
I want to go from homepage of cece.indiana.edu/index.html to cece.indiana.edu/request.html#speaker. Even though I have the id="speaker", my request is not redirected to the specific id "speaker". I can only get this to work when I am on the request page already. Why can't I get this simple thing to work? Also, I've searched and found answers but none have fixed the problem.
Relevant code/snippets:
<h2 id="speaker" name="speaker">Request a Speaker</h2>
URL: cece.indiana.edu/request.html#speaker
If I am on cece.indiana.edu/index.html: I will go to
Scroll onto Navigation bar
Scroll under "get involved"
Click on "request a speaker"
Be redirected to the bottom of the request.html page. - this is not what I want to happen!
What I want it to do, but it is not happening: If I am on cece.indiana.edu/index.html (or any page)
Scroll onto Navigation Bar
Scroll under "get involved"
Click on "request a speaker"
Be redirected to the H2 with the id "speaker".
This not working correctly in Chrome or Firefox, but it has worked in Safari when I've tried it. I want it to work on all browsers.
It's the JavaScript on your page. If all JS is disabled it works fine. There is JavaScript code messing with the page load and specifically with scrolling and animation, so it's not surprising that it's interfering. Your JS even has specific references to URLs that do or do not have #anchors in them.
In this case it seems you are being sent to the bottom of the page because the "smooth scrolling" code in your JS isn't taking into account that the page may already be scrolled part way. Some browsers will "remember" where you had scrolled to last time you loaded a page, so particularly if you use the back button and then click the navigation item again, you'll end up scrolled too far.
If you have the ability to change the JS, you can fix this by making sure the smooth scrolling code ends by checking to make sure it's actually in the right spot, maybe after a small delay.
Was just trying to cobble a quick site together as a favour for my sister. It's based on a template she bought and I've just quickly bunged her copy/pictures in, so I'm aware the markup is far from perfect. That said, I can't see how it would be causing the following issue...
The template uses a jQuery plugin called jScrollPane to make the content sections scrollable. Sometimes however, in Chrome (v20) this doesn't work - it doesn't let you scroll all the way down.
What's really odd though, is the pattern I've found that seems to effect whether it works or not. Try the following
Go to http://mattandkate2012.co.uk in Google Chrome - click 'Ceremony' - can you scroll down far enough to see the map? I can't.
Press the reload icon, click 'Ceremony' - can you scroll down? I can't.
Select the URL in the browser URL bar, press enter - can you scroll down? I can now!
Does everyone else get the same results as above, and do you have any idea why pressing enter in the URL bar has a different effect to the reload button?
This functionality works fine in Firefox and even IE!
Thanks
Pete
From a very quick look I guess it's because the section contains an image and you aren't re-initialising jScrollPane once the image loads. See:
http://jscrollpane.kelvinluck.com/image.html
The difference between refreshing and pressing enter in the location bar is that the cached image is shown when you press enter in the location bar...
I would suggest moving the call to $('.content').jScrollPane({showArrows: true}); to inside the $(document).ready block - if you call it before the document is ready often images or other elements won't have loaded and so the height of the containers will be wrong.
Im using The HTML Mobile Bolierplate and im trying to get the URL Address bar to hide using:
<script src="/static/js/helper.js"></script>
<script>
MBP.hideUrlBar();
</script>
But it's not working, the helper.js loads okay. Anyone know where I'm going wrong?
Thanks
Waiting until the DOM's load event is fired is always a good practice before running UI manipulating code.
For novice users:
jQuery:
jQuery(function() {
MBP.hideUrlBar();
});
Zepto:
Zepto(function() {
MBP.hideUrlBar();
});
For guys coming from Google, I think the MBP.hideUrlBar() function needs a little bit explanation on how to use it. I took time to make it works on Android (native browser only, Chrome can't hide his address bar) and iOS :
First, your page NEEDS to have a scrollbar (it means that your website must NOT be html,body height:100%)
If you want your website to be 100% (which was my case) you will need to calculate manually the height to add to html,body to be sufficient to hide entirely the scrollbar (this mean that we need to know the height of the address bar...)
If you want the MBP function to works on load event, use MBP.hideUrlBarOnLoad(). Beware, it will only works on load event, not on every resize (orientation changes). You will have something like that in your resize function :
function resize(){
firstLoadOfThePage ? MBP.hideUrlBarOnLoad() : MBP.hideUrlBar()
}
(assuming that firstLoadOfThePage is a tag to know when it is the first load of the page (first call of resize function)
Hope it will help.
You can try:
window.scrollTo(0, 1);
to hide the address bar.
On an HTML page, a link like this:
Location on Page
...should navigate to this spot on the page:
<a name="pagelocation">
But in my experience, it sometimes misses - especially when linking from another page (like <a href="somepage.html#pagelocation">). By "misses," I mean it scrolls to the wrong spot on the page - maybe close, maybe not.
Normally, the target location ends up at the top of the screen. I know this can fail if there's not enough room below the anchor to scroll it to the top of the screen.
Why else would it fail? Does it depend on layout at all? How can I fix it?
(I'm keeping this general because I'd like a catch-all reference answer.)
Update 1
Thanks for the pointers so far about non-explicit image sizes. But what about on a page where all the elements have explicit size? (I'm dealing with one now.)
Quite often the scrolling can occur before the page has finished loading. If you have images without widths and heights, the page will jump, then load the image and re-layout itself, making the place you previously jumped to seem wrong.
Edit: Anything else that can change page layout should also be considered with suspicion... this include javascript and CSS that's not loaded in the <head> (never mind that all CSS should be loaded in the head; it isn't always).
If the page is bounced through a redirect, I believe IE will scroll the end page but Firefox won't.
JS Solution
Run this function on document ready.
function goToAnchor() {
hash = document.location.hash;
if (hash !="") {
setTimeout(function() {
if (location.hash) {
window.scrollTo(0, 0);
window.location.href = hash;
}
}, 1);
}
else {
return false;
}
}
I believe the behavior you are seeing is the result of the browser locating to that spot on the page before all images have finished loading. Once the images finish loading, then the layout of the page has changed (the page is likely longer vertically, for example), causing the location of where the anchor should be to have changed - but the browser still thinks it has already navigated to that anchor.
As mentioned above, this is probably due to images being rendered late and 'adjusting' the layout as they load.
If you can specify the size of the images then that much room can be allocated before they render, which should prevent the problem.
As a side note I've had this problem before in the form of using forward/back between enough pages that the images needed reloading, causing me to end up in the wrong place after they had rendered.
I have also seen this happen when JavaScript creates a drop-down menu at the top of a page. Then, once the menu has been finished, it is hidden, scrolling up the content below.
In the meantime, the browser has already set the target location at the top of the window. Hiding the menu a the very top of the page moves the target location up off the top of the window.
Note that you can add id="pagelocation" to just about any HTML element, for the same result, which saves you adding the additional anchors for link destinations.
OK. I think this is new. Using HTML5's autofocus will cause a misfire, as will jQuery's focus() method. Took 90 minutes of trial and error to discover this because I thought the issue was image related :)