Features/Desktop/EditorAPI

Status

Team

Open issues/risks

`

Stage 1: Definition

1. Feature overview

People are editing more and more text in browsers today. The different applications in which people are editing their text have different needs. The needs of a programmer's editor are different from those of an editor for writers, for example.

Ideally, all of these new web-based editors would handle accessibility and bidi text. In practice, the only ones that do are the ones that use contentEditable, which has limited extensibility and limited standardization across browsers.

The goal of this feature is to provide an API to developers to allow them to build customized editor behavior while maintaining accessibility and proper navigation and entry of bidi text.

2. Users & use cases

Code Editors

• high-performance with long files (30K lines)
• ability to do syntax highlighting
• ideally also provides high-performance on files with single long lines
• ability to do "code assist" (popups that provide completions for what the user is entering or possibly to prompt the user to take action in the case of errors)
• remappable keys
• transaction history
• integration with session restore

Rich Text Editors

• why did Google Docs drop contentEditable?
  • The answer had been posted on Google Docs Team's blog http://googledocs.blogspot.com/2010/05/whats-different-about-new-google-docs.html

3. Dependencies

`

4. Requirements

`

Non-goals

`

Stage 2: Design

5. Functional specification

`

6. User experience design

`

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

`

Feature details

Team status notes