[editing] Legal caret positions – invisible text nodes (#75)

The following HTML contains many text nodes (`div.firstChild` would be a text node with `nodeValue='\n    '`):

```
<div contenteditable=events>
    <p></p>
</div>
```

There's a rule saying that caret can be placed:

> Before or after any character in any text node.

That would mean that caret can be placed in that first text node, despite the fact that it would be invisible (unless CSS defines differently – e.g. `white-spaces:pre` case).

There's a rule already saying that:

> The caret cannot be placed inside invisible elements.

Since text nodes are not elements, this rule doesn't apply in this case. So I propose adding another rule (or extending the existing once):

> The caret cannot be placed inside invisible text nodes.

We would also need to define what "invisible text nodes" are (compare: #68).

----

One additional note: If I understood https://github.com/w3c/editing/issues/74#issuecomment-133717022 correctly, this would mean that the caret cannot be placed anywhere between `<b>` elements in this case:

```
<p><b>foo</b>     <b>bar</b></p>
```

That's because the rules say that the caret can only be placed after/before inline elements which are not followed/preceded by text nodes. If we also say that it cannot be placed in that text node between `<b>`s, then this position will be illegal. This could be clarified by defining #74 as follows:

> * Before or after any character in any **visible** text node.
> * After inline elements which are not followed by **visible** text nodes.
> * Before inline elements which are not preceded by visible text nodes and that do not have a previous**Element**Sibling.

* `<p><b>x</b>^    </p>` – OK (matches 2nd rule only)
* `<p><b>x</b>^y</p>` – OK (matches 1st rule only)
* `<p><b>x</b>^<b>y</b>` – OK (matches 2nd rule only)
* `<p>   ^<b>x</b> – OK (matches 3rd rule only)
* `<p>x^<b>x</b> – OK (matches 1st rule only)

(BTW. Making these rules exclusive is a challenge :D I'm hope I'm right about the above.)

----

There's actually one additional node type which complicates this – comments. We could use `previousElementSibling` in the second rule, but it may still not be enough. If we need to worry about comments, perhaps it would be easier to say that this algorithm should totally ignore them.

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