Thinking out loud: "clean output" for inline tools

[jeremyVignelles]

I've seen this on the main page of editor.js

What does it mean clean data output
Classic WYSIWYG-editors produce raw HTML-markup with both content data and content appearance. On the contrary, Editor.js outputs JSON object with data of each Block. You can see an example below
Given data can be used as you want: render with HTML for Web clients, render natively for mobile apps, create markup for Facebook Instant Articles or Google AMP, generate an audio version and so on.

I fully agree with the concept and I find this a key differenciator from other editors. However, it does seem to be the case for blocks, and not for inlines.

However, such paragraph generates this code:

            "data" : {
                "text" : "Given data can be used as you want: render with HTML for <code class=\"inline-code\">Web clients</code>, render natively for <code class=\"inline-code\">mobile apps</code>, create markup for <code class=\"inline-code\">Facebook Instant Articles</code> or <code class=\"inline-code\">Google AMP</code>, generate an <code class=\"inline-code\">audio version</code> and so on."
            }

The fact that there are code tags in the middle of the data would defeat the ability to render it easily and natively on mobile apps and other platforms.

I'd have preferred something like:

            "data" : [
                "Given data can be used as you want: render with HTML for ",
                { "type": "code", "data": "Web clients" },
                ", render natively for ",
                { "type": "code", "data": "mobile apps" },
                ", create markup for ",
                { "type": "code", "data": "Facebook Instant Articles" },
                " or ",
                { "type": "code", "data": "Google AMP" },
                ", generate an ",
                { "type": "code", "data": "audio version" },
                " and so on."
           ]

Advantages

• Cleaner output
• Easier to parse for other languages than js/html
• Easier to sanitize : just encode all entities in text string, easy to do in any language, even at the server side (where everyone should sanitize their input)
• Easier to index : One of the main concerns I have with other libraries is that you need to handle dom/HTML to get the text to index in full-text searches like elastic search. A simple tree traversal would be able to do that here.

Drawbacks

• Breaks the existing API and the existing plugin ecosystem
• JSON will likely be heavier
• HTML rendering would become more complex as you would need to handle inline tools as well

What do you think about this ?

[gohabereg]

Hey @jeremyVignelles !
Thanks for sharing. We had several discussions within the team about clean output for inline formatting. As we want to have ability to implement data-reach inline tools we would definitely need to implement some JSON format for them which will cover simple tools as well. Moreover, it seems we will need it for collaborative editing.

However, our main concern is Editor.js mostly used for web-based environments so switching to such format will make rendering to webpages more complex. It's likely we will provide an option to choose in which format you'd like to save inline fragments.
But considering above this feature is not on the top of our priorities at the moment.

[jeremyVignelles]

Hi,
Thanks for sharing your internal discussions. I have three questions now :

• I thought about having a "transition period" where users would choose between the two format. Do you think it will be okay to maintain two versions of the code in parallel, say, for editing, for example?
• Does that mean that all tools will need to implement two functions, depending on the mode that was selected ?
• Don't you think that the more you wait, the worse it will be to migrate for you and the community ?

[gohabereg]

• it would depend on design. I don't think there will be two versions of code, the core would use only new approach, but there would be another layer on top of the core to convert new format to HTML tags
• no, tools anyway would need to provide render method so Editor knows how to display them, using this method we will be able to provide markup to output
• again, depends on design. At this point my thoughts this feature can be implemented transparent to developer and without breaking backwards compatibility so migration would cost the same

[jeremyVignelles]

I'm not familiar enough with all the APIs, but isn't there somewhere a "parsing" method for the inline tools where the plugin says "yup, that's my code", for example, for edition... ? Generating HTML wouldn't be hard, I guess, but transforming back from either a string or a JSON is really different, don't you think?

[gohabereg]

Inline tools atm just check if fragment is wrapped with particular tag.
Agree, so some of inline tools (complex ones) wouldnt support both modes, but I think it's a fair price for backwards compatibility considering generating HTML from such format would be a pain point -- we are still receiving questions how to convert JSON back to HTML

[gohabereg]

Anyway, to implement this feature a lot of things should be done. Right now not all content you see has clear representation inside JS model, Inline Tool is just a piece. We are going to move to model-first approach but it requires proper maintainable and extensible design

[jeremyVignelles]

I have to admit it was one of my questions too when I started to look into editor.js. Its unusual approach means it's likely not a drop-in replacement for other wysiwyg editors.
With a growing ecosystem, that might be interesting to have server-side JSON-to-HTML and sanitizer libraries in different languages.

[gohabereg]

We would like to but we just don't have resources for that (even to review and declare some 3rd party solutions as "official"), so we are relying on community here

[Forsakenrox]

Awesome feature that i trying to find on very continious period. This feature available in editors and sites like yandex or facebook, they use the same aproach when user write stylish text (paragraph block in case of this library) and making the post with media (video\image or any other widget). All what this library need - is option for change output type for stylish blocks like bold or italic and etc. On sites that i listed befor it look like special mark in json where has property tag like "bold_text" and sub options "start_from_letter: 2" and "end_on_letter: 10". Very simple and flex. Easy to validate on backend and render on frontend

[ChasLui]

Is it possible to replace inline html with quilljs/delta

[uuykay]

Understand where you're coming from, however I also believe it's not the right serialisation for the modern web. I have chosen to go with Markdown as the authoring format with AST conversions.

[bekogeko]

It is an essential feature because it results in better migration for the new web platforms. With this approach, we can quickly render out as we want other than injecting it into the DOM. I'm not saying it should be the default way to do it. Maybe a tool for abstracting it or just an option in the initialization section of the editor. Maybe an even better option is giving it on the saver function as a parameter.