[discussing and analyzing the explainer]

Alice: does Rossen know about this?

Alice: a thing to capture events that may allow you to edit text...

Alice: explainer could have more images...

Ken: typing into an input field and you get feedback while typing like typing "icecream" and getting a prompt for an emoji...

Alice: is it the auhtor telling the page about the editing ...

Ken: both ways. If it replaces "ice cream" with the emoji it needs to know where ice cream is...

Ken: names / selection...

Ken: seems sensible... the API seems sensible. [internationalization cases ...]

Dan: I'm concerned about the responses to the security & privacy questionnaire

Ken: I assume this will only work with input methods shipped with the browser, like emoji picker and accessibility helpers. This is an API for the web site author to integrate with these, and not a way for developers to create their own input methods that will then get access to sensible information such as selected text/passwords etc. Maybe this could be made more clear.

Dan: let's review the assignment of this in plenary

• MathML Core - @alice, @torgo, @hadleybeeman

[...discussion of where we're at now...]

[alice composes comments and pastes into issue

Sangwhan: Doesn't look like there has been much progress.

Rossen: Let's leave a comment that we will punt this until they update us.

Rossen: Still no progress from filers. Left comment

left some comments

Dan: still pending answers to questions Peter raised. Sangwhan said let's close it. Got a response that they're updating the explainer and then update the thread. Sounds like we should wait for the update.

Other:

Rossen: status?

Dan: a comment from Peter in April - no response yet.

Rossen: proposed API has a very strict scope on text. We can debate that further .. if the topic needs to expand .. to elements .. reinvent entire DOM inside... Not interested.

Peter: I just think there's under-specified behaviour... Within the scope of this proposal...

Peter: if you call this on an element that has children what happens to the children? The answer could be "throw them out" - just want to have consistent implementations..

Rossen: ok that's fair.

Peter: there's a question of why not use DOMrange... just an API shape question... just about making it more consistent with other APIs already in the platform. No answer to that either.

Dan: we just need an answer to the questions being asked here...

Sangwhan [via chat]: we should close.

Rossen: I will follow up.

Other:

Rossen: I feel everything I wanted to put forward - how I see this API and how it could be used for editing - is already stated in the minutes... Peter also stated his points. At this point what is the benefit?

Peter: The main overall shape is OK ... the last questions are they need to specify what happens with content that has children.. needs to be specified. Questions on use of DOM range. They said they are going to update the explainer and spec... they added details to the explainer and working on changes to the spec. SO I think we're waiting for them to update the docs.

Dan: concern to do with underspecified behaviour of elements with children.. There were updates in November.. pinging again

Rossen to read & generate comments.

• https://github.com/w3c/edit-context/issues/38
  • https://github.com/w3c/edit-context/issues/53
  • https://github.com/w3c/edit-context/issues/54

Rossen: quite a face-lift. Most of the points were addressed...

Dan: relevant issues:
https://github.com/w3c/edit-context/issues/38
https://github.com/w3c/edit-context/issues/53
https://github.com/w3c/edit-context/issues/54
...examples of resolved issues.

Rossen: Peter I think the one you were concerned with is 53.

Peter: I was concerned that it was underspecified... My only other feedback was ... why aren't these in the DOM range?

Lea: being underspecified would be fine for an early review...

Peter: but this was from 2019...

Peter: do we know the status? There was work happening on a DOM range API... wonder if anything ever became of that? I would suggest they incorporate that...

Lea: this seems to require a lot of manual syncing between this model and the DOM... and usually that can introduce error. So I'm a bit worried that this is designed for the needs of big apps like google docs but not really usable by the average developer...

Peter: original model for building your own editor...

Lea: there's a lot of projects that require that that are not maintained by large companies...

Dan: e.g. cryptpad is an example that's not...

Peter: original API design a simplistic model - editor from scratch - that may not be the only use case...

Lea: this seems to make complex things possible but simple things are not easy.

Dan: reasonable to challenge them on the developer complexity issue.

Lea: on the other hand - as a developer it looks really tedious to do but it's better than contentEditable... Maybe that's what we need.

Dan: could we ask them "what is your story for developer complexity?"

Rossen: I was pretty close to it when it started -- model made sense to me when it was text editing. Certainly needed as a base construct. Having editors generally speaking ... the web has outpaced the capabilities of editors... giving web developers a way to build the rich editors they want to... is the idea. If you're building an editor, you're already an advanced developer... So... I stand behind the fact that this is a great step forward. I don't see it as isolating any developer segment more than any other API...

Lea: Trying to think it through - one thing that gives me pause - APIs where if you want to do something custom then you have to do it yourself - APIs that have a cliff. This could be alleviated by providing a shortcut to create an editContext that already has the correct plumbing. For example if you want to have a text editor thats a different color, or a markdown editor, these are simple use cases... but still very painful in the web platform today. it would be quite nice to not have to write a ton of code to provide an editor that has an improvement... of what the web platform has today.

Rossen: If you assume steady state of a document then you don't need anything... Editing is all about handling and reacting to the actions of the users... changing parts.. Reacting to actions... EditContext is all about reacting... When it comes to text, range API is not great... What you're talking about are higher level edit commands that are built on top of constructs like the EditContext?

Lea: from what I'm seeing it seems you have to write code to sync up basic things - like undoing... all of these things you would normally get for free - you have to write code to sync with the DOM... I'm worried this is quite error prone. Example 3 for example: https://github.com/w3c/edit-context/blob/gh-pages/explainer.md#example-3-mapping-the-selection-from-dom-space-to-editcontext-plain-text-space

Peter: yes this gets to my point - my concern is that it's modelled around a simple text buffer - not structured content... that's what I was asking for in the first place...

Lea: also this https://github.com/w3c/edit-context/blob/gh-pages/explainer.md#undo web based editors rarely use the DOM undo stack.. there are many benefits from not having to maintain an undo stack of their own... for certain editors having an undo stack maintained by the browser is not workable but for something like a code editor, as long as it can be undone reasonably there are no reasons for the develoeprs to want their own undo stack... I would much prefer see somthing that allows you to tweak the existing undo stack or replace it if you want but it shouldn't be a requirement to write an undo stack to use this...

Dan: can we provide feedback that encompasses both positives and negative points?

Lea: I think it's about developer experience... for some use cases this is the right developer experience but for some cases it's not right... We have a design principle... https://w3ctag.github.io/design-principles/#simplicity

Rossen: fwiw I think the undo stack is not mentioned in the spec... Is the explainer maybe stale?

Lea: the explainer has a bunch of things it doesn't do... https://github.com/w3c/edit-context/blob/gh-pages/explainer.md#interaction-with-other-browser-editing-features

Dan: explainer updated 3 months ago...

Lea: also: when you have an API of this kind... can end up with buggy code. buggy editors ... all over the web.

Peter: 2 models - (1) you're building an editor - e.g. google doc - this API is focused on solving that proboem .. in that regard, positive step (2) the browser already has some rich capabilities - but no way to extend / augment those - which is what we'd like to see. My feedback is that they are trying to solve (1) - that's fine - my concern is that I don't see how this feature ties into explaining the editor functions of the browser... Imagine if we opened up the browser's editor...

Lea: meta-comment - this type of thing is exactly why we need to have this initiative [task force] to identify gaps in the web platform...

Rossen: EditingContext is part of the editing task force that's focusing on editing...

Lea: why is it so focused on the specific use case?

Rossen: focusing in the base primatives...

Peter: seems like a side thing of people trying to replace the broswer editor... would love to see this evolve towards a way to augment the browser editor...

First, it's great to see work in this direction, and we definitely recognize the need for it!
  
While many editing use cases do require re-implementing capabilities like undo or caret management, not all use cases share that complexity. Right now, it appears that this API primarily caters to the most complex of cases that require re-implementing many fundamental aspects of text editing, but introduces [sharp cliffs](https://w3ctag.github.io/design-principles/#high-level-low-level) for the simpler use cases, those that merely need to augment regular text editing (case in point: the Markdown editor right here on GitHub). As mentioned in our design principles, there's value in designing APIs that keep [simple things simple, and complex things possible](https://w3ctag.github.io/design-principles/#simplicity).
  
Could this be the begininng of an effort to support *augmenting* the browser editor capabilities, when you don't need to entirely reimplement them? This would not necessarily require a different design: perhaps it can be done with shortcuts (e.g. a way to get an `EditContext` that already has the right plumbing based on a given editable element in the DOM (`<input>`, `<textarea>`, `<div contenteditable>` etc)).

Rossen: last time we talked about it you had an action item to look through the issues that were being worked out.

Peter: I don't see how the three posted are related to what I was talking about

Peter: the listed issues don't seem to be addressing my concerns.. i will follow up with this and I will leave a comment.