Mobile development with touch event or click event

Front-end development now includes cross-browser, cross-platform (different operating systems) and cross-device (different size devices) development.

In the process of mobile development, do you choose the Touch event or the click event? Yes, please do not despise click,click in mobile development is also good.

First, let me start by talking about two issues with the touch event in development:

The 1.touch event has a click-through problem in some scenarios.

The 2.touchstart event is triggered by touching the screen, and the Touchend event is triggered when the finger leaves the screen, and sometimes we just want to swipe the screen and trigger both events.

1 cause of the problem: the sequence of events triggered by the mobile event is Touchstart-->touchend-->click. Add two elements A and b,b above a, when we use the callback function in the touch event to hide the B element, then the a element triggers the Click event. This is because the click event has a 300ms delay, and after 300ms, the B element is hidden, the browser triggers the Click event, and the B element is hidden, and the event is distributed over the a element.

Click through this issue to cancel the default event in the Touch event, E.preventdefault () to resolve.

2 problems are not reconciled.

Second, there are problems with the Click event:

The problem with 1.click events is the 300ms latency problem.

Many developers think that in the early days of mobile development, it was possible to use the Click event, because the response of the device was only 300ms, which was imperceptible. However, as the user interaction experience becomes more demanding, the 300ms becomes intolerable.

What is the origin of 300ms latency on the mobile side?

This goes back to the beginning of 2007. Apple, on the eve of the launch of its first iPhone, encountered a problem: the site was designed for large-screen devices. So Apple's engineers made some promises to tackle the problem of the IPhone's small screen browsing desktop-side site.

The most famous of these is the double-click scaling (double tap to zoom), which is the main reason for the 300 millisecond delay.

Double-click Zoom, as the name implies, using your finger to quickly click on the screen two times, and IOS comes with a Safari browser that zooms the page to its original scale. So what's the connection to the 300 millisecond delay? Suppose such a scene. The user clicked on a link in IOS Safari. Since the user can double-click the zoom or double-click the scrolling operation, when the user taps the screen one time, the browser does not immediately determine whether the user is really going to open the link, or want to double-click the operation. As a result, IOS Safari waits 300 milliseconds to determine if the user clicked the screen again. Given the success of the iphone, other mobile browsers have replicated most of the iphone Safari's conventions, including double-click zooming, which is now available in almost all mobile browsers. Before people just touch the mobile page, in the joy of the time often do not care this 300ms delay problem, but now touch interface like springing up, the user to the experience of higher demand, this 300ms brings the lag slowly become difficult to accept.

That is, the browser will have some default behavior, such as double-click Zoom, double-click Scrolling, etc., these behaviors are mainly designed for the desktop Web site in the mobile device browsing experience. While the user is working, the mobile browser will prioritize whether the user triggers the default behavior.

Browser Developer's Solution:

1. Disable zooming.

When you include the following tags in your HTML document:

<meta name= "viewport" content= "User-scalable=no"/>

<meta name= "viewport" content= "init-scale=1.0,maximum-scale=1.0"/>

Indicates that the page is not scalable, then double-click the Zoom function is meaningless, the browser can disable the default double-click Scaling Behavior and remove the 300ms click Delay.

The disadvantage of this method is that if we face the small print of desktop application, enlarge look is impossible.

This method completely disables scaling, and we just want to disable the double-click scaling behavior.

2. Change the default viewport width

<meta name= "viewport" content= "Width=device-width"/>

Initially, in order for the desktop site to be displayed in the mobile browser, the default viewport width of the mobile browser is not equal to the window width of the device browser, but is larger than the device window browser, about 980px.

We set the width of the mobile browser to the width of the device's window by using the above tag. With the popularity of the response, a lot of sites have been on the mobile side has done a good job, this time you do not need to double-click scaling. If you can identify a site is a responsive site, then the browser can be considered to have been optimized and adapted to the mobile side, so long without double-click operation.

The advantage of this approach is that it does not have to disable scaling completely, but simply disables the browser's double-click scaling behavior.

For more solutions, check out this article: http://www.jianshu.com/p/6e2b68a93c88

All in all, when the mobile development, if the page is relatively simple, you can use the touch event, if the page is more complex, directly with the Click event, the advantage of agreeing with the Click event is that you should not worry about page click Penetration.

Mobile development with touch event or click event