WTF a tap = mouseover!?

[jscheuer1]

Does anyone else think it's at least a little bit creepy that a tap fires a mouseover event? I mean, hmm a click doesn't, so why does a tap? How does a tap firing a mouseover event in anyway aid accessibility? I might be missing something, but I just don't get how this is ever a good thing. Or if it is, how it's a good thing more often than it's a bad thing. My point being that IF it's ever good, most of the time it's bad, and I can't even imagine a case where it's good, can you?

I think they just threw it in because they didn't think things through.

[ddadmin]

Well, to me, it kind of makes sense, as these days a lot of information is triggered by the mouseover event, such as a tooltip, or even more critically, a sub menu. In an ideal world the developer will have separate logic built in to handle touch only devices, but the fact is, for the reason of either the code being old or simply apathy, that's not always the case. A tap emulating mouseover ensures that touch screen devices aren't left out completely in the cold in those cases. My 2 cents anyway.

[molendijk]

With the arrival of touch only devices, developers writing scripts for desktop were left out in the cold, not just because mousing wasn't possible anymore, but also because these scripts became worthless (in a sense) due to requirements pertaining to mobile friendliness. If the creators of mobile devices had left mouseover etc. untouched (if they would not have emulated it), things would have been much easier for developers who want their code to work properly with all devices. The point here is that old scripts must be revised anyway, so why introduce a tap (emulating a mouseover) that does not always work as expected and, thus, may complicate things?

[jscheuer1]

I think DD has hit the nail on the head. As bad as it is, it's needed to allow some semblance of backward compatibility. My main complaint isn't so much the mouseover event that fires on touchstart, as the fact that no corresponding mouseout event fires upon cessation of contact with the element. That waits until a touch event begins on another element - something that might not happen. Certainly it's quite possible for it not to happen for some time, a much longer time perhaps than would be common if a real mouse were in use.

It might be good if the user could toggle it. But most users probably wouldn't understand the significance of doing that, and might become confused not knowing when to use which mode.

Why isn't there a common mouse emulation available for touch devices? You could easily mimic a mouse if you kept one and only one finger in contact with the screen at all times. This would be undesirable most of the time, but would be a great thing to be able to turn on and off when wanted/needed.

We also have devices that can have both mouse and touch input, this makes it even more fun sorting out what input came from where. Fortunately the pseudo mouse events of a touch action are in most cases delayed until about 300 milliseconds after the touch action that leads to them, while a real mouse fires them off without delay. By listening for the touch with the same response function, we can usually handle any inconvenient pseudo mouse events it spawns in a more appropriate manner.