Discussion: Inline nodes with content

[bradleyayers]

Thanks for taking a look into this, the summary is excellent!

Cursor boundaries Confluence adds a zero-width no-break space on the boundaries of @mentions to add another cursor position at the same location, to disambiguate the semantics. Here’s an example where I step through the characters at a constant rate using the arrow keys.

The HTML for this is:

<p>I am &#65279;<a userkey="ff808081560b912f01560c40d04b000b" href="/wiki/display/~bayers" class="confluence-link">Bradley</a>&#65279; from Australia.</p>

Another example is a date:

<p>Today is &#65279;<time datetime="2016-11-15" contenteditable="false" class="non-editable" onselectstart="return false;">15 Nov 2016</time>&#65279;.<br></p>

@marijn

Thus, since the two use cases we’ve got so far (mentions, footnotes) both seem like they’d want to treat these nodes as much as plain old text as possible, maybe we should explicitly disallow non-leaf inline nodes and look for a different solution. If something is supposed to be inline, it probably should behave like other inline stuff, and be represented in the same way.

I was thinking about this yesterday, and I suspect this might be satisfactory. In all the use cases I have in mind, the inline node is plain text, but has some special presentation and semantics applied to it. If it was possible to extend Text in order to restrict the marks that can be applied (in my cases so far I would disable any marks), and hook into selection events to present hover mentions, that would get me a long way.

The situation today seems to be that I could make do with marks, but wouldn’t get any help from the schema to achieve it. I’d need to intercept all commands and prevent any that would violate my constraints. This means that plugins that add support for adding other marks would have no way to tell (by looking at the schema) that they should prohibit it.