Warning:
This wiki has been archived and is now read-only.

RemoteDOM API Specification DRAFT

From Remote DOM Community Group
Jump to: navigation, search

Remote DOM API Specification Draft

Scope

Audiences

Three key audiences:

  • Browser implementers
  • Display device implementers
  • Web developers

(need discussion to determine priority)

Additional audiences: (need discussion to determine priority)

  • test suite authors

Proposed Audience Priority

  1. browser implementers
  2. display device implementers
  3. web developers

Reasoning:

  • The browser implementations will most likely be more complex as will be the security concerns and issues (displays can rely on some physical proximity for example). They also need to ensure proper rendering on display devices.
  • The display device implementers adoption and feasability is crucial to this specification as they need to be able to implement solid means for discovery and communication with browsers.
  • Web developers will have a say in the interface to leverage what browser and display implementers agreed to offer to the web applications and should have a say in the interface design.

Boilerplate

This branch of the Restyle effort is about redesigning the content of the W3C spec template.

The first step is identifying what information needs to be in the template.

The second step will be organizing, ordering, and designing that information.

See SpecProd/Restyle/Content.

Design

This part is about the overal design of the spec: the look and feel of the specs and the layout and styling of the header, of metadata, etc. It's dependent on the boilerplate content being stablized.

Some useful comments:

Readability

This part is about the typography of the specs: the styling of headings, lists, paragraphs, tables, examples, notes, code snippets, IDLs, etc. It integrates with the overall Design aspec.

See existing documentation of markup conventions: