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

> only allow the caret in places where there already are text nodes

This would be extremely complex to handle (as you also stated in [your comment](https://github.com/w3c/editing/issues/51#issuecomment-111752249)).

The caret is simply a UI representation of the selection. It should be possible to see it in all contexts where we expect users to be able to "type". This doesn't include invisible elements simply because we don't expect users to type then, but if we don't make it a restriction it should not be a problem anyway. I mean, if one would set the selection inside an invisible element, then typing would still happen there. The thing that would block this situation to happen is not really cE=typing, but the behavior of the caret to input commands, like arrow-keys and mouse click, which would never make a selection inside invisible elements. So sincerely, I would not care about blocking typing inside invisible elements. For the scope of cE=typing, I would just think about the selection position. The problem of placing the caret in allowed positions should be instead handled by the Selection API.

Still it should be possible to place the caret at any position where text can be inserted. cE=typing is all about this and if a text node is not available for that position, it should be created on the fly.

If cE=typing will not create any node by default, then it is senseless for it to exist as an editing module. We should then review the whole thing and introduce cE=intent, where UAs would not have any default behavior and just intentions would be fired.

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