No edit change proposal for canvas text editing

Summary

The spec contains text that advises authors to not attempt to create text editing in canvas. We should not change this guidance by enabling or promoting canvas text editing - authors and users will not end up with accessible text editing due to the inherent complexity and platform-specific nature of text editing.

Rationale

The canvas 2d context spec has an entire section (http://dev.w3.org/html5/2dcontext/#best-practices) on why authors should not attempt to make a text editor rendered in canvas:

• Mouse placement of the caret has to be reimplemented.
• Keyboard movement of the caret has to be reimplemented (possibly across lines, for multiline text input).
• Scrolling of the text field has to be implemented (horizontally for long lines, vertically for multiline input).
• Native features such as copy-and-paste have to be reimplemented.
• Native features such as spell-checking have to be reimplemented.
• Native features such as drag-and-drop have to be reimplemented.
• Native features such as page-wide text search have to be reimplemented.
• Native features specific to the user, for example custom text services, have to be reimplemented.
• This is close to impossible since each user might have different services installed, and there is an unbounded set of possible such services.
• Bidirectional text editing has to be reimplemented.
• For multiline text editing, line wrapping has to be implemented for all relevant languages.
• Text selection has to be reimplemented.
• Dragging of bidirectional text selections has to be reimplemented.
• Platform-native keyboard shortcuts have to be reimplemented.
• Platform-native input method editors (IMEs) have to be reimplemented.
• Undo and redo functionality has to be reimplemented.
• Accessibility features such as magnification following the caret or selection have to be reimplemented.

Native text editing methods in user agents are simpler to use as an author, and will deliver a superior, platform-specific and more accessible experience for the user - the user agent (as detailed above) has unique information and capabilities that the web platform does not have (Spell checking, speech info, form factor-specific considerations, etc). It would be more prudent to gather whatever requirements authors have for canvas text editing and work on those in the HTML Editing APIs community group.

For the two use cases at http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelectionRevised: For simple cases, superimposing a text field onto a canvas is sufficient for delivering a platform-appropriate editing experience.

For cases where more rich editing is required, other solutions already exist: Online versions of Microsoft Office and SkyDrive already implement a rich text editor by overlaying an editing control on top of the main document. Arbitrary text decoration is in the scope of the CSS working group, font styles and glyphs are in scope for the Web Fonts WG in coordination with CSS. Additionally, IME scenarios are better handled in specs suich as http://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html.

Additionally, even if the spec detailed platform bindings for all the requirements above, authors that make text editing experiences will have to re-implement a prohibitive amount of platform-native functionality. It is unlikely that this will result in fully accessible text editing experiences.

Details

Make no changes to the spec that enables text editing mechanisms.

[Keep the existing spec text at http://dev.w3.org/html5/2dcontext/#best-practices]

Positive Effects

Authors will clear guidance on the best mechanism for text editing.

Negative Effects

None identified

Conformance Classes Changes

None identified

Risks

None identified