I tried wysiwyg with markitup editor but it does not have the same size as original textarea. Check the screenshots
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | markitup.patch | 645 bytes | nquocbao |
| #1 | markitup.png | 12.43 KB | nquocbao |
| #1 | no-editor.png | 5.43 KB | nquocbao |
I tried wysiwyg with markitup editor but it does not have the same size as original textarea. Check the screenshots
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | markitup.patch | 645 bytes | nquocbao |
| #1 | markitup.png | 12.43 KB | nquocbao |
| #1 | no-editor.png | 5.43 KB | nquocbao |
Comments
Comment #1
nquocbao commentedComment #2
nquocbao commentedComment #3
nquocbao commentedHere is how i fix it
Comment #4
nquocbao commentedComment #5
twodPatch looks good. =)
Maybe we should store the original
.css('width/height')values somewhere (like in Drupal.wysiwyg.instances[fieldId]) and restore those on detach? Probably a minor issue is it just overwrites the style with the computed style, but it does this "inline".Comment #6
sunHm. In reality, this is caused by your theme.
In another reality, this is caused by a ugly .resizable-textareas implementation in D6, which we just recently fixed for D7: #735628: Resizable textarea behavior leads to unpredictable results
Short version: Drupal core and most themes only define sane styles for the resizable textarea, but not for a plain textarea. You therefore get the width of the defined 'cols'. Um, as you'd expect ;)
I'm not sure whether we want to fix this bug this way, or rather introduce a global
in wysiwyg.css.
The latter, one could at least override in a theme's stylesheet.
I can see that people identify this as a bug in Wysiwyg, but I'm not sure whether any of the above solution attempts doesn't add more presumptions and burden on themers than we like to.
Comment #7
nquocbao commented@sun: So how we can fix it ? Or should we keep the width & height for markitup and restore it on detach, as TwoD suggestion ?
Comment #9
twodThe patch in #3 no longer applies cleanly and I would normally have rerolled it, but since markItUp's skin stylesheet (style.css) is now properly included in D7 (conflicts with other stylesheets in D6), I noticed something that might change how we think about this issue.
It turns out that markItUp itself doesn't calculate the width of the editing area at all, it leaves it up to its skin to set the size. All the markItUp script cares about is changing the height when dragging its own grippie.
If we're to force markItUp to be the same width as the original textarea (thus overriding its skin's styling), resizing the original textarea isn't enough. In fact, the original textarea is used by the editor for the editing area, which is why forcing its size to a static pixel width makes it bigger, but the editor's header, toolbar and footer are still fixed to 700px (or whatever the skin says).
Because at least Seven (didn't check the other themes) now sets a 100% width on the textarea, it'll automatically resize to whatever with the editor skin says too.
So, shouldn't we make this a "won't fix" and advice people to change the editor size it by using a different skin or overriding it in their Drupal theme's stylesheet?
The Drupal grippie seems to agree, it doesn't want to stay the same width as the textarea after detaching the editor when this patch is used...
Comment #10
Encarte commentedsubscribe
Comment #11
sunComment #12
mgifford