|Status note||Understanding problems.|
|Product manager||Kevin Dangoor|
|Directly Responsible Individual||Kevin Dangoor|
|Product marketing lead||`|
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
- 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
Stage 2: Design
5. Functional specification
6. User experience design
Stage 3: Planning
7. Implementation plan
Quality Assurance review
Stage 4: Development
Stage 5: Release
10. Landing criteria
|Theme / Goal||`|
Team status notes