Tao of field growth
A little Friday fun.
The input fields, Textarea , which are silent when they do nothing with them, actually 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 fingertips of the user, annoyingly moving the mouse scroll.
Sometimes you can forget about it 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, stunned by the indication from above, sometimes disconnects ( textarea {resize: none} ). There are other ways to make life difficult for the user. And then heleaves, takes up scripts and styles.
Sometimes increasing the input field requires moderation. For example, if it reaches 80% of the height of a window or a logical block of a page layout. This extreme case also requires attention, but more often the first problem arises - the fields are small.
While the height of the input field was 6-7 lines, no one really thought about why the height of the fields does not change. But Safari, and then Chrome, set a bad example - they got a corner for which the user could pull and start entering too much text into the comment. It was necessary to do something in order to worsen life, 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 about resize: none.
We started by setting 3 input lines in questions and answers and soon prohibited resize (resize: none). But users are not well-worn, for each resize: none they have their own resize: vertical . The designer had no feeling of a complete victory over theusers with the input field.
And then there was a find (the layout designer - the designer did not even dream about it), tested in the letters section:
- Bravo! - said Big Boss to the layout designer, - Well done, brother, helped out! Now they will dance with us within 120 pixels! Now you just can’t do just styles to drag the input field around the corner and resize as much as you like. Now they will try to write letters on 6 lines, and answers, as usual - on 3 lines. We will show them how not to write articles that take as many as 400 pixels! (Why not 800 and in general why there is still no auto-increase of the input field? Our SEO will explain this to you.)
And then the users took up the scripts. They themselves did not want to cut and generally peaceful people. But I had to. A little magic of scripts with styles - and the fields began to resize manually again. But this did not seem enough. Now, in the desires of users, intoxicated by the thirst for struggle and the taste of victory, the author again loomed.
Autostore- this is a property of the input field, not even provided by the browser (otherwise, why would programmers be needed?). If you add text to a regular block, its borders grow in height (down) without any scripts. The input field does not have this. Only script crutches will help the input field grow, and it’s very elegant to be able to make sure that this growth is ideal, cross-browser and as accurate, to the pixel as the block element (which, for example, with the DIV tag ) originally has . True, the problems are significantly reduced, if you do not need to provide auto-decrease in height, only auto-increase.
Theoretically, I wanted to do this for a long time - not to look at the limited scope 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 cost resize styles and hands. Therefore, the addition now is not 20 lines, but about 7 substantial, the rest is minced for other effects - the maximum height and the absence of a scroll when it is not needed, the realities of the DOM. (The code is adapted for reading, not an exact copy of the user script.)
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 will notice only an increase in the height of the input field, not a decrease. Reducing the input field is not often necessary, and this can be done by dragging the corner. Therefore, the solution is as lazy as possible, but it will probably be quite convenient. In any case, it can be modified or disabled.
On the practical side, I did not want to go into difficulties in order to comply with the principle of maximum simplicity. And so, at the time ofmeditating the analysis of problems with manual resizing of fields, enlightenment decreased, and the dao of autostat was learned.
You can see the author’s action in action and use it on the site by installing the Habrajax user script version 0.87 or higher.
The autostat feature is disabled while saving other script functions - in the settings; default is on. It was tested in Fx, Chrome, but the other 2 browsers should work, and in Opera, the height should be reduced, without having to pull back around the corner (there’s no such possibility). There may be small unpleasant jumps in the height of the field at the beginning of the input of characters due to the many different website layouts, this will be decided a little later by styles. Other side effects of growth may come up - everything will be tested in real work.
UPD 02:00: checked at the Opera - it has not yet automatically reduced the height, but this will be decided in the next update.The opera from some time (for example, it was observed at 11.62) behaved like everyone else except IE with scrollHeight - now you can’t find out the height of the text from it!
UPD 06:00: - version 0.872 - inserted auto-reduction textarea for Opera as the smallest load on scripts. Made by the method described in habrahabr.ru/post/132872 . It loads scripts and the DOM, due to which there may be flickering effects and others, so auto-reduction is not enabled in other browsers (it’s better if you do it using the 2 textarea method, which is implemented, by the way, in the HabrAjax Quotation Corrector - growing textarea in width and height for entering contextual comments).
Tested in Safari 5.1.4 Win + NinjaKit - there are big critical bugs - not filling in spaces, Enter, not saving settings and a number of other shortcomings, therefore it is not recommended yet. In general, NinjaKit is no longer sufficient to support this script, and the best solution is a separate add-on, which is unjustified due to the small number of users (potential 2-3 people).
The input fields, Textarea , which are silent when they do nothing with them, actually 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 fingertips of the user, annoyingly moving the mouse scroll.
Sometimes you can forget about it 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, stunned by the indication from above, sometimes disconnects ( textarea {resize: none} ). There are other ways to make life difficult for the user. And then he
Sometimes increasing the input field requires moderation. For example, if it reaches 80% of the height of a window or a logical block of a page layout. This extreme case also requires attention, but more often the first problem arises - the fields are small.
History
On the well-known news site X. (names are changed, coincidences are random) the variability of input fields is suppressed no less severely than politics. The suppression is multifaceted, as if they, on the other side of the barricade, tried to make it difficult for the creep to fix it by simple means.While the height of the input field was 6-7 lines, no one really thought about why the height of the fields does not change. But Safari, and then Chrome, set a bad example - they got a corner for which the user could pull and start entering too much text into the comment. It was necessary to do something in order to worsen life, 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 about resize: none.
We started by setting 3 input lines in questions and answers and soon prohibited resize (resize: none). But users are not well-worn, for each resize: none they have their own resize: vertical . The designer had no feeling of a complete victory over the
And then there was a find (the layout designer - the designer did not even dream about it), tested in the letters section:
textarea {height: 120px!important};
- Bravo! - said Big Boss to the layout designer, - Well done, brother, helped out! Now they will dance with us within 120 pixels! Now you just can’t do just styles to drag the input field around the corner and resize as much as you like. Now they will try to write letters on 6 lines, and answers, as usual - on 3 lines. We will show them how not to write articles that take as many as 400 pixels! (Why not 800 and in general why there is still no auto-increase of the input field? Our SEO will explain this to you.)
And then the users took up the scripts. They themselves did not want to cut and generally peaceful people. But I had to. A little magic of scripts with styles - and the fields began to resize manually again. But this did not seem enough. Now, in the desires of users, intoxicated by the thirst for struggle and the taste of victory, the author again loomed.
Autostore- this is a property of the input field, not even provided by the browser (otherwise, why would programmers be needed?). If you add text to a regular block, its borders grow in height (down) without any scripts. The input field does not have this. Only script crutches will help the input field grow, and it’s very elegant to be able to make sure that this growth is ideal, cross-browser and as accurate, to the pixel as the block element (which, for example, with the DIV tag ) originally has . True, the problems are significantly reduced, if you do not need to provide auto-decrease in height, only auto-increase.
Implementation
The HabrAjax script was supplemented with the function of auto-increasing input fields as the text content grows. Auto-reduction was not consciously done, because it is possible to manually adjust the height of the input field by moving beyond the lower right corner (except for the Opera, where there is no such function, but it has auto-reduction).Theoretically, I wanted to do this for a long time - not to look at the limited scope 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 cost resize styles and hands. Therefore, the addition now is not 20 lines, but about 7 substantial, the rest is minced for other effects - the maximum height and the absence of a scroll when it is not needed, the realities of the DOM. (The code is adapted for reading, not an exact copy of the user script.)
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 will notice only an increase in the height of the input field, not a decrease. Reducing the input field is not often necessary, and this can be done by dragging the corner. Therefore, the solution is as lazy as possible, but it will probably be quite convenient. In any case, it can be modified or disabled.
On the practical side, I did not want to go into difficulties in order to comply with the principle of maximum simplicity. And so, at the time of
You can see the author’s action in action and use it on the site by installing the Habrajax user script version 0.87 or higher.
The autostat feature is disabled while saving other script functions - in the settings; default is on. It was tested in Fx, Chrome, but the other 2 browsers should work, and in Opera, the height should be reduced, without having to pull back around the corner (there’s no such possibility). There may be small unpleasant jumps in the height of the field at the beginning of the input of characters due to the many different website layouts, this will be decided a little later by styles. Other side effects of growth may come up - everything will be tested in real work.
UPD 02:00: checked at the Opera - it has not yet automatically reduced the height, but this will be decided in the next update.The opera from some time (for example, it was observed at 11.62) behaved like everyone else except IE with scrollHeight - now you can’t find out the height of the text from it!
UPD 06:00: - version 0.872 - inserted auto-reduction textarea for Opera as the smallest load on scripts. Made by the method described in habrahabr.ru/post/132872 . It loads scripts and the DOM, due to which there may be flickering effects and others, so auto-reduction is not enabled in other browsers (it’s better if you do it using the 2 textarea method, which is implemented, by the way, in the HabrAjax Quotation Corrector - growing textarea in width and height for entering contextual comments).
Tested in Safari 5.1.4 Win + NinjaKit - there are big critical bugs - not filling in spaces, Enter, not saving settings and a number of other shortcomings, therefore it is not recommended yet. In general, NinjaKit is no longer sufficient to support this script, and the best solution is a separate add-on, which is unjustified due to the small number of users (potential 2-3 people).