Watch me expand to encompass your every word! Closing remarks #section4ĭue to the way redraws are batched in Opera for Mac OS X, a slight flicker may occur when a new line is added to the text field. The event is simply called input, and you use it just like any other event: textarea.addEventListener('input', function (event) var areas = document.querySelectorAll('.expandingArea') Ī note on delegation: you can easily set this up with a single event listener on the document node and use event delegation to handle multiple expanding text areas efficiently, but only if you’re not supporting IE8 or below, as Microsoft, in their infinite wisdom, did not make the onpropertychange event bubble. Fortunately, such an event exists and it’s incredibly useful, although it’s mentioned so rarely it would seem many are unaware of its existence. What we really want is an event that simply fires whenever the value of the textarea changes. The keyup event works most of the time, but also fires on events where no real change has been made, such as moving the cursor left and right and it does not fire if the user uses the mouse to cut or paste. The change event is not ideal as it only fires when the textarea loses focus. The first improvement we make is related to how we detect input. The technique is an improvement on the offscreen-positioned mirror element. Here, I’m going to show you a better solution to the problem, which sizes the textarea using only the smallest snippet of JavaScript magic along with some cunning CSS. It can be tricky to calculate the exact width of the content-box in the textarea hence there’s normally a “fudge factor” added to the height applied to the textarea, just to make sure it’s not slightly too short, resulting in a box that’s then slightly too big for the content. Worse, if you support flexible-width text areas you must check that the width of the textarea hasn’t changed on each poll as well (an expensive read to offsetWidth). This method works, but the polling is inefficient, especially if you have multiple text areas. This then automatically sizes to fit its content (as a normal block-level element does), after which you can extract the size from the offsetHeight property and apply that back to the textarea. Using setTimeout, the textarea is then polled every 200ms or so, and each time a new value is found, the content of the mirror element is updated. The best solution I’ve seen uses a separate pre element absolutely positioned off screen, styled the same as the textarea let’s call this the mirror element. 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.This doesn’t work if the textarea has a fluid width and the window is resized. The height is recalculated and set only on the keyup (and possibly cut/ paste) events.This breaks if you set the width of the textarea in CSS, use a proportional width font, or simply don’t supply a cols attribute. The height is calculated by guessing where wrapping occurs based on the cols attribute.Trawling the internet, you can find several attempts at creating expanding text areas, but most suffer from one or more of the following problems: Since this is the only way to accept multi-line user input (other than using contenteditable, a whole world of pain I’m not going to dive into today), a little JavaScript is needed to make it resize as desired. While normal block-level elements (like a div, for example) expand to fit their content, the humble textarea does not, even if you style it as display: block.
3 days of design, code, and content for web & UX designers & devs.ĭespite the ubiquity of this control, there’s no way to create it using only HTML and CSS.
0 kommentar(er)
