Support for running in shadow DOM #3891
Comments
|
Haha, thanks for creating the issue! Welcome to the wonderful world of Custom Elements and Shadow Dom. Ps, should probably also work with Shady DOM.
|
|
Hey, thanks for bringing this up. We always wanted to make a custom element for CKEditor (not a big deal itself) but we haven't yet worked on it for CKEditor 5 so we didn't notice that shadow DOM is a bigger problem. The fact that shadow DOM has its own selection will require some changes in the engine, but they should be possible to hide beneath the abstraction that we made. I've just thought about one more thing – CKEditor instance is usually represented by two DOM structures – one which holds the editor itself and one which holds floating elements (e.g. balloon panels). If editor will be enclosed in a custom element and shadow root, how to create the other root which needs to be directly in the I hope this isn't very stupid question, cause I haven't played with custom elements and shadow DOM myself :D. |
|
If you have a control over the custom element itself, there is no issue with getting its owner document, so you have full access to the However I'm not sure if it's a good solution to request access to |
Unfortunately, it's a must have that some elements are directly in body. Otherwise, if editor is used in an element with a fixed size and overflow:hidden, the balloons or modals (if we'll ever have any) might render partially invisible. |
|
I was wondering if floating panels should not endup inside yet another custom element created on the fly for that purpose and positioned within body :? But wait, why we need to access body? I have the impression that floating elements will be simply inside the custom element itself. |
See my comment above. They cannot be in the custom element holding the editor itself (which can be wherever in the DOM structure). They must be in a special custom element (or any element in fact) which is always directly in the
That was my idea too. I just wonder whether it should be CKEditor creating that container or a developer. For the convenience, it'd be nice if the editor did that. But is it ok for developers? |
You didn't answer why, though. |
|
I did :P Because they won't be rendered if the editor is in an element which has We had multiple bug reports about this in the past. |
|
Ouch... those creative use cases :)
I think they would be surprised if the editor would not do that. It would be almost transparent to them, anyway. |
|
Or maybe I'm wrong... https://jsfiddle.net/pp7z788w/ Strange. Cause I'm pretty sure there were problems with that. Otherwise, why would CKE4 went this way? Maybe it was some old browser. We should check it. |
|
OK, now it's bad: https://jsfiddle.net/pp7z788w/1/ |
|
And now it's good again ;) https://jsfiddle.net/pp7z788w/2/ Maybe the use of |
|
Heh... let me guess. CKE4 was forced to put floating stuff to the body, because there was no If there's no gotcha with the BTW, @Comandeer, do you know the place in the CSS spec clarifying why position:fixed behaves differently that position:absolute in this case? :D cc @oleq |
Actually it's not that simple. Some mobile browsers had some issues too. But, according to Can I Use? it's safe now (unless we support also Opera Mini). I'm not 100% sure that fixed will be always working fine, but IMO it seems like a good solution. |
If we're able to easily get the position of some elements/caret relative to the true viewport (and I think that this is the default behaviour of most of the DOM methods), then using BTW, there's another DOM structure which may cause issues – we need an BTW2, I wonder how all that would look in case of an inline editor (with a floating toolbar) – like in this one here: http://sdk.ckeditor.com/samples/inline.html. For this case it's hard for me to imagine the custom element application, because you actually want to make an existing, normal element, an editor. |
Look into my demo ;) That normal element could be wrapped into |
Maybe yes, maybe not. The thing is that if some element residing in a dedicated container in If we go with Still, we may put up with performance issues and more complex implementation to maintain, but the real issue I see is Safari in iOS. I researched possibilities to develop a mobile experience in CKEditor5 and the very general conclusion was more or less: "when the software keyboard kicks in Safari in iOS, |
Great point. Doing anything in DOM on scroll is an antipattern AFAIK. We could, of course, debounce it and use CSS transitions for nicer effects but we'd be still doing something on scroll, so a static positioning feels better in this case. |
|
+1 Is there a plan on getting ckeditor to run on shadow dom? We are using ckeditor in our polymer element, it works fine on shady, but not on shadow dom. It would be really great if we can get ckeditor to play nicely with shadow dom. |
|
Not yet. We haven't researched it so neither we know how hard will it be nor have we seen much interest on that (I guess that this is because it's still a Blink-only feature or so at least Can I use says so). Also, a thing which worries me is that there's a high probability that contentEditable will behave differently in different browsers' implementations of shadow DOM (once they get there). I'm afraid that for a looong time this would become an experimental feature – not really something that you can really rely on. Anyway, the first things to figure out are:
Any help with these aspects might help speed up development of this feature. |
|
@Reinmar Just a quick mention. You've linked to the V0 spec, the actual spec to be implemented is the V1 spec: http://caniuse.com/#feat=shadowdomv1 I think a wysiwyg editor is the perfect example of a custom element that should be running in shadow DOM. Just drop in a If you really want to, you can even create a custom element without shadow dom and do everything in the light (normal) DOM. That might solve some issues. |
|
@Reinmar To help illlustrate the differences between the different doms, I have created a testbed for hoisting ckeditor5 into the shadow dom (via polymer), shady dom, and normal dom here: https://github.com/chrisekelley/polymer-ckeditor5 |
|
Just an FYI, there was a PR on tinymce editor repo to add shadow dom support that was merged back in January: |
|
@jay8t6 it was closed back in January without merge. And will require serious rebase in order to be mergeable again, but there is literally no interest from upstream developers despite what they publicly say. |
|
Thanks for the updates! Do you know how stable and consistent is What I'd focus on first is making sure it all works in Chrome and Firefox which support Shadow DOM natively. Does that sound reasonable? |
|
I've managed to get TinyMCE fully working under both WebComponents v0 polyfill and native implementation in Chromium back in 2015. Though, I've reported one or two issues in Chromium (which I believe are fixed already) and sent a few patches to polyfills to fix various edge cases (I have quite an experience fixing various tricky Shadow DOM-related issues over last few years). Things have changed since then, there is v1 polyfill that have significantly reduced number of abstractions. Overall I think it should be in much better shape now. The only caveat might be Safari, I have no idea what its implementation of Shadow DOM looks like. v1 of the spec is considered stable, so Safari, Chromium and Opera should all work fine. If they are not - definitely push upstream developers to fix their stuff. Firefox and Edge are only working with polyfills in stable versions, so at least for nearest half a year you'll need to be able to get it working under polyfills too. Shouldn't be a major issue though. |
|
@nazar-pc bummer! I really thought it was merged. I am in real need for an editor that supports shadow DOM. |
|
Back in December, Safari had totally different implementation of Shadow DOM than Chrome – it lacked Selection on shadow root. Because of that experimental plugin for CKEditor 4 with Shadow DOM support worked only in Chrome. However I haven't raised any issue as I couldn't find any standard stating that selection should be exposed on shadow root. Selection API specification does not mention Shadow DOM at all and in fact it's the only place, where It seems that there is no sense in implementing Shadow DOM in RTEs as long as there isn't even a stable standard to base implementation on. |
|
@Reinmar Hi there! I’ve been working on creating a web component version of CKEditor5, which involves putting the editor inside of shadow DOM. I’ve made a couple changes to the source code that help increase the amount of support for running the editor in the shadow DOM. So far, these changes are related to the editor’s styles (so that the editor looks visually correct when placed inside shadow DOM) and the engine selection issue. I’d love to contribute these changes back to the repo, though they’re not complete fixes for supporting running the editor in shadow DOM (this issue). Would you be open to accepting incremental changes towards this goal that tackle more fine-grained issues? cc: @justinfagnani |
|
Can we consider this in 2022? |
|
Any idea if this will come in 2023? 🤔 |
|
@ralfpatric most likely not, we have not currently set it as a priority. |
|
I reproduced the issue we are facing when adding CKEditor in ShadowDOM I would like to contribute to this issue. What would be the recommended way to setup this test case with ShadowDOM? |
|
I don't want to be the party killer here but the problem with shadow DOM isn't (to our knowledge) really fixable at the moment. It's been a while since we investigated this and AFAICS we failed to share the details here, but all issues except one were rather straightforward to fix. The one issue being: selection handling 😳🤬 There's currently no standardized API to access selection in a shadow root. If there were even different APIs, but somehow compatible, we could somehow resolve this ticket. But nope – it's 2023 and the state is as follows:
When researching this over a year ago we checked crazy hacks that we found. AFAIR, those were in line with: https://github.com/jsturgill/shadow-root-get-selection-polyfill. Unfortunately, our QA team found many instabilities of those hacks. I can share the results if someone's interested, but it really didn't look promising. The thing is – all editor developers are struggling with this unless they are using an I pinged Firefox guys because I can't believe we'll see the spec for this in the next 3 years. If there will be no reaction, I think that we'll consider going with no hacks but also no Firefox support (or hacks to support Firefox, but without aiming at making it super stable). This is depressing but it may be the only choice. |
|
@Reinmar FYI codemirror uses Note: Firefox does not support the newer spec that is concerned about cross shadow root selections – e.g. when you select multiple elements with multiple shadow roots – but for running an editor within one shadow root, the existing API ( Would that be an option for you? With https://bugs.webkit.org/show_bug.cgi?id=163921 being fixed, one should be able to parse selections in the editor's shadow root for chrome, firefox and safari. |
|
With regards
https://github.com/GoogleChromeLabs/shadow-selection-polyfill Sorry i realise that others have already suggested this approach. Looks possible. This is as far as I have got with ckeditor https://stackblitz.com/edit/lit-element-ckeditor5-83vd6t?file=index.js To do the same in tinymce https://codepen.io/twodareis2do/pen/BaMxbYN This is basically what I want to to. Notice how styles are encapsulated in the tiny-mce component. e.g. try adding bootstrap class such as btn btn-primary using the source editor and compare to button out side. |
|
@2dareis2do, thanks for your suggestions! Tiny under the hood is still a wrapper on an iframe, that's why the issues mentioned in this thread are not relevant to them.
|
|
As it looks with the new API from Safari, ShadowDom could now be supported. |
|
Yes, v17 or 17.1 introduced |
|
But FF works with the document API, |
|
FWIW, there are activities and patches in this Firefox ShadowDOM selection issue . |
|
In my designer (https://node-projects.github.io/web-component-designer-demo/index.html) TextEditing in ShadowDom works with the current Firefox Version using the document.getSelection API |
|
I understand, and congrats on your project, but we would like to minimize the special handling around selection to a minimum. I will keep in mind to test the proposed solution, and it's also reassuring that ProseMirror handles it this way. But it will likely not happen before other projects related to installation (#15502). |
|
With #15502 being closed, is there any update you can share on this issue? |
|
We are conducting some internal tests to understand better the current state of the ecosystem in #16975. |
and others
Apparently, shadow DOM has its own selection (like an iframe), so when running in a shadow root, the engine must use that selection.
Welcome to hell...
Add 👍 if you're interested in support for shadow DOM in CKEditor 5.
The text was updated successfully, but these errors were encountered: