Hide When Focus Lost
Generally users not only need to write in a text control, they need to read it too. A scrollbar is more than a control. It’s a display too that provides vital information useful for reading. If you hide the scrollbars when the text control hasn’t focus, then when the users read the text while the text control is out of focus:
The users cannot estimate how much text is in the control by simply looking at it. They cannot tell if they’re seeing everything or not. If they’re unaware, didn’t notice, or forgot that you’re hiding the scrollbar, they’re likely to assume the visible text is all there is. If they see the scrollbar disappear when the text control loses focus, they might assume (to their alarm) that you’ve truncated their input.
The users cannot tell if they’re at the beginning of the text or scrolled down somewhat. That can change the meaning of what they’re reading. If they’re unaware, didn’t notice, or forgot that you’re hiding the scrollbar, they may think the text starts off differently than it does.
The users need two clicks to read all the text or jump to an arbitrary place in the text, one to put focus in the text control and the other to click/drag the scrollbar. Normally, the user can click the scrollbar immediately to get to any text.
If the users are unaware, didn’t notice, or forgot that you’re hiding the scrollbar, they can confuse another scrollbar (e.g., one for the browser or one for a partially occluded window) for the scrollbar for the text control, resulting in them scrolling the wrong thing, and possibly losing focus on the window. Really annoying when you’re trying to read something. This is especially likely when the text control is nearly the size of the window.
The users need to notice, learn, and remember that scrollbars disappear when the text control loses focus, and then continuously mentally track where the focus is on the page in order to know how to interpret what they see in the text box, and avoid the confusion associated with the above bullets. That adds a mental burden.
So there’s a lot of downsides to hiding the scrollbar. The upside is a little less clutter. However, scrollbars are already quite compact and unobtrusive controls. For nearly any likely situation I can think of, hiding them is not worth it.
Most of these issues apply to other rules for hiding scrollbars, such as showing them only when the mouse moves or when the user hovers over the control. These other rules can have issues of their own too, such as distracting animation effects when slewing the mouse, which defeats the whole point of hiding the controls in the first place (i.e., to reduce distractions).
Hide Until Box is Filled
However, it may be reasonable to hide the scrollbar until the text fills the text control. The upside is, once again, a little less clutter. The downsides are:
The distraction of the scrollbars flashing into view when the user is in the middle of writing something.
The user can’t tell before writing if scrolling is supported, and may think they have to fit what they write in the visible space.
Hiding the scrollbar until there is enough text is best when the text control is big enough for the vast majority of input and the text control is small relative to the scrollbar (so, proportionally, the scroll constitutes a substantial amount of clutter). That lowers the probability of the downsides while raising the relative benefits of the upside.
On a personal note, does anyone know the genius at Microsoft who decided to infuriatingly hide the scrollbar in Word 2013 until the user mouses over the right margin? Please email me their address. I’m fixin' to egg their house this Halloween.