984275 - Computed property 'overflow' of scrolled textarea is 'visible' instead of 'scroll'

Status: UNCONFIRMED

(Core :: CSS Parsing and Computation, defect, P5)

Description

[Dan Dascalescu]

Attachment: textarea-overflowY-should-be-scroll.html

Firefox should correctly return the value of the `overflow` property if the textarea has a scrollbar. That is, return `scroll` (or `auto`) instead of always `visible`. IE and WebKit correctly return `scroll` for a textarea that contains more rows than are currently visible.

*Applying* a property is a different story (bug #212763), but returning "scroll" when in fact the textarea is scroll, should be straightforward.

Comment 1

[Boris Zbarsky [:bzbarsky]]

The computed value of overflow shouldn't depend on the amount of content in the textarea.

It looks like Chrome does something that can't actually be described in CSS here: the computed textarea overflow is "auto" if the specified value is "visible", but other specified values actually change the computed value.  I have no idea what exactly IE does here.

Given that per spec this is a replaced element and hence that the scrolling actually has very little to do with CSS per spec, it's not clear to me that you should be expecting any particular behavior here.  If anything, you should expect the one behavior the spec _does_ require for the "overflow" property: the computed value is the same as the specified value.  Which is what we implement.

Comment 2

[gibwalker]

It would be incredibly helpful if scroll: visible could be set on textarea elements. It's mind-boggling that this can't be done.

Comment 3

[:Gijs (he/him)]

(In reply to gibwalker from comment #2)

It would be incredibly helpful if scroll: visible could be set on textarea elements. It's mind-boggling that this can't be done.

This bug is about the overflow property so I would suggest filing a separate bug for this.

Comment 4

[gibwalker]

(In reply to :Gijs (he/him) from comment #3)

(In reply to gibwalker from comment #2)

It would be incredibly helpful if scroll: visible could be set on textarea elements. It's mind-boggling that this can't be done.

This bug is about the overflow property so I would suggest filing a separate bug for this.

I'm so sorry, I meant overflow: visible

Comment 5

[:Gijs (he/him)]

(In reply to gibwalker from comment #4)

(In reply to :Gijs (he/him) from comment #3)

(In reply to gibwalker from comment #2)

It would be incredibly helpful if scroll: visible could be set on textarea elements. It's mind-boggling that this can't be done.

This bug is about the overflow property so I would suggest filing a separate bug for this.

I'm so sorry, I meant overflow: visible

OK, that still sounds like a different bug though - specifically, bug 212763. This was mentioned in comment 0 of this bug:

(In reply to Dan Dascalescu from comment #0)

Applying a property is a different story (bug #212763)

I'll follow up there.

Comment 6

[gibwalker]

You're absolutely right Gijs, but I couldn't comment on that other thread since it is closed (or at least I couldn't figure out how to, it says I don't have permission to comment on a closed bug). If that's reopened maybe I can move this comment over?

As for comment 26 that you referred to in that thread that said "Textarea should always be scrollable, I don't think any other browser does something different here."

• I have to say this comment is missing the point entirely. Textarea is already always scrollable (just like any other element), and it does this beautifully by default. What it can NOT do (that almost every other element can) is be unscrollable when desired. No one is saying scrollbars are bad, they're just saying that use cases exist where we don't want them.

There is simply no input element that is multiline and can also be styled how a developer wants. I'd argue that making overflow:visible possible on a textarea is very helpful for developer A and doesn't detract from it being always scrollable for developer B. I can go the route of contenteditable divs etc, but it's super messy for all kind of other reasons that I'm sure you're aware of (javascript frameworks like Vue js for example, have all kinds of native support for input that they don't for divs for instance).

Two simple use cases:

1. I want to print a page containing overflowing user input in textareas directly to pdf:
   @media print{
   TEXTAREA {overflow:visible;}
   }

2. A wysiwyg visual design (imagine a postcard) where users need to be able to both input text AND resize the element itself. You can see right away if users can resize the element, it is incredible helpful to not have scrollbars popping up all over the place. The visual design needs to have no scrollbars whatsoever, but making contenteditable divs is a much messier solution and isn't as accessible etc.

Anyway, hope this context is a bit more helpful. Happy to elaborate on anything else if needed.

My appologies for posting in the wrong place - still haven't managed to figure out how to edit these comments.