Re: status of editing

Hey everyone,

given the current situation, I think we should have a call within the next
next few weeks. How would the week between January 18 and 25 work for
others? If not then, do you have alternative suggestions?

On Tue, Jan 3, 2017 at 2:53 PM, Piotr Koszuliński <
p.koszulinski@cksource.com> wrote:

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

It has been pointed out earlier that the Undo Manager API proposal was too
complex for various reasons, but that it it included a way to define the
scope of the undo and that this part could be used to make undo more local.
This may be a good idea, even if it's just a complex way to say that global
undo is never desired anywhere for richtext.

I came to the same conclusion as you, and found that also Google, Apple and
Microsoft softwares are broken. It's almost not noticeable if one doesn't
know where to look, but just find two different places where there is text
input (for example the search bar and the email composing part in Gmail).
Write a little in one, then click into the second. Type a little more. Now
undo all of it. You'll notice that they're all broken, in all the browsers
and all the OSes. Either the undo/redo is deactivated when it should be
activated, or it doesn't undo when it should.

It seems that JS editors really only want direct control voer enabling and
disabling the native undo buttons and listen to the beforeinput events for
both of them. But I understand that due to OS restarints, Safari cannot do
this. Instead they seem to argue that one could get a simple undo manager
where JS can manually add items and make the undo scope be local. This
seems to be almost as good, although it will likely create problems for
collaborate editors, when a change of user A mean that the last 7 changes
of user B no longer have any meaning.

The main point here is that we really need to get going with this. This
should be in the interest of all the involved organizations and companies,
as the undo/redo menus are broken for all of them, and have been for a very
long time.


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

I believe I saw a long description with images in a report written by a
CKEditor person some months ago. Do you have the link for this?


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

Well, I can see that there are 7 Billion people on this planet and with so
many different writing styles and needs, there is likely also a community
out there that happens to want these features. And having direct access to
some of the richtext editing features right on the keyboard sounds pretty
neat.

But I must agree with Piotr that this isn't what the main editors currently
are interested in. I wonder: Has Apple considered whether to open up these
various formatting menus (on iOS and macOS) so that the JavaScript editors
can enter their own menu items in there and replace the existing ones? It
seems like this would allow both for you to keep your menus, while
alleviating some of the frustration these editor devs have had when dealing
with Apple products.



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



-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org