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.

Well, yes. The way it is defined now, it is dependent on CSS. Things that are invisible with `display:none` cannot contain a caret, those turned into inline elements will behave as such and so on. On my part, this was on purpose. 

> 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 a legal `caption` within tables) and less future-proof (while UAs are already on their way to HTML 5.1).

If you think it's easier to describe caret positions in terms of what is illegal, I'm OK with. The important thing is that it can go everywhere where they cannot always go today (for example, in-between SVGs or canvas-elements). Could you come up with an entire text about legal caret positions that could replace the current text and at the same time incorporate all the positions that are currently defined as legal?

> Some of those limitations (e. g. no caret between block elements) may harm Selection’s flexibility in general. 

To me at least this limitation doesn't *have* to be there. The current list is just the minimum amount of places where the caret has to be able to go. This is important to avoid the current situation in which the caret can go in different places in each browser. All these are only places where the caret can be placed programmatically, so it's fully up to the JS code whether it wants to make use of a particular place or not

> Text nodes are also not as simple as they look. HTML defines an ‘inter-element whitespace’ (represented in DOM as text node, but not considered text by HTML); 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.

Ok, is that the only exception for text nodes? Is there a name for the other text nodes?

> 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).

Indeed, but SVGS have a different internal namespace. For now I would like to ensure that the caret can be placed on either side of an SVG under all circumstances (currently it is not possible to put the caret inbetween two inline SVGs in some browsers). More advanced things can wait for future versions.



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