auto adjusting text areas

[cmb]

Seems to work!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Emphasis on "seems" (BTW: is your keyboard broken? )

It doesn't work in IE 8. After a few new lines, the box doesn't grow anymore. I tracked the problem down to

Code: Select all

textarea.style.height = "auto";

, which is apparently necessary for Chrome, FF etc., but must not be used for IE 8 (IE 6 and 7 don't seem to mind either). I was not able to finally track down the problem; it seems to be related to screen updates (giving an alert() seems to make IE 8 work with the line).

Furthermore the setting of `offset' (which may be named `border' for clarity, assuming the textarea doesn't have a horizontal scrollbar) don't seem to require the special clause for Opera (at least clientHeight works fine in 12.14).

I was not not sure about the used events to trigger the resizing. As I learned `input' is part of the HTML5 specification, so it should be fine to use it. A fallback to `keypress' (I would prefer that over `keyup' to cater for key repeats) might not harm. For IE<=8, which doesn't know about `input', `propertychange' seems to be a reasonable alternative.

But still there remained the problem with the height="auto", which shouldn't be worked around by browser sniffing. So I read again the alistapart article about the `mirror' variant:

The required height is calculated based on the scrollHeight attribute, which is not specified in any W3C spec (it was introduced by IE) and thus unsurprisingly has subtle differences between implementations, requiring an inelegant and brittle lump of browser-sniffing code.

Aha! So probably the `mirror' element solution is preferable as offsetHeight is standardized. Now I wanted to look up, where, and I found http://www.w3.org/TR/cssom-view/. There HTMLElement.offsetHeight is going to be standardized; and in the same document I found Element.scrollHeight! So prefering offsetHeight over scrollHeight because of standardization is nonsense.

And as I prefer to avoid a mirror element, if not absolutely necessary, I've investigated the scrollHeight issue further. In most browsers (Chrome, FF, Opera) after setting:

Code: Select all

textarea.style.height = (textarea.scrollHeight  + border ) + "px";

the scrollHeight of the textarea had increased by a few pixels! Not so in IE 8. So I thought about checking, if this is so, and only then setting the style.height temporarily to "auto", which seems to work well.

Christoph

[svasti]

Hmmmmmmmmmmmm (broken keyboard?), doesn't work .............. in IE9
In IE9 deleting will not re-adjust. Re-adjustment happens at the start and while typing... but not while deleting.

Works fine in IE8, Firefox, Opera, Chrome.
I think that's good enough, and re-adjustment while deleting isn't that important... and the a bit complicated mirror technique has been avoided... so, I guess, it could be implemented into the 1.6 version..., by Christoph.

svasti

[cmb]

In IE9 deleting will not re-adjust. Re-adjustment happens at the start and while typing... but not while deleting.

That's caused, because IE 9 finally implements EventTarget.addEventListener() (which is defined by the DOM Level 2 Events Specification from 2000!), but doesn't know about the `input' event, so my code falls back to the simple `keypress', which doesn't recognize `backspace' and `del'. But not only deleting characters isn't catered for: insertion by paste and drag&drop is ignored as well.

Now I've have adapted the script to (hopefully) cater for IE 9 the same way as for earlier versions.

[svasti]

Doesn't do it in IE9... sorry. Same as previous version.

[cmb]

Thanks for testing.

Just found http://help.dottoro.com/ljufknus.php:

The onpropertychange event is buggy in Internet Explorer 9. It is not fired when characters are deleted from a text field (such as input:text and textarea) through the user interface only when characters are inserted. Although the oninput event is supported in Internet Explorer from version 9, but similarly to the onpropertychange event, it is also buggy, it is not fired on deletion.

[cmb]

Hello Community,

I had just implemented this. During testing I opened Settings->Language, and waited and waited and waited... It took about 8s until the page was displayed on Chrome, 5s on Firefox and half an eternity on IE 8. The problem is the initial resize() function which has to be called for all 236 textareas.

So another idea: we deliver all textareas as they were (maybe with one visible row only), and do the resize only, when the textarea gets the focus (maybe resizing it back to the original size on blur). I have implemented this as draft (r779). Note that the single line textareas are a bad idea, if the resizing doesn't work in the browser.

I'm looking forward to hear your opinions. (Note that it's always possible to download a specific revision: http://sourceforge.net/p/cmsimplexh/cod ... anches/1.6).

Christoph

[Holger]

I had a quick look at it, only with FF and - to be honest - I'm not sure if it is a good idea .
It's looking really good but for me the old textareas doing their job too.

BTW: the link to download the revision is wrong, it must be
http://sourceforge.net/p/cmsimplexh/cod ... anches/1.6


Holger

[cmb]

It's looking really good but for me the old textareas doing their job too.

I agree, that the old textareas are doing their job, and that the autosizing is not necessarily better. And of course one has to consider that editing the language strings is not the most typical task when administrating a website. So we may consider to switch back to the previous behavior (or perhaps combine it with the autosize), or to make the autosize a (hidden?) config option.

What do others think?

BTW: the link to download the revision is wrong,

Thanks. I've already fixed that in my former post.

[svasti]

that the old textareas are doing their job,

Sorry, I don't agree. Now it's back to something like in 1.4.

So we may consider to switch back to the previous behavior

That should be the least. In 1.5 The size was determined by php, which at least showed right away, if a setting had more than just one line.

the initial resize() function which has to be called for all 236 textareas.

May be this function could be skipped and its job could be taken over by php, i.e. php determines the starting size of the textarea.

svasti

[cmb]

Now it's back to something like in 1.4.

Well, regarding the overview, yes, but not regarding editing.

May be this function could be skipped and its job could be taken over by php, i.e. php determines the starting size of the textarea.

To do so, we would have to give the textareas a fixed width and use a monospaced font. Otherwise we can only roughly estimate the starting size.

Anyway, I have now changed the behavior a bit: the initial size of the textareas is calculated as in CMSimple_XH 1.5. When a textarea receives focus, it is resized to the required size; on loosing focus it keeps the size. (r831) Feel free to experiment with the different possibilities: in XH_ArrayFileEdit::formField() (cmsimple/classes/FileEdit.php) one can adjust the initial size; in XH.makeAutoSize() (javascript/admin.js) the behavior of the resizing can be adjusted (see the statements that are commented out).