Re: status of editing

Works for me.


Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: johanneswilm@gmail.com <johanneswilm@gmail.com> on behalf of Johannes Wilm <johannes@fiduswriter.org>
Sent: Thursday, February 2, 2017 3:39:13 AM
To: chaals@yandex-team.ru
Cc: Grisha Lyukshin; Dave Tapuska; Gary Kačmarčík (Кошмарчик); Piotr Koszuliński; public-editing-tf@w3.org
Subject: Re: status of editing

How about 18:00 Berlin/Madrid  = 9:00 Pacific = 12:00 Eastern on February 14th?

On Wed, Feb 1, 2017 at 12:30 PM, <chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>> wrote:
Europe GMT+1, available 11-16, 17-20, 23-0100 the next morning.

cheers

30.01.2017, 20:53, "Johannes Wilm" <johannes@fiduswriter.org<mailto:johannes@fiduswriter.org>>:
Whattime zones are those interested in partipating in? I am available at any time.

On Sat, Jan 21, 2017 at 2:03 AM, Grisha Lyukshin <glyuk@microsoft.com<mailto:glyuk@microsoft.com>> wrote:

I am fine with February 14th.



Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: johanneswilm@gmail.com<mailto:johanneswilm@gmail.com> <johanneswilm@gmail.com<mailto:johanneswilm@gmail.com>> on behalf of Johannes Wilm <johannes@fiduswriter.org<mailto:johannes@fiduswriter.org>>
Sent: Wednesday, January 18, 2017 1:07:24 PM
To: Dave Tapuska
Cc: Gary Kačmarčík (Кошмарчик); Grisha Lyukshin; Piotr Koszuliński; public-editing-tf@w3.org<mailto:public-editing-tf@w3.org>

Subject: Re: status of editing

Ok, same here. February sounds good. February 14th then? Or do we need a doodle?

On Tue, Jan 17, 2017 at 9:26 PM, Dave Tapuska <dtapuska@chromium.org<mailto:dtapuska@chromium.org>> wrote:
After Feb 13th generally works for me.

On Tue, Jan 17, 2017 at 2:54 PM, Gary Kačmarčík (Кошмарчик) <garykac@google.com<mailto:garykac@google.com>> wrote:
Feb (in general) works for me.

On Tue, Jan 17, 2017 at 11:33 AM, Grisha Lyukshin <glyuk@microsoft.com<mailto:glyuk@microsoft.com>> wrote:

How about some time in February?



Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: johanneswilm@gmail.com<mailto:johanneswilm@gmail.com> <johanneswilm@gmail.com<mailto:johanneswilm@gmail.com>> on behalf of Johannes Wilm <johannes@fiduswriter.org<mailto:johannes@fiduswriter.org>>
Sent: Tuesday, January 3, 2017 4:02:02 PM
To: Piotr Koszuliński
Cc: public-editing-tf@w3.org<mailto:public-editing-tf@w3.org>
Subject: 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<mailto: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<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<http://www.fiduswriter.org/>


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


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


--
Charles McCathie Nevile - standards - Yandex
chaals@yandex-team.ru<mailto:chaals@yandex-team.ru> - - - Find more at http://yandex.com





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