Standards For Web Apps on Mobile: State and Roadmap
Switch branches/tags
Nothing to show
Clone or download
Latest commit 6f562be Nov 9, 2015
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
data Link to requestidlecallback TR draft Oct 15, 2015
js Improve display of editors activity Sep 3, 2015
specs Update TR data Sep 4, 2015
tools Handle outdated closed-groups.rdf Sep 3, 2015
.gitignore new filename for safari Nov 18, 2014
Makefile
README.md document "feature" key in JSON files Aug 12, 2014
github.svg remove github ribbon, use octocat instead Jan 19, 2015
html5apps.png added HTML5Apps logo for ack Jan 30, 2015
index.es.html
index.html Fix typo Nov 9, 2015
style.css
webapp.svg add platform diagram; close #35 Nov 25, 2014

README.md

Standards For Web Apps on Mobile: State and Roadmap

This repository holds the data and part of the tools needed to build the quarterly Standards for Web Applications on Mobile: current state and roadmap document.

Data

Data model

Each JSON file contains an object that describes a given spec with the following properties:

  • TR: url of the TR document (if it exists); if it doesn't, please also document the following data:
    • title: title of the spec (if known)
    • wgs: working groups responsible for the spec, described as an array of objects with properties "label" (name of the group) and "url" (homepage of the group)
    • maturity: "ed" for editors draft, "N/A" if not even a draft is available
  • feature: the specific relevant feature of the spec (optional)
  • coremob: "fulfills" if the spec was part of CoreMob 2012; "partial" if the spec partially fulfills CoreMob 2012; omit completely otherwise
  • stability: object with property "level" (one of "low", "medium", "high") and "label" that describes textually the stability of the spec
  • editors: object with property "url" that points to the editors draft of the spec; if there isn't one, use a property "label" set to "N/A" instead
  • impl: current level of implementation of the feature in mobile browsers, described via an object with properties "level" (one of "low", "medium", "high"), "label" (a textual description of the implementation level), and "id", the id of the feature in @dontcallmedom/canmymobilebrowser
  • tests: information about test suite for the spec, described via an object with properties "url" (url of the tests that can be run), "repo" (url of the repository of test cases), "level" (how complete the test suite is, one of "low", "medium", "high"), and "label" (a textual description of the coverage level)

Feature description

The index.html file contains purely textual description of a set of features; these features are then automatically summarized in data tables (one per section of the document) via generate.js.

To enable this generation of summary tables, each feature of the document is annotated with:

  • a data-feature attribute whose content will be re-used to label the feature in the summary table
  • one or several a elements with a data-featureid attribute whose value matches the basename of a file in the data directory; each of these elements will generate a row describing the relevant spec
<p data-feature="Name of the highlevel feature">Lorem ipsum <a 
 data-featureid="shortname-used-in-data-directory">Foo
 Specficiation</a> lorem ipsum.</p>

Contributing

Document

Contributions to the body of the document to improve the descriptions of the various features can be made via pull requests on index.html.

Particularly worth checking for updates: sentences that use future events (“will”, “would”, “proposed”, “expect”) or evoke recent events (“new“, “recent”).

Data

The most simple form of contribution is to ensure that the data about the various features is kept up to date.

Most of the data is stored in JSON files in the data directory; please make pull requests to update it. The data that requires most frequent updates is:

  • the level of stability of a given feature
  • the advancement of the test suite.
  • the link to the TR document

The data about the state of implementation is maintained in a separate repository: @dontcallmedom/canmymobilebrowser to which contributions are also most welcomed.

Note that the data about maturity and Working Groups is automatically obtained from the W3C list of Technical reports.

Adding new spec

To add a new spec to the document:

  • create a JSON file in the data directory with the required information
  • add the document to the relevant section of index.html as in the example given in “Feature description”

Building

Building the document remains a somewhat convoluted process:

  • build the editors activity images via @dontcallmedom/w3c-editors-draft-tracker
  • build the implementation status images via @dontcallmedom/canmymobilebrowser
  • install the images generated in the two steps above resp. in editors-activity and images
  • copy the images at the root of @dontcallmedom/canmymobilebrowser in the directory
  • load index.html in a browser
  • export the resulting DOM as the final document
  • add the changelog to that document, set the date, update the version URLs
  • convert it to PDF