-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Support Shadow DOM v1 #403
Comments
Any update here on whether this is planned? Shadow DOM will be in every browser except Edge by October. This would be a great feature to have. I see Trix is built with modern browsers in mind, this makes it the perfect library to support webcomponents, unlike all other competitors who don't seem to offer support for it as well. |
This issue has been automatically marked as stale after 90 days of inactivity. It will be closed if no further activity occurs. |
Any updates on this issue. Cannot use trix in Lit web components due to input binding issue. |
Has there been any progress on this issue? We're trying to use this in combination with Lit components too. I managed to get some functionality by re-implementing some bindings (trix-change etc.) myself, but it's not ideal. Still having the permanent 'Insert URL' dialog and can't apply formatting from the toolbar for example. |
Native support for Shadow DOM v1 is hitting browsers, and Polymer v2 was just released. I am requesting support for Shadow DOM as a feature because there are just too many bugs to try to describe. When Trix is placed inside a ShadowRoot, it is broken in many ways.
It is not binding to the hidden input field. This may be due to needing to perform query selectors using the Shadow Root instead of document?
It is not binding to a custom toolbar (probably same issue as above) but with the added fun that now inputing text is displayed right to left (fun).
The native toolbar is not applying selection formatting for bold/italic/subscript correctly. This is probably due to needing to use ShadowRoot.getSelection() rather than document or window getSelection().
Rather than try to have the community try to document and submit what may be a lot of seperate behavior bugs, I suggest that the project team needs to take on the specific task of making all the existing demos/samples and tests work in Shadow DOM and issue a future release with support for Shadow DOM a specific feature.
The text was updated successfully, but these errors were encountered: