It would be great if Mozilla worked with PhoneGap on this as they already have APIs [1] that cover most of these and have pretty good cross-platform support already [2].
Agree to that. However, given that webkit is the widely used mobile browser, the webkit project should implement something similar asap. This covers a real need and its actually kind of baffling why we still don't have those simple apis in the browser already. Given that both big webkit contributors, apple and google, have vested interests in non-browser mobile apps, it's not surprising.
I believe as long as iOS exists, google will be pushing Android to assert their dominance. I guess that's why they still don't really push chromeOS. (Do any chromeos laptops exist?)
I guess the absence of the APIs can't really be both baffling and not surprising, but I agree with your point. Especially Apple will be sad to see it's 30% go, but it has to realize that the app store will still have its place, if only for the discoverability. Web app builders on the other hand can do so much more with these APIs, while circumventing app store rules and pushing updates whenever they want. Perhaps this could be the rise of alternative app stores on the iOS platform as well, that would be awesome. Fingers crossed for Apple implementing this.
As much as I support what they are doing, I don't see Apple implementing any of this any time soon - even if it is in the Webkit trunk, they'll just rip it out/deactivate it.
Apple's strategy for their phone platform runs deeper then just what is in the open source Webkit codebase.
I used to think/hope open platforms would ultimately win in the market but iOS and the Apple App Store has kind of proved otherwise.
Why not? They pioneered all the techniques they use for using web apps like native apps on iOS, such as adding them to the home screen. I don't think there's any evidence that supports your argument whatsoever.
If people want to run web apps on iOS devices Apples is more than happy to sell them for that purpose.
I agree, unless someone can point to anything Apple has ripped out or deactivated in WebKit. Apple seems to have been pretty open with Mobile Safari.
The most closed thing I can think of is when they only enabled their faster JS engine for the browser itself and not for apps. The next major release changed that, and it is not related to WebKit itself.
Apple has restricted some stuff in WebKit but I don't think anyone would argue that they did so to weaken it. For example you can't (or at least couldn't in the past) use position:fixed in Mobile Safari, and overflow:scroll was relegated to a two finger scroll that no one really knew about and is/was a little intuitive (I think they've fixed this with iOS5 though).
Nitro is enabled in iOS for web apps added to the home screen, but not UIWebViews (aka, PhoneGap). While I don't think it's actively sinister, it doesn't seem like they're going out of their way to correct it, either.
The problem is that they can't allow programs to execute parts of the memory as instructions. This is needed for efficient JITs like the one in Nitro.
Apple is actively (Frequent commits) working on fixing this problem. The project is called Webkit2, and features a Javascript interpreter that runs in a separate process, and thus is able to safely execute Javascript on iOS. This model, btw., is inspired by the multi-process architecture found in other major browsers.
I wonder how Apple feels about web apps after the success that they 've seen with the app store. I mean, they have in the past banned phonegap apps, but only the grounds of their developer terms.
For one, i ditched the kindle app ever since i discovered read.amazon.com .
Well, if the android browser supports it, i think apple will follow. There are going to be so many web apps made, that it's going to be impossible to ignore.
>>Mozilla would like to introduce WebAPI with the goal to provide a basic HTML5 phone experience within 3 to 6 months. [...] Specification drafts and implementation prototypes will be available, and it will be submitted to W3C for standardization.
3 to 6 months is a fairly short timeline for getting all browser vendors and the W3C on board, not to mention getting stable and secure implementations into the wild. At least they're doing all the legwork by putting together the initial specification drafts and implementation prototypes. These additions would be truly incredible if accepted. I know they like to lump every standard under HTML5 these days so I wonder if this is intended to be an addition to that or if WebAPI is completely orthogonal to HTML5.
3 to 6 months is a fairly short timeline for getting all browser vendors and the W3C on board
As far as the specs go, most of the things they list have W3C APIs at reasonably advanced stages. I keep track (somewhat) of the Camera APIs, and they are at a point where Opera has an experimental implementation on Android, and Ericsson has a Webkit version with some support.
The implementation is more tricky. They can fix Firefox on Android of course, but in theory they could pay people to work on Webkit to help out iOS users (and the default Android browser). I'm not sure what Mozilla sees as their vision: is it to create the best web browser on the planet, or is it to make the web platform as good as it could be?
I don't see how they could help Microsoft out with their implementation though.
The more sophisticated the web platforms become, the more opportunities there are to make the best browser on the platform. Conversely, if the web platform stagnates, meaningfully differentiating a browser gets more difficult.
I think the biggest issue is that you would need to get buy-in from the major manufacturers and it doesn't seem to be in their best interest. The further divergence of the platforms, in tandem with the conscious raising of switching costs, is one of their main strategies.
1) It's not "Google's WebIntents", both Google and Mozilla are working on the project together[1], after coming up with the same idea separately at first.
2) This doesn't compete with WebIntents, which is about application selection. WebAPI is about device integration which is compatible with WebIntents. You could, for example, want to make a call and be prompted with several Phone app choices (thanks to WebIntents) and then dial the number and make the call (thank to the Telephony API which is part of WebAPI).
I would prefer that Contacts where not an API and just a user created/chosen web app. Why is there a need for a Contact API?
On a separate note, should someone be starting up a OMA push proxy for SSE? I have a feeling that between Chrome getting an Android port, the Moz/Chrome WebRTC and Moz's Web APIs, that Server Side Events are going to become "a thing" and OMA push proxy would be a useful service.
But how does a system level Contacts API make any sense when Web Intents and any-old-body's webapp exists?
I guess I may be thinking about it incorrectly. If this is for web apps to implement a common standard of functionality across Contact "apps", then this makes sense. Otherwise, why are we falling back to "native" when it comes to Contacts, especially when modern contacts exist as part of an online profile - Google Contacts, Facebook Friends and Twitter accounts I follow compose my entire "Contact List".
You're forgetting SIM cards which contain contact information. People want to be able to start their phone app and have contacts already there. Then they can link to Google or Yahoo or whatever else to import more.
Also remember that this isn't just part of B2G. This is functionality that will be rolled into Fennec. So when you open your contacts web app in Fennec on Android you should have the same contacts that the native contacts app has.
Exactly. The point of the Contacts API isn't to replace existing contacts web apps, it is to make them better by giving them access to native contacts (and potentially other contacts sources).
It would be great if Mozilla followed through on their projects. Prism to Chromeless to stalled. Chromeless has potential to expand their core product, which is the browser. Why does everyone have the need to be Google and have their hands in everything?
To put it in perspective, Mozilla has no mobile platform and is crying for relevance.
Apple -> iOS/WebKit
Google -> Android/WebKit
Mozilla -> ???/Fennec
By getting desktop browsers to implement telephony and other collaboration APIs, I'm sure their hope is to get mobile browsers to likewise expose the precious voice and video APIs of the mobile handsets. And perhaps by doing this, lines between browsers on mobile devices are blurred to where Fennec has a role.
You're right. It did come off trollish. Wasn't my intent. I'm sorry to both parties.
Both WebAPI and WebRTC will produce awesome collaboration apps. Wins all around.
But how, exactly, do the two fit together? Is WebRTC a low-level implementation of protocols, codecs, and transports whereas WebAPI provide the friendly developer-oriented APIs?
Will WebAPI provide hooks for standard widgets for dialer, SMS, contacts, etc?
> But how, exactly, do the two fit together? Is WebRTC a low-level implementation of protocols, codecs, and transports whereas WebAPI provide the friendly developer-oriented APIs?
They're not related. WebRTC is a video chat/conferencing project.
> Will WebAPI provide hooks for standard widgets for dialer, SMS, contacts, etc?
> > Will WebAPI provide hooks for standard widgets for dialer, SMS, contacts, etc?
> Yes, that's its precise purpose.
I'm not seeing any indication that standard widgets are even in their goals. For instance, their Telephony API [1] lists functions that an application implementing its own UI might call, but nothing that indicates that those are UI widgets or expose UI-like functionalities.
[1] http://docs.phonegap.com/
[2] http://www.phonegap.com/about/features