|
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
quirksmode.org.
To investigate this problem, try giving the button to the right a short or
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. |
Demonstration
Event results...
|