Post Reply 
[req] Resizeable textarea?
Jan. 01, 2009, 08:21 PM
Post: #1
[req] Resizeable textarea?
We have conquer the resizeable flash its time to conquer resizeable textareas.
Add Thank You Quote this message in a reply
Jan. 01, 2009, 09:45 PM
Post: #2
RE: [req] Resizeable textarea?
I found a nice-looking script:

http://www.themaninblue.com/experiment/F...Resizer.js

You can test it here:

http://www.themaninblue.com/experiment/FormTextResizer/

EDIT:

I quickly threw a filter together and modified a modified version of the above script (found here: http://www.joaomak.net/util/textareaResizer/):

Code:
[Patterns]
Name = "Header Top Add: User JS Code - Toggle Textarea Resize {z12 ku} [add]"
Active = TRUE
URL = "$TYPE(htm)"
Limit = 16
Match = "(^(^<ProxHdrTop>))$STOP()"
Replace = "<script type="text/javascript">\r\n"
          "/*    http://www.themaninblue.com/experiment/FormTextResizer/\r\n"
          "    http://www.joaomak.net/util/textareaResizer/\r\n"
          "    With some modifications by Kye-U */\r\n"
          "prxTxtRsz = {\r\n"
          "    formEl: null,\r\n"
          "    adEv: function(t,ev,fn)\r\n"
          "    {\r\n"
          "        if (typeof document.addEventListener != 'undefined')\r\n"
          "        {\r\n"
          "            t.addEventListener(ev,fn,false);\r\n"
          "        }\r\n"
          "        else\r\n"
          "        {\r\n"
          "            t.attachEvent('on' + ev, fn);\r\n"
          "        }\r\n"
          "    },\r\n"
          "    \r\n"
          "    rmEv: function(t,ev,fn)\r\n"
          "    {\r\n"
          "        if (typeof document.removeEventListener != 'undefined')\r\n"
          "        {\r\n"
          "            t.removeEventListener(ev,fn,false);\r\n"
          "        }\r\n"
          "        else\r\n"
          "        {\r\n"
          "            t.detachEvent('on' + ev, fn);\r\n"
          "        }\r\n"
          "    },\r\n"
          "    \r\n"
          "    adBtn: function()\r\n"
          "    {\r\n"
          "        \r\n"
          "        var textareas = document.getElementsByTagName('textarea');\r\n"
          "    \r\n"
          "        for (var i = 0; i < textareas.length; i++)\r\n"
          "        {    \r\n"
          "            var a = document.createElement('a');\r\n"
          "            a.appendChild(document.createTextNode("\\u2195")); // possible values: \\u2194, \\u2195, \\u2198\r\n"
          "            a.style.cursor = 'move';\r\n"
          "            a.className= 'prxResizer'; \r\n"
          "            prxTxtRsz.adEv(a, 'mousedown', prxTxtRsz.initResize);\r\n"
          "            textareas[i].parentNode.appendChild(a);\r\n"
          "        }\r\n"
          "        \r\n"
          "    },\r\n"
          "    \r\n"
          "    initResize: function(event)\r\n"
          "    {\r\n"
          "        if (typeof event == 'undefined')\r\n"
          "        {\r\n"
          "            event = window.event;\r\n"
          "        }\r\n"
          "        if(event.srcElement)var target = event.srcElement.previousSibling.previousSibling;\r\n"
          "        else var target = event.target.previousSibling.previousSibling ;\r\n"
          "    \r\n"
          "        if (target.nodeName.toLowerCase() == 'textarea')\r\n"
          "        {\r\n"
          "            prxTxtRsz.formEl = target;\r\n"
          "            prxTxtRsz.formEl.startWidth = prxTxtRsz.formEl.clientWidth;\r\n"
          "            prxTxtRsz.formEl.startHeight = prxTxtRsz.formEl.clientHeight;\r\n"
          "            prxTxtRsz.formEl.startX = event.clientX;\r\n"
          "            prxTxtRsz.formEl.startY = event.clientY;\r\n"
          "            prxTxtRsz.adEv(document, 'mousemove', prxTxtRsz.resize);\r\n"
          "            prxTxtRsz.adEv(document, 'mouseup', prxTxtRsz.stopResize);\r\n"
          "            prxTxtRsz.formEl.parentNode.style.cursor = 'move';\r\n"
          "            prxTxtRsz.formEl.style.cursor = 'move';\r\n"
          "            \r\n"
          "            try\r\n"
          "            {\r\n"
          "                event.preventDefault();\r\n"
          "            }\r\n"
          "            catch(e)\r\n"
          "            {\r\n"
          "            }\r\n"
          "        }\r\n"
          "    },\r\n"
          "    resize: function(event)\r\n"
          "    {\r\n"
          "        if (typeof event == 'undefined')\r\n"
          "        {\r\n"
          "            event = window.event;\r\n"
          "        }\r\n"
          "        if (prxTxtRsz.formEl.nodeName.toLowerCase() == 'textarea')\r\n"
          "        {\r\n"
          "            prxTxtRsz.formEl.style.width = event.clientX - prxTxtRsz.formEl.startX + prxTxtRsz.formEl.startWidth + 'px';\r\n"
          "            prxTxtRsz.formEl.style.height = event.clientY - prxTxtRsz.formEl.startY + prxTxtRsz.formEl.startHeight + 'px';\r\n"
          "        }\r\n"
          "    },\r\n"
          "    stopResize: function(event)\r\n"
          "    {\r\n"
          "        prxTxtRsz.rmEv(document, 'mousedown', prxTxtRsz.initResize);\r\n"
          "        prxTxtRsz.rmEv(document, 'mousemove', prxTxtRsz.resize);\r\n"
          "        prxTxtRsz.formEl.style.cursor = 'text';\r\n"
          "        prxTxtRsz.formEl.parentNode.style.cursor = 'auto';\r\n"
          "        return false;\r\n"
          "    }\r\n"
          "};\r\n"
          "prxTxtRsz.adEv(window, 'load', prxTxtRsz.adBtn);\r\n"
          "</script>\r\n"
          "<style type="text/css">\r\n"
          ".prxResizer { }\r\n"
          "</style>\r\n"

Insert below Header Top Add: Initial JS Code 7.11.29 (ccw! !mos) [...] (d.r).

The filter can definitely be improved Wink I left the CSS class "prxResizer" blank because I don't really have time to experiment with it (to make it look better).
Visit this user's website
Add Thank You Quote this message in a reply
Jan. 04, 2009, 04:31 AM
Post: #3
RE: [req] Resizeable textarea?
hmm...
just noticed this doesn't work on the post-a-reply-textarea right here on this forum...
i'll take a closer look tomorrow to see if i can track it down (or if it's perhaps only my config)...
Add Thank You Quote this message in a reply
Jan. 04, 2009, 05:31 AM
Post: #4
RE: [req] Resizeable textarea?
OK, it's time to weigh in.........


Fearless Leader, I've got to say, in as friendly a way as I can, that you really are showing a propensity to use a hammer even when there are no nails anywhere in sight! Wink IMHO, there are at least two problems with carrying the entire script's code within the Replace element of a filter. Let me elaborate:

Scott probably had several valid reasons for giving us the ability to load files from our local drive into a page. My favorite is that one can save time during the code's construction by being able to test it immediately - no checking "Apply", then getting out of the dialog box, only to get out of another one, then saving the config, then reloading it, then refreshing the page.... Sad By using a text editor on a file, it's simply save the thing, don't even need to close it, and refresh the page - Bang! the results are ready for your eyes. That's one.

Another reason he did this is selectivity - one can load a given file, perhaps containing site-specific scripts, from the local disk, yet those files might be only slightly different from one another. Better yet, with the $TEST/$SET methods, one can load a single file and probably cover every base. This contrasts to just one filter, as you've done elsewhere, but in point of fact, that was a very site intensive filter, and if any of those addresses within the Match string ever change in the future, then one will have to come through the filter, line by line, and hope to get all the updates correct, without introducing any bugs. In an external file, that can be bypassed - the URL match string should have contained all the URLs to be changed, with the appropriate $SET methods left untouched. (In a rather generalized fashion - I recognize that not every file and/or filter will be so easily manipulated.)

All this is not to mention that in terms of troubleshooting, one nearly always has an easier time of it when using an advanced text editor on an external file, what with colored key-words, bracket matching (even better, bracket jumping), and other niceties. Matter of personal preference, to be sure, but thought I'd mention it, just to cover as many bases as possible. Whistling

.......

Now for the 800 lb. gorilla in the room. Scott himself has mentioned it, but of course, that was on an "old" forum, one that Scott tacitly approved as being Official (nudge, nudge, wink, wink). Other developers in the web world are cognizant of the fact that not all browsers treat javascript (or any other scripts) in the same way during page loading. To wit, IE will recognize a script variable as global in nature (unless otherwise declared), and for each unique name, it's "first come, first served". This is why he can inject 'scriptlets' at the top of a page and get away with setting certain values - IE will then ignore other reference to those variable names, unless something in code changes them - watch out now - after the page has finished loading.

That's the big bugaboo - IE (and it's descendents) do this, but nearly all other browsers go the opposite way. (What, us do what IE is doing? Surely you've gotten high on some bad dope!) For them, when the variable is declared, it can be changed immediately afterwards by another declaration, there's no waiting until after the page loads and some var-changing code executes. This explains why some browsers that have Proxo-injected scripts at the top don't behave as expected - their DOM treats variables and scripts radically differently.

.......

Which brings us back to what a filter does, and why it might not be a good idea to have the filter contain a lot of script verbiage. If a script is injected into a page, just about anywhere, it won't be executed until after the page finishes loading.... under the IE paradigm. But newer browsers, possibly IE8 included, are getting smarter about using multi-threaded processors, and are beginning to trigger script execution in parallel with the page's loading, all in the name of quicker load times. Nice idea, but what happens when a script changes a variable, and then the page finishes loading, and the same variable is declared - that latest declaration is now the official value, not the results obtained from the script.

See what I mean? It's a can of worms, for sure. Browsing around the Goog.... er, the web, I see that at least a couple of people have seen the problem for what it does, and come up with solutions. One of them is the XMLHTTPRequest header, which is can be used to delay a request until some other condition has been met. One crafty fellow devised a timing method to delay all external script calls until the page had fully loaded. At that point, the scripts execute, and the variables take on the expected values. Not, to be precise about it, that Proxo can do anything about that!

Which brings us around full circle. It would seem that no matter which route one takes, they can never be sure of the results, given the sargasso of browsers out on the market. From that standpoint, my filter set has taken the moral high road of KISS - the simpler a filter remains, the better the chances of getting the desired result. Big Teeth Nothing magical in that, but you've got to admit, I do sleep pretty good at night. Sinister

Ah, I see the shepard's crook coming out of Stage Left.... time to bid you all adieu and adios, muchachos!



Oddysey

Disclaimer: No portions of hpguru were harmed in the making of this post.

I'm no longer in the rat race - the rats won't have me!
Add Thank You Quote this message in a reply
Jan. 04, 2009, 02:37 PM
Post: #5
RE: [req] Resizeable textarea?
(Jan. 04, 2009 05:31 AM)Oddysey Wrote:  a propensity to use a hammer even when there are no nails anywhere in sight! Wink IMHO, there are at least two problems with carrying the entire script's code within the Replace element of a filter.

i'll have to respectfully disagree Big Teeth

by placing the entire script's code within the Replace element, "newbie types" will actually at least "think" about trying it out...

why? because it's a "self contained" entity, just merge it and run, if you don't like then don't save the merge...

"newbie types" so much as "see" a filter that is NOT "self-contained" and has "includes" (.js, .css, you-name-it) that must be copied into a file structure and they'll read the thread but NOT even "think" about giving it a whirl...

aside from that, yes, i'll agree...
but "self-contained" filter-writes get more of a user base, so often times it becomes a 'necessity' to "self-contain" filter [req]'s...
Add Thank You Quote this message in a reply
Jan. 04, 2009, 10:04 PM
Post: #6
RE: [req] Resizeable textarea?
PR;

What you've said is, basically, that it's more important for Proxo to have a larger user base than it is for single users to have a working filter set. That's like Wing Luke saying to to Caine "when you can snatch the boulder from my hand, grasshopper".

Or to put it a bit more succintly, you'll attract more users with a smaller, simpler, easier-to-understand (and use) config set than with a large hairy one with three dozen 80-line filters. We've discussed before the prospect of being able to write filters, as versus actually writing them. I fall firmly in the first camp, but Inminente (and others) wonder why I don't get in the second camp. I must repeat, in as friendly a manner as possible, it's because I believe in the KISS principle. My filter set has nothing more than 4 lines long, with a few exceptions from Scott's original default.cfg file. I would contend that anyone who's used The Proxomitron for more than a few hours could easily implement, maintain, modify, update/upgrade or otherwise have fun with every filter in my set. (Well, if they went to the same sites I do. Big Teeth) How many people do you know that can make that claim with a set on a par with sidki's works?

But I'm not looking for an adverserial confrontation here, I'm just expressing my viewpoint. Certainly yours is valid, and quite possible not just for you, but for others too. But if push came to shove, I'd put my money on Siamesecat's and besafe's filters having a greater likelihood of gathering more new users into the fold than anything else I've seen in the last five years. Simple yet devastatingly effective, that's the name of the game, if you want to bolster the ranks. IMHO, of course. Cheers



Oddysey

I'm no longer in the rat race - the rats won't have me!
Add Thank You Quote this message in a reply
Jan. 06, 2009, 06:35 PM
Post: #7
RE: [req] Resizeable textarea?
here is a better test link -
http://www.w3schools.com/TAGS/tryit.asp?...l_textarea

the filter "as is" only works in Firefox...
it does not work, for me anyway, in Opera or IE...

i've converted the "bookmarklet one-liner" into a GreenBrowser plug-in, so i'm up-and-running with resizable textareas...


are there any non-Firefox users that want this filter to work for them also, or is the above Firefox-ONLY version suiting everyone's needs?
Add Thank You Quote this message in a reply
Jan. 08, 2009, 02:25 AM
Post: #8
RE: [req] Resizeable textarea?
Err...I don't understand why Fx users would need this. A major reason I use Fx all these years is for the Resizeable Form Fields extension. It's been renamed (was Resizeable Text Area) and changed authors several times over the years but it is indispensible to me.

I would like Proxo to do this for Opera and IE...ESPECIALLY for IE which needs it more than Opera.
Add Thank You Quote this message in a reply
Jan. 08, 2009, 10:34 PM
Post: #9
RE: [req] Resizeable textarea?
i haven't forgotten about this...
if not tomorrow, i should be able to get to it over the weekend...
Add Thank You Quote this message in a reply
Post Reply 


Forum Jump: