Re: [editing] Should the caret move by default, and should we define this behavior? (#58)

> I'm here to participate in the discussion to come up with a new editing API that WORKS. It doesn't matter whether it "provides primitive" or "gives more power to JS".

That's fine, but that's not what contentEditable=Typing set out to do. It's only about offering primitives to JS libraries to create editors. It is not about providing an editor to end users that works. 

>  I don't think Web apps want to have a bunch of if-else statements to check the preferences of Gecko and behave differently based on that.

I think that would be the least of our worries. For example, the standard package CKEditor is 2.9 MB, so a few if-else statements more would certainly not break any camel's back. And hopefully the 2.9 MB could be slimmed down quite a bit as well. 

> Some of the behavioral differences are intential and features.

If we could, many of us would simply override such behavior. And it's a bit weird: Noone tries to tell us what size or shape pull down menus are to be or that menu buttons only go on the right and that the background of all webpages is light blue when seen in Safari to preserve a common experience when surfing the web using Safari. Yet when it comes to editing, somehow it is felt that this needs to be centrally managed.

 > So that's why I'm asking for you to list the problems you have with the current selection APIs and behaviors so that we can come up with the right set of APIs and spec's that address those issues without degrading user experience in CJK languages, bidirectional text, and platform-specific behaviors.

Ok, so you want a list of the most important contentEdtiable bug reports? If there is a chance they will be fixed, I am certain we will be able to provide those to you very quickly. (Btw, this is mainly **NOT** about the selection API, but about contenteditable. Some things may end up being discovered as also be issues for the selection API, but in general that's not what the discussion is about here).

> The reason editing API hasn't improved over the last decade or two isn't because we've been lazy. It's that HTML editing is really hard. 

Noone is accusing you of being lazy. My understanding of the situation was that the browser makers accepted that they will not ever be able to solve this problem and that therefore they will instead hand the task of creating editors over to the JS groups/projects/companies that dedicate themselves to creating editors. That's why I am somewhat confused that you seem to want to go the other direction again and not give us the primitives and instead create a new form of contewntEditable=True.

> We can't just add a bunch of half-baked "primitives" and magically solve the problem. If anything, that'll just exacerbate the problem we have today.

Can you explain why you think the problem will grow bigger if the editing logic is being moved to the JS? The primitives we are asking for are not just random things. They are all backed up with use cases and are suggested by people with many years of experience in this field. As for bugs: they have also been filed many years ago. 

Otherwise, I don't think we get any further here. I suggest you start a new spec with the working editing api that does not offer primitives but "really works". The editing task force already hosts various specs, of which we are still not entirely certain which one survives, so adding one more shouldn't be a problem. I would then also suggest you look through our use cases and bug reports and come up with some concrete suggestions on how to handle things. 

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/58#issuecomment-108630468