Re: [editing] What caret positions do we need to allow? (#51)

> > The way it is defined now, it is dependent on CSS. [...] On my part, this was on purpose.

> This makes sense to me. But it’s also not impossible to think those are HTML 4/Historical Editing APIs terms, no?

Yes, I can see how this could lead to confusion. If we are going to continue down this current path, we should probably be more specific that these values come from CSS somehow.

> > To me at least this limitation doesn't *have* to be there.

> In Selection API or in implementations? I mean, Selection API allows nearly anything, it doesn’t give a damn about the caret or editing, and that’s how it should be. For editing, browsers impose restrictions, and so do we, but those are practical limitations, not abstract ones. That’s why I believe *we*, not Selection API, should spec them. Where am I wrong?

To take a concrete example: caret placement between block elements. I cannot see how editors need them, but if browser makers insist on adding these in the spec and in implementations so that carets are more similar to selections in general, then I don't see how they do much harm either, as the JS code simply can be made to not take advantage of those extra possible placements.

I agree that this is currently how the separation is. All I am saying is that if there strong will to extend the Selection API to also treat carets, then I am not strongly opposed to it, as long as it is still specified somewhere. For me it is most important that it moves forward in some way.

That being said, I can also see some good reasons why *we* should continue to have it here. For example, it was earlier said that we cannot fix cE=true because too much legacy JS code depends on the current, broken behavior.   But if we add it to the selection API, then it will apply to all editing context, which means it will also change how cE=true works and thereby likely break this legacy code.

> One more that comes to mind is what happens to a collapsed whitespace. As multiple whitespace characters render as a single space by default, they should be treated as such by the caret (that’s how it works now, but that’s not spec’ed, again); but if they are visible (e. g. `white-space: pre-wrap`), they are treated as multiple spaces, i. e. the caret moves between them.

True. At the same time zero-width spaces are treated as individual characters. But this is more about the part of caret movement, right? It's not a problem if the caret can be programmatically placed anywhere inside a long series of white spaces, is it?

So if we add caret movement directly to this spec, then this should be taken into consideration (and I think the "move by at least 1 px" rule that was in the prveious draft would actually do that).

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