Re: contentEditable=minimal

>
>
> > 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