We will need some way to change the forced_root_block value for TinyMCE on heading blocks. Otherwise, inside the Heading, there will always be a <p> tag wrapping around the content, which throws off the typography.

I think we should try to have <h1 contenteditable="true">{ ...children }</h1> instead of messing with forced_root_block?

@iseulde Sounds like a potentially better solution. From my understanding, that would mean not using TinyMCE for the heading block? What will we lose out on if we use

<h1 contenteditable="true">{ ...children }</h1>

instead?

Hey,

Have you considered making tinymce use the heading itself as the target container, rather than embedding a div inside the heading? I see at the moment that the Editable react component always creates a div and uses that as the rendered element, but you could make its node name configurable. Then you wouldn't have to worry about forced_root_block (this is probably what Ella is suggesting).

If you want an example of using a heading tag for an inline tinymce instance, see the examples here: https://www.tinymce.com/docs/demo/inline/

@ephox-mogran What are the pros of this approach compared to always using a div container?

It gives tinymce more context for the various operations. With differently structured blocks (like ol and ul), it prevents the insertion of a div tag from causing problems with the HTML structure. Primarily, it means that tinymce is given more information to make decisions, and more of the finer formatting details can be delegated to tiny.

When a tinymce instance is created on a target node, it's able to use that node to govern how it should act (with regards to Enter key behaviour etc). If you are embedding tinymce inside something and then trying to give tinymce restrictions based on information that you know but it doesn't, it's probably going to get a lot more complicated.

@ephox-mogran Thanks for the explanation, Good points here. I guess the more we build blocks (heading, quotes, lists, text ...), the more we'll have context on whether we should do this or not. (Especially when we'll introduce keyboard interactions and HTML restrictions)

See #327 (comment) for relevant changes to edit and save function signature.

Closing in favor of #423