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> 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>:
>
> 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
>
>
>
> --
> Charles McCathie Nevile - standards - Yandex
> chaals@yandex-team.ru - - - Find more at http://yandex.com
>
>



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