Just Not Working

[jg314]

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:

<style>
  textarea {
    overflow: hidden;
  }
</style>

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.0/jquery.min.js"></script>
<script src="js/expanding.js"></script>

<textarea id="textarea" class="expanding" placeholder="This is some placeholder text"></textarea>

Thanks.

[bgrins]

Is it not working for you on this JSFiddle? http://jsfiddle.net/bgrins/pmXxK/

[jg314]

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.

[bgrins]

Interesting, it is an error when no width is specified. Check out the style tag on this updated link: http://jsfiddle.net/bgrins/pmXxK/1/. I'm guessing this one will work for you, but it should definitely be working for you with the original markup.

[jg314]

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.

[bgrins]

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:

1. There might be a solution that involved copying the width over on every change (in the resize event).
2. The other option is to make the width of the textarea (inside expandingText) to be 100% (along with border-box sizing to account for paddings and borders). This would make it match the textareaClone in width, but may cause unexpected results if the textarea had a width set on it originally.

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)

[bgrins]

Here is a sample with the width being included in cloneCSSProperties - it seems to work for your case

http://jsfiddle.net/bgrins/pmXxK/3/

[jg314]

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.

[bgrins]

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 pre, and set it's width to the outerWidth of the textarea (which also has border-box sizing now)

[jg314]

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?

[bgrins]

That's what I though too, but I think it is a bug because of the box-sizing on the textarea, width(). See this version for a demo: http://jsfiddle.net/bgrins/pmXxK/8/

[bgrins]

What is really interesting is the way the position:absolute interacts when there is a margin-top on the pre. See this example: http://jsfiddle.net/bgrins/pmXxK/10/. The position: absolute textarea doesn't start until after the margin on the pre ends (at least in WebKit). This seems like it could cause some issues, but I guess it is working fine in the demo. Haven't checked browsers other than Chrome yet

[bgrins]

I notice you are right about the width/outerWidth thing in Firefox (though IE seems to follow the behavior on Chrome)

[jg314]

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.

[bgrins]

The only issue with content-box is that if the height is set to 100% on the textarea, it ends up taking extra space if padding/margin/border is set. See the example here: http://jsfiddle.net/bgrins/pmXxK/12/.

Or even here with just borders/paddings (since margins seem to cause a lot of other weirdness): http://jsfiddle.net/bgrins/pmXxK/13/

[bgrins]

btw, if you can send over a pull request with your wordBreak fix, I'd be happy to merge it in.

[jg314]

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

[bgrins]

Closing this as it has been broken into Issues #15 and #16