- From: Johannes Wilm <notifications@github.com>
- Date: Wed, 07 Oct 2026 11:18:43 -0700
- To: w3c/editing <editing@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/editing/issues/551/6044069124@github.com>
johanneswilm left a comment (w3c/editing#551) > your thoughts on providing a built-in browser API as well My above proposal is to solve the case where JS editor developer wants to permit extensions to work well with their editor and they just need a way to communicate properly with one-another. That will hopefully be the majority of cases. Even big editors like Google Docs and Microsoft office may choose to follow these recommendations to ensure that extensions communicate more nicely with their editors rather than using the hacks that are out there today that will break whenever the code of those pages changes. After all, also they will be interesting in extensions not breaking their sites. ### What happens if extensions and editors do not agree? This is the question you raise and for which you propose this API, right? We will have to see what the browser developers say, but I am a bit split. #### Reasons not to allow extensions to edit content in editors if the website doesn't want it * I could image there being cases, like a page that is administrating an exam that doesn't want an extension to meddle in what is written in the editor. They want to make sure that it really was the student who typed it. * Or, under EU law, AI-generated content may have to be marked as AI-generated, and that is difficult to do if the JS editor cannot see the different between AI-generated and human-generated content. * A third case could be users writing confidential information in a specific textbox that should not be sent to those operating the server behind an extension. #### Reasons to allow extensions to edit content in editors despite of the wishes of the website operators Currently, the informal standard for turned extension-supplied changes off for a contenteditable editor is to add the attribute `data-gramm="false"`. Great for confidential information sent to banks, for example. But event sites like slack.com uses it. And I actually do want my Slack messages to go through a spell-checker before I post them. I don't see why Slack should decide that I am not allowed to do that. ### Can JS editors be forced? I think it will be very difficult to really force JS editors to accept input from an extension if they really don't want it. What you would need is for all the events to be `isTrusted = true` and you'd have to replay the exact same series of events as if it was a human typing. So that would mean individual key strokes for each letter with random intervals between them, and not faster than the fastest human. But maybe it could be done if the browser vendors believe it is a good idea. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/editing/issues/551#issuecomment-6044069124 You are receiving this because you are subscribed to this thread. Message ID: <w3c/editing/issues/551/6044069124@github.com>
Received on Wednesday, 7 October 2026 18:18:47 UTC