the first is the compatibility of the operation and a mobile browser: The traditional device users use the mouse (including the touch version) and keyboard to manipulate the page, enlarge the picture, drag elements, page scrolling and so on. Some common mouse and keyboard events such as MouseOver, Mouseout, MouseMove, click, Foucs, Blur and so on provide us with a good page interaction, specifically can refer to W3school.
However, the development of a touchscreen-enabled Web page differs greatly from the traditional Web page. Take the mouse hover event, for example, there is a table on the page, when the mouse pointer to the title of the table you want to show a floating tooltip somewhere nearby. Of course, you want this tooltip to be more noticeable to the browser, so you customize a DIV element and let it show or hide it dynamically through JavaScript. This program is simple and works well on many different versions of browsers on common devices. But if you're browsing the web on a touchscreen-enabled device, the problem is that the device doesn't support the mouse, so the user can't use the mouse to hover the title element of the table. The only device that the user can interact with is to touch or swipe the screen with your finger, but it's weird to use your finger to trigger a traditional mouse hover event on a non-touch friendly web page, and you'll notice that the ToolTip is displayed at the moment your finger touches the screen, And then it disappears immediately. This is because the browser triggers the mouseover and mouseout two events by default, and the two events are only done in a finger-touch screen, and you simply have no way to control it. This is just a small example of many differences, there are many different places, such as you on the traditional device with a mouse click on a picture button does not use to continuously scroll div, and on the touchscreen browser will default to you to display the right-click menu and prevent the event to continue execution. Traditional devices usually at the same time the system allows only one mouse to accept the user's operation, while the touch screen generally support multi-touch or even support a variety of gestures, such as left and right slide, two zoom in and out and rotate.
With the development of HTML5, in order to support the operation of the touchscreen, many browser vendors have added a lot of touch-enabled events to their browser engines. However, since the company does not provide a uniform standard, or the standard in different browser vendors to follow the situation is also quite different, so we have to do for the browser version to do some special processing. This reminds me of IE browser in many ways different from other browsers, this time is no exception!
Here are some pages that describe the support for touch events in different browsers, and readers can look at what's different between them.
Internet Explorer support for touch events: http://blogs.msdn.com/b/ie/archive/2011/09/20/touch-input-for-ie10-and-metro-style-apps.aspx
Firefox browser support for Touch events: Https://developer.mozilla.org/en-US/docs/Web/Guide/Touch_events?redirectlocale=en-US &redirectslug=dom%2ftouch_events
There are basically two camps: IE browser and the WebKit kernel-based browser.
So how can you develop a generic page that supports touch events? Basically, we just need to distinguish between IE and WebKit Kernel browser, the remaining compatibility issues are usually better resolved. This page of MSDN introduces IE's support for pointers and gesture events http://msdn.microsoft.com/zh-cn/library/ie/hh673557.aspx there are ways to detect support for pointer events, which we can use to differentiate between IE and other browsers. See this program snippet below:
if (window.navigator.msPointerEnabled) { /*events for ie only* / document.getelementbyid ("Id0"). AddEventListener ("Mspointerover", function ( e) { /*Add mouse over event for touch*/ if (e.pointertype == e.mspointer_type_ MOUSE) { methods.onmouseover (This, e); } }); document.getElementById ("Id0"). AddEventListener ("Mspointerout", function (e) { /*Add mouse out event for touch*/ if (E.pointertype == e.mspointer_type_mouse) { &Nbsp; methods.onmouseout (this, e); } }); document.getelementbyid ("id0"). AddEventListener ("Mspointerdown", function (e) { if (E.pointertype == e.mspointer_type_touch) { /*Do something for touch input only*/ methods.ontouchinput (This.parentNode); } else { /*Do something for non-touch Input*/ methods.onmouseclick ( This.parentnode); } });} else { /*events for non-ie or ie without mspointerenabled*/ $ (This). Bind ("Touchstart", function (e) { e.preventdefault (); Methods.onmouseclick (This.parentnode); methods.onmouseover (this , e); }); /*common mouse events: mouseover, mouseout, click*/ $ (This). Click (function () { Methods.onmouseclick (this), }); $ (this). Hover ( function (e) { methods.onmouseover (this, e); }, function (e) { methods.onmouseout (this, e); });
The code has two main branches for browsers for IE and WebKit kernels. In IE,mspointerdown events do not automatically block mouse events, so you need to use event.pointertype to determine the pointer type. Event.pointertype is an enumeration variable with a total of three values:
Mspointer_type_touch = 2
Mspointer_type_pen = 3
Mspointer_type_mouse = 4
It's strange why there are no enumeration values with a value of 1? It may be used as a reservation! This means that the Mspointerdown event triggers a mouse-related event as well, in fact the mouse event is the first trigger. So we need to judge the pointer type first, and do different processing. In order to increase the compatibility of the page, so that it can have a better experience on devices that support mouse operations, the code specifically adds mspointerover and mspointerout events, and determines when the pointer type is Mspointer_type_mouse to perform the corresponding mouse event.
Here are a few compatibility issues to consider:
1. The Window.navigator.msPointerEnabled statement only determines whether the browser supports Mspointer related events, and does not determine whether the user's device supports touch operations. Currently only on IE10 the object does not return undefined, and other versions of the browser see the object as not present. If you want to determine whether a user's device supports touch operations, you should use Window.navigator.msMaxTouchPoints, if the object exists and the result is greater than 1, it means that the device supports touch operations and is multi-touch enabled.
2. In IE, mspointer related events will only be triggered when the browser is supported, and if the page elements also have mouse events, the mouse events will also be triggered simultaneously.
3. The browser of the WebKit kernel supports touchstart events, and Mspointer related events are considered invalid on these browsers. The E.preventdefault () statement prevents the default behavior of the mouse so that mouse hover events are not triggered.
As a result, the above code fragment is compatible with both <ie10 and IE10, as well as touch and mouse operations compatible with IE10, and non-ie kernel browsers. One situation is not considered, that is the <ie10 case of touch operation, I believe this device should be difficult to see it!
Of course, you can handle the mouse's click event as a touch event, if there are no other events on the element except click. But if there are mouse hover related events on the element, then the user triggers mouse hover while touch, in which case you might consider using the logic above to handle cross events.
the second is the different aspect ratios of various scales (sometimes need to take into account horizontal screen design )
This is related to the resolution of the problem, which I do not quite understand at present, I do not swim you can read this article:
http://www.zhangxinxu.com/wordpress/2012/08/window-devicepixelratio/
questions about the screen:
Whether it's ipad or Android:
Can be installed in the function of the event after the switch, such as a different screen, screen layout design, CSS use of different and so on.
※ You can use window.orientation to determine whether it is a horizontal or vertical screen after switching.
However: There are several items to note about the above code.
1, window.orientation
After testing, on the ipad, and andriod system above,window.orientation to judge the value of the screen is exactly the opposite.
Window.orientation Value Reference:
| |
window.orientation value |
portrait and screen result |
| Ipad |
90 OR-90 |
Horizontal screen |
| Ipad |
0 or 180 |
Vertical screen |
| Andriod |
0 or 180 |
Horizontal screen |
| Andriod |
90 OR-90 |
Vertical screen |
2, how to tell if your device is an ipad or an Android
Automatic judging device horizontal screen or vertical screen
var autofullscreen = function () {
var supportsorientationchange = "onorientationchange" in window,
Orientationevent = Supportsorientationchange? "Orientationchange": "Resize";
Window.addeventlistener (orientationevent, function () {
var ua = Navigator.userAgent.toLowerCase ();
var devicetype = "";
Determine device type
if (Ua.indexof ("ipad") > 0) {
DeviceType = "Isipad";
} else if (Ua.indexof ("Android") > 0) {
DeviceType = "Isandroid";
} else if (Ua.indexof ("iphone") > 0) {
DeviceType = "Isiphone";
} else {
Return
}
Judging the screen
if ("isipad" = = DeviceType) {
if (Math.Abs (window.orientation) = =) {alert ("I am the horizontal screen of the ipad"); }
else {alert ("I am the vertical screen of the ipad"); }
} else if ("isandroid" = = DeviceType) {
Vertical screen or-90 Horizontal screen 0
if (Math.Abs (window.orientation) = =) {alert ("I am Android's vertical screen"); }
else {
Document.webkitcancelfullscreen ();
Alert ("I am a horizontal screen of Android");
}
} else if ("isiphone" = = DeviceType) {
if (Math.Abs (window.orientation) = = 90) {}
else {}
}
}, False);
}
The third is the touch and phone keyboard operation: this involves a lot of content: recommend you look at this article: http://lilin.hn.cn/201402279837.html summary is very comprehensive; paste some of the article here:
How to turn off keyboard auto capitalization in iOS
We know that in iOS, when the virtual keyboard pops up, by default the keyboard is the first capitalization feature, depending on the business scenario, we may need to turn this feature off, mobile version WebKit provides the autocapitalize attribute for the INPUT element, Turn off the default initial capitalization of the keyboard by specifying autocapitalize= "off".
How to completely prevent users from opening a page in a new window in iOS
Sometimes we may need to prevent users from opening the page in a new window, we can use the A-tag target= "_self" to specify that the user opens in a new window, or the target property remains empty, but you will find that the iOS user at the top of the link long press 3 seconds, iOS will pop up a list button , the user can still open the page in a new window by using these buttons, so the target property specified by the developer is invalidated, but the iOS pop-up button can be disabled by specifying the-webkit-touch-callout style property of the current element to none. This technique is only valid for iOS for Android platforms.
How to resolve box border overflow
When you specify a block-level element, and you define a border for it, set its width to 100%. In the mobile device development process We usually define the text box as width 100%, define it as a block-level element for full-screen adaptive style, but you will find that the element's border (left and right) each pixel will overflow the document, resulting in a horizontal scroll bar, in order to solve this problem, we can add a special The style of the-webkit-box-sizing:border-box, which specifies the size of the box to include the width of the border.
A summary of mobile front end development and PC end Front end development