- From: Johannes Wilm <johannes@fiduswriter.org>
- Date: Fri, 30 Oct 2020 17:25:20 +0100
- To: Malte Timmermann <malte_timmermann@gmx.com>
- Cc: public-editing-tf@w3.org
- Message-ID: <CABkgm-SzcqyidxtGQNo45VEF-1bP2CEGz25W_bE6hQcrZa2fsw@mail.gmail.com>
Hey, On Fri, Oct 30, 2020 at 3:32 PM Malte Timmermann <malte_timmermann@gmx.com> wrote: > 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. > For those things you mention, we already have defined them in two other specs. And one of those two other specs (Input Events) is also largely implemented and has been shipped, which is not the case for contentEditableDisabled. The way IME works particularly on Android is what makes them not be able to ship the full, level 2 spec, and that same something would prevent them from shipping the feature if it were in another spec instead. Adding this feature - which they believe they cannot ship - to the spec would likely just mean that they won't ever ship any part of the spec. So that would be counter-productive. Additionally, the aim of contentEditableDisabled is something slightly different than what you want to use it for. You seem to want something like contenteditable=caret. The point of contentEditableDisabled is to hide all the UI and also make the corresponding keyboard shortcuts, etc. also disappear (not work). It sounds like you don't want the various events related to either keyboard event or IME input to go away though, right? So for those reasons, I don't think it is a solution to try to add this feature also to the contentEditableDisabled spec. Maybe browser makers will eventually decide to ship Input events level 2 or contenteditable=caret or something very similar, but I would not count on it. In the meantime I would either switch to a JS editor framework that already has invested the required number of development years into it, or calculate to spend the time doing it yourself. I hope that makes sense. And just to make it clear: I am just expressing my personal opinion here. If there is an interest in this taskforce to discuss adding this to contenteditableDisabled, we should of course have that discussion. Regards Johannes > > 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/> > > > -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
Received on Friday, 30 October 2020 16:25:46 UTC