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

Hi Johannes,

I understand that browser vendors might be slow or unwilling in
implementing such stuff.

But thats also true for implementing ContentEditableDisabled.

*if* they implement that, it would be nice if the spec could also
include my suggested enhancements. It would not be much more work for
them if they implement the restrictions anyway.

 > Sorry that I cannot point you to a quick fix, but this is the current
 > state of things.

Sure, but I am also not (anymore) looking for a solution for the current
state of things. I stumbled over the new  API in it's definition phase,
and thought that new API might be more helpful and more complete if the
basic editing usecase would also be covered.

Best regards,
Malte.

On 30.10.2020 12:26, Johannes Wilm wrote:
> Hey Malte,
> I realize this means more work on your end, but unfortunately this is
> the current state of things and so all the editors deal with this
> situation. Keeping the text stored somewhere else, apart from the DOM,
> seems to have helped many editors to break much less often. Writing a
> good JS editors is usually a multi-year effort (3-8 years or so just for
> the engine) , so if you don't have that time, you might want to look at
> using one of the editor libraries out there. There are several ones
> under open source licenses.
>
> Unfortunately, editing is not as high a priority for browsers as things
> like advertisements and mobile phones, etc. so we cannot just force
> browser makers to ship input events level 2 or contenteditable=caret,
> which would give you what you want without having to roll back. There is
> currently a new proposal called EditContext which would allow you to do
> some more without rolling back, but it would force you to keep a copy of
> the text somewhere else.
>
> Rolling back can be done in several ways. You likely need to keep a copy
> of the text before the change around somewhere so that you know what to
> roll back.
>
> Sorry that I cannot point you to a quick fix, but this is the current
> state of things.
>
> Johannes
>
> On Fri, Oct 30, 2020, 10:45 Malte Timmermann <malte_timmermann@gmx.com
> <mailto:malte_timmermann@gmx.com>> wrote:
>
>     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>
>     <mailto: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 14:32:49 UTC