Do you have any plans to support creating ProseMirror instances in a shadow DOM root so it can be used in web components that use shadow DOM? I had a stab at modifying the source to see if I could get it partially working myself to try to come up with a proof of concept but failed at the point of working out how to fix event targeting. My Javascript-foo isn’t really up to it. For the time being I’m re-writing the rest of my components to not use the shadow DOM instead which is a shame but I’ve hit a time wall and have to deliver, but it would be interesting to know if you have any plans in this direction.
There shouldn’t be a lot needed to make things work inside a shadow dom. One issue I can think of is that DOMNode.contains doesn’t see through shadow DOMs, so the call in the flush method in edit/main.js is likely to cause problems. This is something I’d be interested in supporting, but I’m not testing against it at the moment and have other priorities.
currently we use Quilljs as our editor in our Polymer 1 based app. We are going to migrate to Polymer 2 with Shadow DOM v1. But this is causing major issues with the Quill editor. But the Quill maintainers are not really keen to support Shadow DOM.
A WYSIWYG Editor is very critical for our app and I am looking for alternatives. I was seeing some effort in your side to support it. And the ProseMirror architecture seems to be much cleaner and more extensible to me! I also appreciate the TypeScript typings for the ProseMirror packages!
So what I would like to evaluate is how one could implement a EditorView which takes care of the different environments it runs in. Shady DOM, Shadow DOM and without.
In general we would need to abstract the reading and setting the selection on the document, on a shadowRoot and shadyRoot using the official webcomponents polyfills. And maybe take care of of the MutationObserver changes within a WebCompinent shadow root.
I checked many editors and non of them is supporting Shadow DOM so far. I think that this would give this editor much more attention.
I wanted to ask you about your priorities on this topic.
I think the only significant obstacle to using ProseMirror in shadow DOM at this point is that selection management in Safari’s shadow DOM is kind of broken (see this issue). Other than that, the editor should be usable.
Is Shadow DOM support expected to be fully functional at this point? In my (admittedly limited) testing, I’m not having any issues in Chrome, but in IE 11 I get the following error when moving the cursor in the view:
Object doesn’t support property or method ‘elementFromPoint’
Shadow DOM support is indeed supposed to work. Looks like the polyfill doesn’t implement elementFromPoint on ShadowRoot. That’s not really a ProseMirror problem, though. Adding a method that just forwards the call to document.elementFromPoint should be easy (either monkey-patch it, or create a PR to your polyfill library).
Hi Marijn!
I’m having an issue with Marks that contain shadowRoot in StencilJS.
I have an input that will add an error-tooltip custom element, with shadowRoot, to highlight syntax errors.
When trying to select text, if the selection starts within the shadowRoot, I can’t escape its boundaries, and can only select the text within the custom element. Similarly, I can’t partially select the text inside it, I either select the whole thing or the selection stops at the beginning of the element.
Any ideas of why this could be happening?
I don’t think custom elements with shadow roots for marks or regular nodes with content is likely to ever work (if that’s what you’re doing). Using such elements in widget decorations or entirely custom node views without content should work, but I don’t expect contenteditable-across-shadow-boundaries to be something that browsers will do.
This time, I’m noticing that ProseMirror seems to be quietly broken when used within a shadow root in Safari. I’m not sure if it’s the same issue as before, as I’m no longer seeing any errors in the console.
Instead, we have this situation where the cursor is moved to the end of the document, seemingly any time the document state changes:
I had tried using a shadow dom last year and ended up abandoning it because I was hitting issues particularly with Safari. I think what you’re hitting is just an issue with getSelection not really being supported on browsers like Safari within a shadow dom. Take a look at this discussion.
Yeah that does seem likely. I’m not sure if there’s any way to get a selection within a shadow root in Safari If that’s the case, I guess there’s not much that can be done.
We did decide not to use the shadow DOM in our component, but as I said there’s nothing stopping our consumers from putting the component in a shadow root as part of their own compositions. Stinks.
If that’s the case, I guess there’s not much that can be done.