- From: Johannes Wilm <notifications@github.com>
- Date: Wed, 30 Nov 2016 10:17:23 -0800
- To: w3c/editing <editing@noreply.github.com>
- Message-ID: <w3c/editing/issues/156/263950779@github.com>
> Hard for me to tell, because I don't know anything specific about any other editor than CKEditor, but I'd presume that all RTEs without a custom data model (and perhaps, to some extent, even some with custom data models) let the browser insert and delete text without much control. You may be right that those editors exist. I just want to make sure that we don't spend a lot of time working features that effectively no-one is using. For the undo behavior, for example, I contacted all the editors I could find, and none of them let just the browser built-in undo work by itself, and everyone had their own undo manager[1], even those that I don't think have started working on an outright data-model. Now that is of course slightly different than whether one lets the browser handle text input, but if one does manage one's own undo-stack, but at least it means that the JS will have to record what changed on every user input. > What happens when the caret is positioned at either edge of selectMeAndTypeOver and the user types something? Should the new text be part of the <a> node or adjacent to it? If it should be adjacent to it, should it be merged into the existing nodes or should new text nodes be created? I think this depends a lot on the editor and the contents. For example, in links, I usually want to be able to escape them when writing at either end. For bold text the same behavior would be ultra-annoying. Or so I think right now. I am not sure that hard-coding either behavior into browsers is the right path. It's more something that editor projects like CKEditor and similar should experiment with. They'all also be the only ones who can really effectively make the right decision when it comes to "custom" text types such as "piece of text that is visually 'linked' to a comment that is floating to the right of it". But in order for them to be able to do that easily, it may be _slightly_ easier if the selections were always the same (so one doesn't have to have code that checks whether all contents of a node have been selected and then select the node itself in some browsers and not in others). But then again, CKEditor seems to have this figured out, and the others will probably manage to do that as well eventually. [1] https://github.com/w3c/editing/issues/150#issue-179043895 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/editing/issues/156#issuecomment-263950779
Received on Wednesday, 30 November 2016 18:17:56 UTC