Is this project still active?

[apfelbox]

We recently ported our complete internal RTE to use mobiledoc-kit under the hood and I also saw that Ghost switched their editor as well.

I really love this project and would love to see it flourish. It solves a huge amount of issues we had with previous editors. Also I love the idea of doing the spec of the format sort-of separately from the actual implementation.

However, as I was browsing through the open issues + pull request, I sort of noticed that there is not a lot of activity from the side of the maintainers / members. The last release is around 4 months old. So my question: is this project still active? Is there some way we can help?

[henriqemalheiros]

I was wondering the same thing! I think the maintainers could really use some help to improve this project.

There is a forgotten roadmap that needs some attention. Yesterday I've actually started writing a list of strongly opinionated thoughts and was hoping to post it until next week. Is mostly renaming, simplifying and standardizing stuff. A major tidying up.

Maybe we can start a discussion to bring new ideas to the table and share some thoughts? I'd be glad to be a part of this.

[henriqemalheiros]

Ok, I've completed my list of suggestions.

These are the milestones from the original roadmap I agree with:

• Remove the legacy section type of <img>;
• Consolidate loosely spec’d markup types: <strong> and <b>, <em> and <i>;
• Improved logging and debuggability in Mobiledoc-Kit. Specifically in development builds offer a logging utility for DOM mutations handled by the editor. Production builds should have this functionality stripped (there are some good libraries out there, like debug);
• Resolve clicking buttons can cause document activeElement and selection to go out of sync #497, dealing with odd document.activeElement and contentEditable interactions. Additionally, add focus and blur hooks to editor;
• Rework the build system to offer a non-bundled build (ES6 modules) (I've seen rollup being used a lot);
• Improve the ergonomics for initial blank documents autofocus only works if Editor is created with a mobiledoc #511.

And these are what I've come up with:

• Rethink editor hooks: there is a didUpdate, but not a willUpdate. There's not a didFirstRender or didMount hook. The cursorDidChange event name doesn't reflect the inner workings of the editor, since it's the range property that actually changes. The beforeToggleMarkup hook is redundant, since any logic inside this event should be done by the user before calling the toggleMarkup method. The willHandleNewline hook isn't needed anymore, since new lines can be detected using keyCommands or inputHandlers.
• Remove link tooltip, placeholder and styling: these are UI stuff that doesn't fit in (what I perceive as) the spirit of Mobiledoc Kit. In my use case, neither of those things are used. In Ghost's, only the placeholder is used. The element classes could be removed as well (if needed, data-* attributes can be used instead).
• Remove default image card: there is no need to a default image card. Plus, if the user registers another card named image, although the editor uses the correct one, the default is still there in the cards array.
• Remove card display/edit mode: this was actually considered on the original roadmap, but didn't make the cut. Just as Bustle's and Ghost's, my use case also opts for a edit only approach. I think it's natural to do this, since most people uses Mobiledoc Kit alongside Ember, React or Vue. The display/edit mode would only make sense in a vanilla JavaScript project (which is extremely rare these days).
• Standardize atom/card render function arguments: the env object in the atom render function is different from the env object in the card render function (look here and here). What bothers me the most is that there is no didRender hook for atoms. Also, the cardOptions object should be renamed to richOptions since it is passed both to cards and atoms.
• Standardize inputHandlers and keyCommands: one thing that annoyed me while inspecting the code is that the inputHandlers are neatly handled by a class, while the keyCommands are a bunch of functions all over the place. Their register methods are inconsistent (onTextInput vs. registerKeyCommand). It would be better to create a class to handle the keyCommands and rename onTextInput to registerInputHandler. I also think it would be nice to rename keyCommands to keyHandlers, but maybe this will cause some confusion.
• Remove non-mobiledoc parsing/serialization: the editor should only receive mobiledoc objects as input and return mobiledoc objects as output. Any other transformation should be done by the user.
• Remove shortcut/proxy functions: the toggleMarkup method in the editor is different from the toggleMarkup method in the postEditor. It's difficult to know when each one should be used. These shortcut/proxied functions (deleteRange, toggleSection, insertText, detectMarkupInRange, etc) should be moved to the postEditor (or other appropriate place).
• Rename postEditor: renaming it to transaction would better express what the postEditor really does: it aggregates a series of commands to edit the post and the executes it in one take. This is not actually really necessary, though.
• Improve postEditor hooks: the postEditor has three hooks that are called technically at the same moment (look here and here). For example, a better placement for the afterComplete hook would be right before the runs return statement, solving this Ghost's use case (and mine too).
• Remove redundant utils: for example, there's this file that implements some array polyfills. It would be better to use core-js, babel-loader or even lodash. This could be easily done during the build system rework mentioned above.
• Resolve the spellcheck problem: this is a very old problem. Look here, here, here, here and here. Other libraries also faced this problem, such as Slate (here, here and here) and Draft (here).
• Proper documentation: JSDoc is kind of good, but it's not friendly at all. Also, most of the API remains undocumented. After all the work, the v1.0 deserves a good documentation (it would be nice to use GitBook).

I also have suggestions about some concepts of the mobiledoc format, but I think it's better to present them in a PR since they are not actually related to the library refactoring.

[apfelbox]

I really like all your proposals.

Especially the image type and the editor / view mode distinction are things, that I came up with myself. Because of the mobiledoc format being pretty straightforward to render, there is no need for the editor to have separate render functionality. I am pretty sure, that most users will opt for using a separate / custom renderer instead of using the editor to only render the document.

I have a few things to add myself, but most of them are related to the actual mobiledoc format, so I'll be happy to add them in the separate issue.

[apfelbox]

I would like to expand the one point:

Remove link tooltip, placeholder and styling

We are integration our RTE based on mobiledoc-kit into a larger CMS and would like to keep using the built-in link markup. However, the links in our CMS have way more properties then just a URL, so we need to

a) hook into a link being currently selected (we can already do that for example via cursorDidChange()) and display an edit button.
b) add a custom key/value map to the link markup entry – we currently do that by just storing it in the rel attribute, but that is a hack I would like to avoid (but that is a topic for the format, not (only) the editor)
c) maybe be able to display some own popups inside the actual editor (not sure if and how that is currently possible) at the caret / specific elements (think of an autocomplete popup for example).

[henriqemalheiros]

a) hook into a link being currently selected (we can already do that for example via cursorDidChange()) and display an edit button.

Yes, it is possible. Ghost's uses its own mouseover event listener that detects an a tag. But there are other ways to do that. In my case, I only show the link toolbar when the range is collapsed within a link markup (this is checked during the cursorDidChange hook, as you mentioned).

b) add a custom key/value map to the link markup entry – we currently do that by just storing it in the rel attribute, but that is a hack I would like to avoid (but that is a topic for the format, not (only) the editor)

Are these valid HTML attributes? If so, we just need to extend this array. If not, I don't think it is a good idea. I really like how sections and markups are valid HTML elements, while atoms and cards can be anything the user wants then to be.

c) maybe be able to display some own popups inside the actual editor (not sure if and how that is currently possible) at the caret / specific elements (think of an autocomplete popup for example).

Again, you can refer to Ghost's card menu popup. They cleverly use a inputHandler to show the popup when the user types a / in a empty section. Then they use the cursorDidChange hook to get what the user is typing and update the popup. You can see it in action here.

[apfelbox]

Are these valid HTML attributes?

Actually, they are not – at least not really, as they don't make sense in an HTML context (like the page id the link internally points to). I previously had it implemented as atom, but this has the huge disadvantage that you can't directly edit the text + can't use it with other markup (except you want to do nested editors, which are a pain to manage).

I really like how sections and markups are valid HTML elements, while atoms and cards can be anything the user wants then to be.

I would like to keep that. I would separate the tag + attributes from an additional payload. The payload is ignored when just simply rendering to HTML, except you have a specialized renderer that knows what to do with the payload.

We actually have the same thing (sort of) with sections: we would like to separate the styling of a headline from the actual HTML tag – as design and SEO have conflicting interests. So we would just add an attribute to headlines that defines which visual "level" this headline has.

I understand that this deviates a bit from some of the core concepts, but if they are fairly easy to implement (and adopt in the format), this would be really great. Because for me, one of the main strengths of mobiledoc is that it is indeed not HTML, but way more structured. This solves a lot of issues like embedding rich content in the text. I would find it weird if everything works smoothly except we have to make these hacks in cases of markup / (core) sections.

Again, you can refer to Ghost's card menu popup.

I actually quite extensively used their editor before and really love the implementation. This really is a rich text editor for the modern age.

My issue was more that I would like to position the popup not just below the start of the line (which iiuc what Ghost does), but I would like to position it beneath the cursor – no matter where it is in the line.

[henriqemalheiros]

I previously had it implemented as atom, but this has the huge disadvantage that you can't directly edit the text

I think editing an atom value directly like you edit a markup would be great. I also faced this constraint, but just accepted it since it only affects a tiny fraction of the overall experience.

can't use it with other markup

Maybe I didn't understand what you meant, but you can use markups in atoms.

We actually have the same thing (sort of) with sections: we would like to separate the styling of a headline from the actual HTML tag – as design and SEO have conflicting interests.

I had a similar use case and solved it using my own renderer. Anyway, I'm strongly against custom payload on markups and sections.

My issue was more that I would like to position the popup not just below the start of the line (which iiuc what Ghost does), but I would like to position it beneath the cursor – no matter where it is in the line.

Ghost positions it's toolbar based on the current range. The link input uses a similar approach, but instead of using window.getSelection(), it converts a MobiledocRange to a native Range.

[apfelbox]

Maybe I didn't understand what you meant, but you can use markups in atoms.

Besides from nesting an editor, I can‘t make part of the text content of an atom bold or italic. I can make the whole atom bold or italic, but I can’t only markup a part of it.

[zicklag]

I know this issue is a couple of years old, but that kind of solidifies the question. Is this project mostly unmaintained? The contributor graph doesn't look awful, but it's not necessarily promising:

[donaldsonjulia]

@ZeeJab I am also curious if this project is still active. I'd like to make contributions to the Ember mobiledoc addons, but some Ember friends suggested I contact you to see if it's still being used actively (and therefore worth the effort of the Ember upgrades).

[kevinansfield]

Is this project mostly unmaintained? The contributor graph doesn't look awful, but it's not necessarily promising:

We're still using mobiledoc-kit heavily at Ghost. The reason for no activity from our side is because we haven't had to make many changes to it, stable !== non-active/unmaintained 🙂

I'd like to make contributions to the Ember mobiledoc addons

We don't use the ember addon because we wanted more control over the integration with our app but I'd personally love to see them upgraded, I think it would be useful for existing and new users discovering mobiledoc.

[ZeeJab]

Hi @donaldsonjulia! As @kevinansfield said, the project is very much maintained and active 😄 The entire https://www.bdg.com/ portfolio runs on mobiledoc-kit, so rest assured the project is stable and battle tested. Happy to have more contributors to the ember addons! Let me know if I can be helpful.

[tholman]

Any with those two answers, we can close this issue.