Imagine a mobile webpage with a navigation bar at the very top of the page.
Using javascript/jQuery I'd like to be able to detect when a user scrolls "past" the top of the screen.
Let me try to explain: Imagine that the webpage just loaded and you see the navigation bar at the very top of your screen. Now, you put your finger on the screen and drag down. On an iPhone, this will look something like:
I'm looking for something similar to the following:
$(document).ready(function () {
$(window).scroll(function (event) {
var y = $(this).scrollTop();
if(y < -20)) {
//do something
}
Unfortunately, this won't work on Android phones because they don't have the same elastic behavior as iPhones:
The bad news
So, let's start with the bad news: there is no way to get the information you wish for natively. Why? Because once you get into the 'elastic' zone you're dragging the entire webview component down rather than just the content of the document like in your pseudo code.
What does this practically mean? Emulation or Native wrapping
Emulation, the choices
So you will have to run your own solution and you will have to make a couple of choices. First of all if you wish to use elastic scrolling you should note that this is patented by Apple Inc. in patent US7469381 B2. Please go through this patent carefully to ensure you won't be infringing (even if you're building an iOS only app this does not change anything).
Secondly the question is whether you really want to emulate a native experience. There is a big lobby against native experience emulation due to 1) a believe that it can't ever be perfect enough and 2) as operating systems and browser change your code will stay out of date and thus look terrible/weird or possible can even cause entirely unexpected behaviour/combinations.
Secondly you will have to decide whether you wish for the same elastic behaviour on android or whether you wish to give a more native like experice on android. Personally I believe it makes for some excellent UX, so I wouldn't explicitedly disadvice you from using an elastic effect, however it is something you should consider carefully.
Emulation, the scripts
Most scripts that provide similar emulation to what you want are "pull to refresh" scripts. Depending on your specific wishes you should simply use one of those scripts and either alter them or use some CSS to hide the message inside them.
Hook.js - Not perfect emulation of the native experience and uses the old iOS background, but a pretty good option none the less, to hide the spinner just use
.hook-spinner{
display:none;
}
iScroll.js - Very well developed code and behaves excellently. Disadvantage is that it provides a lot more than what you're looking for which might be either a good thing or a bad thing. You can find a sample implementation of pull to refresh behaviour here, but do note it's for an older version of iScroll, in the last version the example seems not to have been implemented, but it should be quite similar. Just look at the code to see how to remove the pull to refresh message.
jQuery scrollz - Just one more option. Seems to be comparable to hook.js, but does have some iScroll like features as well. You can 'remove' the message by specifying the pullHeaderHTML with empty HTML strings.
Native wrapping
The alternative, which I am convinced you do not want to do, but I do want to add for the sake of completeness, is to distribute your app as a native app for example bundled up in phonegap. However to get this working would require a fair number of changes to the phonegap code itself and would not be an advisable approach (I have once developed a phonegap app using native components and interactions 'around' it triggering various javascript events, although doable and presenting certain advantages it's not something I would advice).
So..I'm not sure what do you need this for.
If it's for a ListView - you can override onOverScrolled
If you need this for ScrollView - there's a way by also extending it. I don't remember now, but if you need it - I can find it.
If it's for a WebView inside your app - I'm pretty sure it's not possible. The amount of control you have on the way web pages are rendered and manipulated is limited.
If you want the Chrome/stock browser to act the way it does on iOS - I don't think it's possible unless you get the browser's code and change it yourself :)
Related
Are there any docs or training materials available that advise the best way to include multiple jQuery plugins in an abstract way, allowing for extension of those plugins, and also global control of things like events, setTimeout() etc?
I want to be able to do these kind of things:
Extend someone else's jQuery plugin, e.g. if I want to add a new feature, but not touch the original codebase
Have my own server-side detection script pass a value to JS (using a HTML meta tag) so JS can detect that and then decide which script to use (e.g. tone down some of the jQuery for lesser devices)
Better control all the events that are attached
setTimeout() - I have loads of these dotted around the place at various intervals - I want to control all this in one function
Add my own fixes to jQuery scripts. If I download a ready-made one and use it I always find I can improve usability - especially on mobile devices - so I want to add my own fixes and improvements.
Control the resize event. There's all sorts going on at the moment and it's quite a job triggering a full re-size when I write new code (and the resize is pretty slow on some mobile devices)
You can use RequireJS or similar library to load scripts dynamically depending on screen size or navigator's user agent parameter (You will need to set condition checking yourself though).
I'm trying to add an android-like spinner to my mobile website. To put everyone in context the site is access via a WebView in an android application not from the phone/tablet browser.
Now the problem is adding a nice jQuery android-like spinner or spawning a native control that looks something like this:
Follow this link for image. Image taken from my phone on the Google calendar app.
I really don't want the solution posted here.
For several reasons:
- the plus button on top and bottom looks awful
- doesn't apply for other types of spinners that I have such as states (FL, CA, etc).
- I might need one, two or three spinners depending on the case
All those conditions completely discard the native DatePicker and I don't know if it's possible to get rid of the + things in it to make it look like the image above. If the case, that wouldn't solve the problem for the state spinner.
We also have an iPhone version of the app and we use cubiq spinning wheel but i don't want iPhone look-n-feel for the android version.
Thanks!
This one looks like a promising solution but I haven't tried yet.
http://mobiscroll.com/
I have a question about Javascript widgets. The widget I am working on simply embeds content on a page instead of using iframes. So far it looks good. But there are cases where some users layouts are messing up the widget. For example, the widget might require a width of 300px to appear. But the parent div is set to 250px and hence the right part of the widget is cut off.
I was wondering what sort of precautions should be taken to prevent this? I was talking to the product manager who mentioned he wanted me to check the parent div elements and get the size and then show an alternate message if their size is not accurate. But again, since this is Javascript and the widget is supported in many diff browsers(including IE6), I am wondering how fail-safe this method would be? What if I need to iterate the DOM all the way up before getting a valid size? I am also worried about performance here. This extra checks would slow down the delivery of my widget content to "good users" since I am adding a layer of complexity to all users. I don't want to penalize good users just because of the few errant ones.
I am not using any sort of JS library here, so any solution should not suggest the use of one. Also, the reason for not using a library was simply not to add extra weight to the page load to deliver a widget. I understand that "jquery" for example is small, but in my case, even 24k compressed seems like an overkill for a widget delivery that contains no core code for the widget.
Has anyone dealt with such issues before? What are your solutions to these?
There are reliable ways of determining the size of an element using JavaScript. You're quite right that you may need to iterate up the tree in some cases, but the answer you get will ultimately be quite valid.
Although you don't want to directly include any library code in this project, you may consider looking at how the major libraries implement their "what's the width of this element" functions to drive your own implementation.
Beware of quirks mode too.
I'd check to see of the page has Jquery, if not load it into the page using no-conflict mode. Then use jQuery to examine the page.
See: How to embed Javascript widget that depends on jQuery into an unknown environment
We have a nav that expands on rollover (based on this code: http://www.dynamicdrive.com/dynamicindex1/droptabmenu.htm).
First, should we have a no-javascript version of the nav?
If yes, what is the best way to do so?
Yes you should always have a non-javascript version of your navigation.
The best way to do this is to apply any styles that hide sub-menus with javascript - so if the javascript isn't run the whole menu will be visible.
The HTML for the menu you've linked to looks fine - <ul>s and <a>s - nice and easy for a spider or non-javascript user to read.
It's always a good idea to have a no-Javascript version of everything.
Search engine robots usually do not interpret Javascript, so your pages might not be indexed if they can't be reached without Javascript.
A sitemap page that simply has a link to every static page on your site is the easiest way to make sure everyone can get to anywhere.
You may want to use unobtrusive javascript, which basically means have no javascript in your html page, just load the javascript files.
Now, if you start with a menu on the left, for navigation, using <li> and anchor tags then you can have some navigation without javascript.
So, if your javascript runs, the first thing it should do, when the dom tree is ready, is to set display: none on the navigation div and put in the new, more interactive navigation bar.
This way you can see how it works without any javascript.
Or, you can have a message telling them that javascript is required and do nothing else, but this would also be hidden as above.
I prefer to have things work, even if it has less functionality, without javascript, when possible.
Don't get me wrong: It's a good idea to support browsers that don't have JavaScript turned on, especially for something as simple as a menu.
However, when a project doesn't have it in the budget, or the application that you're writing is deeply dependent on JavaScript, it just doesn't make sense to support it.
Statistic from w3c and the counter indicate that 93% to 95% of users have JavaScript enabled. Now, mind you that this is a global demographic. To really determine if it's worth your time and money, it would behoove you to do your own statistics to determine what percentage of your traffic/demographic has JavaScript enabled.
As a side note: for reasons similar to why people are moving away from supporting IE 6, my company is also moving away from noscript support. Especially in large scale RIA's, it's just not practical to write the same thing twice. Maintaining two code bases for one project is not my idea of a good time. But of course, this is always based on the client and the target demographic.
Uhm I'm not sure if anyone has encountered this problem
a brief description is on IE6 any <select> objects get displayed over any other item, even div's... meaning if you have a fancy javascript effect that displays a div that's supposed to be on top of everything (e.g: lightbox, multibox etc..) onclick of a certain element and that div overlaps a <select> your div get's to be displayed as if it's under the <select> [on this case a max and minimum z-index doesn't work ]
I've tried googling and found the iframe shim solution
but I wanted some pretty clean alternatives
or better yet has anyone found a better solution?
since the method using iframes uses around 130mb of ram might slow down poor people's machines
You don't have to hide every select using a loop. All you need is a CSS rule like:
* html .hideSelects select { visibility: hidden; }
And the following JavaScript:
//hide:
document.body.className +=' hideSelects'
//show:
document.body.className = document.body.className.replace(' hideSelects', '');
(Or, you can use your favourite addClass / removeClass implementation).
There is a plugin for jquery called bgiframe that makes the iframe method quite easy to implement.
Personally, as a web developer, I'm to the point where I no longer care about the user experience in IE6. I'll make it render as close to "correct" as possible, and make sure it's functional, but as far as speed goes, too bad. They can upgrade. IE7 (though still quite slow, compared to every other browser) has been out for 2 years (almost to the day!). IE8 is going to be out shortly. Firefox is available for every platform. Safari is also an option (and super fast). Opera is available for most/every platform.
IE6 was released in over 7 years ago. IMHO, there is no reason to still be using it, other than lazy users and incompetent IT departments (or if you're a web developer).
in case anyone is interested, here's some IE shimming code.
* html .shimmed {
_azimuth: expression(
this.shimmed = this.shimmed || 'shimmed:'+this.insertAdjacentHTML('beforeBegin','<iframe style="filter:progid:DXImageTransform.Microsoft.Alpha(style=0,opacity=0);position:absolute;top:0px;left:0px;width:100%;height:100%" frameBorder=0 scrolling=no src="javascript:false;document.write('+"''"+');"></iframe>'),
'inherit');
}
ref: this gist by subtleGradient and this post by Zach Leatherman
Prior to IE7 the drop down list was a "windowed" control meaning that it was rendered as a control directly by Windows rather than the browser synthesizing it. As such, it wasn't possible for it to support z-indexing against other synthesized controls.
In order to appear over a DDL, you must use another windowed control, like IFRAME. You can also use a little known IE-only feature called window.createPopup() which essentially makes a chromeless popup. It has limitations, like unstoppable click-out, but they are actually kinda helpful if you are building a hover menu system.
The simplest and most elegant solution to that annoying IE bug is found at: http://docs.jquery.com/Plugins/bgiframe using jQuery.
I reached that conclusion after trying for 2 days to make it work with WebSphere Portal / Portal Applications where everything is dynamic, including the fly-over menu.
There's also the activex method, which I'm starting to explore. It requires creating conditional code to use an activex control instead of a select box for ie6. There's a demo script showing the technique, which is discussed in more detail here.
Update: it appears that MS Office is required for the active-x control to be on the user's machine. In theory, it might be possible to include that somewhere, somehow, but that's getting a lot messier.
I know many people suggested their own tips, but in my case, I just simply hide select using jquery like the below.
$(':date').dateinput({
format: 'dd/mm/yyyy',
onBeforeShow: function(event) {
$('select').hide();
},
onHide: function(event) {
$('select').show();
}
});