Ckeditor5: WebComponent for CKEditor 5

Created on 24 Jan 2019  ·  11Comments  ·  Source: ckeditor/ckeditor5

Let's ship every build as a web component 💛

  • [ ] Shadow DOM support

    Ability to close the editor in a shadow DOM would greatly improve its integrity by scoping its styles. However, this requires some changes:

  • [ ] The body UI collection (https://github.com/ckeditor/ckeditor5/issues/1478)

    The so-called "body collection" is where we keep floating panels (so they are not trimmed by overflowed parents and are easier to position). It's automatically created in the <body> element. If we'd enclose CKEditor in a <ck-editor>, we should not leak from this element, hence we need to give the developer some control over where this collection is rendered.

  • [ ] Naming (<ck-editor> or <ckeditor-classic> or ?)

    The name must contain the - character 😿 Also, there may be multiple editor types on one page, so <ckeditor-*> seems natural. Or not?

  • [ ] Should every editor build expose a web component by default?

    For once, it would be cool that you can use ClassicEditor.create() or <ckeditor-classic> after importing @ckeditor/ckeditor5-build-classic into your page.

    However, I'm not sure how much additional code will the componentization of CKEditor require. I hope it won't increase the final size that much because we'd have to consider having two files in each build (ckeditor.js and e.g. ckeditor.webcomponent.js).

  • [ ] How to componentize specific types of editors. It's fairly easy with the classic editor, but gets more tricky with the inline/balloon editors and super tricky with the decoupled editor. Most likely, we should keep it as consistent with the React/Angular/Vue components as possible.
  • [ ] How to make the editor configurable (pass the config object).
  • [ ] How to build CSS for web components. This may be a blocker for having one build for normal and component use.

If you'd like to see the support for web components, please react with ❤️ .

feature

Most helpful comment

Hi there! What's the latest thinking on this issue?

I’ve been working on a project to wrap open-source UI widgets into web components, and I’m interested in potentially creating a CKEditor web component, or at least try to help move the process along.

It seems like getting the theme from the .css file to work with shadow DOM is going to be one of the more challenging tasks, since the styles inserted by the webpack style loader won’t get applied to any shadow DOM elements. I’m not very familiar with CKEditor’s build system or webpack in general, but perhaps there could be a loader that creates multiple entrypoints -- one that loads styles into the main document (as the loader does now) and one that doesn’t, which would be used for styling shadow DOM.

Would anyone here be able to provide more insight on this issue?

All 11 comments

cc @Comandeer @oleq @pjasiun

There is something called The Gold Standard, containing many of the best practices around creating maintainable Web Components. It can help in choosing the right way.

Shadow DOM support

I'm wondering if it wouldn't be better to have multiple, nested Shadow DOMs. Something like that:

|
| -- #shadow-root
     |
     | -- UI component
     |    |
     |    | -- #shadow-root
     |
     | -- editable
          |
          | -- #shadow-root

This way we have encapsulation on every possible level.

How to make the editor configurable (pass the config object)

WCs should be generally configurable via attributes (just like React components and native DOM elements). IMO it would be nice to break config object into many observed attributes, but at the same time – add config property to the component (just like native DOM elements: attributes vs properties, e.g. [class] attribute vs classList property).

  • Should every editor build expose a web component by default?

I think yes. Each editor may have different properties/attributes as you mentioned already. On the other hand, I agree it would be nice to make it similar to the react integration.

I added one point to the list:

  • How to build CSS for web components. This may be a blocker for having one build for normal and component use.

Would this feature include support for Web Components in the editor, too?

I'm trying to edit a WC in the editor and finding an issue with the cursor disappearing. It's a basic WC with slotted text. It works perfectly in the editor until I attach the Shadow DOM. Then, I find that the cursor disappears once I delete the text inside the WC, and I can no longer edit the document.

I've set up a demo and described the bug in #5724.

Is this something that should work in the the current version (v15.0.0)? If not, +1 for future support 😄

@danielamorse, I created a separate ticket for editing web components inside the editor: https://github.com/ckeditor/ckeditor5/issues/5740.

@Reinmar IS ckeditor5 compatible with lit-element? I have faced the issue that the style of ckeditor toolbar is not applied when I call ClassicEditor.create() to create a rich editor.

image

We never tested it with lit-element. I guess as long as there's no support for webcomponents in general, lit-element will not be supported as well.

Ah sad, was about to integrate with a web component (LitElement). Any workarounds to make this work?

I guess one way is to make CKEditor render in Light DOM and slot all the way into Shadow DOM.

Hi there! What's the latest thinking on this issue?

I’ve been working on a project to wrap open-source UI widgets into web components, and I’m interested in potentially creating a CKEditor web component, or at least try to help move the process along.

It seems like getting the theme from the .css file to work with shadow DOM is going to be one of the more challenging tasks, since the styles inserted by the webpack style loader won’t get applied to any shadow DOM elements. I’m not very familiar with CKEditor’s build system or webpack in general, but perhaps there could be a loader that creates multiple entrypoints -- one that loads styles into the main document (as the loader does now) and one that doesn’t, which would be used for styling shadow DOM.

Would anyone here be able to provide more insight on this issue?

@ywsang i'm working on chrome extension project and i used CKEditor 5-react for text editor. Now i'm using shadow dom to avoid website and extension css conflict.
At injecting styles into ckeditor's element or parent element is bit more difficult(not going to use impossible word) using webpack.
So to solve this problem i'm injecting style tag into shadow dom. It is look like this

Screenshot from 2020-12-09 19-01-34

I achieved this by creating style element in shadow root of selected element and appending style tag to that shadow root, some thing like this

let extensionRoot = document.getElementById('extension-div');
if (extensionRoot) {
    // Create the shadow root
    const shadowRoot = extensionRoot.shadowRoot;

    if (shadowRoot) {
        app = shadowRoot.getElementById('my-extension-root-flip');
        if (!app) {
            // Create a div element
            app = document.createElement('div');
            app.setAttribute('id', 'my-extension-root-flip');

            const ckStyle1 = document.createElement('style');
            ckStyle1.textContent = ckEditor1;

                        // Append div to shadow DOM
                        shadowRoot.appendChild(app);
            extensionRoot.shadowRoot.appendChild(style1);
        }
    }
}

I think this might will work.

Thanks

Was this page helpful?
0 / 5 - 0 ratings