Jquery Mouse Events Click and Click Again

The click issue is quite unproblematic and piece of cake to utilise; yous listen for the event and run lawmaking when the upshot is fired. It works on just about every HTML element there is, a core feature of the DOM API.

As often the example with the DOM and JavaScript, there are nuances to consider. Some nuances with the click event are typically non much a business organisation. They are minor and probably near people would never even discover them in the majority of use cases.

Take, for example, the click event listening to the grandfather of interactive elements, the <button> element. There are nuances associated with button clicks and these nuances, like the difference betwixt a "click" from a mouse pointer and "click" from the keyboard. Seen this mode, a click is non e'er a "click" the manner it'due south typically defined. I actually have run into situations (though not many) where distinguishing betwixt those ii types of clicks comes in handy.

How do nosotros distinguish between different types of clicks? That's what we're diving into!

First things first

The <button> element, as described by MDN, is simply:

The HTML chemical element represents a clickable push button, used to submit forms or anywhere in a document for accessible, standard button functionality. By default, HTML buttons are presented in a mode resembling the platform the user agent runs on, just you lot can alter buttons' appearance with CSS.

The office we'll cover is plainly the "anywhere in a document for attainable, standard button functionality" function of that clarification. As you may know, a push button chemical element can take native functionality inside a form, for instance it can submit a class in some situations. We are only really concerning ourselves over the basic clicking part of the chemical element. Then consider just a simple button placed on the page for specific functionality when someone interacts with it.

Consider that I said "interacts with information technology" instead of just clicking it. For historical and usability reasons, ane can "click" the button by putting focus on information technology with tabbing and then using the Space or Enter key on the keyboard. This is a bit of overlap with keyboard navigation and accessibility; this native feature existed fashion before accessibility was a concern. Nonetheless the legacy feature does assist a great deal with accessibility for obvious reasons.

In the example above, you can click the button and its text characterization will change. After a moment the original text will reset. You lot tin can also click somewhere else within the pen, tab to put focus on the button, and and so use Space or Enter to "click" it. The aforementioned text appears and resets too. There is no JavaScript to handle the keyboard functionality; it'due south a native feature of the browser. Fundamentally, in this instance the push button is only aware of the click event, but non how it happened.

One interesting divergence to consider is the behavior of a button beyond different browsers, peculiarly the way it is styled. The buttons in these examples are set to shift colors on its agile state; so you click information technology and information technology turns majestic. Consider this image that shows the states when interacting with the keyboard.

Keyboard Interaction States

The first is the static state, the second is when the button has focus from a keyboard tabbing onto it, the third is the keyboard interaction, and the quaternary is the result of the interaction. With Firefox you will just see the outset two and concluding states; when interacting with either Enter or Space keys to "click" information technology you do not run across the 3rd state. It stays with the second, or "focused", state during the interaction and then shifts to the last one. The text changes every bit expected just the colors do not. Chrome gives us a bit more as you'll see the starting time two states the same as Firefox. If you use the Space key to "click" the push y'all'll see the third state with the color modify then the last. Interestingly enough, with Chrome if yous utilise Enter to interact with the push button you won't see the third land with the colour change, much like Firefox. In case you are curious, Safari behaves the same as Chrome.

The code for the upshot listener is quite elementary:

          const button = document.querySelector('#push');  button.addEventListener('click', () => {   button.innerText = 'Button Clicked!';      window.setTimeout(() => {     button.innerText = '"click" me';   }, 2000); });        

At present, let'due south consider something here with this code. What if you found yourself in a situation where you wanted to know what caused the "click" to happen? The click consequence is unremarkably tied to a pointer device, typically the mouse, and still here the Space or Enter fundamental are triggering the same event. Other form elements accept similar functionality depending on context, merely any elements that are not interactive by default would crave an additional keyboard event to work. The button chemical element doesn't crave this additional event listener.

I won't become too far into reasons for wanting to know what triggered the click consequence. I can say that I have occasionally ran into situations where it was helpful to know. Sometimes for styling reasons, sometimes accessibility, and sometimes for specific functionality. Often different context or situations provide for unlike reasons.

Consider the following not as The Way™ but more than of an exploration of these nuances we're talking about. Nosotros'll explore handling the various means to interact with a button chemical element, the events generated, and leveraging specific features of these events. Hopefully the following examples tin can provide some helpful data from the events; or possibly spread out to other HTML elements, as needed.

Which is which?

One simple way to know a keyboard versus mouse click event is leveraging the keyup and mouseup events, taking the click effect out of the equation.

Now, when yous utilize the mouse or the keyboard, the changed text reflects which issue is which. The keyboard version will fifty-fifty inform you of a Infinite versus Enter central existence used.

Here's the new lawmaking:

          const push button = certificate.querySelector('#push button');  function reset () {   window.setTimeout(() => {     button.innerText = '"click" me';   }, 2000); }  push button.addEventListener('mouseup', (e) => {   if (east.button === 0) {     button.innerText = 'MouseUp Event!';     reset();   } });  button.addEventListener('keyup', (e) => {   if (eastward.code === 'Space' || eastward.code === 'Enter') {     button.innerText = `KeyUp Event: ${e.code}`;     reset();   } });        

A bit verbose, true, but we'll go to a slight refactor in a bit. This example gets the point beyond about a dash that needs to be handled. The mouseup and keyup events have their own features to account for in this situation.

With the mouseup event, about every button on the mouse could trigger this event. Nosotros usually wouldn't want the right mouse button triggering a "click" event on the push, for instance. So we look for the e.push with the value of 0 to place the primary mouse push. That style information technology works the aforementioned as with the click upshot all the same nosotros know for a fact it was the mouse.

With the keyup issue, the same thing happens where nigh every key on the keyboard will trigger this event. And then we expect at the event's code property to wait for the Space or Enter key to be pressed. So now it works the same as the click event merely we know the keyboard was used. We even know which of the two keys nosotros're expecting to work on the button.

Another take to determine which is which

While the previous instance works, information technology seems like a bit too much code for such a simple concept. Nosotros really just want to know if the "click" came from a mouse or a keyboard. In virtually cases we probably wouldn't care if the source of the click was either the Infinite or Enter keys. But, if we exercise care, nosotros tin can take advantage of the keyup event properties to notation which is which.

Cached in the diverse specifications about the click event (which leads us to the UI Events specification) in that location are certain backdrop assigned to the upshot. Some browsers have more, but I want to focus on the detail belongings for the moment. This property is tied direct to the mouse input that fired the event itself. And then if the mouse button was used then the property should return a 1 every bit the value. It can too potentially report a higher number representing multiple clicks that is often tied to the double-click threshold adamant by the OS of the device. Equally a bonus, this property reports a zero for the click result being caused past something other than the mouse input, such equally the keyboard.

I'll accept a moment for a shout out to Jimmy downward in the comments. I originally had a different method to determining keyboard versus mouse clicking, still information technology wasn't consistent across all browsers since Safari reported values slightly dissimilar. Jimmy suggested the detail property equally it was more consistent; and then I updated my examples accordingly. Thanks to Jimmy for the proposition!

Here's our new lawmaking:

          const button = document.querySelector('#button');  button.addEventListener('click', (e) => {   push button.innerText = east.detail === 0 ? 'Keyboard Click Event!' : 'Mouse Click Consequence!';      window.setTimeout(() => {     button.innerText = '"click" me';   }, 2000); });        

Back to just the click event, but this time nosotros look for the holding value to determine whether this is a keyboard or mouse "click." Although notice we no longer have a style to determine what fundamental was used on the keyboard, but that is not much of a concern in this context.

Which one out of many?

Now is a good fourth dimension to talk nearly Pointer Events. As described by MDN:

Much of today's web content assumes the user's pointing device volition be a mouse. However, since many devices back up other types of pointing input devices, such as pen/stylus and bear upon surfaces, extensions to the existing pointing device event models are needed. Pointer events address that need.

So now permit's consider having a need for knowing what type of pointer was involved in clicking that button. Relying on just the click consequence doesn't actually provide this information. Chrome does have an interesting property in the click issue, sourceCapabilities. This holding in turn has a property named firesTouchEvents that is a boolean. This data isn't e'er available since Firefox and Safari do not support this still. Withal the arrow event is available much everywhere, even IE11 of all browsers.

This event tin provide interesting data nearly touch or pen events. Things similar pressure, contact size, tilt, and more. For our instance here we're just going to focus on pointerType, which tells us the device blazon that acquired the event.

Some other point to brand in relation to the detail property in the click outcome mentioned above. The pointer event also has a detail property but at this fourth dimension the spec states that the value of that belongings should always be nada. Which obviously conflicts with the previous thought that a value of zip means the keyboard and a value higher up zero ways mouse input. Since nosotros can't rely on that property in the pointer issue, that it makes it difficult to include both click and pointer events within the same situation. To be fair, y'all probably wouldn't want to do that anyhow.

Clicking on the button will now tell yous the arrow that was used. The code for this is quite simple:

          const button = document.querySelector('#button');  button.addEventListener('pointerup', (east) => {   button.innerText = `Pointer Result: ${e.pointerType}`;      window.setTimeout(() => {     push.innerText = '"click" me';   }, 2000); });        

Really, not that much dissimilar than the previous examples. We listen for the pointerup result on the button and output the event's pointerType. The divergence now is there is no event listener for a click event. So tabbing onto the push button and using space or enter cardinal does nothing. The click event still fires, but we're not listening for it. At this point we only have code tied to the push that only responds to the pointer event.

That evidently leaves a gap in functionality, the keyboard interactivity, and then we notwithstanding need to include a click result. Since we're already using the pointer event for the more traditional mouse click (and other pointer events) nosotros take to lock down the click event. We need to only let the keyboard itself to trigger the click consequence.

The code for this is similar to the "Which Is Which" case up above. The departure existence we utilise pointerup instead of mouseup:

          const button = document.querySelector('#button');  role reset () {   window.setTimeout(() => {     button.innerText = '"click" me';   }, 2000); }  push button.addEventListener('pointerup', (eastward) => {   button.innerText = `Pointer Upshot: ${e.pointerType}`;   reset(); });  button.addEventListener('click', (e) => {   if (east.detail === 0) {     button.innerText = 'Keyboard  ||Click Outcome!';     reset();   } });        

Here nosotros're using the detail property again to determine if the click was caused by the keyboard. This way a mouse click would be handled past the pointer event. If i wanted to know if the central used was infinite or enter, then the keyup example above could be used. Even and so, the keyup issue could be used instead of the click event depending on how you wanted to approach it.

Anoher accept to determine which one out of many

In the ever-present need to refactor for cleaner code, we tin effort a different way to code this.

Yep, works the same as before. At present the lawmaking is:

          const push button = document.querySelector('#button');  function btn_handler (east) {   if (e.type === 'click' && e.detail > 0) {     return faux;   } else if (east.pointerType) {     button.innerText = `Pointer Event: ${due east.pointerType}`;   } else if (east.detail === 0) {     push button.innerText = 'Keyboard Click Event!';   } else {     button.innerText = 'Something clicked this?';   }      window.setTimeout(() => {     push button.innerText = '"click" me';   }, 2000); }  button.addEventListener('pointerup', btn_handler); button.addEventListener('click', btn_handler);        

Another scaled downwards version to consider: this time we've reduced our code downwardly to a single handler method that both pointerup and click events telephone call. Kickoff we detect if the mouse "click" caused the event considering the detail belongings has a value higher than aught; if it does, we wish to ignore it in favor of the pointer event.

Then the method checks for the pointer event, and upon finding that, information technology reports which pointer type occurred. Otherwise, the method checks for keyboard interactions, if detail equals zero, and reports accordingly. If neither of those are the culprit, it just reports that something caused this code to run.

So here we have a decent number of examples on how to handle button interactions while reporting the source of those interactions. Yet, this is merely one of the handful of form elements that we are and so accustomed to using in projects. How does similar lawmaking work with other elements?

Checking checkboxes

Indeed, similar code does piece of work very much the aforementioned way with checkboxes.

There are a few more than nuances, as yous might look past now. The normal usage of <input type="checkbox"> is a related label element that is tied to the input via the for attribute. One major feature of this combination is that clicking on the label element will bank check the related checkbox.

At present, if nosotros were to attach event listeners for the click event on both elements, we go back what should be obvious results, even if they are a bit strange. For example, we become one click upshot fired when clicking the checkbox. If we click the characterization, we get two click events fired instead. If nosotros were to console.log the target of those events, we'll see on the double outcome that i is for the characterization (which makes sense as nosotros clicked it), but at that place's a 2d event from the checkbox. Fifty-fifty though I know these should be the expected results, it is a chip strange because we're expecting results from user interactions. Yet the results include interactions caused by the browser.

So, the next step is to look at what happens if we were to listen for pointerup, only like some of the previous examples, in the same scenarios. In that case, we don't get ii events when clicking on the label chemical element. This likewise makes sense every bit nosotros're no longer listening for the click result that is beingness fired from the checkbox when the label is clicked.

At that place's yet some other scenario to consider. Remember that nosotros have the selection to put the checkbox inside the characterization element, which is mutual with custom-built checkboxes for styling purposes.

          <label for="newsletter">   <input blazon="checkbox" />   Subscribe to my newsletter </label>        

In this case, we actually but need to put an outcome listener on the label and non the checkbox itself. This reduces the number of outcome listeners involved, and however we go the same results. Clicks events are fired as a unmarried event for clicking on the label and ii events if you click on the checkbox. The pointerup events do the same equally before too, unmarried events if clicking on either element.

These are all things to consider when trying to mimic the behavior of the previous examples with the push element. Thankfully, there's not too much to it. Here's an example of seeing what type of interaction was washed with a checkbox form element:

This example includes both types of checkbox scenarios mentioned to a higher place; the top line is a checkbox/label combination with the for attribute, and the bottom i is a checkbox inside the label. Clicking either one will output a message below them stating which type of interaction happened. So click on one with a mouse or utilise the keyboard to navigate to them and and so interact with Space; but like the push examples, information technology should tell you which interaction blazon causes it.

To make things easier in terms of how many event listeners I needed, I wrapped the checkboxes with a container div that actually responds to the checkbox interactions. You wouldn't necessarily have to do it this style, but it was a convenient mode to do this for my needs.

          const checkbox_container = document.querySelector('#checkbox_container'); const checkbox_msg = document.querySelector('#checkbox_msg');  function chk_handler (e) {   if (eastward.target.tagName === 'LABEL' || e.target.tagName === 'INPUT') {     if (e.pointerType) {       checkbox_msg.innerText = `Pointer Event: ${east.pointerType}`;     } else if (e.code === 'Infinite') {       checkbox_msg.innerText = `Keyboard Upshot: ${e.code}`;     }          window.setTimeout(() => {       checkbox_msg.innerText = 'waiting...';     }, 2000);   } }  checkbox_container.addEventListener('pointerup', chk_handler); checkbox_container.addEventListener('keyup', chk_handler);        

So, since we're listening for these events on a container div I wanted to lock down the targets to just the label and the input. Technically it would exist possible in some cases to "click" on the container div itself; which nosotros wouldn't desire to happen. Then we check for a pointer effect and update the bulletin. After that we effort to place the Space cardinal code that would have come from the keyup event. You may call up that the push button examples higher up used both the Enter and Infinite keys. It turns out that checkboxes often don't react to the Enter primal in browsers. Another fun dash to keep in mind.

Radioing your radio buttons

Thankfully, for radio button inputs, nosotros tin even so use the aforementioned code with like HTML structures. This generally works the aforementioned because checkboxes and radio buttons are essentially created the same fashion—it's just that radio buttons tend to come up in groups tied together while checkboxes are individuals fifty-fifty in a group. As you lot'll encounter in the following example, it works the same:

Once more, same lawmaking attached to a similar container div to prevent having to do a number of event listeners for every related element.

When a dash tin exist an opportunity

I felt that "nuance" was a adept word choice because the things we covered hither are not really "issues" with the typical negative connotation that word tends to take in programming circles. I always endeavor to see such things as learning experiences or opportunities. How can I leverage things I know today to push a piddling further alee, or maybe it's time to explore outward into new things to solve issues I face. Hopefully, the examples above provide a somewhat different way to wait at things depending on the needs of the project at hand.

Despite this commodity focusing more on form elements because of the click dash they tend to have with keyboard interactions, some or all of this can be expanded into other elements. It all depends on the context of the situation. For example, I recollect having to do multiple events on the aforementioned elements depending on the context many times; often for accessibility and keyboard navigation reasons. Have you built a custom <select> chemical element to accept a nicer blueprint than the standard one, that also responds to keyboard navigation? You lot'll run into what I mean when you get at that place.

Only recall: a "click" today doesn't always have to be what we think a click has always been.

vasquezbronst.blogspot.com

Source: https://css-tricks.com/when-a-click-is-not-just-a-click/

Share this post