Using cards within text sections in Mobiledoc

[fbarl]

Hi,

I'm working on an Ember project where we recently decided to switch to using content-kit-editor for our rich text editors. So far we've been using a more or less customized component which had some basic text-markup capabilities (bold, italic, etc..) as well as the ability to mark a section of the text as a 'note', which would then open a custom popup on click in the 'render' mode. Since we were operating with the text directly through the DOM elements, this was rather easy to customize, but now that we've decided to move away from our HTML-based rich-text editor, I don't see an obvious way to do it with Mobiledoc.

So, on my first glance, it seemed to me that implementing a note-card would work just perfectly for what we need, until I realized that Mobiledoc cards can only be used on the top level of the Mobiledoc document and not within the text sections. Since we'd ideally want to be able to wrap the text in a note without breaking the paragraph (or even its markup), this hardly seems like a good choice. Then alternatively, if we'd add notes just as custom markup wrappers, we'd be very limited in what we could do that way before our code and the text content would start getting messy. In concrete, we'd probably be forced to put javascript event triggers directly on the DOM elements (for opening the popups), instead of doing it more Ember-like.

Coming back to the title of this issue, it would be ideal for our project if Mobiledoc would somehow support nested sections, or if that's not possible, at least cards nested in the top level sections. I would be very grateful to hear from anyone if there's any chance of Mobiledoc supporting this in the future. If that's not on the horizon, does anyone have a suggestion how my mentioned issue with notes could be best solved with the current setup? :)

Thank you!

[mixonic]

@fbarl I think we do something like what you want for the Bustle CMS. We have "inception" cards that are themselves hosts to an inner instance of Content-Kit. They payload of a inception card contains the incepted card's Mobiledoc.

That code isn't published anywhere yet, but I think there is general agreement that it could and should be.

[rlivsey]

I've been having similar thoughts when it comes to implementing @mentions, sounds like there's some crossover there too.

[fbarl]

@mixonic I'm not sure I understood the details of how these 'inception' cards would work, but it seems to me that they still wouldn't allow for inserting card sections into text sections. I understood that you'd add some sort of 'recursive' functionality with your cards, but the text sections on any level would still not be able to incorporate custom cards, or did I not get it right?

@rlivsey Yes, I can imagine there'd be a similar issue with implementing the (inline) mentions :)

[mixonic]

it seems to me that they still wouldn't allow for inserting card sections into text sections.

Agreed. I think @bantic and I discussed this in the last few days.

Designing an API for inline cards seem extremely non-trivial to me. For example:

• To have an inline card that does @-prefix name completion, what is needed? An API for attaching to a entered key, or just re-use the existing text triggers? What happens when the user wants to cancel the dropdown? If they can click outside it or press escape, how does the inline card support that?
• The previous example is 100% different than highlighting an area and flagging the content as a note. This implies APIs about selection and toggling, but also around intersection selections.
• What other use cases exist? How do we deal with things like the cursor moving across an inline card (does it trigger events on entrance/exit, or do you just have normal key events?)

Some further thoughts:

• I definitely acknowledge there is an opportunity for a feature/API here. I just think it is still too nebulous and requires more exploration and design before picking a direction.
• Implementation of this probably means we need to implement our own cursor. That is non-trivial and has some other implications on the UI- for example on OSX you can press an hold a key to choose an accent. We would like to preserve that functionality even as we implement more of what contentEditable does today.

[rlivsey]

@mixonic I wonder if inline cards need to be interactive at all in any way, or if a first pass at something which would work for both our @mentions use-case and a notes use-case is simply a kind of markup area with attached metadata of some sort.

@mentions only need interactivity when they are being inserted, which can almost be implemented today by tracking when an '@' is typed and then capturing subsequent input in some way (but a more elegant API is probably necessary). Notes are "just" like links where you're attaching metadata (the href etc) to some text. The interface provided to insert them is out of the scope of the editor itself, much like the toolbar buttons etc…

One thing potentially required (but not essential) for @mentions (other than tracking metadata) is being able to delete the item as a block, so it would be non-editable and if the cursor was after a mention then hitting delete would delete the whole thing.

It's been a long day and I'm not thinking particularly clearly, so will mull over it some more!

[bantic]

We're now planning on implementing "inline cards", calling them "Atoms". The discussion and work is happening around issue #222. Closing this so that discussion can continue there. Please reopen if I've missed something.