Drop textarea.js in favor of CSS3 resize

sub.

This makes sense to me visually, but I'm not a JS expert so I will not RTBC it. I will, however, hand it to the bot. :-)

Make sense and looks good. This will even fix #835820: Don't set CSS directly in JS, make it themable . The behaviour is the same after applying the patch, however it make a little visual difference. Before and after screenshots attached. It would also be better to keep the same css classes if possible.

@idflood what browser did you test this in?

Sorry, I forgot to clean the caches. After clearing both drupal and browser caches the result looks different. I attached a screenshot of the new result. I tested this on firefox 4.0 / safari / chrome and the result is consistent across browsers. Maybe I did something wrong with the patch but it applied successfully without warnings.

I've added two "width: 100% !important;" to fix the textarea width. The issue was most visible by loading node/add/article with a small browser window and then making it bigger after the page has loaded.

As a side note, I've just filed #1153300: Deprecate Drupal's textarea resizer as a related issue. I think it's technically separate from this issue but I defer to the JS gurus.

(Actually it might be nice to bake that functionality right into jQuery Resizable. That's a good way to contribute back to a sister project.)

How awesome is that, it works really well :)

With this we don't have to worry about #1301952: Objectify textarea js anymore.

+++ b/misc/textarea.js
@@ -2,29 +2,12 @@
-    $('.form-textarea-wrapper.resizable', context).once('textarea', function () {
...
+    $('div.form-textarea-wrapper.resizable textarea', context).once('textarea').resizable({

Let's remove the 'div' in the selector.

+++ b/misc/textarea.js
@@ -2,29 +2,12 @@
+    // Use jQuery UI to make the textare resizable.

Typo in "textare"

+++ b/misc/textarea.js
@@ -2,29 +2,12 @@
+      // Provide handles on the bottom right and bottom.
+      handles: 's',

What means "bottom right", and why? The grippie was only at the bottom before?

+++ b/misc/textarea.js
@@ -2,29 +2,12 @@
+      // Leave at least one line in the textarea.
+      minHeight: 32

A hard-coded pixel size is a bit unfortunate. Any ways around that?

+++ b/modules/system/system.base.css
@@ -67,18 +67,28 @@ fieldset.collapsible .fieldset-legend {
-  width: 100%;
+  width: 100% !important;
...
+  width: 100% !important;

No !important in core CSS.

+++ b/modules/system/system.base.css
@@ -67,18 +67,28 @@ fieldset.collapsible .fieldset-legend {
+html.js .form-textarea-wrapper.resizable {

#1269586: Use .js instead of html.js in CSS

The layout tweaks going on for resizable textareas are quite advanced and went through extensive testing. See #735628: Resizable textarea behavior leads to unpredictable results

Here is a patch, use CSS resize if possible, if not fall back to jquery ui. I kept the resizable-textarea to simplify CSS styling and be able to differenciate between a CSS resize and jquery resize.

Interesting.

1. Shouldn't jQuery UI Resizable itself contain that CSS3 resize support check and dynamically react to it?

   Looks like we need to load jQuery UI Resizable anyway as polyfill? (that said, would be highly interesting to investigate whether we can introduce a lazy-load mechanism for polyfill code [which would have to integrate deeply with Drupal.ajaxPageState])

2. If we keep the current incarnation, the code should use $.support as feature detection pattern, unless I'm mistaken.

1)

a. I assumed it wasn't applicable to everything but it is :p resize won't help jquery ui, there is no way to make all events/options available with only a CSS resize and the actual width / height resizing is pretty trivial compared to animations and other crazy things ui does.

b. totally agree, and with loaders it's actually really easy to do, cf. the whole script loader issue.

2) nothing helpfull inside $.support for this, since ui-resize won't be able to use it, there is no need for jquery to test it.

So yeah unifying them all sounds like a good idea but it's not actually possible.

a side note about ajaxpagestate integration, I don't get it. Here is what a conditional loading would look like :

    if (!supportsResize) {
      require(['ui.resize'], function () {
        // Use jQuery UI to make the textare resizable.
        $wrappers = $(context).find('.form-textarea-wrapper.resizable').addClass('resizable-textarea');
        $wrappers.find('textarea').once('textarea').resizable({
          // Provide handles on the bottom right and bottom.
          handles: 's',
          // Leave at least one line in the textarea.
          minHeight: 32
        });
      });
    }

That would work that way for any loader (curl, requirejs, etc.)

Where does it involve something like ajaxpagestate ?

I know this has nothing to do here but it's such a good example I can't leave it alone.

Sorry for the ajaxPageState/script-loader confusion. Looks like I have to make myself way more familiar with the anatomy of those script loaders. Anyway, thanks for noting, and yeah, let's discuss that elsewhere.

nothing helpfull inside $.support for this

I thought the idea of $.support is to have central feature detection? Hence, by using $.support contributed and custom modules and themes can (re-)use the condition?

My understanding is that the feature detection is always run to be always available. Since this is not included in all of the pages 3rd party scripts can't rely on it anyway. And they won't/souldn't be loading textarea.js just for that.

From what I read over at jquery this is used for jquery or plugins. I have a huge plugin or set of plugins and I need a global thing for browser features: use $.support instead of a global var. I have nothing against adding the result to $.support but since the scope is so tiny and it won't be added on most of the pages, it's just not worth it.

worst case people starts using it, we have to take it out because somehow it slows js too much you have many people not happy about it, a bit like the global $ thing.

Thought: If we want to be an HTML5-centric system (my understanding is that we do) and embrace modern web conventions (my understanding is that we do), then why have a JS fallback? If a browser doesn't support resize, then those users don't get resize. That's the conventional approach these days for optional stuff like that, is it not? The form still works, the user loses no capability to interact with the page, but he is limited by his browser. Aw.

Opera is hardly a major market, and will get resize support soon enough anyway I expect, so why go to all that work when we can just say "HTML5 takes care of it, let's go have a beer"?

meh, fine with me. Just need someone to decied between #1153300: Deprecate Drupal's textarea resizer and this one there are patches for both. You might want to talk to UX people before though, the browser native resize handle is tiny tiny. As much as I hate grippie it has the advantage of being easy to find, click and drag.

I support the idea and stated reasoning for removing it.

FWIW, the spec: http://www.w3.org/TR/css3-ui/#resize

Indeed, this means to load less code in the frontend (which is way more important than "less code to maintain"), and it's not like users wouldn't be able to edit the textarea content anymore. And, if absolutely necessary on your own site, you can happily and very easily overload this with jQuery UI or your custom forward-port of textarea.js (doh ;)).

We still want to retain compatibility with the #resizable textarea Form API property though. For that, I'd suggest to change the property's value into a string, its default value to 'vertical', and lastly, apply a corresponding CSS class according to that; i.e.:

  $form['message'] = array(
    '#type' => 'textarea',
    '#resizable' => 'vertical', // default
  );

which is turned into

  $element['#attributes']['class'][] = 'resize-vertical';

ends up as:

<div class="form-item form-type-textarea">
<textarea class="resize-vertical"></textarea>
</div>

and lastly gets triggered:

.resize-vertical {
  resize: vertical;
}

#24 is exactly what I was talking about. I presume we would add support for the other resize values as well (horizontal, both, and none)? It looks like it would be a trivial patch.

(We may want to fold this issue into #1153300: Deprecate Drupal's textarea resizer at this point.)

We may also want to ping Jacine as HTML5 lead in case she disagrees, but I suspect she'd be OK with this approach.

Cool. Tagging this for the current sprint.

In the sprint meeting today, Jacine gave a thumbs-up to switching to pure-CSS with no shiv on this issue. Who wants to write the patch? :-) (Basically implement #23 and #24.)

Oopsies.

I'll give it a shot tonight, unless someone beats me to it.

Here's a first pass.

Hey, neat! :) Here's a screenshot:

One thing I ran into when I was testing (Chrome 17, OSX Snow Leopard): it will only let you make the box bigger, you can't move the corner up in order to collapse the box and make it smaller. At first, this made me think the patch wasn't working. It'd be nice to retain this functionality, for the purpose of taking screenshots and other things. Not sure if this is just a quirk with this specific implementation or not; http://robertnyman.com/css3/resize/resize.html shows that this property can even re-size things to stupid levels, so hopefully it can be fixed in a way that doesn't screw non-CSS3-compatible browsers. :)

Yea I notice that too :-/. Seems like a weird implementation coming from this line in the spec.

The user agent may restrict the resizing range to something suitable, such as between the original formatted size of the element, and large enough to encompass all the element's contents.

So essentially the smallest an element can go seems to be it's initial width :-/

Here are a couple of stackoverflow questions related to this exact same issue.

http://stackoverflow.com/questions/8771650/html5-resize-only-on-makes-it...
http://stackoverflow.com/questions/6313358/css3-resize-property-allows-o...

:-(

CSS resize is not supported in opera nor IE. That makes me a little sad (I like opera) but I'm sure IE people will be angry.

Can we discuss (maybe somewhere else) how we handle js fall-backs for this kind of things?

Patch at #30 is tested and works well.

@nod in the last html5 meetup we discuss supporting ie in a contrib module that people can install if they want ie support. So we can have a contrib module that brings ie support for all these functionality. You can see more detail about this in the meeting notes (http://groups.drupal.org/node/206193#comment-687768).

The idea behind this is we support the native functionality which is nicer/cleaner/leaner out of the box and if you need ie support you can just install the extra module. Also we talk about this not being such a big deal being that technically the form is still usable and doesn't really harm anyone if an ie user can't resize a specific textbox.

Thanks, I wasn't aware of that. That's good enough for me :)

The UX team might have something to say about this patch. Tagging for them.

Gentle reminder that we had something along the lines being proposed in #35 in core some time ago:

Legacy module

(different purpose, but otherwise comparable)

Definitely a discussion for a separate issue, but I wanted to point out early that it might make sense to provide legacy/polyfill/fallback support within core.

Manually tested #43, works in Chrome Canary, Chrome Stable, and Firefox. However, I see inconsistent behavior:

1. Only Firefox provided a mouse icon that looked like an up arrow combined with a down arrow.
2. Firefox and Chrome Stable allowed me to change the height of the textarea, Chrome Canary allowed me to change the height and the width.

Other than that it was fine. I wasn't able to reduce the height or width beyond the default.

Doesn't work in Opera 11.61, IE9, or IE8

I didn't put the min-height or max-width because it didn't make sense to me.

This is good, changing back to RTBC.

This looks great! Committed/pushed to 8.x.

Let's add a change notification - there may be themes out there doing custom styling of this etc.

@catch it looks like this commit didn't actually make it up to drupal.org. Same thing with a couple of other issues.

@ericduran is correct. (Fixing priority.)

Let's try that again. Committed/pushed!

My first Change notification. Please let me know if I've done anything wrong: http://drupal.org/node/1465840

Problem/Motivation

Drupal 8 aspires to rely more on the foundations of the internet such as CSS3 and HTML5 and no longer needs to support old-IE browsers that required JavaScript driven implementations for textarea resizing. We want to reduce our code weight by reducing that amount of additional behaviors we apply to form elements such as resizing a textarea.

Proposed Resolution

Remove the textarea.js script that enabled the ability to resize textareas and instead rely on a pure CSS 3 and HTML5 based solution.

I think maybe a before/after screenshot would be nice so people see what the difference is. This is more visual than anything else.

It's probably easiest to steal the picture from #32. webchick already did the work for us. Thanks, webchick! :-)

I polished the change notice formatting a bit more, moved the screenshots below the description, and added a sample textarea implementation using the new #resizable allowed values.

Thanks @xjm and @cosmicdreams! Removing the sprint tag.

What do people think about backporting this to 7 (there was a little note about it in #1153300: Deprecate Drupal's textarea resizer)?