Warning:
This wiki has been archived and is now read-only.
RemoteDOM API Specification DRAFT
Contents
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
- browser implementers
- display device implementers
- 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.
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:
- http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0082.html
- http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0095.html
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: