On Feb 16, 5:11 am, davidroe <[email protected]> wrote:
> On Feb 15, 8:37 am, Matteo <[email protected]> wrote:
>
> > I noticed that webkit for iphone adds about 300ms on onclick events. I
> > found an old post on this group about this curious behavior but no
> > solution was given. Probably I am reinventing the wheel here, anyway
> > the solution is just to intercept the finger tap and trigger the event
> > ontouchend instead of on the standard onclick.
>
> > Here's a demo page, point your iphod (iphone or ipod touch :P ) or
> > simulator (does not work on standard browser)
> > tohttp://cubiq.org/dropbox/clickdelay.html
> > The first button triggers the standard click event (with 300ms lame
> > delay). The second button casts the same click event but ontouchend
> > thus eliminating the 300ms delay.
The function removeClickDelay is used as a constructor, it is a
javascript convention that constructors start with a capital letter
(ECMA-262 follows this convention in most cases).
Also, the name of the function is a bit misleading - perhaps it should
be called "NoDelayClick" or "InstantClick" or such.
The function changes the UI in fundamental ways. Press and hold on
the first button and it is greyed-out to show it has focus. Move your
finger and the focus is removed since the movement is interpreted as
panning. If the button it tapped, the element is greyed/ungreyed
quickly to show the user where the event occurred before the click
event fires. I think this is a very useful feature, even though it
looks less that elegant in an otherwise slick touch interface.
This behaviour seems to hark back to the very early Mac OS days, when
things that would respond to a click blinked a couple of times before
doing whatever it was they were about to do. If I remember correctly,
in Mac OS 7 you could configure the number of flashes to be 0, 1 or 3
(or maybe it was none, short and long, I forget).
Apple's touch interface seems to mimic this to some extent - when an
element like a button is touched, it is greyed out to show it has
focus. If the finger is moved and the viewport pans, the element
loses focus and is not greyed out anymore, letting the users know the
button won't do anything now.
For a tap, the flashing grey and slight pause gives the user time to
see what it was they touched (or confirm that the UI interpreted the
click on the element they tried to click). It fits with the rest of
the UI.
This behaviour is prevented by the removeClickDelay function, I think
it should remain.
One thing that differs for the touch interface is that in a normal
application, a mousedown, move, mouseup on the same element fires a
click event. That doesn't happen with the Apple's touch interface,
which is likely a good thing in general but means buttons are a little
fussy about fingers moving during an attempted click that happens to
pan a little too far.
> > Have you encountered this issue? Is there an easier solution?
I have never seen it as an issue. In general, I hate messing with the
UI - the more standard it is, the simpler it is for users to use it
(the strategy of least surprise).
> trap ontouchstart instead of onclick?
No, for the reasons noted in the linked blog post. A click event
occurs when both a mouse down and up occur on the same element. For a
touch interface, touchend is equivalent to mouseup so it's an
appropriate event to use.
--
Rob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"iPhoneWebDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/iphonewebdev?hl=en
-~----------~----~----~----~------~----~------~--~---
