Implement styleselect equivalent for inline/CSS-class formatting

[mrwweb]

Current TinyMCE (and therefore the WordPress post editor) supports the styleselect. This is an excellent way to allow editors to apply classes to HTML elements which is a great way to handle inline formatting like making a button or non-wrapper-block-element formatting like giving a paragraph a "Notice" or "Intro text" style.

I currently don't see how this type of formatting would work with this editor, but losing this ability would be a huge loss for applying this kind of inline/simple formatting.

Is re-implementing this type of feature on the roadmap at all? Is there another way this could be handled? Making an entire block type just for a "button" feels like overkill and doesn't address the ability to create inline span styles.

• TinyMCE documentation | TinyMCE Demo ("Formats" menu in second row)
• Codex documentation
• Example of usage from WordPress StackExchange

Here's a screenshot on a site I've implemented it on:

[jasmussen]

Seems like the freeform block should potentially be able to support this:

#365

I think of it freeform block as essentially the old editor in block form.

[mrwweb]

That seems like a good path forward.

The more I think about it, the scope of such a feature should probably be limited to applying inline CSS classes and/or markup (like <mark>) so that the idea of "block variants" (is there a term of that concept yet) is handled in a different way that can apply to all block types.

[mtias]

We have support for additional classes to be added via the inspector, so closing as covering the original intention.

[mrwweb]

@mtias Thanks for paying some attention to this ticket.

While adding a class to a block is useful for developers and power users, it is not the original intention of the ticket nor is it remotely close to feature parity with the styleselect.

In brief:

1. The styleselect can insert inline markup and classes. (My primary usecase.)
2. The styleselect can insert multiple inline elements based on what is appropriate for the markup (, , , etc.)
3. The styleselect was a drop-down menu with user-friendly labels. The reason it was useful is you could let a user choose "Border Button" and not have to remember or conceptually grasp a .prefix-button--border class.

If you refer back to the screenshot, I think you'll see all of these aspects and hopefully understand why a textbox for CSS classes is a totally different feature and usecase.

[mtias]

@mrwweb apologies, I've been going through piles of issues today and my brain is a bit exhausted.

The screenshot shows what should really become blocks under gutenberg, discoverable in the main inserter. (We have a pull quote block already, for instance, and the others could likely be custom blocks provided by you to your users.) That's the whole point of blocks, to avoid users remembering markup or classes.

It'd be good to have more examples of what sort of inline treatments would be useful to have to figure out how to handle them.

[mrwweb]

@mtias not a problem. I kinda of figured this was at the end of a bug scrub. Thanks for all your work.

You're right that the first drop-down shown is basically blocks and the second contains some styles of blocks, but here are some examples where I don't see a current way to handle with Gutenberg:

• An inline button class (or similar style variant) added to a link
• A highlighted inline portion of text with <mark>
• An "intro text" style that can be applied to the first sentence of a paragraph
• [Edge case] A way to apply the .screen-reader-text class to a portion of a link to make it more screen reader friendly
• Anything else you'd want to do with a <span>

More than anything, I'd like to highlight that in both this ticket and #783 (basically this request but for blocks), the ability for the theme to define user-facing Names for classes and styles is incredibly powerful and useful. A CSS class field is useful, but my experiencing training users to use similar features (such as in the Make theme), it doesn't really "stick" for users and they always have to refer back to documentation to remember class names.

It's also worth noting that both tickets almost certainly require some form of editor styles (#422) so that applying the class to the editing interface can result in the user seeing what the theme has applied.

[tekTutorialsHub]

<p>Here is the guttenberg paragrpah where i want <span class="code">This is important</span> to be shown in some fancy style</p>

The above is still possible, but to do that i need to click on Edit HTML and add the span element manually.

In the old classic editor, all I need to do is to

1. Select the Text
2. Click on the Menu and click on the custom style (refer to the screenshot provided by OP @mrwweb )
3. The span class was automatically inserted.

[mrwweb]

Following up on @tekTutorialsHub's comment, #783 addressed block style variants (quite successfully!), but not inline style variants within text. That was the other place that styleselect shined, for inserting <span>, <mark>, etc. with one or more classes (and with the potential to scope styles to specific elements or contexts). That does still feel like a need, and being able to add the styleselect to the end of the floating toolbar would beautifully address the need.

Maybe this issue can be reopened? It's certainly a clearly-defined regression from the Classic Editor extensibility.

[chrisvanpatten]

I think this is covered in #4658 which is still open. Definitely recommend following along there.