Re: status of editing

Hi Johannes,

> * The undo stack is global, which means it's broken for every editor we
have been able to find on the net, including those managed by all the
browser maker companies. It would be good if we could figure out how to
replace the global undo stack for contenteditable with separate undo stacks
for every contenteditable element (could be an optional setting if this
works best for Safari, even though no existing editor uses the global
setting) [3].

It's a very good point that this is broken for everyone. I can understand
Webkit's team rejecting the proposals to expose the undo manager because
that would be impossible/hard to integrate with the OS or browser. But the
truth is that the situation is totally broken already and currently every
RTE I checked implements its own undo manager, which completely ignores
what the browser tells it. It's also unacceptable for RTE authors to have a
global undo stack (we've taught users that each editor handles undo
separately [1]). Finally, I don't understand how the browser's undo stack
is supposed to work with RTEs implementing custom data models and
collaboration features. Ryosuke pointed out [2] that W3C "specifically
worked with Google Docs team to ensure their undo worked with the API", but
I don't understand how was that supposed to work. It'd be interested to see
some PoC or discussions, because it may turn out that the proposed Undo
Manager API would be acceptable.

> * There is a large, opverlapping menu on iOS giving formatting options.
This is problematic for two reasons: 1. It overlaps the texteditor 2.

I agree with everything you wrote, but I'd like to add one thing here. It's
a much broader topic, but we've been researching how we can show our own
controls on Safari@iOS and it turns to be extremely hard when the on-screen
keyboard is visible. As far as I understand, Safari implements some
non-standard viewport mechanics which makes positioning things very hard
(if not impossible). From what we've seen, it all works as you'd except in
Chrome@Android.

This means that not only the menu is overlapping with our controls and that
we can't control it, but we also can't reliably display something on the
screen when the keyboard is visible. So the situation is broken on 3 levels.

>  The issue with the non-available features in editors has apparently
become worse with the "Touch Bar" on Macbook Pro. While Safari always had
some editing options hidden in an obscure menu that don't seem to work in
any of the existign editors, some of these formatting options are now more
prominently placed, which means it will be more obvious when they don't
work [5].

This is really sad. We've been working to gain more control over the
editing experience and suddenly a font color picker appears in the "Touch
Bar". I can even understand bold, italic and lists which are what more than
90% RTEs enable (although, not all – see Twitter). But font color doesn't
appear in any modern editor because it's a non-semantic styling option
which, in most cases, content authors should not be able to use. Exposing
features like font color picker in the touch bar moves us back to 00's [4].


[1] https://github.com/w3c/editing/issues/150#issuecomment-249815640
[2] https://github.com/w3c/editing/issues/150#issuecomment-249775255
[3] https://github.com/ckeditor/ckeditor5-design/issues/149
[4] https://twitter.com/reinmarpl/status/815891250612174848

--
Best Regards,
Piotrek Koszuliński | CKEditor Lead Developer
--
CKSource – http://cksource.com | Follow CKSource on: Twitter
<http://twitter.com/cksource> | Facebook <http://www.facebook.com/cksource>
| Google+ <https://plus.google.com/+CKSource> | LinkedIn
<http://www.linkedin.com/company/cksource>