Is there a onPaste callback or equivalent to remove styling that's been copy and pasted?
For example, if I copy a paragraph from x-website and paste it in the editor, the color/font/etc is pasted n as well. Would be good to have a callback to remove styling from copy/pasted text.
Quill 1.0 will feature a PasteManager of sorts that will make it very straightforward to support the exact scenario you are looking for.
Until then in Quill v0.20.1, I suspect your best bet is to subscribe to event 'text-change' which will happen after the paste and you will get the pasted delta from which you can create a new delta and apply it to the editor that both removes the incoming delta and applies a delta with removed formatting. Non-trivial I know...
Okay, def not going to re-invent the wheel here. Not even sure what "deltas" are. I'm not familiar with this library. When is 1.0 coming in beta?
Deltas are lists of operations, built using rich-text. For your use, here, you'd probably just want to accept the delta, look at the ops attribute (an array of operation objects), and strip out the attributes on each operation that would apply the nonsense you don't want.
Interesting. Would you have any code you've used that I could play with?
I like that approach Scott, slightly simpler than what I was originally suggesting.
I guess the question is how would you know that the edit was in-fact a paste as opposed to the user just applying styling via the editor? I imagine both would have source = user so not sure how to distinguish.
Yeah, that's my question as well, with I was about to ask. Messing about with deltas...seems text-change fires for each key press.
if insert length is > 1? Seems a bit hacky though.
You might be able to get away with a hack like that, but the text-change event isn't technically called on each character the user types. Instead it's effectively polling the DOM for changes, defined by pollInterval configuration (default 100ms). Config details here: http://quilljs.com/docs/configuration/. So you could end up with user typing in the editor that's greater than length 1 but not a paste.
I see. Good point. I just tested and you're right. it can pick up 2 characters when I "speed typed".
...hmm.
Scratch that, even more if I hit multiple keys at once. I got up to 4.
I suppose I'm assuming that your quill wouldn't be leveraging style attribute stuff to apply formats (leaning more heavily on blots and class attributors). If you know your formats all tie to a class or element or so on, you can then assume that any op with attributes.style are coming from external paste.
No, my quill would include VERY basic styling; bold/italic/strikethrough/highlights/colors, etc. Fonts, size, and any other styling copied from a paste of another site - wouldn't work.
If you're using a specific, known set of colors/highlight colors, you could get away with all of that styling using only classes and elements (.strikethrough, <strong> etc), which would make your life much easier. Otherwise, I would look into what your ops actually contain on paste from external sites and what your formatting applies to an op, and then code your way from there. Hopefully it doesn't result in string manipulation nonsense if it doesn't have to.
An alternative is to pull from the develop branch and utilize the new clipboard to parse out styles from external markup.
Thanks, appreciate it. Let me see what I can whip up. Otherwise, back over to TinyMCE I go 馃憥 :(
Curious Scott, are you already working against Quill 1.0 develop branch for your projects?
@mbarwick83 Boo TinyMCE!!! ;)
I know, I know...
@sachinrekhi Yes, for our project we're working with quill on develop. Just finished a quill module that accepts incoming content pastes from known external content providers and converts them to their equivalent markup/styling/attributes/blots in Quill. Pasting Medium and getting the right formats in a specific way, not merely relying on Quill's very accurate coercion.
Also seconding the Boo TinyMCE.
@scottsheffield Sweet! So the new clipboard feature in develop isn't sufficient for your need because you don't want an exact translation, but want to coerce very specifically for your use-case?
BTW how stable is develop feeling? Debating when to take the plunge to start working against it as opposed to v0.20.1
The difference between Quill's default clipboard behavior and my extension of that behavior (note, my module is fully dependent on Quill's clipboard), is just that it allows me to get specific.
Clipboard looks at the entirety of the node that is incoming (say, Medium's Primary Heading <h3 name="bfc3" class="graf--h3">Primary Heading</h3>), and then uses every bit of information available on that node to try and coerce it to the proper blot. In vanilla quill, this means it becomes a Header blot with an H3 node, dropping the name and class, and adding an ID generated from the content (functionality courtesy of the Header blot), resulting in this markup: <h3 id="primary-heading">Primary Heading</h3>
But since I know Medium uses an H3 to represent a Primary Heading, and I know I use an H2 for Primary Headings, my module matches the Medium H3 (.graf--h3), and then applies my PrimaryHeading blot to that operation (PrimaryHeading is a simple Block extension that uses H2 for blot.tagName and doesn't add an ID based on the content), resulting in this markup: <h2>Primary Heading</h2>, which looks like a primary heading in my editor, making the paste from Medium to Quill result in markup that looks like you wrote it in Quill originally.
@sachinrekhi - As for Quill develop's stability, I obviously find it stable enough to work on and work with extensively, but feel free to judge for yourself.
Looks like this has been adequately answered--thanks for the help @scottsheffield and @sachinrekhi
maybe, ctrl+shift+v could help u
For future reference, I found the answer to this question here: https://github.com/quilljs/quill/issues/1184#issuecomment-384935594