Note: Using stopPropagation
is something that should be avoided as it breaks normal event flow in the DOM. See this CSS Tricks article for more information. Consider using this method instead.
Attach a click event to the document body which closes the window. Attach a separate click event to the container which stops propagation to the document body.
$(window).click(function() {
//Hide the menus if visible
});
$('#menucontainer').click(function(event){
event.stopPropagation();
});
Warning! This answer is too old and doesn't work on modern browsers.
I'm not the poster of this answer, but at the time of writing this, this is the most voted answer by far in both positive and negative votes (+1035 -17), and it's still marked as accepted answer (probably because the original poster of the question is the one who wrote this answer).
As already noted many times in the comments, this answer does not work on most browsers anymore (and seems to be failing to do that since 2013).
After over an hour of tweaking, testing, and trying different styles of markup, I think I may have a decent solution. The requirements for this particular project were:
- Inputs must be on their own line.
- Checkbox inputs need to align vertically with the label text similarly (if not identically) across all browsers.
- If the label text wraps, it needs to be indented (so no wrapping down underneath the checkbox).
Before I get into any explanation, I'll just give you the code:
label {
display: block;
padding-left: 15px;
text-indent: -15px;
}
input {
width: 13px;
height: 13px;
padding: 0;
margin:0;
vertical-align: bottom;
position: relative;
top: -1px;
*overflow: hidden;
}
<form>
<div>
<label><input type="checkbox" /> Label text</label>
</div>
</form>
Here is the working example in JSFiddle.
This code assumes that you're using a reset like Eric Meyer's that doesn't override form input margins and padding (hence putting margin and padding resets in the input CSS). Obviously in a live environment you'll probably be nesting/overriding stuff to support other input elements, but I wanted to keep things simple.
Things to note:
- The
*overflow
declaration is an inline IE hack (the star-property hack). Both IE 6 and 7 will notice it, but Safari and Firefox will properly ignore it. I think it might be valid CSS, but you're still better off with conditional comments; just used it for simplicity.
- As best I can tell, the only
vertical-align
statement that was consistent across browsers was vertical-align: bottom
. Setting this and then relatively positioning upwards behaved almost identically in Safari, Firefox and IE with only a pixel or two of discrepancy.
- The major problem in working with alignment is that IE sticks a bunch of mysterious space around input elements. It isn't padding or margin, and it's damned persistent. Setting a width and height on the checkbox and then
overflow: hidden
for some reason cuts off the extra space and allows IE's positioning to act very similarly to Safari and Firefox.
- Depending on your text sizing, you'll no doubt need to adjust the relative positioning, width, height, and so forth to get things looking right.
Hope this helps someone else! I haven't tried this specific technique on any projects other than the one I was working on this morning, so definitely pipe up if you find something that works more consistently.
Warning! This answer is too old and doesn't work on modern browsers.
Best Solution
(Note: As per Sharky's feedback, I've included code to detect backspaces)
So, I've seen these questions frequently on SO, and have recently run into the issue of controlling back button functionality myself. After a few days of searching for the best solution for my application (Single-Page with Hash Navigation), I've come up with a simple, cross-browser, library-less system for detecting the back button.
Most people recommend using:
However, this function will also be called when a user uses on in-page element that changes the location hash. Not the best user experience when your user clicks and the page goes backwards or forwards.
To give you a general outline of my system, I'm filling up an array with previous hashes as my user moves through the interface. It looks something like this:
Pretty straight forward. I do this to ensure cross-browser support, as well as support for older browsers. Simply pass the new hash to the function, and it'll store it for you and then change the hash (which is then put into the browser's history).
I also utilise an in-page back button that moves the user between pages using the
lasthash
array. It looks like this:So this will move the user back to the last hash, and remove that last hash from the array (I have no forward button right now).
So. How do I detect whether or not a user has used my in-page back button, or the browser button?
At first I looked at
window.onbeforeunload
, but to no avail - that is only called if the user is going to change pages. This does not happen in a single-page-application using hash navigation.So, after some more digging, I saw recommendations for trying to set a flag variable. The issue with this in my case, is that I would try to set it, but as everything is asynchronous, it wouldn't always be set in time for the if statement in the hash change.
.onMouseDown
wasn't always called in click, and adding it to an onclick wouldn't ever trigger it fast enough.This is when I started to look at the difference between
document
, andwindow
. My final solution was to set the flag usingdocument.onmouseover
, and disable it usingdocument.onmouseleave
.What happens is that while the user's mouse is inside the document area (read: the rendered page, but excluding the browser frame), my boolean is set to
true
. As soon as the mouse leaves the document area, the boolean flips tofalse
.This way, I can change my
window.onhashchange
to:You'll note the check for
#undefined
. This is because if there is no history available in my array, it returnsundefined
. I use this to ask the user if they want to leave using awindow.onbeforeunload
event.So, in short, and for people that aren't necessarily using an in-page back button or an array to store the history:
And there you have it. a simple, three-part way to detect back button usage vs in-page elements with regards to hash navigation.
EDIT:
To ensure that the user doesn't use backspace to trigger the back event, you can also include the following (Thanks to @thetoolman on this Question):