Re: status of editing

Grisha and I are Pacific
Dave is Eastern

On Mon, Jan 30, 2017 at 11:48 AM, Johannes Wilm <johannes@fiduswriter.org>
wrote:

> 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>
> wrote:
>
>> I am fine with February 14th.
>>
>>
>> Sent from Outlook <http://aka.ms/weboutlook>
>> ------------------------------
>> *From:* johanneswilm@gmail.com <johanneswilm@gmail.com> on behalf of
>> Johannes Wilm <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
>>
>> *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>
>> wrote:
>>
>>> After Feb 13th generally works for me.
>>>
>>> On Tue, Jan 17, 2017 at 2:54 PM, Gary Kačmarčík (Кошмарчик) <
>>> garykac@google.com> wrote:
>>>
>>>> Feb (in general) works for me.
>>>>
>>>> On Tue, Jan 17, 2017 at 11:33 AM, Grisha Lyukshin <glyuk@microsoft.com>
>>>> wrote:
>>>>
>>>>> How about some time in February?
>>>>>
>>>>>
>>>>> Sent from Outlook <http://aka.ms/weboutlook>
>>>>> ------------------------------
>>>>> *From:* johanneswilm@gmail.com <johanneswilm@gmail.com> on behalf of
>>>>> Johannes Wilm <johannes@fiduswriter.org>
>>>>> *Sent:* Tuesday, January 3, 2017 4:02:02 PM
>>>>> *To:* Piotr Koszuliński
>>>>> *Cc:* 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> 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
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Johannes Wilm
>> Fidus Writer
>> http://www.fiduswriter.org
>>
>
>
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org
>