Textarea: Refactor to use <textarea> node rather than content-editable <div>

[rcoup]

(Filed on behalf of Alex)

Currently Textarea claims it's just a textarea that supports resizing with content.

Except that:

• It uses an IFRAME or ContentEditable? DIV depending on browser.
• That means lots of accessibility/event/focus-handling code wrt the rest of the page.
• Nearly every method is a big if-else block on whether its using an IFRAME or a DIV.
• The DIV/IFRAME is written as an inline conditional TemplateString? with inline javascript via <script> tags.
• It processes some HTML tags via ~15 uncommented regexes, to replace <br/>, <p>, <div>, &gt;, etc.

Fundamentally, wouldn't it just be easier to be a TEXTAREA that sizes?

phiggins(?) pointed out there is a problem in FF detecting the size of content in a textarea (to shrink height, growing is ok), but surely there's a simpler workaround than going to these lengths? (helpfully solving #4929 & #4137).

[bill]

I forget the issues with using a textarea, besides the problem that a textarea wouldn't shrink on FF. Doug, do you remember?

Rcoup/Alex - you are welcome to try refactoring it.

[doughays]

We discussed ths before and concluded that since the iframe isn't needed for FF3, that any work would be to make it work better on FF2 and that browser is going away, so it wasn't a good investment.

[bill]

Well, yes, when FF3 is released (or at least, when we desupport FF2), we will remove the iframe code and that will make things a lot simpler, and addresses the first 4 point from above:

• It uses an IFRAME or ContentEditable? DIV depending on browser.
• That means lots of accessibility/event/focus-handling code wrt the rest of the page.
• Nearly every method is a big if-else block on whether its using an IFRAME or a DIV.
• The DIV/IFRAME is written as an inline conditional TemplateString? with inline javascript via <script> tags.

I filed #4988 to help us remember that.

But even removing the iframe code still leaves the final issue from the original post:

• (Textarea) processes some HTML tags via ~15 uncommented regexes, to replace <br/>, <p>, <div>, &gt;, etc.

IIRC, the problems with using a real <textarea> and resizing it via JS were:

• FF2 doesn't shrink area when text is removed (hopefully that problem goes away with FF3 and ContentEditable <div>s?)
• problem detecting cut/paste into the textarea, via either ctrl-v or the right-click/Paste menu item. Need to resize text area when someone pastes it, or cuts out of it. Also when someone deletes a big chunk of text, either via the delete key or perhaps via a context menu (so I guess you would need a timer monitoring the textarea's contents?)
• We have to detect when people type Japanese or another Asian language, not just English. Not sure if compositionend works on IE. See related bug#4743.
• need to detect screen resize, and also when user adjusts browser's font size, making it bigger or smaller, because both those events could affect the length of the textarea (see related bug #4560)

So anyway, it seems much more complicated than you were thinking. You are welcome to post an alternate version that uses a <textarea> node, and if it's simpler (and addresses all the points from above) will be happy to replace the current version, but without a working example I have to mark this as invalid for now, since I don't have any reason to believe that using a <textarea> tag would be simpler.

[bill]

(Just updating bug title to be more descriptive). BTW, in the above text, last paragraph, I should have said "encouraged" rather than "welcome". I always love to see code reductions. Do you guys have a better idea than setting an interval timer to keep checking if the textarea contents have changed?

[bill]

Oh, I just remembered the main reason we didn't use a textarea node to implement the Textarea widget. It would require javascript sizing on page load, which we "outlawed" at DDD (in January 2007, IIRC) because of slow performance and issues when the widget is initially hidden.