Re: [selection-api] caret-based selection movement (#27)

Yes, I was going on the assumption that we would want the caret to jump inside a cE=true that is nested inside a cE=false should there be such a situation. It seems if there is an editable area it should be reachable via arrow keys? I'm open on this though.

Here's an example of what I meant with "cE=false transparent":

    abc|<span contentEditable=false></span>def  
    abc<span contentEditable=false></span>d|ef  //after right-arrow

Whether the caret jumps the cE=false with the character before or after it is a matter of picking one and spec'ing that.

> And how do you insert text just before AND just after such an invisible element?

If the element is empty or is not visible (display:none) then the user has no way of knowing which side of the element the caret is on anyways. It will seem like pressing the arrow key has no effect (that caret won't physically move between the before and after position). 

> I wonder whether it would be easier to stay consistent if empty SVGs and empty cE=false as well as invisible elements were treated the same as single characters as it's hard to know when they are really empty. But I am not a browser developer. Maybe it's easy for them to distinguish.

I agree that UAs will have a hard time really knowing whether an SVG or other element is really empty. Also, empty elements can still have visible borders, and other things that give them a visible presence. So I think you're right it's better to be consistent and treat SVGs the same whether they are empty or not.

However, I'm still a bit torn on elements that are display:none. Invisible elements are completely removed from the document layout, and have no possible visible manifestation. The caret would just be "stuck" for  a moment with no obvious reason why. Further, the UAs already track that property closely for their layouts, so there is little reason to think this would cause them a problem.


---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/selection-api/issues/27#issuecomment-65948885