Mozilla Hacks

Introducing WebAPI

Avatar photo By Robert Nyman [Editor emeritus]

Posted on August 23, 2011 in Device APIs, Featured Article, HTML, Mobile, Mozilla, and Web APIs

Mozilla would like to introduce WebAPI with the goal to provide a basic HTML5 phone experience within 3 to 6 months.

The current situation

Where we are today, there’s a clear distinction between the Open Web and native APIs and how things have to be built. As many developers are aware of, we need consistent APIs across web browsers, operating systems and devices to be able to build something for the world, not just a specific device or vendor. We need a way to take the web to the next step.

What is WebAPI?

WebAPI is an effort by Mozilla to bridge together the gap, and have consistent APIs that will work in all web browsers, no matter the operating system. Specification drafts and implementation prototypes will be available, and it will be submitted to W3C for standardization. Security is a very important factor here, and it will be a mix of existing security measurements (e.g. asking the user for permission, like Geolocation) or coming up with new alternatives to ensure this.

In the nearest timeframe we are looking into building:

  • Dialer: Telephony & Messaging API, Contacts API
  • Address Book: Contacts API
  • SMS: Telephony & Messaging API, Contacts API
  • Clock
  • Camera: Camera API, Filesystem API
  • Gallery: Filesystem API (could possibly be FileReader & FileWriter in conjunction)
  • Calculator
  • Settings: Device Status API, Settings API
  • Games: Accelerometer API, Mouse Lock API
  • Maps: Geolocation API, Contacts API

Contribute

We know that there are so many talented people out there with great input, so please contribute through any of these means:

Hiring developers

We are also hiring several full time engineers for working with WebAPI. Read the job description and apply.

About Robert Nyman [Editor emeritus]

Technical Evangelist & Editor of Mozilla Hacks. Gives talks & blogs about HTML5, JavaScript & the Open Web. Robert is a strong believer in HTML5 and the Open Web and has been working since 1999 with Front End development for the web - in Sweden and in New York City. He regularly also blogs at http://robertnyman.com and loves to travel and meet people.

More articles by Robert Nyman [Editor emeritus]…

117 comments

  1. Tomer Cohen

    I wish the web will have access to nearby devices using Bluetooth for example. This will allow us to send information to our mobile device right from the browser, without having a centralized synchronization server such as Firefox Sync.

    August 23rd, 2011 at 03:53

    1. fatriff

      No need for it.. Bluetooth is a dying technology.. Seriously, where’s the need? There’s not only firefox sync out there, there’s a huge amount of add-ons and programs which work only on the home network for syncing files and bookmarks and things without having to use the cloud.

      August 23rd, 2011 at 07:05

      1. Natanael L

        Dying? Hardly! I use it all the time when I’m physically close my friends!
        You know, I’m not always on a WiFi, and Bluetooth doesn’t suck as much power for file transfers as WiFi/3G.
        Also, there’s few good options for wireless local file transfers. Apps like Bump don’t work on non-smartphones, etc, and not for laptops either (but Bluetooth does).

        August 23rd, 2011 at 09:59

    2. Don Park

      The dream of peer to peer bluetooth for phones was dead the moment bluetooth 1.0 was released. The power hit to remain ‘discoverable’ was simply too much for cell phones to produce. Then there was the bluejacking scare. Also my guess is the cell providers feel threatened by a wireless data network they dont control.

      There is a new hope though, Bluetooth Low Energy, part of Bluetooth 4.0. Totally redone to be very low throughput and hence very low energy usage. It will enable games and social media apps to discover other people in the room that have the same apps/interests/etc.. I’m still waiting for the first handset to ship with it, but the chip itself seems to be well into production runs.

      August 23rd, 2011 at 10:19

      1. Jasper Janssen

        My new Macbook Air does BT 4.0 including LE, allegedly.

        It would not surprise me if that spreads with newer handsets from that manufacturer.

        August 23rd, 2011 at 14:39

    3. BrianMB

      Ad-hoc communication APIs are a gaping hole in the list above (whether it’s conducted over Bluetooth or not should be up to the browser or OS vendor).

      August 24th, 2011 at 10:21

      1. Robert Nyman

        Yes, that is an interesting field!

        August 25th, 2011 at 01:58

        1. L1Blom

          The API should hide Bluetooth and WiFi Direct as competing standards in a ad-hoc api.

          August 25th, 2011 at 08:08

          1. Robert Nyman

            I think it depends on what kind of API, but that is one approach.

            August 25th, 2011 at 23:09

  2. Cameron McCormack

    Many of the specs on the list of things to work on within the WebAPI project seem to overlap with ones developed in the W3C DAP Working Group. Presumably we’ve deliberately decided not to go with those, but to invent new ones. I haven’t actually seen any discussion about why this is the case — has there been some? When it comes to standardise these new APIs, will we be bringing them to DAP?

    August 23rd, 2011 at 04:22

    1. Marcos Caceres

      It does seem a little arrogant on the part of Moz to basically say “those W3C/DAP guys don’t know what they are doing… or we don’t care what the w3c is doing even if they have been at it for 2 years; we will do it right, then dump it on the W3C for ratification”. Sounds a lot like what Microsoft tried to pull with XDomainRequest back in the day. Not a good way to do standards, IMHO.

      August 24th, 2011 at 00:07

      1. Robert Nyman

        Marcos,

        That is not the case, though. Mozilla is experimenting with approaches and techniques, learning from other projects and is prototyping to see what conclusions we can make. The idea is to collaborate with W3C and all players and together form a good solution, and not just dump it on them.

        August 24th, 2011 at 00:17

      2. John Drinkwater

        More recent example please, try Apple/WebKit dumping CSS animation at W3C.

        August 24th, 2011 at 03:07

        1. Marcos Caceres

          Don’t get me wrong, I’m all for dumping stuff on W3C working groups if they were not already working on the stuff (specially if there are no implementations already). Anyway, looking forward to seeing what comes out of all this :)

          August 24th, 2011 at 03:20

          1. Robert Nyman

            No worries. :-)
            I hope some great collaboration comes out of this!

            August 24th, 2011 at 03:58

  3. Shishir Ramam

    While implicit in the telephony API, an ability to use/record the microphone would aid with innovations in application interactivity. This can be very useful in a variety of domains – early education, handicapped accessibility and just plain fun!

    August 23rd, 2011 at 04:48

    1. Gerardo Capiel

      I second that along with the need for TTS APIs to enable self-voicing applications, which will be useful for eyes-free applications and accessibility. Google has done good work here in a TTS for web apps and extensions, see:

      http://code.google.com/chrome/extensions/trunk/tts.html

      Common APIs for accessibility in general would also be good. Apple made a W3C proposal around this:

      http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html

      August 23rd, 2011 at 08:03

      1. Robert Nyman

        Absolutely, there are many interesting options here!

        August 23rd, 2011 at 14:55

    2. Jay Fienberg

      I also was going to bring this up: mobile devices commonly have microphones and speakers, and are natural audio devices. At the same time, there are increasing means in HTML5 / Javascript to both play and manipulate audio in the browser.

      The “Gallery API” concept, listed above, presumably is targeted at photos and perhaps video, but there’s a similar need for audio-only media–either “Gallery” includes a variety of media, or perhaps a broader “Media Collection” API could be an umbrella for photos, audio, video, mixed, etc..

      August 23rd, 2011 at 14:53

      1. Robert Nyman

        I agree. I believe this is a first step to explore and build upon to consider things like that.

        August 23rd, 2011 at 14:57

  4. Tim

    I’m not sure whether you are talking about just an API or a firefox mobile product or external framework like PhoneGap. You guys should really be focussing on the other main native functionalities that PhoneGap doesn’t provide yet, calendar and push notifications seem to be missing on your list (I hope you’re doing call logs as well in your dialer api).

    August 23rd, 2011 at 04:54

  5. Robert Nyman [Mozilla – post author]

    Thanks for your comments!

    Tomer,

    Bluetooth definitely sounds interesting! It’s not a part of the first steps, however, but maybe one day.

    Cameron,

    I’m not sure exactly how that process will be, but I hope to find out and will get back to you/this page.

    Shishir,

    It could prove very exciting indeed!

    Tim,

    It is a collection of APIs, aimed for standardization and implemented by everyone. I do agree that calendar and push sounds interesting!

    August 23rd, 2011 at 05:16

    1. Natanael L

      Also, NFC, gyroscope, etc…
      There’s actually quite a bit of hardware that could be supported, I have no idea how to figure out what should be prioritized.

      August 23rd, 2011 at 10:01

      1. John Drinkwater

        WebNFC is planned https://bugzilla.mozilla.org/show_bug.cgi?id=674741
        gyroscope should be supported already http://hacks.mozilla.org/2009/10/orientation-for-firefox/

        August 24th, 2011 at 03:10

        1. Robert Nyman

          Thanks John!

          August 24th, 2011 at 03:59

  6. Jonas Arnklint

    Cool, awesome initiative!

    August 23rd, 2011 at 05:17

  7. Marty Zalega

    I think this is a great direction but I think this is too narrow a vision and too specific to mobile devices. The only difference between desktop and mobile is form-factor. While I want access to a camera and the user’s address book I think this concept needs to be more broader and should allow web applications to do anything a native application can as long as the user allows it. If the user has a scanner and authorises it so the app should be allowed to use it. Same goes for other components like bluetooth and printers etc. I admit, this does sound too ambitious but for most components there is a lowest common denominator. For instance, scanner and camera etc fall under imagery and can be a unified interface. The browser is becoming the OS is the wrong ideology. The browser should be the conduit.

    August 23rd, 2011 at 06:04

    1. Chris B

      I would argue that there are meaningful differences between mobile and desktop – it’s not just a form-factor issue. The portability, and therefore the relevance, of location-specific information is of a great deal of relevance to mobile devices, but not to desktops. Also, another example is cameras – on desktops these are used nearly 100% of the time to capture video of the user for use in 2-way video chat. On mobile devices the cameras are used more often to take photographs (and videos) of the users surroundings – with 2-way video being something which is only gaining popularity (as a seperate function) in recent times.

      August 23rd, 2011 at 23:52

      1. Robert Nyman

        Absolutely, and it will be interesting to create APIs that are very empowering for some devices and use cases, where they will be more basic on, for instance, a desktop computer – but to still make them useful in all cases.

        August 24th, 2011 at 00:03

      2. Bruno Torquato

        There are some meaningful differences in what types of usage are more predominant on one platform or another, but I would argue that this observation has little to do with what an API should enable. The fact that a mobile is used more for snapshots than for 2-way video chat does not preclude it from 2-way video chat in any way. The fact that geolocation services are more relevant to mobile devices does not preclude it from being an important part of the desktop-OS-based web experience, especially when people are overwhelmingly choosing laptops over desktops, and things like the MacBook Air are blurring the lines between mobile and desktop experiences. “One web” should mean “one web”, not a mobile and a desktop web. The OS of your device should not be taken as a way to broadly assume how you wish to use it.

        August 24th, 2011 at 07:18

        1. Robert Nyman

          No, I rather meant that there will be cases where some features will be available, for instance, mobile devices but not on a desktop/laptop. Most don’t support accelerometer, for example, and probably never will. The API should still be there, though, and then the developer can take action based on responses from it.

          August 24th, 2011 at 07:29

  8. Will

    Case in point: following the link from hn to here on my iPhone I get a desktop webpage and the email field doesn’t have the right snake oil to flip my keyboard into email mode and the link for the project page gives me a white screen. Someone taking ownership of a project for making tools that are useful enough to make “mobilizing” easy is necessary for solving this problem. Kudos.

    August 23rd, 2011 at 06:22

  9. Alex

    This is a great initiative! I hope something will actually come out of it but unfortunately, I don’t see Apple cooperating with this.

    August 23rd, 2011 at 06:31

  10. David Crone

    Are you going to look at how the HTML5 element can be extended to support a standard approach to content-encryption and DRM? Without these there’s a huge swathe of content that won’t be available in a really standard way across the various device eco-systems because the content providers won’t support it.

    August 23rd, 2011 at 06:36

    1. David Crone

      This should say HTML5 video element (It got kludged out because I tried to use angle-brackets :-))

      August 23rd, 2011 at 06:37

  11. Robert Nyman [Mozilla – post author]

    Jonas,

    Thanks!

    Marty,

    Interesting thoughts! I think this is a start, and then we will see how it goes and where it can lead us.

    Will,

    I believe it’s a matter of many things, such as teaching people about how to do it, what the common denominators are etc. Tooling is also good, but behind that we need more APIs and similar to be able to detect and do some of those things as easy as possible.

    David,

    When it comes to encryption it’s definitely interesting. WIth DRM, it is important in some cases but I’m not exactly where DRM will fit.

    This is beyond the scope of WebAPI, though, at least for now.

    August 23rd, 2011 at 06:43

  12. Matthew Phillips

    I’ve begun working on a phone app in my spare time. The source can be retrieved from here:

    https://github.com/matthewp/b2g-phoney

    Of course phone calls cannot be placed as the Telephony API is not far enough along.

    Here’s a problem that needs to be solved though: while many “dialer” apps can place calls, but there can only be 1 which answers. There needs to be a method to get permission to become the default phone answering app. Then when an incoming call is received B2G will route the call to the default app. I propose this:

    bool ringing()

    This can be called by the app on launch. If it returns false there is no call to receive. If it returns true then the app can prompt the user to answer or hangup.

    August 23rd, 2011 at 07:25

  13. N.V.Balaji

    It is very exciting to hear this – the WebAPI development will speed up the “browser as a platform” paradigm tremendously. The time line looks aspirational !

    I am wondering how are you planning to manage the application framework – Issues such as :
    1. app going to foreground or background,
    2. app invoking a functionality of another app (something like web Intents),
    3. app getting invoked on start-up,
    4. app not having any UI (more like a service)
    5. app sending some piece of info to all listeners in the system

    August 23rd, 2011 at 07:28

  14. Kamil Trebunia

    How is this related to: http://www.w3.org/2009/dap/ ?

    August 23rd, 2011 at 08:13

  15. Cole

    Please, please remove the Contacts API. This makes far more sense as a user chosen application.

    August 23rd, 2011 at 08:41

  16. Robert

    I’ve been hoping for these features for a while – but could you not think of a better name?

    August 23rd, 2011 at 08:44

  17. Alexander Kanavin

    Also, how is this related to http://www.wacapps.net/specifications ?
    Aren’t you duplicating the work they’ve already done?

    August 23rd, 2011 at 09:12

  18. Richard

    How do you guys plan to do this without introducing ActiveX-esque vulnerabilities into Firefox?

    August 23rd, 2011 at 09:16

  19. Amit Naik

    An excellent effort by Mozilla – however any word on anyone else offering to join this initiative?

    A standard is only as good as the community it manages to attract and unless at least some of the other players like Google, Apple, Microsoft etc show some interest this will end up as just another API.

    August 23rd, 2011 at 09:43

  20. Robert Nyman

    fatriff,

    Not sure Bluetooth is a dying technology, but it’s not up to me to decide.

    Matthew,

    Interesting, thanks for sharing!
    It is a good point about answering, and I hope it will be kept in mind.

    N.V.Balaji,

    All good questions, and I’m not sure it has been decided at this time. Please try the WebAPI discussion group.

    Kamil,

    Some ideas are similar, but in others there might be varying goals.

    Cole,

    I believe there will be cases where accessing the Contacts will be necessary and useful.

    Robert,

    Well, this is the name for now, but we’re always open for suggestions. :-)

    Alexander,

    I don’t know those specifications in detail, but I believe there will be both collaboration and inspiration going on.

    Richard,

    I can’t say more about the implementation details in Firefox or any other web browser/device right now. If you have experience with this, though, please share in the WebAPI discussion group.

    Amit,

    This is the first steps, and the aim is to have it evolve into/be part of a specification so it will apply to everyone.

    August 23rd, 2011 at 09:49

  21. Chad Smith

    This is a great idea, and glad to see it happening. I have a business who does something similar but not quite the same thing. It’s named The Easy API – http://theeasyapi.com – and I saw the same struggle that all other developers are having. I decided to start to build an API that would encompass and encapsulate other APIs providing a single API to code for and get the power of all the others. Additionally it gave me the ability to cache some results where possible. I opened it up to other developers in Feb of 2010 and started tracking the requests in mid October 2011. The Easy API does about 250,000+ requests a day and is used by a variety of companies.

    This is a project that I am going to keep on my radar as it’s near and dear to my heart. I also am going to look for ways that I can help, and if you have anything specifically that you need help with please let me know.

    Take care,
    Chad

    August 23rd, 2011 at 10:53

    1. Natanael L

      These Android intent like “meta API” ideas have already been discussed.
      https://bugzilla.mozilla.org/show_bug.cgi?id=674720

      :)

      August 24th, 2011 at 03:25

      1. Natanael L

        Found another:
        https://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/68ef6753fe663141/5fc1e8545a7e8b3e#5fc1e8545a7e8b3e

        August 24th, 2011 at 03:27

        1. Robert Nyman

          Thanks Natanael!

          August 24th, 2011 at 04:00

  22. A man who loves Firefox

    I’m really sorry for such words, but I’m fed up with this. Mozilla, stop making shit, that no one needs, for god sake, make Firefox faster and less voracious!

    August 23rd, 2011 at 11:34

  23. Chad Selph

    “WebAPI”? Could you have chosen a more vague name for these standards?

    August 23rd, 2011 at 11:55

  24. Robert Nyman

    Chad,

    Thank you, that sounds great! Please look under ways to contribute in this blog post too, and feel free to have ideas anytime!

    A man who loves Firefox,

    I’m sorry you feel that way. The objective of Mozilla is to keep the web open, and to empower both developers and users with open standards, tools and technologies. We deem this something very important in the mobile space, and given similar projects and efforts in this area, it seems to be a well-founded take.

    We will naturally also continue to make Firefox as good as we can.

    Chad,

    The idea is to generally offer various APIs to a web layer, but I understand that the term isn’t that descriptive.

    August 23rd, 2011 at 13:39

  25. Walter loose

    Why not create a firefox browser for each platform that addresses these apis?

    August 23rd, 2011 at 14:00

    1. Stuart Carnie

      There are platforms with specific restrictions whereby Mozilla could not include all the necessary features required by the API. For example, Apple would need to include these features in Mobile Safari / WebKit.

      August 23rd, 2011 at 14:39

  26. Robert Nyman

    Walter,

    The goal is to have APIs that will work no matter the web browser and operating system. Naturally Firefox will support these APIs to in the environments where Firefox will be available.

    August 23rd, 2011 at 14:18

  27. Lee

    When I stop to think about the countless hours that so many smart people have spent on trying to recreate through the browser what we’ve already had for decades, it makes my head hurt. Do we really need to spend time recreating basic operating system functions (file storage among other things) through the browser? Seriously, why? There is no such thing as write once, run anywhere. If there is, that means the death of any kind of differentiation or break out technology because write once run anywhere requires no deviation in any way.

    August 23rd, 2011 at 14:32

  28. Kamil Trebunia

    Lee, if those other technologies were so good, then they would be eclipsing Open Web and not the other way round as it is happening right now – it’s the Open Web that takes over more and more traditional technology stacks.

    August 23rd, 2011 at 14:36

  29. Robert Nyman

    Lee,

    There are many factors here, but one of the main ones is that with all the different operating systems and devices, it is quite costly and time wasting developing a separate application for each of them. On top of that, the problem there is that the owners of various app stores and operating systems decide what you can develop for it, what you are allowed to deploy.

    I would rather say that differentiation lies in user experience and similar things rather than if the API access is being done from native or web code.

    August 23rd, 2011 at 14:45

  30. Gabriel

    Any possibility to include streaming audio? Both desktop and mobile devices can benefit from services like voip, streaming radio and other forms of live audio uploading/downloading. It’s such a pity we need to use flash nowadays.

    August 23rd, 2011 at 15:37

  31. J.D.

    By that reasoning, every popular product today is “good” because it is popular.

    The “Open Web”, as you call it, is winning because it’s easy for new users. It’s optimized for getting started. That is simply one axis of quality.

    You could just as well argue that if, say, “Catcher in the Rye” was so good, it would be eclipsing “Twilight” (or “Garfield”) in sales and not the other way around. And “Twilight” is certainly very good at selling books (and movies), but to claim that it’s good-in-general because it’s good-at-this-one-thing is tautological.

    Jumping on the popularity bandwagon of the moment can be a good way to catch a rising tide and profit from it briefly. It’s not a good long-term investment. Most of the artistic works which we recognize today as being great were not popular in the day they were created. These APIs may last and thrive, or they may die out soon, but it is virtually impossible to predict right now.

    The web is becoming a big meta-platform, now that we have enough performance to throw away on such a thing. Is it better than the past few decades of operating systems research? As far as I can tell, only politically: operating systems are full of such contentious issues that the web folks have found great success in building a new level that sidesteps all of the existing operating system fights. Easier to make a new “Filesystem API” for the web that abstracts away everything (and is simpler and less powerful than a 1980’s filesystem) than try to get even two of the OS vendors to agree on anything.

    The web is better at distribution and installation, often (but not always), at the cost of being worse at pretty much everything else.

    August 23rd, 2011 at 16:05

  32. John

    The top of your wishlist is DRM? ROTFL!

    August 23rd, 2011 at 16:17

  33. Ben Vitale

    I would echo the previous comments about W3C DAP and wonder if this work hasn’t already been started.

    August 23rd, 2011 at 16:54

  34. James

    Please refer to http://xkcd.com/927/ and then adopt one of the 14 existing proposals.

    August 23rd, 2011 at 17:01

  35. Ben Vitale

    The DAP group is certainly interested in engagement.

    http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0051.html

    August 23rd, 2011 at 17:02

  36. Andrew

    A Calendar API covering CRUD would be wonderful to include in this 3-6 month period as it seems to have stalled in the W3C DAP group.

    August 23rd, 2011 at 17:02

  37. Jason

    Does the inclusion of the FileSystem API means there’s going to be attempts to implements the parts of the W3C’s File API that includes system and directory.

    Or is it something else?

    August 23rd, 2011 at 17:09

  38. Robert Nyman

    Gabriel,

    That would rather be a work of HTML5 in general, I would think, But I agree, it is very important that we get that.

    J.D.,

    Regarding the Open Web, I would first and foremost say that it is important just because it is open. It is not owned by any company or group, and anyone can use and take part of the open standards.

    For Mozilla, it’s definitely not about what’s popular right now, but about what we believe is good for the web and in line with our mission.

    John,

    For some people and organizations and media, DRM is quite important, though, so I understand the wish.

    Ben,

    It is not clear exactly how it will work, but Mozilla’s efforts are a bit wider than the current ones of W3C DAP. I hope the WebAPI goes back into W3C and we will find a solution that everyone gains from, and that we can work together.

    James,

    Mozilla’s ideas and goals aren’t covered by that, but by putting the results back into W3C I hope it will end up in an existing one, or that two or more will merge.

    Andrew,

    It would be very nice, yes.

    Jason,

    It is not clear right now what it will cover, but initially I would say reading and writing files.

    August 24th, 2011 at 00:04

  39. Archaeopteryx

    Yay for Calculator implementation, no more need for exploits to launch it.

    (Sorry for this unproductive comment, but I couldn’t resist.)

    August 24th, 2011 at 00:48

  40. Robert Nyman

    Archaeopteryx,

    I’m just glad you are happy about it. :-)

    August 24th, 2011 at 00:51

  41. Andrew Ozz

    This all sounds very good but what about contentEditable / designMode? WYSIWYG editing in the browser has been around for ages (10+ years) but is still not standardized. It works well for very simple text formatting but kind of falls apart as soon as you try a little more advanced HTML.

    Considering that a lot of the web content is currently published through the browser and this will only increase in the future, it’s sad that such an useful feature gets so little attention.

    I am aware that there are several very good Javascript based editors (I contribute to one of them) but just think of the possibilities if there was a standardized, robust editing support build into the browser.

    August 24th, 2011 at 07:05

  42. Fabio

    You don’t know…will be very useful to have it now!…
    Great project guys! I will tell about it to many developer friends.

    Ciao! F.

    August 24th, 2011 at 07:09

  43. Robert Nyman

    Andrew,

    I agree that contentEditable definitely needs more attention and work, but it is far from the scope of WebAPI at least.

    Fabio,

    Thanks, glad you like it!

    August 24th, 2011 at 07:36

  44. Davison

    I also agree that the scope of this initiative should not be limited to mobile devices. We could have web applications that finally function as true desktop apps if there was only a way to interface the code running in a web browser with system hardware or even other software running on the system.

    True, the implications of such an interface would certainly be complex with concerns for security and system stability, but the benefits would justify the time spent working on these things. Think of finally being able to create an application that has the power of jQuery and the portability of a browser, but can also print directly from javascript to a label printer (without bringing up a standard printer dialog box). Think of kiosks, POS systems, and all sorts of other applications that would be possible. Right now the only way to do something like that is to create some complicated and crufty plugins based on lower level languages and an ancient plugin architecture.

    Having a javascript-based API for access to the system is exactly what I’ve wanted for years.

    August 24th, 2011 at 21:10

    1. Robert Nyman

      I agree, there are tons of use cases where it would make things a lot easier. I think what matters right now, though, is testing this out and prototyping it, one step at a time, and see exactly where we can take it.

      August 25th, 2011 at 01:59

  45. Scott Wilson

    It would have been much nicer to preface this with an explicit commitment to collaborate with DAP and WAC rather than allow the impression of “screw those guys, we know best!” to form.

    And don’t say things like “put the results back into W3C”. Work together as a real community from the outset. Its just making a few posts to a mailing list ffs.

    August 25th, 2011 at 01:27

    1. Robert Nyman

      The idea is not to just dismiss the W3C DAP, WAC and their work, but rather experiment with some things that aren’t exactly covered by them.

      To me, at least, doing test cases and coming up with approaches and suggestions is more than just posting to a mailing list.

      August 25th, 2011 at 02:02

      1. Scott Wilson

        (As an Apache committer, most of what I do in terms of doing test cases and coming up with approaches and suggestions is basically posting to mailing lists! Ditto W3C. I don’t think Moz is much different…)

        I think having separate discussions going on about fundamentally the same features (contacts API, camera API etc) just isn’t helpful.

        Incidentally, which are the things that you think aren’t covered? I couldn’t see anything on the list above that isn’t in DAP, HTML5, WHATWG or WAC.

        August 25th, 2011 at 02:15

        1. Robert Nyman

          The list is pretty basic and the initial steps, but from what I hear from the team, there ideas and thoughts that go beyond W3C DAP.

          I agree that if, over time, we can find a good way to collaborate and not have redundant discussions about the same thing, it will be great!

          See this as a first step, and over time I hope all these questions and worries will be worked out.

          August 25th, 2011 at 03:10

  46. Chris K

    @fatriff – there are other uses for bluetooth than sync, but I agree with you sync is my preferred tool for the situation Tomer is describing. That said, Mozilla is founded on giving users a choice, so if Tomer wants to make a FF plugin / add on, I fully support that idea.

    August 25th, 2011 at 07:12

  47. Gerard Braad

    Since B2G is far from existing what will be used a base platform to start the development of these APIs?

    August 25th, 2011 at 19:28

    1. Robert Nyman

      I believe prototyping is going on for various platforms, but have no more specifics. Please look into the ways of contributing in the article if you want to talk more to them about it.

      August 25th, 2011 at 23:11

  48. Yop

    pliz i just need a browser that open in less than 30 seconds.

    August 26th, 2011 at 13:24

  49. patrick21

    Bluetooth has to be implemented. I work for a germansSoftware development business and programmed a lot of stuff with measuring devices for heating, oder EC-Card Reager, that are connetced via BT from a mobile device. Without some kind of interfacce, i can not convert the programs written in c# to html5 but i want to…is there anything coming? irda is dead but communication via bt is a must imho

    August 27th, 2011 at 09:08

  50. patrick21

    I have to add sth. to the BT post…it would be very comfortable to synchonize Data from my mobile Device to a desktop pc. imagin an app that collects data on the phone and send it directly to the desktop counterpart app an vice versa, if its connected via BT for syncronization, without being online. For example sending a sqlite db, or a file to import it. I feel sorry for my english, but you guys are the only ones that are responsible for HTML5 standards and i feel like its the future to come with. No one to talk about that here in germany :(

    August 27th, 2011 at 09:23

  51. Reg

    Sorry to be the cause of another round of derisive laughter, but the top issue for our organisation is DRM. We deliver internet video-on-demand solutions, and any delivery mechanism that doesn’t allow us a reasonable attempt to protect our client’s content from theft simply doesn’t get considered. For a long time the most favoured solution was Flash, but now clients are starting to insist on Silverlight.

    Ideally we would be able to take advantage of decryption beyond control of the browser – especially an open source one (no offence intended). This could be handing an encrypted video stream over to a HDMI device. After all IP TV is here – well almost.

    Not everyone will be using a HDMI device, and lower quality streams often do not require such strict protection. It would good to be able to push out a native build of a codec with our own decryption in it.

    August 28th, 2011 at 15:20

    1. Robert Nyman

      I do understand the need for DRM, and it is not something that will just go away. I would say it’s not currently within the scope for WebAPI, though. Only the future can tell where it all evolves with DRM and solutions.

      August 29th, 2011 at 05:51

    2. Natanael L

      DRM never works. It only needs ONE person to figure out how to break it, and then it’s broken.
      Combine that fact with open source, and…

      August 29th, 2011 at 05:59

      1. Robert Nyman

        I think that, no matter the opinion, a lot of organizations require DRM for content they share (think all kinds of media houses etc). I the end, even if it’s broken, I believe it’s about making it harder for people to share content that they don’t own.

        August 29th, 2011 at 06:35

        1. Natanael L

          And yet it is only an inconvenience to the honest people while only the original hacker among the the “less honest” sees it.

          August 29th, 2011 at 06:57

          1. Robert Nyman

            I’d agree that most implementations of DRM are a nuisance for most users, yes.

            August 29th, 2011 at 07:03

    3. Foo Bar

      DRM on audio/video content is simply physically impossible.

      Even if a software scheme cannot be defeated, anyone can just hook the audio/video outputs to a capture card, or just point a camera at the screen or attach a microphone to the speaker (if done properly, quality loss is negligible).

      The only thing you can successfully use DRM on is console games, provided that the console platform is properly designed for that.

      September 3rd, 2011 at 16:09

      1. Robert Nyman

        We know that, but I believe it’s more of making it harder for end users, thus hoping they won’t go through the effort of trying to break it.

        September 5th, 2011 at 01:37

  52. Fredrik Söderström

    This is great, I can’t wait to use this!

    This is a great way of keeping the web open instead of everything becoming closed source apps.

    August 31st, 2011 at 11:19

    1. Robert Nyman

      Thank you, good to hear!

      September 1st, 2011 at 02:40

  53. Julien Gouesse

    Please don’t use DRM. This is not what I expect from Mozilla foundation! It is absolutely unacceptable. Defending DRM consists in defending a technical mean to protect industries refusing to adapt their business model, it is not what I expect from an open source product. Supporting DRM in WebAPI means that you plan to give more power to corporations and less power to users, it is exactly the opposite direction taken by the vast majority of free open source softwares. DRM endangers our rights, it allows to disable features, block products, censor and delete content even without the consent of the users. Putting such a thing in WebAPI would lead to allow such things remotely in both desktop and embedded environments. Do not sacrify our freedom to increase their profits. Our lives are worth more than their profits! Say NO to DRM, say YES to free open source softwares respecting our rights.

    September 1st, 2011 at 06:07

    1. Robert Nyman

      I understand your strong opinions about DRM, and I’ve mentioned above that it not in the scope of WebAPI at all. What I am personally saying, though, is that for a number of legal reasons a number of media outlets are required to have a certain level of protection of their content – something HTML5 can’t offer at this time.

      So, I understand that the need is there in the market, but I don’t see Mozilla any time putting work into enabling DRM.

      September 1st, 2011 at 07:15

  54. Julien Gouesse

    Thank you for this clarification. In my humble opinion, the world can live without DRM and the market must evolve so that it does not need such a control on contents. If the market refuses to evolve, we should not encourage it to preserve “old” mechanisms by any means dangerous for our rights.

    As you say, it is clear that DRM is technically not in the scope of WebAPI. Maybe I expect too much from Mozilla Foundation but even the principle of restricting users’ ability to freely use purchased products should not be tolerated.

    September 1st, 2011 at 07:53

    1. Robert Nyman

      Personally, I’m not a believer in DRM either. But I do sympathize with the problems some developers/organizations have to face.

      Like you mention, from a Mozilla perspective, we do all kinds of activities to promote openness and the Open Web, and we aim to help out with offering open alternatives.

      September 1st, 2011 at 08:34

  55. David Rogers

    Sorry for my late response. Whilst I am pleased that Mozilla have finally come round on device APIs, I am equally frustrated that for the past three years they refused to engage with the OMTP BONDI, W3C DAP and WAC work on this. The scope was always there to be expanded and you could easily have contributed to the charter that I and others wrote. It is still unclear from the comments above as to whether you intend to fully contribute to the efforts ongoing in DAP and make this truly cross-browser and cross-industry. Also, please can you explain how you intend to handle access security and different user needs e.g. privacy?

    September 2nd, 2011 at 03:22

    1. Robert Nyman

      Personally I weren’t around with Mozilla back then and I don’t know enough about the history to have a comment on that. Hopefully the follow-up blog post addresses some of your questions.

      September 2nd, 2011 at 03:29

  56. Daniel Pavlic

    Hello,

    The WebAPI project looks very interesting. However, I don’t see any reference to the element in your spec. I think it would be a very good idea to make an API for drawing objects on the canvas which would make much easier to make a GUI than now is. The former Mozilla SkyWriter project (now http://cloud9ide.com/) has accomplished just this. It would be great to publish this engine so that everybody would be able to use it. Is this part of the WebAPI project?

    October 7th, 2011 at 14:54

    1. Robert Nyman

      That is not part of the WebAPI project at this time, but I agree it would be nice to be able to see that. We’ll see how it evolves.

      October 8th, 2011 at 15:03

  57. Daniel Pavlic

    Hi Robert, thanks for your reply. If an engine for drawing on the HTML canvas element is not part of the WebAPI project, and if I understand the accomplishments in the former SkyWriter i.e. former Bespin project correctly (http://benzilla.galbraiths.org/2009/02/17/bespin-and-canvas/), then it seems to me that Mozilla Labs already created an engine for drawing on the canvas 2 years ago? How would it be possible to create those menus, tabs, buttons etc. There must be an api created by the Bespin project so you can say e.g. WINDOW(x,y,length,height) and you get a window on the canvas which you can drag, minimize, maximize, put buttons on etc. I did not investigate deeper into what is now Cloud9 IDE, I’ve just read the blog articles about Bespin and I’ve seen the screenshots of the IDE so I might be missing something.

    October 8th, 2011 at 17:54

  58. Majid

    Great work!.

    April 17th, 2012 at 02:18

    1. Robert Nyman

      Thanks!

      April 17th, 2012 at 03:53

  59. Davy McAleer

    Hi Robert,
    firstly you have the patience of a saint replying to all the varied requests and opinions!
    This is possibly a bit early in the day to consider, but one of the big issues at present with Android versus Apple is the ability to securely control the device in the business environment and the level of security overall for both consumers and business users. Is there any thought to creating an MDM (Mobile Device Management) API to enable encryption, implementing settings and restrictions remotely and lock and wipe type functionality in the case of a device being lost?
    Android OEMs have implemented this in a very piece meal fashion and this greatly diminishes the usefulness of the devices in the corporate environment – and with BYOD policies starting to come into play more and more Apple now looks alot more compelling for businesses and consumers in terms of security.
    Just wondered if you guys had any thoughts on remotely managing B2G devices or some form of permissions type roles function to be able to access your APIs if one of the MDM companies creates an App to run on the devices and access all the APIs you are exposing.
    Thanks and looking forward to seeing this stuff hit the real world – hats off to all those dedicated open sourcers!
    Regards
    Davy

    April 22nd, 2012 at 13:34

    1. Robert Nyman

      > firstly you have the patience of a saint replying to all the varied requests and opinions!

      Thanks! :-)

      When it comes to current state and future plans for WebAPI, I’m personally not aware of work being done on that at the moment. But please keep track of the WebAPI page to see the progress!

      April 24th, 2012 at 15:04

  60. Gene Vayngrib

    This so is overdue! W3C is indescribably slow in this area. And Apple does not push device api in Safari as it will disrupt its App Store. Google behaves exactly the same as Apple on this issue. We have tried to remedy this with our own project 4 years ago, bhoost.com by creating a shell around webkit and know that it is no small undertaking. The problem is that people want to use a regular browser, not download a special one that gives access to Device Web APIs. So Mozilla entering this game may finally make Web Apps accessing Device APIs a reality. Besides, this would give Mozilla a leg up. Imagine a runaway popular Device-enabled Web App which works only on Mozilla for a while, until WebKit catches up. That App could be a Facebook Messenger, since Facebook pushes HTML5 agenda heavily as opposed to native Apps, or it could be something new.

    Some thoughts:
    1. What would be cool, is to have an ability in JS to check if browser supports Device API. This way we could offer user to download Mozilla browser.
    2. To compete with the Native Apps we need an easy way to register an icon on the home screen.
    3. To compete with the Native Apps we need an ability for a Web App to run in the background, or wake up upon some Device event.
    4. To compete with the Native Apps we need a way to autostart the background component of the browser and certain startup Web Apps. Imagine if user after a phone reboot needed to start the Phone and SMS apps manually. Can’t write a Web App that alerts me when some of my friends are in the vicinity if this ability is not present.

    April 27th, 2012 at 19:24

    1. Robert Nyman

      Yes, we look to have everything standardized and hope that all the major players will follow suit.

      Regarding the thoughts:

      1. Generally it’s rather up to what kind of API that you want to use, than having a collective check for all. Besides, the number of APIs included change all the time, so maintaining that isn’t realistic.

      2. I completely agree.

      3. Platform dependent, but yes, they should be able to run in the background.

      4. When it comes to phone and SMS specifically, I think it depends on what application will have the right to access that and also how you can detect things in the background.

      April 29th, 2012 at 08:42

  61. Gene Vayngrib

    Robert, thank you for your reply.
    1. Right, it is best to do checks on per feature basis. Can this be part of the new APIs? This way we will not need to come up with some ingenious and always different discovery mechanisms.
    4. May be I was not clear enough. I was referring to the Phone and SMS as examples of the apps which auto-start upon the phone reboot. If I were to create a new Siri, a new augmented reality app, a new social discovery app that reacts to where the user is in the environment and what is around him, I need to rely on the fact that my Web App is started after phone reboots.

    April 29th, 2012 at 08:53

    1. Robert Nyman

      1. Well, the hope is that general feature detection should work. Web browsers shouldn’t claim to support, for instance, a method if it isn’t fully implemented.

      4. Ah, I see. Not sure exactly where we stand with that at the moment, but I agree.

      May 8th, 2012 at 05:49

  62. Aravind R S

    Are there any plans in B2G for APIs to allow web applications to interact with each other? I think there is definitely a use case for simple interactions like Android Intents (WebIntents?).

    There might also be a need for something like background services that other applications on the device can communicate with via something like RPC.

    Intent use case: users may install multiple apps that provide “share” functionality on various social networks; Apps with content that can be shared could raise a generic “Share” intent and the user can then choose among the apps that provide that functionality.

    Intent/Services use case: users may have multiple internet radio apps from different websites, as well as a generic “music hub” app. The music hub app should be able to obtain a list of installed apps that have the “music playing service” capability, start/stop the services, and send messages to them for pause/play etc.

    July 12th, 2012 at 07:24

    1. Robert Nyman

      Intents and working cross-apps are indeed interesting! It’s not clear at this moment exactly how that will be, but I do hope we will see some good progress there!

      July 31st, 2012 at 08:28

  63. robert

    I think this first line
    Mozilla would like to introduce WebAPI with the goal to provide a basic HTML5 phone experience within 3 to 6 months.

    is very misleading. From what I understand, as a newbie, WebAPI is trying increase the number of cross browser APIs. They are not specifically targeting mobile or phones.

    July 16th, 2012 at 11:53

    1. Robert Nyman

      If you have seen the progress with Firefox OS, and with the hope of other mobile vendors following suit, it was exactly the first goal which has now been reached.

      Then, of course, we want as many APIs as possible be cross browser, no matter the platform.

      July 31st, 2012 at 08:31

  64. Himan Chen

    Hi,will you please tell me how to add a WebAPI to B2G,in other words,how can I write a WebAPI? Thank you!!!

    August 14th, 2012 at 19:59

    1. Robert Nyman

      WebAPIs are developed by Mozilla and the community and then submitted to the W3C for standardization. Please join that project and share any ideas you might have!

      August 15th, 2012 at 01:14

Comments are closed for this article.