> -----Original Message----- > > On 23/06/2014 18:25 , Julie Parent wrote: > > Well stated. I like contentEditable=cursor. > > Works for me. Should I just scare up a draft? It is likely to be a pretty > short > spec :) >
I'm really looking forward to getting things sorted out! But I think we may want to take a step back and make sure we all agree on the problem, goals, and use cases, as Ryosuke has been pushing for. We have several different proposed solutions. Does it make sense to very clearly state all of this before we press on too quickly? I'm working on a draft now, and would like input. The list below takes a stab at it, but I'm sure there are others we should add and maybe some we don't need? Problems: * ContentEditable is too complex and buggy to be usable as-is * ContentEditable does not easily enable the wide range of editing scenarios * There are many ways to indicate user intentions and no clean way to understand them all * Accessibility tools have difficulty understanding what actions are available * Frameworks and sites may have difficulty understanding what is implemented, what should show up on toolbars and menus, and what needs to be polyfilled in editing scenarios Goals: * Make it easy to disable browser behavior in editing scenarios * Make it easy to implement custom behavior with appropriate APIs * Allow overwrite of behavior for a user intention from all actions that indicate that intention * Enumerate available actions in a given context before and after javascript adds/modifies behavior Use Cases: * Create a js framework that enables a WYSIWYG editor and works the same in all browsers with little browser-specific code * Use a js framework to insert a customized editor into an email client * Use a js framework to insert a customized editor into a blog * Use a js framework to insert a customized editor into a wiki * Create a document editor that uses an HTML editor as a frontend but a different document model as a backend * Empower complex editors to be accessible by enabling users to understand available behaviors with little accessibility-specific work from the framework or site
