On Jul 30, 1:56 am, "manifestinteract...@gmail.com
If you are going to reply to specific points, it is preferable to do
so below trimmed quotes of what you are replying too. Posting order
> > > I have written a jQuery plugin that can use the built in Touch methods
> > > including ontouchstart, ontouchend, ontouchmove, ongesturestart,
> > > ongesturechange and ongestureend.
> jQuery is a popular library that is used by hundreds of thousands of
> developers world wide. This free plugin was to allow the developers
> who are using jQuery a method of using the built in features of the
> iPod/iPhone touch gestures.
How do you estimate "hundreds of thousands"? Your inference, based on
a complete guess of use, is that because a large number use it, it
must be OK to use. By the same logic, if there are more "developers
world wide" not using jQuery, doesn't that make *not* using it a
Agrument about the quality of a library should be objectively based on
the benefits of using it rather than generalisations and wild
estimates. The primary reason not to make code dependent on a library
is that it becomes tied to the fortunes of that library. It also
infers that a separate version of the code must be developed for each
An alternative approach is to create independent code and supply
instructions on how to integrate it with some of the more commonly
> Since it is clear that you do not use
That inference can't be drawn from what I posted, however it's
> and that you have not actually looked at the plugins code,
You can't draw that inference either, but I did.
> will let you know that there is, in fact, no "browser or device
I will let you know that jQuery uses quite a bit of browser sniffing -
for example, the string "jQuery.browser.msie" occurs 17 times in
Regardless, the statement was a general comment that was not
specifically directed at the plugin, but at developing a gesture-based
interface. There is a disturbing trend toward browser detection and,
where development is targeted at mobile devices, device detection.
Both approaches are flawed, the sooner they are again relegated to
oblivion the better.
For the record, I am currently working on how to integrate touch
gestures with traditional pointing device gestures (noting that some
platforms already use touches to emulate a pointing device and that
some may use pointing devices to emulate touches). The goal is to
provide the ability to scale or rotate objects without regard for
which interface is being used.
> Both this and the dojo plugin use the built in methods of the Apple
> devices, there is no need to sniff/detect anything. It will work if
> you have a device that supports the methods, and fail gracefully if it
> does not.
The primary reason touted for using a general library is that it
allows cross-browser development. In that context, the aim is for
features to work in as wide a variety of situations as reasonable
(let's say in this case the most common 4 browsers and platforms).
The challenge is not to produce an effect based on a specific gesture,
but provide a feature that works appropriately for the interface being
used - e.g. scaling might use a pinch effect for a touch interface and
ctrl+mousedown followed by ctrl+mousemove where a pointing device is
being used. If a particular environment supports both, then both
> There is nothing "unfortunate" about either plugin and both serve a
> need that has been expressed by developers, like myself.
It is unfortunate that two bits of code that could have been
complimentary are mutually exclusive because the authors chose to tie
them to specific libraries.
> If you "expect a set of functions optimised for low-power CPUs and
> without the library baggage would perform much better" then please
> either offer an alternative, or work on providing a solution.
The validity of my criticim is independent of whether I personally
provide an alternative. The fact that Neil Roberts' code provides
much smoother scale and rotation actions proves the first part of the
statement. The tendency for libraries to be focused on generalised
functions and not performance provides a basis for the second.