Re: Request: ContentEditableDisabled: add insertCharacter(s) and deleteCharacter(s) to the DOMCommandTokenList

Hi Johannes,

thanks for coming back on be.

We already hinder various DOM manipulations, but it's really not easy
multi platform.

We had situations where Safari created strange/wrong IME events for keys
which normally result in regular key events on other platforms,
and we also need to block/disable auto completion on mobile. Browser
Addons also can make problems. Such an API could tell them what they are
allowed to do and what not.

Detecting and rolling back changes not done by us would be very tricky.

Detection itself could be done by adding hashes to all text nodes or the
p elements after doing our own manipulation. Not sure how expensive the
calculation for a larger document would be, didn't test yet.

Rolling back means we would also need to store our text somewhere else
additionally, resulting in much larger memory footprint. On the other
hand, we would not need the hashes then.

So we already do a lot of effort to hinder DOM manipulations, but if the
new API could do the trick, that would be awesome!

Best regards,
Malte.





On 26.10.2020 15:08, Johannes Wilm wrote:
> Hey Malte,
>
> The thing I think you are looking for is the beforeinput event (Input
> Events spec). By canceling that event, you can stop the browser from
> manipulating the DOM. Unfortunately, due to various factors outside of
> our control, with the exception of Safari, the browsers have so far not
> been able to implement it fully, so you probably won't get around
> needing a mechanism to listen for dom changes and then roll them back
> once the browser is done.
>
> Johannes
>
> On Fri, Oct 23, 2020 at 11:15 PM Malte Timmermann
> <malte_timmermann@gmx.com <mailto:malte_timmermann@gmx.com>> wrote:
>
>     Hi,
>
>     I am new here. I stumbled over the draft for ContentEditableDisabled
>     while again searching for a solution to hinder extensions writing in the
>     DOM of our editing web application.
>
>     We use ContentEditable only to get key/IME events and cursor traveling.
>     We (try to) hinder the browser to make any changes to the DOM on
>     it's own.
>
>     The reason is that we use the concept of "operations", and if somebody
>     else but our own code manipulates the DOM, the positions from operations
>     become invalid.
>
>     https://www.slideshare.net/Malte.Timmermann/ox-documents-explained
>
>     ContentEditableDisabled could be THE solution for our problem.
>
>     Unfortunately, simple text manipulations seem to be out of scope of the
>     ContentEditableDisabled API.
>
>     I am pretty sure there are many Apps out there who could benefit of
>     disabling all unwanted DOM manipulations including simple key input.
>     CKEditor must have the same problem, not sure how Jira implements the
>     collaborative editing. In the end, every app that manipulates rich
>     content in a collaborative way could benefit.
>
>     Do you think it would be reasonable to add insertCharacter(s) and
>     deleteCharacter(s) (or "text" instead of "character" ) to the
>     DOMCommandTokenList?
>
>     Might look strange for people on first glance, but in certain scenarios
>     this is a critical thing.
>
>     Best regards,
>     Malte.
>
>
>
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org <http://www.fiduswriter.org/>

Received on Friday, 30 October 2020 09:45:17 UTC