Web pages and touch-screen devices
Posted: Sun 22 Feb 2015 15:55
This note describes problems with mouse clicks on touch screen devices. Its a general discussion, not limited to BCA Web Services, of course, although Im experiencing it on the BCRA web site.
Web pages often make use of JavaScript events to control what is displayed on the customer's screen. In particular, mouse movements may trigger the mouseover, mouseout and click events. One common use is to cause some aspect of the page to change when the user hovers his mouse over an image.
A problem arises when a touch screen is being used without a mouse. Should the user's finger tap be treated as a mouse 'hover' or a mouse 'click' - or as a totally separate event? Obviously, given time, programmers will become aware of the need to program specifically for touch screens but - in the meantime - there is a need to provide compatibility with older web pages. This is not a trivial issue to deal with, because the browser cannot 'know' what the programmer's intentions were regarding the use of mouseover, mouseout and click events (not to mention all the other mouse-related events that exist).
Browser manufacturers have tried to deal with this as best they can. For example, Chrome 40 will respond to a tap on an element by firing the mouseover and click events, in that order. Subsequent taps will fire only the click event. Tapping elsewhere will fire the mouseout event. This is clearly "fairly sensible" behaviour. Internet Explorer 11, on the other hand, responds to a short tap with mouseover--mouseout--click; and to a longer tap with mouseover--click--mouseout whilst tapping off the element does nothing. This is astounding and bizarre behaviour! It totally subverts the function of the mouseout event. Any programmer using mouseout is going to find that his code does not work in MSIE 11.
There are other incompatibilities. For example, a very long tap fires up the rightclick menu in Chrome. In MSIE it also fires mouseover--mouseout. A double-click, in Chrome, fires click--click--doubleclick but in MSIE it fires mouseover--mouseout and then zooms the screen.
This is causing problems for me, because I am using mouseover and mouseout extensively on various web sites and I now see that those sites are not useable on a touch screen running MSIE. I have had to implement some additional JavaScript that is capable of evaluating the number of taps that a user has performed, so that first tap corresponds to mouseover and second tap corresponds to click. This is a partial solution, but this still does not provide an answer to Microsoft's total subversion of the mouseout event. I cannot see any way, on a touch screen running MSIE, of cancelling an element that has been displayed by hovering/tapping on an element, other than putting it on some sort of timer, perhaps.
Further helpful info at http://quirksmode.org .
To investigate this problem, go to http://bcra.org.uk/mouseclick.html and try giving the buttons there a short or a long tap, or hover or click, to see what events are reported.
You can also look at the images on the BCRA Bookshop page.
Related problem - TITLE attributes. Programmers frequently set the TITLE attribute of an HTML element so that, when the user hovers his mouse over the element, a tool-tip appears. Current advice, from W3.org is ... "Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g. requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet)". But TITLE attributes are very useful, as an "I wonder what this would do if I clicked on it?" sort of thing. To this end, I have written some experimental code that - without requiring changes to the HTML (it uses JS and CSS) - implements a routine of "first tap => show tooltip; second tap => follow link" but I have not implemented it anywhere yet because it will not work in Internet Explorer - not only the mouseout problem mentioned above, but the fact that IE uses a different event model to the rest of the world, which makes it such a pain to add events to elements via JavaScript.
Web pages often make use of JavaScript events to control what is displayed on the customer's screen. In particular, mouse movements may trigger the mouseover, mouseout and click events. One common use is to cause some aspect of the page to change when the user hovers his mouse over an image.
A problem arises when a touch screen is being used without a mouse. Should the user's finger tap be treated as a mouse 'hover' or a mouse 'click' - or as a totally separate event? Obviously, given time, programmers will become aware of the need to program specifically for touch screens but - in the meantime - there is a need to provide compatibility with older web pages. This is not a trivial issue to deal with, because the browser cannot 'know' what the programmer's intentions were regarding the use of mouseover, mouseout and click events (not to mention all the other mouse-related events that exist).
Browser manufacturers have tried to deal with this as best they can. For example, Chrome 40 will respond to a tap on an element by firing the mouseover and click events, in that order. Subsequent taps will fire only the click event. Tapping elsewhere will fire the mouseout event. This is clearly "fairly sensible" behaviour. Internet Explorer 11, on the other hand, responds to a short tap with mouseover--mouseout--click; and to a longer tap with mouseover--click--mouseout whilst tapping off the element does nothing. This is astounding and bizarre behaviour! It totally subverts the function of the mouseout event. Any programmer using mouseout is going to find that his code does not work in MSIE 11.
There are other incompatibilities. For example, a very long tap fires up the rightclick menu in Chrome. In MSIE it also fires mouseover--mouseout. A double-click, in Chrome, fires click--click--doubleclick but in MSIE it fires mouseover--mouseout and then zooms the screen.
This is causing problems for me, because I am using mouseover and mouseout extensively on various web sites and I now see that those sites are not useable on a touch screen running MSIE. I have had to implement some additional JavaScript that is capable of evaluating the number of taps that a user has performed, so that first tap corresponds to mouseover and second tap corresponds to click. This is a partial solution, but this still does not provide an answer to Microsoft's total subversion of the mouseout event. I cannot see any way, on a touch screen running MSIE, of cancelling an element that has been displayed by hovering/tapping on an element, other than putting it on some sort of timer, perhaps.
Further helpful info at http://quirksmode.org .
To investigate this problem, go to http://bcra.org.uk/mouseclick.html and try giving the buttons there a short or a long tap, or hover or click, to see what events are reported.
You can also look at the images on the BCRA Bookshop page.
Related problem - TITLE attributes. Programmers frequently set the TITLE attribute of an HTML element so that, when the user hovers his mouse over the element, a tool-tip appears. Current advice, from W3.org is ... "Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g. requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet)". But TITLE attributes are very useful, as an "I wonder what this would do if I clicked on it?" sort of thing. To this end, I have written some experimental code that - without requiring changes to the HTML (it uses JS and CSS) - implements a routine of "first tap => show tooltip; second tap => follow link" but I have not implemented it anywhere yet because it will not work in Internet Explorer - not only the mouseout problem mentioned above, but the fact that IE uses a different event model to the rest of the world, which makes it such a pain to add events to elements via JavaScript.