Re: New API proposals from Editing TFs discussions

Johannes, Travis, everyone,

A few thoughts...

The Editing TF isn't a particularly formal affair. Some TF have a 
charter and a chair, but the Editing TF is more of a recognition that 
there is a group of people interested in working together on editing 
activities. It was like this in WebPlat and in WebApps before that.

The Editing TF has a public email address. This means anyone is able to 
participate in discussions and to comment on proposals, specs, and 
related conversations. It's actually the responsibility of every WG to 
seek wide review on all it does, and this is one way that expectation is 
met in WebApps.

When it comes to contributing to specifications there is a need to make 
sure the patent policy is honoured, but as Johannes notes this is easily 
solved. I think most active contributors to editing activities are 
already members of WebApps or work for a member organisation that has 
joined, and our policy for including IE is fairly relaxed. Marcos and I 
need to agree to it (and providing the person has been shown to be a 
useful and active participant, that's usually simple), and the 
prospective IE needs to complete a form.


Whatever happens, it's really good to see more energy pouring into the 
editing activity!

Léonie.


On 26/07/2019 11:01, Johannes Wilm wrote:
> 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 <mailto: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
>     <mailto:Grisha.Lyukshin@microsoft.com>>
>     *Sent:* Thursday, July 25, 2019 1:31 PM
>     *To:* Johannes Wilm <johannes@fiduswriter.org
>     <mailto:johannes@fiduswriter.org>>
>     *Cc:* Alessandro Curzi <Alessandro.Curzi@microsoft.com
>     <mailto:Alessandro.Curzi@microsoft.com>>; Bogdan Brinza
>     <Bogdan.Brinza@microsoft.com <mailto:Bogdan.Brinza@microsoft.com>>;
>     Bo Cupp <pcupp@microsoft.com <mailto:pcupp@microsoft.com>>; Anupam
>     Snigdha <snianu@microsoft.com <mailto:snianu@microsoft.com>>; Sanket
>     Joshi (EDGE) <sajos@microsoft.com <mailto:sajos@microsoft.com>>;
>     Peng Lyu <penlv@microsoft.com <mailto:penlv@microsoft.com>>; Frankie
>     Wu <frankiew@microsoft.com <mailto:frankiew@microsoft.com>>;
>     public-editing-tf@w3.org <mailto:public-editing-tf@w3.org>
>     <public-editing-tf@w3.org <mailto: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
>     <mailto:johannes@fiduswriter.org>>
>     *Sent:* Wednesday, July 24, 2019 2:12 PM
>     *To:* Grisha Lyukshin <Grisha.Lyukshin@microsoft.com
>     <mailto:Grisha.Lyukshin@microsoft.com>>
>     *Cc:* Alessandro Curzi <Alessandro.Curzi@microsoft.com
>     <mailto:Alessandro.Curzi@microsoft.com>>; Bogdan Brinza
>     <Bogdan.Brinza@microsoft.com <mailto:Bogdan.Brinza@microsoft.com>>;
>     Bo Cupp <pcupp@microsoft.com <mailto:pcupp@microsoft.com>>; Anupam
>     Snigdha <snianu@microsoft.com <mailto:snianu@microsoft.com>>; Sanket
>     Joshi (EDGE) <sajos@microsoft.com <mailto:sajos@microsoft.com>>;
>     Peng Lyu <penlv@microsoft.com <mailto:penlv@microsoft.com>>; Frankie
>     Wu <frankiew@microsoft.com <mailto:frankiew@microsoft.com>>;
>     public-editing-tf@w3.org <mailto:public-editing-tf@w3.org>
>     <public-editing-tf@w3.org <mailto: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
>     <mailto: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 <http://www.fiduswriter.org/>

-- 
Director @TetraLogical TetraLogical.com

Received on Friday, 26 July 2019 11:18:54 UTC