[w3c/selection-api] Clarify how `selection.modify()` when the granularity parameter is `paragraphboundary` handles non-editable elements in an editing host (Issue #179)

[The specification](https://w3c.github.io/selection-api/#dom-selection-modify) doesn't define the behavior of `seleciton.modify()` when the granularity parameter is `paragraphboundary`.

Consider [this test case](https://codepen.io/Peng-Zhou/pen/LYKGNWQ)
```html
<div contenteditable id="container">
  this <a contenteditable="false">link</a> after
</div>

<p>1. Make the selection like "this link after|".</p>
<p>2. Click button to move the caret by line.</p>

<button>Move</button>

<script>
document.querySelector('button').addEventListener('click', (event) => {
  document.getElementById('container').focus();
  const selection = window.getSelection();
  selection.modify('move', 'backward', 'paragraphboundary');
});
</script>
```

The behavior of browsers:
- Safari, Edge, and Chrome: The caret position is `this link| after`.
- Firefox: Not support the granularity of `paragraphboundary`.

If we make `a` to be editable, the behavior of browsers:
- Safari, Edge, and Chrome: The caret position is `|this link after`.
- Firefox: Not support the granularity of `paragraphboundary`.

The behavior of `selection.modify()` when the granularity parameter is `paragraphboundary` should be be consistent, whether `a` is editable or not.



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/selection-api/issues/179
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/selection-api/issues/179@github.com>