silverstripe / silverstripe-framework

Silverstripe Framework, the MVC framework that powers Silverstripe CMS

https://www.silverstripe.org

BSD 3-Clause "New" or "Revised" License

721 stars 822 forks source link

Remove noisy bottom row from default HTMLEditorField #8865

Closed chillu closed 2 years ago

chillu commented 5 years ago

It shows the breadcrumbs to the HTML tag, which isn't super useful to the majority of content authors. Given how common TinyMCE is, those 20px in height add a LOT of clutter overall. Particularly now that we're starting to embed TinyMCE in more constrained views such as block inline editing.

clarkepaul commented 5 years ago

upgrade to newer TinyMCE which would remove this feature anyway https://github.com/silverstripe/silverstripe-admin/issues/675
reduce UI impact by organising available actions https://github.com/silverstripe/silverstripe-admin/issues/653

lerni commented 5 years ago

I agree it shouldn't be there and since I cannot see movement in #675 & #653 I suggest to just set https://github.com/silverstripe/silverstripe-framework/blob/4/src/Forms/HTMLEditor/TinyMCEConfig.php#L263 to false but probable to late for 4.4 ;(

maxime-rainville commented 4 years ago

Just had a quick glance to see how easy this would be. You can use you can use the statusbar: false option to hide the that bottom bread crumb thingy. The problem is that the resize handle is also part of the status bar ... so if you disable the status bar, you indirectly disable the ability to resize your editor.

To try it out, all you need to do is update TinyMCEConfig::$settings with a 'statusbar' => false entry.

This S/O question discuss how you can disable the breadcrumb bit without disabling the resize handle. But you're still left with empty status bar. One response suggested using CSS to hide the status bar while keeping the resize handle ... it looks a bit hackish but it could work.

@clarkepaul If you think loosing the ability to resize is an acceptable trade-off and I can create a quick PR.

clarkepaul commented 4 years ago

@maxime-rainville no we really need to keep the resize functionality. It's horrible editing large images and bodies of text in the small area. If we can't remove the breadcrumb then can we reduce the impact of it height-wise? It might just need to wait until TinyMCE gets upgraded as its only about 12 pixels in height there ...

michalkleiner commented 4 years ago

I'd vote for keeping the resizing as well. However, I don't think this is a high impact issue.

maxime-rainville commented 4 years ago

We could remove the breadcrumb and reduce the space allocated to the status bar with some CSS.

There's a way you can set the height of the status bar to zero and have the resize handle float over the scroll bar but that may lead to some weird results. Not sure how browsers will handle have some DOM element float over a scroll bar.

clarkepaul commented 4 years ago

In my opinion, the best result would be to minimize the height of breadcrumb but have it remain functional. They are actually useful for navigating up and down the HTML, is that possible?

maxime-rainville commented 4 years ago

Current (37px)

No vertical padding (20px)

No vertical padding + reduced font-size/line-height (16px)

michalkleiner commented 4 years ago

Each of the breadcrumbs is a button allowing editors to navigate and select the parent elements. It's not particularly usable on mobile already, but reducing the font-size/line-height makes the touch target even smaller. I reckon the editing experience on mobile needs to be considered as well (not only in this particular case).

clarkepaul commented 4 years ago

Lock-in option B @maxime-rainville :)

GuySartorelli commented 2 years ago

Closing because it's extremely unlikely we will be doing this 8n CMS4, and were intending to upgrade to tinymce6 in CMS5.