Thinking out loud: "clean output" for inline tools
See original GitHub issueI’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 formobile apps
, create markup forFacebook Instant Articles
orGoogle AMP
, generate anaudio 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 ?
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:10 (5 by maintainers)
Top GitHub Comments
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
Is it possible to replace inline html with quilljs/delta