w3c-webmob / web-api-gap Goto Github PK

The API Gap Project is producing a document comparing the APIs and features available across various mobile platforms, and how web APIs and functionality compares.

Shell 7.86% HTML 56.14% JavaScript 23.79% CSS 12.20%

web-api-gap's Introduction

API Gap Repo

What is the API Gap Project Doing?

The API Gap Project is producing a document comparing the APIs and features available across various mobile platforms, and how web APIs and functionality compares. As APIs will contiually be added to native platforms and the web this document will continue to evolve.

The document is held in the document/ directory
All other directories and files are currently being used to list the apis we need to include in the document, these will be migrated to the document soon.

How do I contribute to the document?

Please feel free to send in pull requests! Please also raise issues as to how the document should be structured, what APIs we should include and other editorial hints and tips.

A little more about this repository

This repository was set up to compare the features available across various mobile platforms, with a specific focus on how the Web fares in that comparison. The /document is a result of this work.

Each feature is documented as a separate markdown file in the features directory.

To document a given feature, please start from the template file, and update it with data on the availability of the said feature across platforms.

For each line in hte list, include one of the following values (using bolding):

unknown (default if empty): no info gathered on this platform
browser: for HTML-based platforms, the feature is available and uses the same API as the one defined for browsers
sysapp: for HTML-based platforms, the feature is available and uses the same API as the one defined by sysapps
extension: for HTML-based platforms, the feature is available as defined by browsers or sysapps specs, but is extended with additional capabilities
yes: feature is available
partial: feature is partially available
planned: not available yet, but work on this feature has been announced
alternative: not available directly, but there exists work arounds (e.g. server-side solutions)
no: feature is not available
N/A: feature is not applicable to this platform

List of features

Defining what a feature is is tricky; the following documents can be used as source of inspiration:

web-api-gap's People

Contributors

Stargazers

Watchers

Forkers

web5design imaffett pauljt jakearchibald mangini paumoreno alexbardas cthedot umaar raucao maxspivak spencerx pablosoundaudio mtco kleopatra999 d4n1 takeshiu beingsane mattlk13 deniak

web-api-gap's Issues

Change the section name from BlackBerry to BlackBerry10

BlackBerry10 is more appropriate than only BlackBerry, since we are referring to the platform instead of the brand.

sysapp

do we keep, change or remove sysapp from data? recommendation is to remove

Add comments about how healthy web implementations are

In https://github.com/w3c-webmob/web-api-gap/blob/gh-pages/document_text.md add some comments as to how healthy the development of web versions of the apis are.

For each API

Hi all! For each API we will need to list / show qualities related to information the readers will want to see, are people happy to show these pieces of information for each API?:

Feature: what feature the api has
Description: of the api functions
API / Platforms: list native platforms which use this api and the names they give it
Related Web API: does a related web api exist?
Working Group: which w3c working group is/should look after this?
Current implementations: do any browsers do this already?
Plugins: do any plugins do this already?
Security Concern: short sentence on possible security concern of api
Dependancies: what would the web need to have to support this?

Draft document

send to dom an example of what i imagine the accelerometer data to look like in the document so he can adapt the script for this

Related Web APIs

For notes: here are the related APIs for each section:

Core Web Design and Development: SVG, Canvas, WebGL, CSS Transforms, CSS Animations, Web Animations, Flexbox, Fonts (CSS Font Loading, WOFF), Full Screen, Screen Orientation, 3D graphic API for HTML5

Is BT LE really not supported on FFOS & Chrome? The spec is BT 4 (=BT LE)

New API Document Structure

Last time we spoke we were thinking of making it similar to Dom’s "Standards for Web Applications on Mobile: current state and roadmap" document (http://www.w3.org/Mobile/mobile-web-app-state).

What I want to figure out now is how we should structure the API Document. Effectively we'll be listing Native APIs and the platforms that support them, then we'll be stating somewhere whether they have been implemented on the web yet or not. So, we could group APIs by categories, as in the "Standards for Web Applications on Mobile: current state and roadmap" document.

If you guys agree with this - can we copy the structure from the "Standards for Web Applications on Mobile: current state and roadmap" document for our document? Or do you think we need to add or remove some categories. The categories currently are:

Core Web Design and Development
- Graphics and Layout
- Device Adaptation
- Forms
Data storage
Media and Real-Time Communications
Usability and Accessibility
Device Interaction
Network Integration
Application Lifecyle
Payment and Services
Performance & Tuning
Security & Privacy