On Mar 17, 2014, at 4:59 AM, Robin Berjon <ro...@w3.org> wrote: > On 15/03/2014 18:44 , Johannes Wilm wrote: >> yes btw -- where should one go to lobby in favor of the editing spec? I >> have been communicating with several other browser-based editor >> projects, and there seems to be a general interest of more communication >> with the browser creators and spec writers. Currently the situation is >> that it's so broken in all the browsers, that one needs to use a 100% >> javascript approach, painting the caret manually and creating a separate >> system for selections, to circumvent the main problems of >> contenteditable (for example: >> https://bugzilla.mozilla.org/show_bug.cgi?id=873883 ). Codemirror is a >> good example of that. > > My understanding from talking to various people is that at least part of the > problem comes from the type of code that is currently deployed in the wild. > An awful lot of it works around browser inconsistencies not through feature > testing but through user agent switching. This means that when a given > browser fixes a bug in order to become more in line with others (and > presumably the spec), it actually breaks deployed code (some of which is > deployed an awful lot). > > I've been talking with some editor developers and have heard some interesting > ideas, notably from the Substance.io people.
I think one big problem with contenteditable and execCommand is that it's a very high-level API and that there are two very distinct use cases: WYSIWYG editor - Some CMS, Mail clients, etc... Semantic editor - Some CMS, word processors, etc... And there are also two distinct desires as to what kind of markup UAs should generate: Minimal output - Mail clients want to minimize the size of emails Preserving all elements - CMS editors, etc... want to mark parts of documents via span with id, class, etc... I'm very pessimistic about the prospect of fixing execCommand. I think we have a much better chance of coming up with some lower-level API that JS libraries could use to build editors. > One suggestion has been to make at least the selection API interoperable, > which seems achievable. So I'm very glad to see Ryosuke propose it here, I > was about to suggest the same. Glad to hear that. > Another that I've been mulling over is to have something like > contenteditable=minimal (bikeshed syntax at will). This would give you a > caret with attendant keyboard motion and selection, but no ability to > actually edit the content. Editing would happen by having a script listen to > key events and act directly on the content itself. The hope is that not only > is this a saner architecture for an editor, but it can also bypass most > (possibly all, if the selection API is improved somewhat) browser bugs to do > with editing. That sounds more like a selection-mode API than contenteditable to me. > I reckon a spec for that could be put together relatively easily. I'm still > digging through Web editors' code to get a feel for how much it would > actually help. The biggest piece we're missing on the web platform today is mapping of key events to intended editing actions. e.g. how do you know that Shift+Enter should insert line break as opposed to start a new paragraph, or that Shift+Control+Left should extend selection to the beginning of the line. Another big piece is undo. We currently don't have any ways to hook things up with browser's native UI for undo/redo, and as a result, most of websites implement their own undo manager which is incompatible with undo/redo menu items. I tried to solve this problem a few years ago with UndoManager API when I was still at Google but that turned into an incomprehensible monstrosity once we introduced undo scopes and other advanced APIs. We might need to introduce something simpler first like the one introduced in IE11 that uses execCommand to start and end an undo unit [1]. [1] http://blogs.msdn.com/b/ie/archive/2013/10/24/enhanced-rich-editing-experiences-in-ie11.aspx - R. Niwa
