I'm trying to research the potential pitfalls of hiding a scroll bar in a textarea on a web page only when the element has focus.

EG: No text = no scroll bars, text starts to overflow = add scroll bars, user moves to another element = scroll bars go away, user focuses on text again = scroll bars return.

I'm wondering if anyone has any input on this use case and how a user may react to it. Personally, I loath how the scroll bars look in browsers and prefer to not see it if I don't need it, but I know a lot of you have more experience with these things than I.

jsfiddle to show the effect

  • I tried your demo. The appearing/disappearing scrollbar is actually very distracting and I don't like it at all. Also, hiding the scrollbar prevents the scroll wheel on the mouse from working on hover. You have to click before the scroll wheel will work. This is not the case for the other text areas on that page.
    – 17 of 26
    Commented Oct 22, 2013 at 15:25

3 Answers 3


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.

  • Good answer. I think the most important part of this is the fact that scrollbars provide information to the user even when they don't have focus.
    – 17 of 26
    Commented Oct 22, 2013 at 15:20
  • @17of26 Now I agree...still wish they weren't so ugly though.
    – Justin
    Commented Oct 22, 2013 at 20:51

this wild text areas aren't very welcoming, my preference for this input is to use an autoresize script.

no content = small text area (1 or 2 rows), growing up with content http://www.jacklmoore.com/autosize/

  • 1
    I agree with you, but this question is specific to does it create a bad experience to take away scroll bars on blur?
    – Justin
    Commented Oct 21, 2013 at 19:31
  • 1
    since you can't use your mouse scroll button to check the hidden content without focusing the field, i think it's not improving the default behavior, that's why i prefer to save space on empty field and show all of the content on the others. Commented Oct 21, 2013 at 19:37

If you could prevent the text from wraping at the inserted scrollbar, I would prefer using :hover to display it.

Another idea would be to display the scrollbar only if you move the mouse or its wheel. But this will need some JavaScript magic, I guess.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.