Re: New API proposals from Editing TFs discussions

Hey Travis,

yes so the editing taskforce is in place and continues the work on the
existing specs. Responsibilities for text editing and those current specs
clearly lies with the Webapps working group that has been established
already. I am not opposed to additionally also start a community group if
there is the interest to put additional resources into text editing on the
part of browser makers in the coming 5 years that just always has meetings
together with the taskforce. The main advantage of that that I can see is
that someone can put in their resume/CV that they are the "President of the
W3C Community Group on Editing" and then hopefully we can get that person
to feel enough responsibility to organize meetings, etc. rather than me
having to do it on the side.

As for your points:

1. Additional participation: This does not seem relevant in our case. We
already have all the browsers present and all JS editor projects are either
actively participating or are not doing so on purpose (mostly because too
much time is wasted on discussing process, browser makers don't stick to
things agreed in the past, etc.). I am actively going out to find new JS
editor projects projects all the time and contact them whenever I find
them. I don't see how W3C processes have stopped anyone from participating
in our discussions, given that anyone interested from the JS editor side
has been able to get in via "Invited Expert" status.

2. Two step process: That is probably relevant when you discuss things in
groups of hundreds or thousands of developers, but not when you have
meetings of 7-15 developers dedicated to editing. And that's the situation
we have been in since the editing taskforce was started and I don't see it
changing any time soon. It's not helpful to have two different rounds of
discussions at the level we are at. And unless browser makers are willing
to put a lot more resources into editing, it does not reasonable that they
will go for implementing two alternative preferred ways for JS editor
frameworks to interact with the browser. It's either going to be Input
Events level 2, your new proposal or some third proposal, but not all three
at the same time. We may end up disagreeing which way to go forward, but at
least we will find out about that in the same meeting. For JavaScript
developers it would mean a turn for the worse if browser makers would add a
second editing method besides contenteditable and then have have a ton of
bugs in both methods and not have the resources to fix either one. For this
purpose it just sounds like a lot of overhead that is completely
unnecessary and probably stops the last little bit of progress we were
experiencing over the last few years.

3. Independent organization: I take this as meaning that there will be this
President of the Editing Community Group who, in coordination with the rest
of us, can organize other meetings. I am not opposed to us getting a little
more independence from the working group because many times personal
interests between Editing Taskforce participants and other WG participants
have differed so much that neither knew what was going on in the other
meeting and one needed to communicate a lot back and forth when we needed
something from them. So yes, this is the one valid reason I can see.

My suggestion: I am fine with a community group that officially organizes
meetings to discuss editing related things (organizes rooms, etc.) with
some kind of President/Secretary who gets the job of having to do that. The
meetings should however also be able to discuss those specs that are
further in the process already, as we simply don't have the number of
people interested in editing on this planet to have that be two entirely
separate entities and we really need to hear about disagreements in the
same room and not in two completely different fora. Not everyone is forced
to stay during the entire meeting, so if we discuss new proposals in the
morning and things that are on track in the afternoon, then those who don't
want to participate in the second part can just stay away. Most likely that
means that on paper the meeting needs to be organized between Editing
Taskforce and Community Group, and in reality that means that when
organizing the meeting, the President of the CG coordinates with the chairs
of the Webapps WG to make sure invitations are being sent out in time, to
the right people, etc. to follow W3C/WebApps rules. As long as there are
only 1-2 meetings a year that really shouldn't be a problem.



-

On Fri, Jul 26, 2019 at 2:35 AM Travis Leithead <
travis.leithead@microsoft.com> wrote:

> Johannes, thanks for your response!
>
> It sounds like we share the same goal: to be sure the same community of
> individuals who are interested in developing the specifications currently
> in the WebApps WG charter also participate in discussions around new
> proposals, so that the whole picture of editing can be considered together.
>
> It sounds like you are also wondering about what to do with new proposals
> (and we have a few we'd like to discuss). One option you've noted is to
> re-start an Editing task force under the Web Apps WG. I would say we are
> not opposed to that idea. However, I think there are a number of good
> reasons why we should consider using a community group. Perhaps you would
> agree?
>
>    1. Encourage additional participation. We need a good blend of
>    feedback from both implementers as well as editing framework developers and
>    other developers to have higher confidence that our proposed solutions meet
>    their needs.  Community Groups have a much lighter-weight IP policy, and do
>    not require being a member of the W3C to join, thus reducing the barrier
>    for these folks to participate if invited.
>    2. We'd like to use an Incubation model for new proposals, which means
>    in practice that we want to be able to make rapid progress and potentially
>    rapid change without the process overhead of Rec-track documents, charter
>    reviews, etc. We've seen a two-step model work well in community groups
>    (like Web Assembly or Immersive Web) where the proposals can be developed
>    in a community group and then brought into their "big brother" working
>    group for more formal polishing and final recommendation approval. It's
>    very possible or even likely that with a two-step incubation model for
>    editing in place, the Web Apps WG may want to move some of their existing
>    long-term deliverables back into incubation (ones that aren't making
>    progress)...and that's can't really happen with a task force.
>    3. We think having a new Editing-focused CG that encompasses the
>    existing folks in the prior editing task force will help keep a cohesive
>    community together, enabling independent meetings, dedicated focus of the
>    group on related editing specs, etc. This goal is attainable via a
>    re-started Editing task force as well, though the CG can continue
>    independently of what may or may not happen to Web Apps WG's charter in the
>    future.
>
> The bottom line is that we hope we can depend on your existing expertise
> regardless of the outcome of where we all decide to do the work. You've
> been an excellent partner over the years, and we really value your insight.
> Our purpose is to continue to advance editing on the web so that it becomes
> easier and easier to make 1st class editing experiences possible (and
> easier/more reliable) too!
>
> ------------------------------
> *From:* Grisha Lyukshin <Grisha.Lyukshin@microsoft.com>
> *Sent:* Thursday, July 25, 2019 1:31 PM
> *To:* Johannes Wilm <johannes@fiduswriter.org>
> *Cc:* Alessandro Curzi <Alessandro.Curzi@microsoft.com>; Bogdan Brinza <
> Bogdan.Brinza@microsoft.com>; Bo Cupp <pcupp@microsoft.com>; Anupam
> Snigdha <snianu@microsoft.com>; Sanket Joshi (EDGE) <sajos@microsoft.com>;
> Peng Lyu <penlv@microsoft.com>; Frankie Wu <frankiew@microsoft.com>;
> public-editing-tf@w3.org <public-editing-tf@w3.org>
> *Subject:* Re: New API proposals from Editing TFs discussions
>
> Hi Johannes,
>
> Creating issues on the explainer repo is probably best in terms of
> tracking the issues where the document is.
>
> Yes, we do intend to discuss this at TPAC.
>
>
> Sent from Outlook <http://aka.ms/weboutlook>
> ------------------------------
> *From:* Johannes Wilm <johannes@fiduswriter.org>
> *Sent:* Wednesday, July 24, 2019 2:12 PM
> *To:* Grisha Lyukshin <Grisha.Lyukshin@microsoft.com>
> *Cc:* Alessandro Curzi <Alessandro.Curzi@microsoft.com>; Bogdan Brinza <
> Bogdan.Brinza@microsoft.com>; Bo Cupp <pcupp@microsoft.com>; Anupam
> Snigdha <snianu@microsoft.com>; Sanket Joshi (EDGE) <sajos@microsoft.com>;
> Peng Lyu <penlv@microsoft.com>; Frankie Wu <frankiew@microsoft.com>;
> public-editing-tf@w3.org <public-editing-tf@w3.org>
> *Subject:* Re: New API proposals from Editing TFs discussions
>
> Hey Grisha,
> this all looks very interesting. Where would you like the discussion about
> these proposals to take place? Should one file issues on
> https://github.com/MicrosoftEdge/MSEdgeExplainers/issues
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fissues&data=02%7C01%7Ctravis.leithead%40microsoft.com%7C8f3a69e40b3641eda31e08d7113f2589%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996835226149464&sdata=P2IDBQIxXyLXR%2B87t8RnvyxoImGXMXgCjRAkb6pqV%2F0%3D&reserved=0> and
> add a specific label to them, should one respond to the entries on wicg.io
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwicg.io&data=02%7C01%7Ctravis.leithead%40microsoft.com%7C8f3a69e40b3641eda31e08d7113f2589%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996835226159458&sdata=v3yptfGbbQMLtbc9XlBo4uct7JLXjMXgD3%2Fd2OmIGrU%3D&reserved=0>
> or what is the preferred way?
>
> And I guess you guys would want to have a face to face discussion  as part
> of an editing meeting at TPAC as well?
>
> On Sat, Jul 6, 2019 at 1:12 AM Grisha Lyukshin <
> Grisha.Lyukshin@microsoft.com> wrote:
>
> adding few folks from Microsoft that previously expressed interest in
> these APIs.
>
> Hi Everyone,
>
> I am writing to let you know that we have couple of proposals publicized
> on WICG that were inspired by some of the discussions in Editing group.
>
> https://discourse.wicg.io/t/proposal-editcontext-api/3656
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.wicg.io%2Ft%2Fproposal-editcontext-api%2F3656&data=02%7C01%7Ctravis.leithead%40microsoft.com%7C8f3a69e40b3641eda31e08d7113f2589%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996835226159458&sdata=nI2ZFFyQo4PjfVhg%2F2dKV8EXQAPl%2BpQSG%2FSATQGRKKQ%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.wicg.io%2Ft%2Fproposal-editcontext-api%2F3656&data=02%7C01%7Ctravis.leithead%40microsoft.com%7C8f3a69e40b3641eda31e08d7113f2589%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996835226159458&sdata=nI2ZFFyQo4PjfVhg%2F2dKV8EXQAPl%2BpQSG%2FSATQGRKKQ%3D&reserved=0>
> [Proposal] EditContext API
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.wicg.io%2Ft%2Fproposal-editcontext-api%2F3656&data=02%7C01%7Ctravis.leithead%40microsoft.com%7C8f3a69e40b3641eda31e08d7113f2589%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996835226169453&sdata=%2BP4mxH9LYgjdUSxjvEikxaeX%2F1%2BwvdGU2WGr05oSUDg%3D&reserved=0>
> EditContext API was inspired by discussions in Editing TF. It allows web
> applications a deeper integration with operating systems’ input services.
> The proposed design allows for clean separation of document object model
> and data model and a number of other benefits that are not available to a
> web developer today. Some of the gaps that the proposal aims to fill in the
> web platform: Very hard to build interoperable text editor on the web using
> browser primitives, i.e. contenteditable or textare...
> discourse.wicg.io
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdiscourse.wicg.io&data=02%7C01%7Ctravis.leithead%40microsoft.com%7C8f3a69e40b3641eda31e08d7113f2589%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996835226169453&sdata=rU6KYHeS3WoDGYELFa%2Fp0uGrJYdc3Ndk3CRdlcOe2M4%3D&reserved=0>
> https://discourse.wicg.io/t/proposal-highlight-api/3679/3
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.wicg.io%2Ft%2Fproposal-highlight-api%2F3679%2F3&data=02%7C01%7Ctravis.leithead%40microsoft.com%7C8f3a69e40b3641eda31e08d7113f2589%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996835226179452&sdata=O%2F8pojIEEBkep6AnScDshSuSSmf0a5xZqPW2InIfe90%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.wicg.io%2Ft%2Fproposal-highlight-api%2F3679%2F3&data=02%7C01%7Ctravis.leithead%40microsoft.com%7C8f3a69e40b3641eda31e08d7113f2589%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996835226179452&sdata=O%2F8pojIEEBkep6AnScDshSuSSmf0a5xZqPW2InIfe90%3D&reserved=0>
> [Proposal] Highlight API
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.wicg.io%2Ft%2Fproposal-highlight-api%2F3679%2F3&data=02%7C01%7Ctravis.leithead%40microsoft.com%7C8f3a69e40b3641eda31e08d7113f2589%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996835226189441&sdata=QkpcNAaeQUGzqhBaqpsXriuDHPLBM5QRlZ4iwpgTl7M%3D&reserved=0>
> This proposal was inspired by this issue in Editing discussions. Highlight
> API allows web developers to style arbitrary range objects without causing
> DOM updates of the view. There are a number of scenarios where this would
> be useful, including third party spellcheck and grammar extensions,
> javascript implementation of find-on-page, or javascript, rendering of its
> own selection. Currently, browsers do not provide this functionality which
> forces web developers to modify DOM in order to achieve...
> discourse.wicg.io
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdiscourse.wicg.io&data=02%7C01%7Ctravis.leithead%40microsoft.com%7C8f3a69e40b3641eda31e08d7113f2589%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996835226189441&sdata=cHeUWCFF6K%2FroSHS%2Bxxy%2Fv%2FDQIeqIHyOVeaV4jcpjKw%3D&reserved=0>
> Would love for you to take a look at it and provide some feedback on the
> idea, design, etc...
>
> -Grisha
>
> Sent from Outlook <http://aka.ms/weboutlook>
>
>
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.fiduswriter.org%2F&data=02%7C01%7Ctravis.leithead%40microsoft.com%7C8f3a69e40b3641eda31e08d7113f2589%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996835226199434&sdata=LtzLfc9R%2BGoWUHzNl4B38vi1ZP%2FrEUndqhrhoJuTfXc%3D&reserved=0>
>


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