Re: contentEditable=minimal

On Tue, May 27, 2014 at 1:48 AM, Ben Peters <Ben.Peters@microsoft.com>wrote:

> >>> 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.
>
> The goal of Command Event is to make this a non-issue. If sites respond to
> bold/italic/list commands they can handle this UI just fine. Are you
> concerned that a site may not use bold so the button would have no effect?
>

Yes, it should be possible to disable whichever feature you don't need. In
some cases you don't need lists (because e.g. you're editing a text that
will become a content of a paragraph). And in some cases you don't want
bold/italic because your use case requires only structured HTML. So being
able to handle such commands is a one thing. But first of all there should
be no assumption that a user needs these buttons, because a browser just
don't know about that. If I think that users need toolbar, I can render a
custom one.

There's one more assumption that makes editing on mobile devices
(especially low-res devices) very hard. It's that if user focuses editable,
then he/she wants to type, so native keyboard should pop out. Very often
it's true, but in some cases user may want to select some text and using
toolbar apply styles or lists, etc. And when the keyboard is visible
there's very little space to do that. If there was any API to control
whether keyboard is visible, then we could achieve much better UX.


-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer