RE: Native vs web UI use cases

Thanks Norbert. This nicely sums up that editing implementations fall somewhere between the browser doing the work and the site doing the work, and that editing UI can also be implemented by the browser or site. The way I see this working is that a site can create their own experience from scratch to enable 1b and 2b, or can use a framework (TinyMCE, CKEditor, etc) to enable 1a and 2a. The original contentEditable can also be used for 1a and 2a, but we're trying to move into a more extensible model instead where frameworks build this functionality instead of the browser.

> -----Original Message-----
> From: Norbert Lindenberg [mailto:w3@lindenbergsoftware.com]
> Sent: Sunday, July 13, 2014 10:48 PM
> To: public-editing-tf@w3.org
> Cc: Norbert Lindenberg
> Subject: Native vs web UI use cases
> 
> The explainer [1] has a good list of use cases representing different
> application types in which content can be edited. After reading the discussion
> so far, it seems clear to me that participants also have or see different needs
> for the degree to which contenteditable should integrate with native user
> interfaces vs be implemented using web technologies. Should we capture
> these as use cases as well, and do the following descriptions adequately
> represent them?
> 
> 1a) Some applications need their text input and text enhancement
> functionality and user experience to be as close as possible to that of native
> applications, including the same behavior and visual design, and are willing to
> trade off some control over editing behavior for that.
> 
> 1b) Some applications need to have full control over editing behavior,
> including interaction with input methods and spelling checking and correction
> software, and are willing to implement that interaction themselves and
> accept that they won't always match the functionality and user experience of
> native applications.
> 
> 2a) Some applications need to integrate with the browser's user interface to
> enable, disable, and initiate common commands (such as Undo or Cut), and
> to represent current state (such as whether all, none, or some of the
> selected text is bold).
> 
> 2b) Some applications need to have full control over their user interface for
> commands and state representation, are willing to implement that user
> interface themselves, and need related browser user interface to be hidden
> or disabled.
> 
> Norbert
> 
> [1] http://w3c.github.io/editing-explainer/commands-explainer.html

Received on Monday, 21 July 2014 23:41:40 UTC