Dao field growth

A little Friday fun.
The input fields, Textarea , which are silent when they are not doing anything, really want to grow. When the volume of input texts exceeds their size, their secret desire is not always heard by designers and layout designers, because they are already far away and think about new horizons. It is, if you listen to the user's fingertips, annoyingly moving the mouse scroll.

Sometimes this can be forgotten if the size of the input field is provided mostly satisfactory. In 3 out of 5 browsers there is even a place for resizing, which the layout designer, deafening by indicating above, sometimes turns off ( textarea {resize: none} ). There are other ways to make life difficult for the user. And then he leaves is taken for scripts and styles.

Sometimes the growth of the input field requires moderation. For example, if it reached 80% of the height of the window or logical block layout of the page. This extreme case also requires attention, but more often the first problem arises - the fields are small.

Story

On the well-known news site X. (names are changed, coincidences are random), the variability of the input fields is no less rigid than the policy. The suppression is many-sided, as if they, on the other side of the barricades, tried to make it harder for the encroachment to fix it by simple means.
')
While the height of the input field was 6-7 lines, no one really thought why the height of the fields does not change. But Safari, and then Chrome set a bad example - they had a corner, for which the user could draw and start typing too much text in the comment. It was necessary to do something to make life worse, so that they, these crowds clicked where necessary and did not write where it was not necessary. The last straw was Firefox about a year ago. When he began to resize the input field, he urgently needed to do something. And then they remembered resize: none .

We started with the fact that in the questions-answers we set 3 input lines and soon banned resizing (resize: none). But users are not badly baked, for each resize: none they have their own resize: vertical . There was no feeling of a complete victory over users by the input field.

And then there was a find (at the layout designer - the designer did not even dream about it), tested in the letters section:

textarea {height: 120px!important}; 

- Bravo! - said the Big Boss to the coder, - Well done, brother, helped out! Now they will dance with us within 120 pixels! Now you just can’t do it with styles to drag the input box to a corner and resize it for what you want. Now they and letters will try to write on 6 lines, and the answers, as usual - on 3 lines. We will show them how not to write articles, which are given as much as 400 pixels! (Why not 800 and in general why there is still no auto-magnification of the input field? Our SEO manager will explain this to you.)

And then the users took up the scripts. They themselves did not want to cut, and in general peaceful people. But I had to. A little magic scripts with styles - and the fields began to resize again manually. But this was not enough. Now, in the desires of users, intoxicated with the thirst for struggle and the taste of victory, automost once again loomed.

Compost is an input field property that is not even provided by the browser (otherwise, why would programmers be needed?). If you add text to a normal block, its borders grow in height (down) without any scripts. The input field does not have this. Only crutches of scripts will help the input field to grow up and it is very elegant to be able to make sure that this growth is perfect, cross-browser and just as accurate to the pixel that the block element initially has (which, for example, with the DIV tag). True, the problems are significantly reduced, if you do not need to provide auto-height reduction, only auto-increment.

Implementation

The HabrAjax script was supplemented with the function of autogrowing of input fields as the text content grows. Autoreduction is not consciously done, because it is possible to adjust the height of the input field manually by moving the lower right corner (except for the Opera, where there is no such function, but autoreduction is arranged in it).

Theoretically, this would have been desirable for a long time - not to look at the limited margins of the fields, but not to write 20 lines of the script, if the inconvenience is solved by 1 line of styles. Therefore, 1.5-2 years were resized styles and hands. Therefore, the addition now - not on 20 lines, but about 7 pithy, the rest is minced for other effects - the maximum height and the lack of scrolling when it is not needed, the realities of the DOM. (The code is adapted for reading, not an exact copy of user scripts.)

 var dQ = function(q){return document.querySelector(q);}; var win = typeof unsafeWindow !='undefined'? unsafeWindow: window; var tAGrow = function(tA){ //- if(!tA) return; var tSHPrev =0, tAInh, tATout maxH = Math.floor(win.innerHeight *0.8), tAF = function(ev){ if(tSHPrev < maxH && tAInh) clearTimeout(tATout), tA.style.overflow ='hidden', tAInh =0; var tSH = tA.scrollHeight - (isChrome?6:!isFx?win.opera?2:6:0); //  if(win.opera){ //   tA.blur(); tA.style.height = 0; tA.style.marginBottom = tSH +'px'; tSH = tA.scrollHeight -2; tA.style.height = tSH +'px'; tA.style.marginBottom = 0; tA.focus(); } if(tSHPrev <= tSH && tSHPrev < maxH){ tA.style.height = tSH +'px'; if(tSHPrev < maxH && tAInh) clearTimeout(tATout), tA.style.overflow ='hidden', tAInh =0; }else if(!tAInh) clearTimeout(tATout), tATout = setTimeout(function(){tA.style.overflow ='inherit'; tAInh =1}, 230); tSHPrev = tSH; }; tA.addEventListener('keypress',tAF,!1); //     tA.addEventListener('keyup',tAF,!1); tA.style.resize ='vertical'; //   (Fx, Chrome, Safari) tA.style.maxHeight = maxH +'px'; }; tAGrow(dQ('.editor #comment_text')||dQ('.editor #answer_text')||dQ('.editor #text_textarea') ); tAGrow(dQ('.editor #text') ); 

It is known that if you do not duplicate an input field in an invisible place to get the correct text height in Firefox / Chrome / Safari, you can only see an increase in the height of the input field, not a decrease. Reduce the input field is not often necessary, and this can be done by pulling around the corner. Therefore, the solution - the most lazy, but probably will be quite convenient. In any case, it can be modified or disabled.

On the practical side, I did not want to go into complexity in order to observe the principle of maximum simplicity. And so, at the time of meditation, the analysis of problems with manual resize of fields, enlightenment descended, and the author's tao was known.

You can see autorost in action and use it on the site by installing the version of user script Habrajax 0.87 or higher.

The possibility of autorost is disabled when saving other functions of the script - in the settings; default - enabled. It was checked in Fx, Chrome, but the remaining 2 browsers should work, and in the Opera the height should be auto-reduced, without the need to pull back to the corner (there is no such possibility). There may be small unpleasant jumps of the field height at the beginning of character input due to the numerous different site layouts, this will be decided a bit later by styles. Other growth side effects may come up - everything will be tested in real work.

UPD 02:00: checked in the Opera - it does not automatically reduce the height, but it will be decided in the next update. The opera from some time (for example, it is observed at 11.62) behaved like everyone else, except IE, with scrollHeight - now it is impossible to know the height of the text!

UPD 06:00: - version 0.872 - inserted a textarea autoreduction for Opera as the smallest load on scripts. Made by the method described in habrahabr.ru/post/132872 . It loads scripts and DOM, which can cause flickering and other effects, so auto-reduction is not included in other browsers (it’s better, if done, with the 2 textarea method, which is implemented, by the way, in the HabrAjax Quotation Corrector - a growing textarea in width and height for entering contextual comments).

Checked in Safari 5.1.4 Win + NinjaKit - there are big critical bugs - not entering spaces, Enter, non-saving settings and a number of other shortcomings, so it is not recommended yet. In general, NinjaKit is no longer enough to support this script, and the best solution is a separate addon, which is unreasonable to do because of the small number of users (potential 2-3 people).