RFC 0026 Block in the Rich Text Editor

[lassefredslund]

Request for Comments: Blocks in the RTE

Read the full RFC document here.

This RFC discusses adding Blocks in the Rich Text Editor. We would love your feedback on the described feature.

How do I contribute?

Most importantly, we don’t want to miss anything, so everything goes in terms of clarifications, questions, suggestions, etc.

Please do the following things if you want to contribute:

1. Read the RFC document here
2. Please read and respect the RFC Code of Conduct
3. Come back here and add comments down below 👇

[jdpnielsen]

For the Content Delivery API, we propose that blocks should be listed in an array in the Json output and then referenced from within the RTE HTML element. While not used in a headless context, a partial view is needed, just like with blocks for the block list and the block grid.

Consider the Portable text format - it works really well in Sanity: https://github.com/portabletext/portabletext

[skttl]

I fully agree with @deanleigh that you shouldn't build complex pages in the RTE - but we still need some macro-like functionality, for inserting non-trivial stuff, like buttons, icons, tooltips etc. in an RTE.

The proposal seems like a good solution for replacing macros without adding too much.

In this part: https://github.com/umbraco/rfcs/blob/0026-blocks-in-the-rte/cms/0026-blocks-in-the-rte.md#show-the-block-in-the-rte, it says that blocks by default will be inline, but the mockup implys that it's a block level element (the full width). If it was inline, it should only take up space matching the width of the content. In #13556 the point for inline macros is made. Also buttons, icons etc. would mostly need to be inline or inline block.

[deanleigh]

Just noticed > eg. for an icon in the button?
Easily done with Format and CSS
I have added numerous highly styled elements in sites over the years in TinyMCE and they are very simple for the end user

[bielu]

I just went through all commnents in this dicusssion and I would argue there is no usage for "real" macros, all macros mentioned there should be done as separate blocks, exlcuding example by @c9mb which should be done as custom TinyMCE editor! I am going to be most controversial and I am going to say Macros were bad idea in first place, and now we discussing if we should introduce something what is basically same but newer, than why do we even remove macros in first place?

[bjarnef]

@deanleigh I agree often styling of a button / anchor can be done using Formats in TinyMCE adding a class and CSS Pseudo-classes, but we have also had designs with a bit more fancy buttons / anchors, which required at least the text to be wrapped in a <span>, e.g. because the underline animation only need to style on the actual text.
One way to solve this is to enable the Template plugin and add custom HTML, but sometimes there's a chance editors could mess up the HTML.

One benefit with an inline Block is that the HTML is isolated and we can re-use a component, which already is used in Block List and Block Grid.

[bielu]

@bjarnef I see your point, but than I would argue then they should split content into multiple block to make editing managable. Adding back feature to replace macros will let to another wave of sites built in RTE! even wordpress dropped now that type of feature for specialised blocks (see gutenberg). I really think we should look into what other cms are doing to not repeat same mistakes or learn from them.

[deanleigh]

@bjarnef I have argued that we should have a plugin section at the end of the RTE instance page for some TMCE's own very clever plugins.
But as @bielu has argued surely from a content management UX we should be encouraging users to add, remove, copy, paste blocks and RTE is just one of those blocks.
I have tried to create a examples of common blocks and some less common ones (tabs, faqs) in https://umbootstrap.com/ to show how easy it is and what a great editing experience when combined with Block Preview

[skttl]

One thing thats missing from the current macro implementation to this, is the ability to cache the output. But I don't think it should be a setting on the macro/block anyway, so I'm good with keeping that out.

[enkelmedia]

I think that the RFC looks good! I do agree with arguments that point out that it's better to create specific blocks for stuff but that only works if the RTE is used inside a Block Grid or a Block List. When the RTE is placed directly on the Content Type, something similar to macros is valuable. We have several sites that have been around for 5-10 years with many thousands of nodes, some of them just do not make sense to re-implement and migrate to a block-based structure.

I think that it's important to be able to have different cshtml-files (if needed) for the frontend rendering of blocks in the RTE - I did not see this explicitly pointed out but I assume that this is the plan.

Keep up the good work!

[bielu]

When the RTE is placed directly on the Content Type, something similar to macros is valuable. We have several sites that have been around for 5-10 years with many thousands of nodes, some of them just do not make sense to re-implement and migrate to a block-based structure.

so it is better to keep wrong structure which with time will became more and more complicated. You can write automated migration to usync migration to split it into blocks. It does make sense to reimplement it, to make it easier to manage as managing content and macros in RTE is awful :)

I think that it's important to be able to have different cshtml-files (if needed) for the frontend rendering of blocks in the RTE - I did not see this explicitly pointed out but I assume that this is the plan.

I would assume they would use same as grid block(gridblocks) and block(blocks) separate folder so mostlikely inlineblocks/

[skttl]

@bielu no one in this discussion is advocating using blocks in rte as a replacement for block lists/grid. And the discussion is not about whether or not to have this feature, but how to implement it.

And block list/grid can't add inline elements, which is the main reason we need similar functionality in the rte.

We could come up with some kind of short code functionality like in WordPress, but that would just be the same functionality, but a lot harder to work with for both editors and developers.

You could also create your own plugin for tiny mce or templates, but that is only possible for those with unlimited developer resources. And you would end up having implementation details (fragile html markup) in your content, where it should only be concerned with what it is, and what it contains.

And with formats, you are limited in what you can do, you can basically only change the element type or add a class name. You wouldn't be able to add accessibility features to your content.

[bielu]

And block list/grid can't add inline elements, which is the main reason we need similar functionality in the rte.
We could come up with some kind of short code functionality like in WordPress, but that would just be the same functionality, but a lot harder to work with for both editors and developers.

That is my point you shouldn't create inline content :) if you need add something more complicated than heading you already should split it into separate block :)

[skttl]

I'm not sure we agree on what inline content is. I'm talking about inline level elements, as described in https://www.freecodecamp.org/news/inline-elements-and-block-elements-in-html-explained/

[bielu]

@skttl yeah, i guess, I still think button other inline html tags should be handled as TinyMCE plugins in same as URL picker is :)
what i meant for inline content is same approach as people were doing with including whole section of site. Because of context what I readed as inline elements was like included in RTE not as html inline element! you saying it would be less fragile, but still it would keep reference and can be easily broken by editor anyway, so not seeing benefits over html markup from tinyMCE plugin, which would be reausable outside of umbraco as well :)

[lassefredslund]

I've discussed the inline functionality a bit with @nielslyngsoe and we suggest adding an inline property on the blocktype settings so that the implementer has a chance to control the look within the RTE. However, if this setting is set to inline it will behave like explained above, where the editor can still choose to place it on its own line.

The main purpose is to enable implementors to enforce a Block not to appear inline and as well avoiding unnecessary HTML when seeking a non-inline style.

[lassefredslund]

Thanks for the comments.
This feature is included in V13 RC1. Please go and test it out, and raise an issue in case something doesn't work as expected.