We have in mind the "block-based editor" or "content builder" solution you're talking about. This could be relatively easily created having CKEditor as its base. This means that CKEditor may not be the ready to use way for it but it provides a good framework to develop such solution.

For example, its powerful widgets system [1], which can be used to handle "blocks", providing at the same time an excellent user experience.

At the same time, it would avoid issues that we see with the current solutions or prototypes available out there. For example, paragraphs would not be treated as separate blocks, like a video embed, but instead, they would be part of the content flow. This would allow for easy selection of multiple paragraphs. This would also avoid issues with large selection copy-and-paste.

What is needed here, is work. And this work much probably would go beyond the CKEditor scope, because it needs some level of integration with the application. It needs the development of such "blocks, and control of its behavior. All this on top of a dedicated UI solution, maybe in some senses similar to what we have with Letter [2].

There are hundreds of different use cases for editors. Our intent with CKEditor was designing a decent framework for others to build on top of it. It would be great to see the community getting together to bring such solutions to life. We're more than happy to help.

[1] https://docs.ckeditor.com/ckeditor4/docs/#!/guide/dev_widget... [2] https://ckeditor.com/letters/

It's really all the same, HTML is already a component-based system but the parsing and tooling for it is poor when used through javascript. Maybe WebAssembly will change that but using a content-block approach is definitely a way to get around some of the complexity. Medium's editor uses a similar approach, probably the most common and there's Mobiledoc which is a standardized JSON format and editor framework: https://bustle.github.io/mobiledoc-kit/demo/

Side note, list of various editors: https://gist.github.com/manigandham/65543a0bc2bf7006a487

I do a ton of work with CMS's, building sites for non-technical clients who manage their site without much knowledge of HTML, CSS, or any coding/encoding (even markdown would be a bit much for some of my users).

The big win that you get with a block-based system (as opposed to 1 big chunk of HTML) is that it allows us to build out the content editing interface in a way that is very "guided" for the user... like, if there is a photo gallyer, we have a repeating list of slides and they have fields for a photo and a caption. Then on the front-end we can build our HTML+CSS markup around those specific fields. You can't do that easily with 1 big chunk of HTML.

Right, that's what I mean about HTML tooling. It's a fine data format but DOM manipulation isn't very good compared to a JSON data structure with native integration into javascript and more universal parsing ability. The mobiledoc format is a good start at standardization.

> "block" based content

I've been wondering if this wouldn't be good for something like MarkDown editors that show the output as you type side-by-side, because you would be able to limit compilation to the block being edited (in this case, to maintain document structure the blocks would have to be be defined by headers).

Although I also would expect that dedicated tools do this already for efficiency purposes.

The reason I'm thinking about this is because I once saw a product in development at an e-learning company where they showed me a new product where (among other things) they wanted the students to write their stuff in MarkDown, in a naive "re-render the whole thing on every keypress" way. This... did not really scale at all.

You could probably get away with re-rendering at the actual paragraph level, provided you do a bit of minimal bookkeeping to track which input paragraph corresponds to which output paragraph—which, if you want to make it so that the input and output windows scroll alongside each other, you need to do anyway.

On a note that's tangentially related to this but more directly related to the top-level post, ProseMirror has a demo which involves a markdown-to-WYSIWYG editor where both sides are editable: http://prosemirror.net/examples/markdown/

Block Based Editing...?

SharePoint is knocking and asking for it's render model back. Web-parts in SharePoint are the whole reason why SharePoint runs like a dog.

For the open web to go down this route is very worrying indeed.

Wagtail has a similar sort of thing, inspired by Sir Trevor I think, called StreamField; it still has to have a RichTextBlock type to support inline-level formatting (bold, italic, links, etc.) Currently it's either CKEditor or TinyMCE (I forget which) but they're replacing it with something implemented using Draft.js and serialised as JSON, which isn't far off what ProseMirror or this new CKE version do as far as I can tell.

The block-based content is an idea that has been around for a long time and is embodied in several CMS's. Concrete5 has them baked into its core, ExpressionEngine and Craft CMS have the "Matrix" fields, Wagtail has "Streamfields" (as another commenter mentioned), most of the hosted CMS's now have it (Weebly, Squarespace, etc), some of the flat-file CMS's and static site generators have it (Kirby and Lektor off the top of my head), and even Wordpress has had it for a while via the amazing "Advanced Custom Fields" and "Flexible Content Fields" plugins. (And wordpress is about to get a lot more block-y with their new "Gutenberg" editing interface, although it still spits out one big chunk of HTML which means you don't get the front-end markup advantages that you do with a true block-based system).

* Concrete5: http://www.concrete5.org/

* Craft: https://craftcms.com/features/matrix

* Wagtail: https://wagtail.io/features/streamfield/

* Kirby Builder: https://github.com/TimOetting/kirby-builder

* Lektor Flow Blocks: https://www.getlektor.com/docs/models/flow/

* ACF/FCF: https://www.advancedcustomfields.com/add-ons/flexible-conten...

* Wordpress Gutenberg: https://wordpress.org/plugins/gutenberg/

As a developer, there are 2 advantages I've found to the block-based approach:

1) The editing interface can be custom-tailored to the content and the non-technical users who are editing the site via a GUI interface can be more "guided" through the data. E.g. a photo gallery can have repeating list of slides and each slide has separate image + caption fields. This is hard to do with a single WYSIWYG editor (Worpdress uses "shortcodes", for example, but those are a terrible UI for most non-technical users... the whole point of a GUI is to not have to use code)

2) The front-end HTML+CSS markup can more easily be customized around the content fields. Using the image gallery as an example again... since each photo + caption of a slide is a discreet content field, I can insert that into any photo gallery markup I want. If the input data is itself HTML (as it would be from a WYSIWYG editor), I don't have that ability (unless I parse the HTML I guess, but that is terribly brittle and making a ton of assumptions about the generated HTML that will probably change depending on WYSIWYG widget version, where the content was pasted in from, etc).

"Rick text editor" :D

Brilliant! Bet he built that because he couldn't cope with the insanity of ContentEditable either.

Probably not safe for Morty's to use tho.

TINYriCKEditor