Augmenting Types
in [JavaScript]
|
From: Jorge on 5 Jan 2010 20:13 On Jan 6, 1:50 am, Jorge <jo...(a)jorgechamorro.com> wrote: > > And S60 === a badly broken, buggy fork of webkit. ....that -besides- has not been updated ever since v1.0. -- Jorge.
From: Garrett Smith on 5 Jan 2010 20:31 Jorge wrote: > On Jan 6, 1:27 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> Jorge wrote: >>> On Jan 5, 2:55 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >>>> Apple lies to the consumers about the technology. >>> Could you please elaborate ? >> First mobile web browser? Apple? No, how about windows mobile or maybe >> Nokia S60. > > Mobile IE ? Are you serious ? That's the worst IE ever ! even worse > than desktop IE ! (wait, is that possible ?) > > And S60 === a badly broken, buggy fork of webkit. Still, much better > than any mobile IE. > > The truth is that the first serious, decent browser ever on a > smartphone has been mobile Safari. No matter what you say or how much > you hate Apple and everything Apple. That's not my personal opinion, > it's a fact, it's history. > You can compare Mobile Safari to windows mobile or Nokia S60, but that does not change chronology and it doesn't make what Apple said true. Mobile Safari was not the first browser on a smartphone. It was certainly the most hyped up ever. Windows Mobile could run DHTML stuff way back in around I think 2001 or so. >>>> Makes a web-incompatible browser >>> Which is ... ? >> Safari on iPhone, of course. Doesn't support even basic CSS overflow; > > Assuming you mean e.g. overflow-x:hidden; , which version does not > support that ? > overflow scroll or auto doesn't work. >> Doesn't support mousemove event. > > Does not need to as there's no mouse in the iPhone :-) > There is no mouse here on my laptop. The event name containing "mouse" is misfortunate. Renaming the event to "pointer", while well-intentioned, was impractical. >>>> patents the incompatibility >>> You probably mean the touch/gestures iPhone JS API ? >> Yes. > > They are in their own right. And they have *not* said a word (yet) > about the licensing fees (if any). It could be licensed for free (and > eventually it could even become an w3 standard, then) > *but*only*if*Apple*wanted*... :-) > The w3c individuals might actually be so misguided as to adopt such a badly designed Touch Events API. It that is really an awful API to use and is also totally unnecessary. Mouse events could work just fine if Apple had not designed a browser where drag events scrolls the window. >>>> prevents other >>>> browser competition on iPhone. >>> Here's a thought: design from scratch, build and try to sell your own >>> "smartphone". Then allow your competitors to put their software in >>> (Flash comes to my mind) so that you risk loosing control over your >>> own invention. Bright idea, yeah. >> I could care less about Flash. How about not monopolize the OS by >> disallowing Fennec, which is free. > > Fennec ? What's Fennec ? > http://www.google.com/search?client=opera&q=Fennec&ie=utf-8&oe=utf-8 Fennec's a cute littlel animal with big floppy ears. Fennec is a mobile Firefox that's gonna run on a bunch of browsers. It will not run on Apple iPhone because Apple forbids that. Any application for iPhone must be approved by Apple and must also be sold on Apple store. Apple charges the developer for this. Want to make a free application for your friends? You need to pay Apple for that. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 5 Jan 2010 21:03 Garrett Smith wrote: > Jorge wrote: >> On Jan 6, 1:27 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >>> Jorge wrote: >>>> On Jan 5, 2:55 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >>>>> Apple lies to the consumers about the technology. [...] > Fennec's a cute littlel animal with big floppy ears. Fennec is a mobile > Firefox that's gonna run on a bunch of browsers. gonna run on a bunch of phones, not browsers. Fennec *is* a browser. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Jorge on 5 Jan 2010 22:45 On Jan 6, 3:21 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > (...) > Sure. I'm qualified to say that. No? I have developed an API for YUI > Test specifically for testing Touch Events. (...) Let me ask, what other touch/gestures JS APIs are out there ? > I have provided reasons for why the API is awful. When, where ? > Regarldess, the worst > problem is that normal mousemove event does not work. It's "generated" after certain user actions (touches/gestures), but as there's no mouse to track there can't be a normal mousemove. > >> Mouse events could work just fine if > >> Apple had not designed a browser where drag events scrolls the window. > > > Surely that's why everybody else is trying to copy the iPhone's > > "awful" design and UI. > > They are copying the business that makes money. And copying the phone that set the bar. > > And scroll events can be trapped (as touches) before the scroll > > occurs. > > As far as I have tested, mousemove event does not fire. What do you mean > by "trap" a scroll event? 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. > >> Fennec's a cute littlel animal with big floppy ears. Fennec is a mobile > >> Firefox that's gonna run on a bunch of browsers. > > > Ah. That. That's good news. Really. I'm glad it's finally out. I > > appreciate mozilla very much. > > >> It will not run on > >> Apple iPhone because Apple forbids that. > > > There are other browsers in the iPhone already (e.g. icab). Probably > > if mozilla just leaves out the plugins it could very well by approved > > for the app store. > > I was not aware of icab on iPhone. 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. > >> Any application for iPhone must be approved by Apple and must also be > >> sold on Apple store. > > > Of course. The same goes for the xboxes and wiis and playstations and > > nokias and ... and ... > > No, not for all devices. Even if that were true, it wouldn't make one > individual company following the others any more right. > > I believe Palm allows free (unregulated) application installations. It used to be so with their PDAs I believe. Don't know about the Pre and webOs. (whose apps are written in JS :-) > I > don't keep up with xbox. I hate video games more than I hate the mobile > indusgry, but mobile is realate to the Internet, so related to my > profession. -- Jorge.
From: Garrett Smith on 6 Jan 2010 00:09
Jorge wrote: > On Jan 6, 3:21 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> (...) >> Sure. I'm qualified to say that. No? I have developed an API for YUI >> Test specifically for testing Touch Events. (...) > > 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.lang.javascript/browse_thread/thread/00a3e699050e44df/9c500b1523fc7d9b?show_docid=9c500b1523fc7d9b See 0 answers there. >> I have provided reasons for why the API is awful. > > When, where ? > 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 >> Regarldess, the worst >> problem is that normal mousemove event does not work. > > 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. >>>> Mouse events could work just fine if >>>> Apple had not designed a browser where drag events scrolls the window. >>> Surely that's why everybody else is trying to copy the iPhone's >>> "awful" design and UI. >> They are copying the business that makes money. > > And copying the phone that set the bar. > >>> And scroll events can be trapped (as touches) before the scroll >>> occurs. >> As far as I have tested, mousemove event does not fire. What do you mean >> by "trap" a scroll event? > > 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. > >>>> Fennec's a cute littlel animal with big floppy ears. Fennec is a mobile >>>> Firefox that's gonna run on a bunch of browsers. >>> Ah. That. That's good news. Really. I'm glad it's finally out. I >>> appreciate mozilla very much. >>>> It will not run on >>>> Apple iPhone because Apple forbids that. >>> There are other browsers in the iPhone already (e.g. icab). Probably >>> if mozilla just leaves out the plugins it could very well by approved >>> for the app store. >> I was not aware of icab on iPhone. > > 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. >>>> Any application for iPhone must be approved by Apple and must also be >>>> sold on Apple store. >>> Of course. The same goes for the xboxes and wiis and playstations and >>> nokias and ... and ... >> No, not for all devices. Even if that were true, it wouldn't make one >> individual company following the others any more right. >> >> I believe Palm allows free (unregulated) application installations. > > 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. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |