Closed zeraphie closed 7 years ago
Hi @zeraphie,
So it looks like what's happening here is that grammarly is modifying the structure of the DOM which is unfortunately a problem for ContentEdit/Tools because it wont know about these changes which is likely to cause side-effects (as we see here).
One option may be to capture blur events against the element using ContentEdit and then look at the state of the element to see if it's been corrupted by grammarly and attempt to fix it. If you rig up a jsfiddle or example site with grammalry and provide instructions to reproduce the issue I'll happily take a look and see if it's possible.
Thing is that I'm using grammarly as a chrome addon, I'm not sure where this issue belongs as well in all honesty, because now that I think about it, should grammarly do the grammar checking on a contenteditable field? or just inputs?
How about that before the save happens, it sanitises the output via a whitelist of tags (stripping just the tag, not the text inside) and removes attributes in prior order to save html? I'll come up with a small something and put it on codepen, see if it works in an isolated way :)
Hi there,
I noticed on one of the projects that I'm using this, that using grammarly interferes with how the editor saves, because grammarly adds a chunk of attributes and an element as well for this... Is there a way of stopping this from happening? I'm not really sure, but maybe escaping all attributes on the elements, in one example I'd had the additional markup actually caused it to automatically save the paragraph as contenteditable so when the page was opened, that particular paragraph was editable? Below is a demo of the markup added