Make Core TinyMCE Block Type

[anna-harrison]

Make a core/TinyMCE block type which integrates seamlessly with the gutenberg UI, and provides:

• backwards compatibility for legacy documents
• support for complex document types, e.g. multi column text with bullet lists in tables
• support for advanced features, e.g. font styles, text colours, indenting
• accessibility*
• mobile support**

*Accessibility Use the gutenberg React UI components and extend them with accessibility features Make new React UI accessible components for any advanced features not present in existing block types

**Mobile support The TinyMCE block type could embrace TinyMCE mobile capability (rolled out later this year)

Related to discussions in #349 and #335. Note that this issue is orthogonal to #335 as 'core/TinyMCE' block type will deal with its own block type, not with broken, unknown or un-parseable block types (although it is possible that these block types could be channeled to TinyMCE block type for rendering)

[jasmussen]

CC: @aduth @mtias as to whether it's the same or a different block than the "unknown" block. I suspect they are the same, though the verbiage of "broken" or "unknown" sounds more gloomy than it should.

[aduth]

Note that this issue is orthogonal to #335 as 'core/TinyMCE' block type will deal with its own block type, not with broken, unknown or un-parseable block types

Curious what distinction the TinyMCE block proposed here has from the freeform block type (default) introduced in #335 ? I had thought perhaps TinyMCE would simply become the implementation of this freeform block. There are some UI design considerations though. If the proposed TinyMCE block would include toolbars and such similar to what exists in the editor today, this would appear quite cluttered if now applied to each top-level parsed element (every paragraph).

[jasmussen]

I tend to agree with Andrew — I like quite a bit the idea of this block being very functional indeed, though we should be mindful for it to not become a microcosm of an editor inside an editor, nesting doll style. Probably worth spec'ing out what we expect it should be able to do, and comparing. I'll make a note to make a mockup as well. Hopefully we'll uncover where we overlap and don't.

[anna-harrison]

@jasmussen @aduth : yes, perhaps my choice of words around "unknown or un-parseable block types" was indeed a bit gloomy... let me clarify as that was not intended :-)

When we spoke about #335 with @intronic and @mimo84 we understood that the main focus of that issue was to finding a soft landing spot for any blocks that are syntactically un-parseable (is this right?)

With TinyMCE block type, we are proposing a block type that can handle "complex" block types (think multi-column text, lists, tables, bullets all in one block). We are not suggesting to create a parser/corrector for blocks which are syntactically unsound

We are in total agreement that this block type must respect the gutenberg UI philosophy, so it will not be a TinyMCE-as-we-know-it-today-editor inside the gutenberg editor. It will have more functionality than the current blocks, and on this, we are very open to suggestions for what this means at a detailed level

At this stage we envision that the extra functionality will be provided through contextual toolbars (as in gutenberg). As gutenberg moves to Calypso, we can look at exposing more rich or advanced functionality through a sidebar-style interface

[anna-harrison]

@jasmussen @mtias this is how I imagine TinyMCE block type... does this overlap with what you have in mind?

Summary of these notes on ephox blog

[jasmussen]

Nice mockups!

On a meta-level, it feels like the role of this block is to leverage what TinyMCE does best: text. And so perhaps instead of TinyMCE block, or even "Freeform" block as the temporary name I suggested, this blocks name might simply be "Text", and it would replace the Paragraph block, perhaps even the Heading block depending on how it feels.

What it does, essentially, is provide a single continuous block for text, even if the UI might still treat individual paragraphs as blocks. It would be separated only by non-text blocks, such as galleries, images, and so on. Mockups:

Edit: Please see mockups later in the comment.

[BoardJames]

I've been looking into how to skin the tinymce block so the TinyMCE menus look like the other block menus.

I've started with the TinyMCE default skin as a starting point which is written using stylesheets in the "less" format and I've converted them to "scss" so they match with the rest of the project and don't require any special processing.

I plan to include the generated combined stylesheet on the edited page and set the TinyMCE configuration to have "skin" set to false so it doesn't try to load the skin.

The hitch is the fonts and the icons. They will have to be served in the folders "fonts" and "img" relative to the skin stylesheet. I'm not sure how to serve a folder in a plugin; reading though the code I think I'll need to list each file to be served (there are 14) in the index.php file with wp_enqueue_style. That's not terrible but I would like a better way and I'm sure one must exist.

[aduth]

They will have to be served in the folders "fonts" and "img" relative to the skin stylesheet.

Is there no way to point explicitly to the resources; it must be inferred from the skin path?

[BoardJames]

The paths are specified in the css so as long as I find all references they could be put anywhere. Since I'm not proposing changing them they could refer to the version served with tinyMCE on wordpress (assuming the CORS headers are set right) now that I think about it - I will try that and see how it works out.

[jasmussen]

@EphoxJames Let me know if I can be of help here.

[BoardJames]

Thanks jasmussesn for the offer. I got it working Monday but I forgot to write an update (Tuesday was a public holiday in Australia) so here's what I did:

• I changed the URLs (for fonts and images) in the custom skin to point at the nightly TinyMCE you've been using.
• I loaded the skin by importing into the style.scss for the Editable component
• I put a dummy skin (2 empty css files) in for the skin_url parameter of TinyMCE - it seems that at least for inlite theme it does not accept false to mean don't load a skin
• I added wp_register_style calls in the index.php to serve the dummy skin

The rest of the day I spent modifying the skin to make the contextual floating toolbars of the inlite theme mimic the block toolbars.

[BoardJames]

This is what I have currently:

[BoardJames]

@jasmussen What is the correct procedure to get dash icons approved for this project? - We (Ephox) would like to get a TinyMCE icon approved for this TinyMCE editor block. Should approvals still go via pull requests to the dashicons github?

[jasmussen]

Hi @EphoxJames! Nice, fast work! Lots to unpack here.

On the skin, the primary goal here is to keep the design as unified as possible. Since this is going to be a core block that ships with the editor, ideally it would be as easy to style as any other block we are creating. If you can reference an external stylesheet to make sure toolbars and formatting controls are 1:1 the same as those that come with other blocks, that is essentially idea.

On the TinyMCE block, as it will ship with core it should probably not be called "TinyMCE block", and it should probably have a more generic icon rather than a logo. The feature set will essentially be virtually the same as what the current WordPress editor has, barring a few UI changes, but the primary purpose of this block is to serve double duty as a fallback block for when we are loading old or unidentified-by-our-parser content, as well as a block users who prefer it might want to insert and use manually. I have so far proposed the term "Freeform Block" as the name, but if a better one pops up that's okay too.

On your screenshots and specific implementation: Nice work! We should not be using the inlite theme for this block, though. The inlite theme, correct me if I'm wrong, uses popup toolbars that show up when you select text. For this editor we are trying a "block-first UI", where we essentially dock the toolbars to the top of the block itself:

This is a mockup from another block we are proposing, "Continuous Text" (#447). Depending on how the Freeform block goes, it's possible the Continuous Text block could be a subset of the same block.

On Dashicons: In general if you ever do need a dashicon (though I don't think we should do the Tiny logo), I can help you with that. Either by designing the icon for you, or working with you to get it into the set. We've smoothed out the build process so it shouldn't be too painful.

I hope that answered some of your questions, let me know if you have others, or if I can provide you with mockups or anything else. Don't be afraid to ping me on Slack either (username @joen).

CC: @annaephox as things are crystallizing around the Freeform Block/"Writers Block"/TinyMCE Block, and for your thoughts on the continuous text block.

[BoardJames]

Replying to the request:

If possible, we'd love to see as much of your work as possible happening directly in the Gutenberg Github, as pull requests off master.

This work is available to view on the branch add/365-make-core-tinymce-block-type2 . I was waiting for the discussions about the iconography and naming to be resolved before putting in a pull request.

[jasmussen]

This work is available to view on the branch add/365-make-core-tinymce-block-type2 . I was waiting for the discussions about the iconography and naming to be resolved before putting in a pull request.

Nice, just had a look at this branch, it seems like a SOLID start 🎉

We shouldn't use the inlite theme, though. The controls should be docked at the top of the block itself.

Here are some mockups of how that might work:

https://cloudup.com/cZzrYnpNEaC

[jasmussen]

Latest mockups as of May 9th:

[BoardJames]

So I created this (branch add/365-freeform-block ) by merging bit and pieces from the text block and list block.

[BoardJames]

I'm not certain what to make of the mockup where the list is applied - is that splitting the freeform block and creating a list block in the middle?

[jasmussen]

I'm not certain what to make of the mockup where the list is applied - is that splitting the freeform block and creating a list block in the middle?

Yes, it is, but this is not something that has to happen, actually. This is just an idea, and not a priority, so let's ignore that bit for now.

Dig your work judging on the screenshot above! Seems like a good approach!

[jasmussen]

So I created this (branch add/365-freeform-block ) by merging bit and pieces from the text block and list block.

Actually looking at that screenshot, it seems like it might be good to stop here and let this be the basis for the first pull request for review. Let's try and get this merged in, and then we can discuss next steps (like porting more buttons from the old editor) in separate tickets, with separate PRs, just to keep code flowing into master, and keep pull requests as small as possible. Sound good?

[BoardJames]

Ok, I'll put in a pull request.

[jasmussen]

I'm closing this block in favor of #972, which is a new attempt at explaining the block in a more concise way.