> > > > 6. Spell check. When you want a native spell check you cannot override > > context menu. When you want custom context menu, you need custom spell > check > > (which is extremely hard). And context menu is very important for many > users > > because they used to look there for contextual options, so most editors > > override it. Therefore, a way control at least one of them (I guess it > won't > > be a context menu, though that would be awesome) will be great. > > There's already a contextmenu feature in HTML, though I don't know if > any other browser than Firefox implements it. And the spec has seen so > much changes that I don't know how closely Firefox conforms to the > spec. Anyhow, I think the ability to extend/replace the existing > context menu is the way to go if that's what people need. > > Do you mean: http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus ?
I didn't know about it. It doesn't seem to work on any browser yet, but it should be able to solve our problems. I hope it will be implemented soon. > > > 5. There should be no native toolbars in cE=minimal (and other native UI > > interfering) like the one Safari opens on iOS if you have non-empty > > selection. > > I haven't yet checked exactly what's in the iOS toolbar, but generally > I don't think we should dictate UI. Clearly on mobile we don't want to > forbid browsers to bring up the virutal keyboard, which is a form of > "native UI". And the spellcheck UI that safari displays also doesn't > seem bad if spellchecking is enabled. > > And UI for cut/copy/past that android renders seems good to render > *somewhere* when there's selection. > On iOS the contextual toolbar not only contains copy/cut options which are of course ok, but it also contains bold, italic and lists buttons. That's unacceptable and I assume this kind of native UI will not be implemented for cE=minimal. > > > Another thing that we should look at is the ability to style ranges > rather than just elements. In Gecko we have an internal feature that > allows us to style DOMRanges. This allows us to render a red dotted > line under misspelled words and black line under composition > characters. And do that without worrying about managing a lot of extra > elements in the DOM. > > Right now pages are forced to sprinkle elements all over the DOM in > order to do the same thing, which then makes editing that DOM more > complex. It would be awesome to find ways to enable styling ranges > which would allow them to keep a simpler DOM. > Wow! Such feature would be awesome. This reminds me about an idea mentioned in https://medium.com/medium-eng/122d8a40e480 that cE could be reimplemented with shadow DOM. It would be extremely powerful if caret and selection and styled ranges were real, accessible elements. Which brings me to think: when we discussed this at the Summit, there was > some agreement (between all four of us :) that it was a good idea to > support multi-range selections. These are useful not just for tables, but > also for bidi. The reason for the latter is that when selecting a line with > multiple embedded directions (using a mouse), you want to have the visual > selection be an unbroken line (as opposed to the crazy jumping around you > get if you follow logical order). > It's definitely useful, though it does come with its problems. The > question that opens up for me is: do we want to support multi-caret editing > as well? The data model certainly supports it, but we have to account for > it early if it's an option. > At any rate, multi-range selections would be much easier to handle if we > had something like Selection.forEachRange(function (r) {...}). Uh... multi-range selections. I find myself and my colleagues ignoring them. They add so much complexity to already complex tasks that we simply handle first range and ignore other. And I don't remember complains about that. They make some sense when selecting table columns but this is not a necessary feature and may be also handled by an editor by fake selection. Multiple carets are useful in code editors, but not a single text editor's end user know about them (and I believe they were removed from Firefox). I don't know the bidi case though. But if it could be handled without multi-range selections I would gladly forget about them. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
