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

As for ‘inline’ and ‘block’, CSS terminology may imply it’s CSS-dependent; from the Display Module perspective, a `<p style="display: inline">` is ‘inline’, not ‘block’ as we’d expect in HTML Editing APIs/HTML 4 terms. That’s sort of ambiguous.

Per HTML 5, most illegal positions may be described as follows: Elements that do not accept text/flow content must not accept the caret (in addition to `table`, those are `ul`, `ol` and `dl`). In ‘inline/block’ dichotomy, we’ve got to describe those as exceptions, which is a pain (we missed `caption` within tables, in addition to `td` and `th`) and less future-proof (while UAs are already on their way to HTML 5.1).

‘Stubs’ are not voids, right. They just don’t accept any content (`br` fits here). Note: SVG (and MathML, for that matter) is not stub: it may hypothetically have editable text nodes down the tree (that’s complicated, maybe not for v1).

Text nodes are also not as simple as they look. HTML defines an ‘inter-element whitespace’ (represented in DOM as text node); they are allowed almost anywhere, but will immediately invalidate the document on any non-whitespace input when in certain positions (e. g. direct child of a `table`). They fit the definition of ‘any text node’ [1, 4], but they shouldn’t be a legal caret position.

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