-
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
Paste results in span tags, with weird style attributes #534
Comments
I think this is related to #533, theres some odd things in pasting that didn't happen in our pre-release but do happen now :( |
I know the feeling :( Hey but if you wanna know where your work is being used, it'll be up on www.branded.me soon :) Awesome work btw. |
Ah, I remember this now, it's a side effect of copying HTML in browsers, specifically Chrome/Webkit. <p style="box-sizing: border-box; margin: 0px 0px 10px; color: rgb(85, 85, 85); font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 20px; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);"><b style="box-sizing: border-box; font-weight: 700;">... Which is kinda understandable, but really annoying. 90% of that is stripped by the sanitizer, the others are allowed through but basically what it is is all the stylings present on that element, so when you paste it it looks the same. I don't think I can actually fix this unless I say that styles do not copy/paste over as there's no way of telling the difference between styles set by the user or styles set by chrome. I'm going to tag everyone whose been involved with pasting so I can get a collective opinion on it (Next Comment). Nice site, it's always cool to know where it's being used, maybe I should setup some sort of "This is used here..." list sometime. |
Sorry all for the mass ping, I've tagged a bunch of people as I need a bit of an opinion and you've all influenced the paste process as it currently stands in v1.3.0 +. Situation in brief is that current copy-paste of HTML mainly in Webkit browsers (Haven't checked others yet but I think it's the same) brings across lot's of unnecessary style attributes due to the copy. Short example: Copy The sanitiser is generally good at stripping these out, except as we start letting some through like color they start showing up in the paste. Due to not being able to reliably test whether a style has been set by chrome or the user the two options are:
I think option 2 is probably the best but I'd rather get a sense of what everyone else thinks before I go ahead and change something like this which could adversely affect people. Thanks in advance for your help! @barathank @realdigid @DBounds (#471) @kaiqigong @anitin @diagramatics @rahul-sekhar @edouard-lopez |
I feel bad for not even contributing or responding to anything after my issue. I'll try and help in any way I can. This copy-pasting issue seems very complex and rely heavily on how browsers implement copy and paste, and this gets more complex if you're dealing with contenteditable elements. So I crosschecked the behavior as much as I could and it seemed like the whole feature needs a better, rugged implementation than a simple contenteditable div. I tested it on http://textangular.com with the predefined text mostly, using Ctrl+A when I want to get the whole text. Here's what I can pick up.
There are also some strange behaviors during my test that had happened one or two times and after that I wasn't able to replicate at all. In short, there is little guarantee of the browsers being able to parse the HTML correctly, yet even managing to keep a standard to work together, cross-browsers or even working on only one. All of that, I suspect are from the lack of standard on contenteditable elements. If I remember correctly there is no default AngularJS implementation on handling contenteditable as well, and that might be due to the major difference on the behaviors on each browsers. If we opted to not fix the issue (or even fix it) there might be more bugs that are related to the contenteditable behavior. Maybe another option would be like what the other text editor plugins are doing—create a hidden input to capture user inputs, process it, and output to the text editor view. Good luck, hopefully this helps. |
Any way you could provide an option to strip ALL html from the paste? If you point out where this is parsed, I'll do it and make a pull request. This would temporarily solve this problem, anyway, atleast for myself. I'm sure some users of this would like an option to do that too, I've seen it in a few other solutions. |
@diagramatics Thanks for your thoughts and extensive testing!! I never thought of trying to copy-paste between different browsers. In essence our current implementation of copy paste uses this solution: http://stackoverflow.com/a/6804718/1413689. Someone kindly contracted me to add in the ability to paste from word and persist formatting. A side effect of that was the ability to paste HTML with formatting (as word actually sends XML that either is or closely resembles HTML). Using a non-contenteditable input to catch input would make the point moot as then pastes would be without formatting bar newline characters. @samhellawell We could do that, we used to do this as the only option so adding it in shouldn't be too bad. Full Paste Reference taBind.js#L247-L439. FYI this would be such a simpler function if IE supported I think you pointed out what might be the best solution; give options to the paste parsing: text-only, full-html, no-styles (default?). (The latter two would be required for Word paste). |
Ah, that makes sense. I was thinking about how Atom handles its text input when I realised it is not a WYSIWYG editor. I guess sacrifices had to be done, I agree with @samhellawell as well in this situation until a rewrite of the system is needed. P.S: I tried looking for references on how contentEditable works and found this post about how Medium makes their text editor and bashes contentEditable. |
Fixed with release v1.5.2 |
Hey @JoelParke and team, I came across this bug again in version 1.5.12. I get a white background around copy/paste text: color: rgb(77, 77, 77);background-color: rgb(255, 255, 255); Any ideas? |
Same issue here, v1.5.16. Browser: Google Chrome. If I copy and paste any text from any webpage the styling is preserved inline after pasting the text and it overrides my own styles later when rendering with ng-bind-html or ta-bind. |
@bencun we implemented a special handler for taPaste to strip out inline styles. |
@naelshawwa So how am I supposed to go around this issue, I seem to be unable to find anything? EDIT: Oh, I see now what you mean. I guess I'll implement it myself then. If you care to share your handler I'd be grateful. EDIT2: I ended up using this function for taPaste, it removes all inline styles:
I've also applied the modification to the textAngular itself mentioned in #1071 because I also had a bunch of tags when pasting the data which nowhere to be found in source material (html, body, nonexistent br tags) even when only copying and pasting a single word of text. |
When I type text in the editor, then select it and paste back into the editor, it wraps the text in span tags with the set colour and background colour.
The text was updated successfully, but these errors were encountered: