Features/Desktop/EditorAPI
Status
| Editor API | |
| Stage | Draft |
| Status | ` |
| Release target | ` |
| Health | OK |
| Status note | Understanding problems. |
{{#set:Feature name=Editor API
|Feature stage=Draft |Feature status=` |Feature version=` |Feature health=OK |Feature status note=Understanding problems. }}
Team
| Product manager | Kevin Dangoor |
| Directly Responsible Individual | Kevin Dangoor |
| Lead engineer | ` |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
{{#set:Feature product manager=Kevin Dangoor
|Feature feature manager=Kevin Dangoor |Feature lead engineer=` |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}
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
` {{#set:Feature open issues and risks=` |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. |Feature users and 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
|Feature dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=` |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}
Feature details
| Priority | Unprioritized |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | Platform |
| Secondary roadmap | ` |
| Feature list | Platform |
| Project | ` |
| Engineering team | ` |
{{#set:Feature priority=Unprioritized
|Feature rank=999 |Feature theme=` |Feature roadmap=Platform |Feature secondary roadmap=` |Feature list=Platform |Feature project=` |Feature engineering team=` }}
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}