Re: status of editing

If it would help to have a WebEx enabled for this call, let me know the 
date and time (UTC) and we'll get it set up for you.

Léonie.

-- 
@LeonieWatson tink.uk Carpe diem

On 17/01/2017 19:33, Grisha Lyukshin 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 <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
>     <https://github.com/w3c/editing/issues/150#issuecomment-249815640>
>     [2] https://github.com/w3c/editing/issues/150#issuecomment-249775255
>     <https://github.com/w3c/editing/issues/150#issuecomment-249775255>
>     [3] https://github.com/ckeditor/ckeditor5-design/issues/149
>     <https://github.com/ckeditor/ckeditor5-design/issues/149>
>     [4] https://twitter.com/reinmarpl/status/815891250612174848
>     <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 <http://www.fiduswriter.org/>

Received on Tuesday, 17 January 2017 19:53:04 UTC