Jorge said:
Let me ask, what other touch/gestures JS APIs are out there ?
RIM and Palm uses just mouseevents, though they don't fire mousemove
either.These guys copied Apple in making what would be mousemove to
perform a scroll.
http://groups.google.com/group/comp.../9c500b1523fc7d9b?show_docid=9c500b1523fc7d9b
See 0 answers there.
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0169.html
| * initTouchEvent takes 18 parameter variables. Three of these
| variables are "TouchList" variables. Each TouchList is comprised of
|one or more Touch instances. Was a simpler API considered?
|
| * the TouchEvent payload for the eventListener does not have the
| interesting data itself. Instead, the interesting data is on the
| "changedTouches" TouchList. The callback must address this complexity
| by hanling not only a touch event, but a touch event which is not
|directly useful (the information the program needs is in the touches
| or changedTouches).
In response to Nokia's "Kari Hitola" suggesting we have "real discussion":-
| > Let’s hope that now there could be a real discussion about the
| topic.
|
| [snip]
|
| A "real discussion"?
|
| I would think that would include identifing problems and have them
| post the problems with a few alternatives.
|
| A productive discussion would include reasons and insight to the
| design of touch event, including problem scenario and proposed
| solution.
|
| The one known existing api (Apple's) for touch event has not been
| justified (and justificaiton for specific parts was directly asked, by
| me, above, in this trhead).
We never got any justification for the API, but Kari followed up with
some statements that were shown to be false. He followed up with:-
| Garrett's and my objectives were actually quite different.
and:-
| Sorry for sounding like a broken record, and trying to sell our
| manipulation event too much.
*My* objective is writing applications that don't have separate
codebases for each special touch events API. I am selling nothing. I am
sorry for nothing.
* retrofitting existing drag 'n drop code (APE)
* modifying existing event simulation framework code (YUI2)
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0192.html
| The APIs for simulation and for handling event callback are both
| complicated. Simulation includes 18 parameter variables, plus all of
| the key modifiers, like ctrlKey, metaKey (how the user is supposed do
| that off is beyond me). It includes a pageX (nonstandard). It includes
| screenX (can't explain the rationale for that one). It could easily
| work in a compatible way so that the event properties of the actual
| event would "work" for most touch events.
|
| I am aware that Apple has rotation and scaling. Must these necessarily
| be coupled to the input device ("touch")? Could the rotation/scale be
| independent of that (much like a contextmenu event is independent of
| the input device or method that that device triggers it (recall old
| mac IE, where click-hold caused a context menu to appear).
SOmewhere in that thread I asked if some proposal had come from
"(misguided) individuals in Nokia USA". That, and some mistruths, were
used to justify permanently banning me from w3c public webapps.
I don't mind being banned; it doesn't *personally* affect me. The w3c
providing preferential treatment to its paying members' business needs,
while turning against developers is disturbing.
I'm not making any excuses or apologies. I'm not saying I'm mr nice guy
or joe happy, but I am speaking out the truth, and that is something
that those w3c sponsors cannot enjoy.
http://groups.google.com/group/comp.lang.javascript/msg/dbcce101c82730a1?dmode=source
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0182.html
http://yuilibrary.com/projects/yui2/ticket/2528514
It's "generated" after certain user actions (touches/gestures), but as
there's no mouse to track there can't be a normal mousemove.
It could. A mousemove event could fire and then, whatever else they
want. Sort of like domActivate would fire and click would fire and focus
would fire, all ased on the same user-initiated "click".
The design of publish and subscribe is a well-known pattern. It is easy
to undertand and widely implemented in many languages (DOM Events, for
example).
So not only can mousemove be generated, it should be. The pointing
device is either a finger or stylus and when it moves, the mousemove
should fire.
Mousemove events sometimes need to know the event coords where the event
occurred. The clientX property provides this information. Surprisingly,
it is missing from TouchEvent.
[copyright Garrett Smith:
Multiple mouse events requires only one small modification to the API,
and that is to add an `id` property to the event.
Other events may fire at the same time, but these other events are not
tied directly to the mouseevent.
- end copyright Garrett Smith]
Apples touchEvents, in contrast:-
Apple's patented API for creating a single touch.
Touch createTouch( in DOMWindow view, in EventTarget target,
in long identifier, in long pageX, in long pageY,
in long screenX, in long screenY)
raises ( DOMException);
To create a TouchList, at least one Touch must be created.
To create a TouchEvent, it is necessary to first create three TouchList,
each of which needs at least one Touch.
I don't want that. I don't like the DOM API (it is awful in the same
way), but this is taking that to perverse extremes.
I want something like:-
dispatchEvent(target, {clientX: 10, clientY: 12 /*,...*/});
Last I proposed that, it was responded to by FUD "its impossible to
determine the contents of an opaque object" and then Cameron McCormack's
suggestion of instead changing all the dom event properties from
readonly to read/write. When I pointed out that it would result in
errors as:-
var x = document.createEvent("click");
x.clientX = 12; // Script Error: Never try to set a readonly property!
He followed up that the API could change, though did not provide any
suggestion that it would be important to feature test these readability
of these features, nor did he provide any strategy for what a client
would do when that failed.
Then we had Schepers come with some sort of global object inference
feature checker that accepts a string and returns a boolean. Sounds
great but I would not trust that; I would trust what I can test, not
what the browser says works. The code that the browser uses to perform
the task would likely not be the same code that reports whether or not
that task can be done. The likelihood of a browser misreporting feature
support seems fairly high.
And copying the phone that set the bar.
You said: "if Apple had not designed a browser where drag events
scrolls the window"
I say: if you capture the touch event you can prevent/cancel the
scroll action.
The iPhone isn't the most interesting target for mozilla's mobile
browser, there's a whole lot of other very nice phones crying out loud
for a good browser while the iPhone's got already a pretty good one,
since the start.
MOzilla is a great open source project. Why should Mozilla developers
pay to distribute the application?
The business situation with Mozilla is complicated and beyond my
understanding. Google funds Mozilla and now Google has their own Phone
coming out (Nexus One).
http://www.google.com/phone
You'll have the opportunity to actually buy the phone, not stuck with
greedy, lying phone carriers (they're even worse than cable companies).
I just tried to view a web page and got into "text selection" mode, with
those little blue dots.
Well the web browser is only part of the phone. IT is a bad part, but
then, so are all the other parts.
It has a bad camera, isn't very sturdy, has a horrible speaker (i like
speaker phone when I am on hold), it does not cradle like a clamshell,
and the buttons are nearly impossible to use.
There isn't any one task that hte iPhone is acually good at.
It used to be so with their PDAs I believe. Don't know about the Pre
and webOs. (whose apps are written in JS
Yes, I am aware of that. Palm Pre in HTML5.
