resize should be opt-in, not opt-out!

I'm sure this has been mentioned elsewhere (some fun and frolics at the end of this issue, but I'm with Bèr 100% on this one. The resizable text areas (in HEAD and 4.7.0-beta3) don't work at all for me in Konqueror, and are very jerky and strange under Firefox. I've experienced jumping textareas, textareas inaccessible and hidden under other content and content not complying and remaining fixed in place in the window even when the textarea is resized (ie it fails to 'push' the content down).

How about a contrib module to provide all (or most of) this JS/AJAX stuff, with a list to allow admins to turn different features on and off?

+1 - great idea, but untested as yet. Could this also allow for a whopping toggle switch for all supported JS/AJAX within a theme?

Well, it gets my vote. I test it tomorrow sometime.

+1 for removing this unneeded core feature into a contrib module.

I think it would be better in a module than a theme, as users will be able to switch it on or off without hacking it into their favourite theme.

...or the theme settings page. ;-)

I agree with Ber's approach to nifty features that might be annoying to other people. The patc also looks ok to me.

+1 for removing this unneeded core feature into a contrib module.

The resizable textareas are just as much a usability add-on as e.g. collapsible fieldsets. Should those be disabled by default too? Before you say "the collapsible fieldsets are not buggy", let me remind you of the kind of hacks that we went through to make those work:

html.js fieldset.collapsed table *,
html.js fieldset.collapsed legend,
html.js fieldset.collapsed legend * {
  display: inline;
}
/* Note: IE-only fix due to '* html' (breaks Konqueror otherwise). */
* html.js fieldset.collapsible legend a {
  display: block;
}

But, they do work now.

When it comes down to it, Javascript is not the real issue. It's crappy CSS support; the fieldsets have demonstrated this before. With the textareas, all the different browsers have their own idea of how CSS applies to them. Check the various incarnations of textarea.js: it was the CSS styling and markup which changed again and again. The mouse handling on the other hand hasn't changed since day one; its 'browser compatibility layer' consists of a single, short line of code.

So, your proposal that we use a "a proven-to-work toolbox like prototype" would not change a thing about the issues you're seeing with the textareas. Remember that Konqueror file upload bug a while ago? Same story. In fact a JS toolkit would only make it much harder to track down, because of the extra layers in between.

I think that keeping our 'rich UI' features on by default provides more incentive for modules and themes to work with them, rather than against them. Many people are shouting for "more Ajax" and "more rich UIs!", so this can only be a good thing.

If you want to do a rich UI in Drupal, you need to deal with variable content in variable forms with variable styles and it all needs to degrade. It is not trivial to get right, but it is worth trying to get right. We don't need patches to disable JS, we need more people to stop being afraid of it. Code, debug, play around, test. But don't throw out the baby with the bathwater.

The resizable textareas are just as much a usability add-on as e.g. collapsible fieldsets. Should those be disabled by default too?

Yes. :-) I've said before we're over-relying on those.

What I could go for is a checkbox set inside a fieldset somewhere (theme page? settings page? I don't know.) to selectively enable or disable "Visual FX". Want collapsable fieldsets? Check on the "collapsable fieldsets" checkbox and they're done. Don't want the super-resizing textareas? Check that checkbox off. The functionality shouldn't be affected, but implementing it shouldn't be too difficult, I'd think. We'd just need some sort of "visual FX" registry. If someone adds a funky-effect (core or contrib), they register that as a string. Then a simple

if (fx_get('resizable textareas')) { 
  // Do the fancy JS magic
}

And we're done. We can even default stuff to on if we want to show off, but those who don't want it for whatever reason can easily get rid of them.

I know my opinion isn't that important, but have too admit that I rather would see the JavaScript/Ajax usability things in several contrib-modules, than default in core.. So +1 on moving *all* JavaScript/AJAX features from core to contrib into /several/ modules.

Well, there are JS thingies that are (IMO of course) usability improvements and there are some that aren't. The collapsible fieldsets belong into the first category, while the expandible textareas are of the second kind.

People who want to write the great novels of the 21st century in a browser textarea should not be taken serious anyway.

And there also were times where we didn't care for the shouting masses.

I see no konqueror version. While it was not working with Drupal 4.7 beta 2 and konqueror 3.5 it started working somewhere between beta2 and beta3 in the cvs (#42913 I think it was - removed a ta.endDrag(e) ). I tested this 3/4/5 days ago with Fedora Core 4. Firefox 1.0.7 and 1.5.0 work also.

Resizable textarea should be on by default. Feel free to turn them off in your theme.

Resizable textareas should probably work by default, too. I don't know (or care) enough about javascript to fix it, sorry, but it means that we can't upgrade any of our sites beyond beta 2 without stripping this feature out of the code.

Resizable textarea should be on by default. Feel free to turn them off in your theme.

Why should resizable textareas be on by default but collapsable fieldsets off by default? What makes the one more important to push so heavily than the other?

Since upgrading to KDE 3.5, I've found the resizable text areas not working every other time I update against CVS HEAD or so. As of this post it is working, but I've no faith in it staying that way. What happens is that the page below the textarea moves, but the textarea itself doesn't go anywhere.

With that kind of unpredictability, the first thing I'd do on any Drupal install is go in and strip out the damned JS for it. But I'm skilled enough to do that (I hope :-) ). Not everyone setting up a Drupal site is.

Really, this would be a simple contrib module to achieve the same global effect. Like rich-editors (HTMLArea, FCKEditor, etc.), this should be an admin option via module, not an essentially mandatory feature.

I can't believe KDE is going that route. what else are they going to remove? ...maybe they should think about packing the browser as a virtual machines ...sorry, I know I'm not adding anything useful here, but I couldn't resist.

Maybe it is easy to add a global setting to allow admins decide, maybe the attribute #resizable could be inserted on textareas by default if they choose, or maybe even an option at user level?

I fully support Crell. the feature as such does not add much to Drupal and has the potential to alienated quite a few people. It should not be enabled by default and maybe not even in core. Niftyness isn't an appropriate core standard.

Bèr, you can not fill a upload form with javascript (only read the file name maybe), this is what makes it secure. All other things you can hide to submit some text (javascript can not access local files) info back to the server hiding this fact from the user can be done easy with xmlhttp (and it should be that way, javascript is designed to hide things from the user). Real life example is gmail, they allows you to dynamically add more uploads using javascript.

About javascript security read more at http://www.quirksmode.org/js/intro.html. Konqueror 3.5, at least mine with FC4, asks you every time you upload file(s) if you would like to do so. If Konqueror developers are implementing security by disallowing you to hide things, which I don't believe, they are just creating Security through obscurity and breaking standards. I can not find anything on this subject with google, if you have links please give me some.

+1 for making resizer optional, it's tacky and not that useful.

+1 on making it optional.

(anyone worked out how to get rid of it?)

Dub

Answering my own question here..but, here's a phptemplate template.php snippet that will override and disable the resizable text area thingy for a specific theme

hope that helps others.

I imagine it wouldn't be too hard to plop a checkbox on the theme configure page to toggle it?

Dub

+1 should be optional!

See also: http://drupal.org/node/84500

As I feel a bit resposible defending resizable textareas, here's a patch that should (worked for me) make this optional feature with setting at admin/settings/textarea (copy-paste + modify from Clean URLs).

I think a more generic fix will be better. Rather than adding checkboxes galore for each feature that we want disabled etc., introducing an option to override (or unload) JS (or CSS) files will be more prudent, cleaner and modular. drupal_add_js / drupal_add_css store all includes in a static array. Adding a method to replace this array accordingly will solve this (and other) issues.

My 10p.
-K

Can now override css in .info files, .js should be coming soon if not already, so won't fixing this since there's more and more javascript in core and this isn't the sort of thing you want to add checkboxes for.