Full screen (distraction free)

[xiaosunJessica]

ckeditor 5 has give up the function about full screen(maximize)???? 

---

A quick update from the dev team 👋: since this issue gained popularity we'd like to know which kind of editing works best for you (fullscreen vs distraction-free). Please let us know by participating in the poll down below. Thanks 🙏

[Reinmar]

We didn't implement such a function yet. We may do that one day, but that'd be also possible as an integration feature (not part of CKEditor 5). In fact, it would be normally easier to implement that way because there's less assumption one will need to make compared to what we need to predict.

BTW, this could also be called a "distraction free mode".

[Reinmar]

I think that @oleq made some prototypes of a full-screen editing. Were there any problems with that in the past? I think that we'd have to take care of the balloons, am I right?

[oleq]

The topic is related to:

• https://github.com/ckeditor/ckeditor5-design/issues/149 – my initial idea was that in fact "mobile editing ~= distraction-free editing" but soon we found out the fullscreen API is not available in iOS and fixed positioning doesn't go well with iOS native keyboard too,
• https://github.com/ckeditor/ckeditor5-engine/issues/692 – the problems with editor encapsulation in DOM and floating elements like balloons, which cannot be in the <div class="ck-editor"> container, which often gets static dimensions and overflow: hidden.

But for plain distraction mode (ignoring iOS) I suppose we could use the same approach as v4. The only difference would be the mode switcher moving the "body" collection containing balloons to the <div class="ck-editor"> container when the editor is full–screen and reverting this change when it gets back to normal.

Since the editor spans the entire viewport anyway we don't have to worry about overflow and cropped balloons.

I think the balloon positioning system is ready for that except that maybe if a balloon is already open when full–screen is requested, we need to re-position it as soon as the "body" element collection moves. But this should (?) be covered by editor.ui#update event which can be triggered manually using the corresponding EditorUI method.

[oleq]

Just FYI, Apple allowed native fullscreen mode on iPad in iOS 12 (checked, it's working). But not on the iPhone (why?) :(

If we had it on every device, it could be a huge step forward for us (as previously discussed).

[leknoppix]

Hello, I have to little plugin to include to have the fullscreen

https://github.com/leknoppix/ckeditor5-fullscreen

[walidbagh]

Any news on this?

[gitmarcalinascris]

Any UpdatE?

[pradeepmanas]

[oleq]

FYI I did some research on this topic and here are my findings.

---

Fullscreen mode (maximize)

UX perspective

• Fullscreen mode ≠ distraction-free mode
  • True, it will give you more space to create content (more context).
  • True, it may simplify the way the toolbar works if there were so many items that they were grouped (they may all fit in and become easily accessible now).
  • True, it will detach the editor from the rest of the application and reduce the noise (to some extent).
  • It will not reduce the number of UI element the user will see, though. Quite the contrary, when toolbar items get ungrouped, they may see more of them.
• In CKEditor 4, this feature is called the maximize plugin. There's a button in the toolbar (and/or a keystroke) which maximizes the editor container hiding the rest of the page underneath.
  • Unlike CKEditor 4 though, I'd avoid stretching the edited content horizontally to the width of the screen. This looks unnatural and creates extremely long lines of text (e.g. panoramic displays); they just look weird. The width of the maximized content should be proportional to the screen width with a sane max value; a column of text.

Technical perspective

• You can check the entire implementation in the CKEditor 4 repo. It's fairly simple but there are some quirks (like saving and restoring styles).
• In theory, this could be possible in all editor creators. There are some risks, though:
  • UX risks
    • ❓ In the balloon block editor, exiting fullscreen will require two clicks, people could also feel lost.
    • ❓In the balloon editor, it will be difficult for the user to exit the fullscreen mode once the toolbar disappears. There's no way to exit unless the toolbar is visible and that is only possible on non-collapsed selections so there must be some alternative way of doing this, for instance, when the editor is empty (an "x" in the corner of the screen? could be configurable).
  • Integration risks
    • ❓In the document editor, things may go wrong because the toolbar container and editing root container are supervised by the integration. Collecting these elements (moving them in DOM) so they go to a common container before going fullscreen could break due to:
      • specific CSS rules that applied to them (e.g. content styling, could be solved by integration guide and a configurable editing root class),
      • the front-end framework that supervises (renders) them going wild (e.g. React, Vue).
    • ❓Not sure what to do with multi-root editors. This is probably up to the integration.
    • ❓There's a question of what to do with the annotations sidebar (a.k.a. collaboration sidebar). The more I think about this, the less likely we can pull this off without a wrapping container. And the wrapping container (like in document editor) is a source of problems with the integration's CSS and front-end frameworks.
    • ❓Content minimap is the same story as annotations sidebar 👆
• We'll need certain plugin events (such as maximize and minimize) fired by the feature plugin so custom integrations can handle them on their own and they can react to them if necessary (BTW: the event should trigger EditorUI#update as a side-effect).
  • TBH, it's worth checking if making the editor creator's UI (ClassicEditorUI, InlineEditorUI, etc.) responsible for reacting to these events and do most of the job (because creators' UIs know their implementations and quirks) is a good thing, leaving some common tasks to the maximize plugin only. This would de-centralize fullscreen/maximize, which I think is good practice: the plugin will not bloat as new editor creators arrive.
  • TBH, it's OK if the maximize/fullscreen plugin was just a button that fires some events and nothing else.
• For the record, we cannot use the Fullscreen API because even if it was supported by most browsers (AFAIR not supported by Safari on iOS yet), it totally hijacks the Esc key. Whenever pressed in whatever the context, it exits the fullscreen mode and there's no way to intercept it; this happens on the browser/OS level, not the DOM level. It makes sense because people would abuse it to trap users on web pages but the side-effect is the editing experience is very fragile and the user will exit the fullscreen frequently.
  • Besides, to use the Fullscreen API, all editor UI must be gathered into a single container before entering the mode. Floating UI elements in the .ck-body collection (in <body>), collaboration sidebar, everything must go there. Otherwise, those things will be left behind and will not work in the fullscreen mode. It is possible (I did a PoC a few years back) but this is painful and it's easy to miss some things.
    • OTOH, given the earlier considerations, this might be a must-have to some extent (floating stuff will work but document toolbar, annotations sidebar, etc. will not) 🙁
• Idea: What if maximize created another editor?
  • Messy for front-end framework integrations like Vue/React/etc.
  • Or just another root? (and destroy the old editing root, AFAIR very unlikely for two editing roots to coexist in current architecture).
    • This might be great for front-end frameworks.

Distraction-free editing

UX perspective

• The general consensus is that distraction-free editing means no UI visible when typing text.
• It's worth noting that for some users, dark mode is an essential part of the distraction-free editing experience.
• Some users may expect distraction-free editing to go together with maximize.
• There's a good chance CKEditor 5 already offers distraction-free UX (or some bits of it).
  • In other WYSIWYG HTML editors, distraction-free editing is what we call the balloon editor in CKEditor 5.
  • For starters, we could start calling the balloon editor (which is pretty vague) a distraction-free editor.

Technical perspective

• It depends on which elements need to be implemented (e.g. on-demand dark mode, maximize).
• Users who use Classic editor may want to have a button that goes to Balloon editor mode.
  • Currently impossible without destroying/creating editor instances.

[oleq]

As a follow-up to my previous comment, here's a question to anyone watching this issue: which feature would you like to see developed?

• React ❤️ for maximize that brings a button to display the editor full-screen (like in CKEditor 4).
• React 🚀 for distraction-free editing that hides the UI when you are typing.

Feel free to leave a comment if you had something else in mind. This will help us implement the feature you need the most. Thanks 🙏

[Madejczyk]

@oleq what do you think about maximize view with changing editor type and display mode - https://ckeditor.com/docs/ckeditor5/latest/features/collaboration/annotations/annotations-display-mode.html#narrow-sidebar ? Example: as normal view, I have classic build https://ckeditor.com/ckeditor-5/demo/ and inline balloon comments display mode. And when I click on full screen button I would like to change view to Document with wide sidebar for comments. Similar approach to https://ckeditor.com/docs/ckeditor5/latest/features/collaboration/annotations/annotations-display-mode.html#demo that I can jump between display modes.

[oleq]

 Thanks, @Madejczyk 🙏 We'll keep that in mind.

[Madejczyk]

@oleq when you will test above feature please check the tooltip of the first button. Probably the tooltip will be partially visible, but this is minor issue :)

[M-hanif]

strongly we need a maximize button in the editor UI.

[lserwatka]

Do you have any visibility when this feature could be available for CKEditor 5 users?

[smileBeda]

This is a must. maximize plugin

Following to get updates on this feature progress (it feels a bit as if it has been abandoned reading this thread.)

[feaswcy]

vote for maximize. @oleq

[wimleers]

This is technically a regression in Drupal since it moved from CKEditor 4 to 5 — since this is no longer available. It took >1.5 year for somebody to notice though.

We're tracking this in the following Drupal core issue: https://www.drupal.org/project/drupal/issues/3331158.

[ssougnez]

Is there any update on this feature? I've built a CMS app using TinyMCE and I'd like to replace it with CKEditor, however, the lack of Fullscreen feature is a deal breaker for our users. I would love having it.

[noeGnh]

You can try this. It comes from the code of the plugin in this reply https://github.com/ckeditor/ckeditor5/issues/1235#issuecomment-645512140 but I had to remove the icons in svg because it didn't work :

<script setup>
  import FullScreen from 'fullscreen.js'
  import ClassicEditor from '@ckeditor/ckeditor5-editor-classic/src/classiceditor'

  const editorConfig = ref({
    ...
    plugins: [
      ...
      FullScreen,
      ...
    ],
    toolbar: {
      items: [
        ...
        'fullScreen',
        ...
      ],
    },
  })
  const val = ref('')
</script>

<template>
  <ckeditor
    :editor="ClassicEditor"
    tag-name="div"
    :config="editorConfig"
    :model-value="val">
  </ckeditor>
</template>

<style>
  .ck-editor__editable {
    min-height: 100px;
  }
</style>

// fullscreen.js

import Plugin from '@ckeditor/ckeditor5-core/src/plugin'
import ButtonView from '@ckeditor/ckeditor5-ui/src/button/buttonview'

import 'style.css'

export default class FullScreen extends Plugin {
  init() {
    const editor = this.editor

    editor.ui.componentFactory.add('fullScreen', (locale) => {
      const view = new ButtonView(locale)
      let state = 0
      view.set({
        label: 'Fullscreen',
        withText: true,
        tooltip: true,
      })

      view.on('execute', () => {
        if (state == 1) {
          editor.sourceElement.nextElementSibling.removeAttribute('id')
          document.body.removeAttribute('id')
          view.set({
            label: 'Fullscreen',
            withText: true,
            tooltip: true,
          })
          state = 0
        } else {
          editor.sourceElement.nextElementSibling.setAttribute(
            'id',
            'fullscreeneditor'
          )
          document.body.setAttribute('id', 'fullscreenoverlay')
          view.set({
            label: 'Normal Size',
            withText: true,
            tooltip: true,
          })
          state = 1
        }
      })

      return view
    })
  }
}

// style.css

#fullscreenoverlay {
  overflow: hidden;
}

#fullscreeneditor {
  position: fixed !important;
  top: 0;
  left: 0;
  right: 0;
  bottom: 0;
  z-index: 10000;
}

#fullscreeneditor
  .ck-editor__editable.ck-rounded-corners.ck-editor__editable_inline,
#fullscreeneditor .ck.ck-editor__main {
  height: 100%;
}

[ssougnez]

I created my own plugin to do so but still, I think that this should be part of core plugins maintained by the CKEditor tool.

[Witoso]

@ssougnez thanks for the comments! Yes, this is in our plans but I don't have a specific ETA yet. Interestingly, this is actually a quite tricky feature to develop as we don't know everything about the surroundings of the editor, and at the same time, we need to make it pretty generic.

[ssougnez]

In the plugin I created, I did it like this:

For the style, I used a position "fixed". This way, the surrounding of the editor should not matter very much as this removes it from the normal flow of the document. The other overrides are mainly cosmetic and maybe the CSS in the post above works better than what's below (but the goal was to leave other HTML element than CKEditor's one untouched):

.ck-editor.ck-editor__fs {
    position: fixed !important;
    top: 0;
    bottom: 0;
    left: 0;
    right: 0;
    display: flex;
    flex-direction: column;

    .ck-editor__top {
        border-bottom: 1px solid var(--ck-color-toolbar-border);
    }

    .ck-editor__main {
        flex-grow: 1;
        overflow: auto;
    }

    .ck-content {
        border-top: 0;
    }
}

And for the Typescript:

this.editor.ui.componentFactory.add('timestamp', () => {
    const button = new ButtonView();

    button.set({
        ...
    });

    button.on('execute', () => {
        if (element) {
            if (element.classList.contains('ck-editor__fs')) {
                element.classList.remove('ck-editor__fs');
            }
            else {
                element.classList.add('ck-editor__fs')
            }
        }
    })

    return button;
});

I don't have much expertise with ckeditor but does it need to be more complicated than this?

[bskibinski]

I would recommend to start "quick and easy", you will probably see a surge of people requesting this feature because of Drupal 10 migration coming month.

There are a 1000 use-cases you could try to cover in one go, but just start with a 'simple' "position fixed, z-index over 9000, width/height 100%" kinda solution :) you'll probably have over 80% coverage of use cases. Then it's easier to gather any bug reports, and if it's actually worth the effort to support iphone mobile screens or not. The fullscreen api is not meant for this, you don't want to hijack the start bar or other things.

A lot of people have small screens, and admin environments make the ckeditor fields even smaller, they just want a bit more space. The 'max-width text-length' problem should be addressed by your own custom CSS, set a max-width that approximates your site.

The municipalities of the Netherlands will be gratefull for this plugin! ;-)

[Witoso]

We are very unlikely to introduce "quick and easy" (and dirty :wink:). We need to be thoughtful of integrators implementing the editor in various environments, and sticking to a specific version for years, in an ever-changing browser/js environments.

That said, for Drupal, as this is a known platform, we actually provide a Full-screen plugin as a part of our premium module. It is free-to-use! :)

[pikulinpw]

Following the discussion about the feature to maximize the editor to full screen, I developed a plugin that solves this problem. I would appreciate it if you tried it and share your experience using it. Any additions, suggestions or questions are welcome. Your feedback will help make the plugin even better!

https://github.com/pikulinpw/ckeditor5-fullscreen

[queenielow]

Following

[Jeff-Tian]

Now it's 2024. Do we have updates on the (full screen/maximize) feature (officially)?

I am using https://github.com/ckeditor/strapi-plugin-ckeditor inside the strapi CMS, a custom field. Although it's automatically growing in height, the width is too narrow. The fullscreen/maximize helps when writing stuff.

[sathya2015]

We are using ckeditor5 that came with DLL compatible packages in PeopleSoft, Hope to see this Maximize/full screen option in core plugins. Any help on how to implement the plug-ins where dll builds are used.