webcomponentsjs and contenteditable divs - workarounds?

[Eric Eslinger]

Hey folks,

I know that the full webcomponents.js polyfill for shadow DOM currently breaks contenteditable divs [1]. This was something I kind of glossed over when first architecting stuff, but it's clearly the case.

My specific problem is the interaction between the polyfill and the quill.js [2] rich text editor. I love quill on principle- it uses a non-HTML internal representation and is amenable to an OT-based multi-editor realtime approach. There don't seem to be any other rich text editors on the market that even come close to quill's delta representation (if anyone has any suggestions, I'm all ears).

My choices now seem to be:

1) implement some kind of iframe isolation booth for quill and handle passing events into and out of the iframe. I *think* this will work, and that the runtime environement that quill experiences inside the iframe will not be polyfilled, and therefore the execCommand function will work properly.

2) move from polymer 0.5 and the shadow dom to polymer 1.0 and the local dom. This works nicely and quill runs in a local dom world, but breaks Angular integration.

3) move from polymer 0.5 to some other front-end UI framework (probably angular-material). If I'm going from the 0.5 polymer and components libraries to polymer 1.0, there's already a lot of work in re-naming elements, tweaking styles, and so forth.

4) Hope there's a webcomponents 0.8 release that fixes execCommand in the full shadow DOM polyfill.

5) some other workaround that I hadn't thought of, and is why I'm writing this email.

Right now the app runs fine in all browsers, and it looks fine everywhere. That is to say, it runs fine in all browsers, except that editing doesn't work. You can type in the contenteditable div that Quill makes, but you can't use the toolbar to style things and the backspace key doesn't work. Under the 0.5 wc library even that didn't work, but the createTreeWalker update in 0.6 helped some things.

So, have other people run into these issues? If so, what approaches to using rich-text editors in a webcomponents environment are you using?

Eric

[1]: https://github.com/webcomponents/webcomponentsjs/issues/212

[2]: http://quilljs.com/

[tda...@ourfuture.org]

This issue is literally making me crazy.  Yes.  I have no CLUE how to fix it.

[Eric Bidelman]

On Mon, Aug 17, 2015 at 8:53 AM <tda...@ourfuture.org> wrote:

This issue is literally making me crazy.  Yes.  I have no CLUE how to fix it.

On Wednesday, June 3, 2015 at 11:53:24 AM UTC-4, Eric Eslinger wrote:

Hey folks,

I know that the full webcomponents.js polyfill for shadow DOM currently breaks contenteditable divs [1]. This was something I kind of glossed over when first architecting stuff, but it's clearly the case.

My specific problem is the interaction between the polyfill and the quill.js [2] rich text editor. I love quill on principle- it uses a non-HTML internal representation and is amenable to an OT-based multi-editor realtime approach. There don't seem to be any other rich text editors on the market that even come close to quill's delta representation (if anyone has any suggestions, I'm all ears).

My choices now seem to be:

1) implement some kind of iframe isolation booth for quill and handle passing events into and out of the iframe. I *think* this will work, and that the runtime environement that quill experiences inside the iframe will not be polyfilled, and therefore the execCommand function will work properly.

2) move from polymer 0.5 and the shadow dom to polymer 1.0 and the local dom. This works nicely and quill runs in a local dom world, but breaks Angular integration.

Can you explain more where things break? +Steve Orvell has been doing some experiments with Angular/framework interop and 1.0's Shady DOM. That might help here.

 

3) move from polymer 0.5 to some other front-end UI framework (probably angular-material). If I'm going from the 0.5 polymer and components libraries to polymer 1.0, there's already a lot of work in re-naming elements, tweaking styles, and so forth.

4) Hope there's a webcomponents 0.8 release that fixes execCommand in the full shadow DOM polyfill.

5) some other workaround that I hadn't thought of, and is why I'm writing this email.

Right now the app runs fine in all browsers, and it looks fine everywhere. That is to say, it runs fine in all browsers, except that editing doesn't work. You can type in the contenteditable div that Quill makes, but you can't use the toolbar to style things and the backspace key doesn't work. Under the 0.5 wc library even that didn't work, but the createTreeWalker update in 0.6 helped some things.

So, have other people run into these issues? If so, what approaches to using rich-text editors in a webcomponents environment are you using?

Eric

[1]: https://github.com/webcomponents/webcomponentsjs/issues/212

[2]: http://quilljs.com/

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/f1d7d634-eeff-4f4a-a5fa-fa428af24841%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Eslinger]

The last set of experiments I ran was with angular 1.3 and polymer 0.9 in shady DOM mode. In particular, when I had ng-repeats of polymer elements, the polymer elements did not behave properly (styling and some events weren't working right). I assumed this was because ng-repeat uses jqLite's prepend / after calls for DOM manipulation (in the enter() method on the animate service, which seems to be where all the actual DOM manipulation is done in angular). 

If this had some customization hooks so I could use the Polymer.dom interface instead, it'd work. But from where I sit, requiring Polymer.dom calls to interact with shady DOM instead of using the default DOM api means that any other library I use for DOM manipulation (angular, ember, whatever) won't work if the stuff I'm adding / subtracting has a shady dom.

This kind of breaks the best part of webcomponents - it's no longer just the DOM that you're working with, so it's not compatible with other libraries out of the box.

e

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CACGqRCBAtKHqh_VSD1NPGU8Q_p2YWZkGRqLeO5Lp%2BHYYmaBN%2Bg%40mail.gmail.com.

[Eric Bidelman]

On Mon, Aug 17, 2015 at 10:40 AM Eric Eslinger <eric.e...@gmail.com> wrote:

The last set of experiments I ran was with angular 1.3 and polymer 0.9 in shady DOM mode. In particular, when I had ng-repeats of polymer elements, the polymer elements did not behave properly (styling and some events weren't working right). I assumed this was because ng-repeat uses jqLite's prepend / after calls for DOM manipulation (in the enter() method on the animate service, which seems to be where all the actual DOM manipulation is done in angular). 

If this had some customization hooks so I could use the Polymer.dom interface instead, it'd work. But from where I sit, requiring Polymer.dom calls to interact with shady DOM instead of using the default DOM api means that any other library I use for DOM manipulation (angular, ember, whatever) won't work if the stuff I'm adding / subtracting has a shady dom.

The dom-patch experiment does exactly this. It patches the native DOM APIs to provide interop with frameworks that do this type of manipulation.

I'm not up to speed with its readiness, but you're free to give it a try.

 

This kind of breaks the best part of webcomponents - it's no longer just the DOM that you're working with, so it's not compatible with other libraries out of the box.

Another reason we need shadow dom in more browsers :\

[Eric Eslinger]

Hmm, I'll take a look at the experiment. For my day job project however, we had to move off of polymer - the cost of porting from 0.5 to 1.0 was high enough to warrant looking at other frameworks for UI stuff like modals and side drawers and suchlike, and the angular workarounds were complicated enough to make ngMaterial really tempting (eight months ago, when we first took up Polymer, ngMaterial looked promising but was still mostly a proof-of-concept, IMO).

I do agree that the real win here will be a fully-compliant shadow dom implementation in all major browsers. /stare iOS. Get on it, apple; having a nice modular way to import UI dependencies will help everybody.

e