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
Just Not Working #14
Comments
Is it not working for you on this JSFiddle? http://jsfiddle.net/bgrins/pmXxK/ |
I'm not too familiar with JSFiddle, but I assume I'm supposed to type into the textarea in the bottom right box. When I do that the textarea doesn't grow in height. This is using a different computer, but the same os and browser. I am running Windows 7 with Google Chrome. Thanks so much for the quick help. I really appreciate it. |
Interesting, it is an error when no width is specified. Check out the |
The problem I'm running into seems to be that textareaClone doesn't seem to have the same width as my textarea. This seems to be the case if I use a pixel width or a percentage on my textarea. What's the reason you don't include 'width' in cloneCSSProperties? I assume if I set the width of texareaClone to match my textarea's width then everything will work correctly. |
You are correct about that. Width is tricky because if the width of the textarea is a percentage, then we would only be copying the value at the time of initialization. There are a couple of possible solutions:
I'm almost leaning towards 1, since it would handle most cases well - we would just need to be careful in the case of a hidden textarea's value being set or something (if the width got reported as 0). If you want to make it work temporarily, I think the solution you proposed should be fine (as long as you don't have a percentage width on the textarea) |
Here is a sample with the |
When you copy over the width at initialization, what would force it to change? Would it change once the other elements are laid out on the page? I really appreciate the explanations and the plugin is great. I ended up adding two array elements to cloneCSSProperties. The first being 'width' and the second being 'word-break'. I was still having issues after I added width. This was caused by a style in Twitter Bootstrap that sets all pre elements to use word-break: break-all. This made words break on two lines, so the heights no longer matched. I haven't tested it cross-browser, but it works in Chrome. Thanks for all the help. I really appreciate it. Let me know if there is anything I can do to help you improve the plugin. |
Here is a test harness for fixing this issue using option 1: http://jsfiddle.net/bgrins/pmXxK/5/. Notice that I have enabled visibility on the |
I don't think you need to pull the outerWidth because you are already using the padding and margin from the textarea. If you use outerWidth instead of width you are double counting the padding and margin. Right? |
That's what I though too, but I think it is a bug because of the |
What is really interesting is the way the position:absolute interacts when there is a margin-top on the |
I notice you are right about the |
I see both problems. I feel like the box-sizing is definitely going to cause cross-browser issues. What about setting the inline style of the box-sizing on the textarea to be content-box? That way all the browsers would be looking at width the same way. |
The only issue with Or even here with just borders/paddings (since margins seem to cause a lot of other weirdness): http://jsfiddle.net/bgrins/pmXxK/13/ |
btw, if you can send over a pull request with your |
The width issue is an interesting one. I ended up setting all the textareas to box-sizing: border-box. If someone uses content-box it will go over 100% width if there are padding and margin, but most people will be using content-box anyways, and should understand how that works. The only time it will be an issue is when someone has used border-box and then all of a sudden the width changes. Maybe that is something you can just put in the readme. It just seems like the plugin is a lot less effective without adding a width to the pre tag. In almost every case I tried it didn't work because the pre tag ended up much wider than the original textarea. I also sent over a pull-request for the addition of word-break. I sent it as 'word-break', which jQuery seems to read fine. Is there a reason you use 'wordBreak' instead? Jonathan |
Is there a problem in the latest commit? I've been trying to get this to work in a basic implementation and it functions like a normal textarea without expanding at all. I've tried it in both Chrome and IE9 with no success. I hope I'm just missing something basic. Here is my code:
Thanks.
The text was updated successfully, but these errors were encountered: