Whizzywig width

If I remember correctly, there's an error in how the editor reads non-fixed css widths. Try setting a fixed width on the original textarea, or was it the field wrapper?

I took a look at the latest version and it first checks originalTextarea.style.width and uses that for the editor width if it's defined. If not, it grabs the value of originalTextarea.cols, appends 'ex' and uses that instead. The code works as it should, but the result is obviously not what one would expect since converting columns to scalable units isn't always that easy.

For the editor to match the textarea size, the width must be set inlined or via .style.width. I think the best way to do this would be to read the textarea's .offsetWidth value and set that as pixels in .style.width before attaching the editor, and revert it to its old value when detaching the editor. I'm too tired to create a patch for this atm but it should be pretty straight forward.

subscribe

subscribe

Patch as per #2 (though using jQuery's methods). Sorry I forgot about this issue.
Note that for Whizzywig 60+ you also need the patch in #753536: The version of Whizzywig could not be detected..

I can verify that this fixes the issue. One thing I noticed is that Whizzywig .61 loads whizzywig-56.js instead of whizzywig.js Should this be the case?

Thanks for testing!

Yes, that is correct. The filename shows the earliest editor-[API]-version supported by that file.

Ok, this does fix the width issue, but there are still things to deal with for Whizzywig versions 60+, and all versions in Webkit browsers (Chrome), but I'll tackle that in another issue.

Committed #5 to all branches.
The fix will be in the -dev snapshots soon, and will also be part of the next stable release.
Thanks for reviewing, testing and commenting!