212763 - overflow: visible on textarea isn't applied

Status: RESOLVED WONTFIX

(Core :: Layout: Form Controls, defect)

Description

[Matthew Cheale]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

Setting "overflow: visible" on a textarea does sod all and behaves the same as
"overflow: scroll".

Reproducible: Always

Steps to Reproduce:

Comment 1

[Matthew Cheale]

Attachment: Three textareas with different overflow settings.

The top one shouldn't have scrollbars, it should just display all the text.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Frankly, it's not clear to me what overflow:visible should do, given that
<textarea> is a replaced element.

Comment 3

[Josh Birnbaum]

this seems similar in concept to bug 171315, which was marked invalid.

Comment 4

[Andreas Reichert]

Hmmmm - in my Opinion visibilty means to be visible - not hidden behind scrolled
content....

Comment 5

[Raúl]

Attachment: Three textareas expands with internet explorer but not with mozilla, with overflow in visible mode.

Comment 6

[Raúl]

Here is what says W3C:
http://www.w3.org/TR/1998/WD-css2-19980128/visufx.html

Comment 7

[Bill Mason]

bz: re your comment 2, since overflow now applies to replaced elements in the
current CSS 2.1 draft, does that change anything with this bug?

Just ran into this issue today, and would like to see if it really is an issue
or if this should be invalidated.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Actually, I have no idea how overflow is supposed to apply to replaced
elements... I'll send mail asking about that.

Comment 9

[Boris Zbarsky [:bzbarsky]]

The usual thing; there is no consensus in the WG on the matter.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Note that if I _do_ change things so overflow:visible applies to textarea, we
crash.  So if someone wants to do this they'd need to sort that part out.

Comment 11

[Boris Zbarsky [:bzbarsky]]

*** Bug 244850 has been marked as a duplicate of this bug. ***

Comment 12

[sean]

Attachment: XHTML 1.1 test case including @media print rule

http://www.w3.org/TR/2004/CR-CSS21-20040225/visufx.html#overflow says that
overflow applies to inline-block elements.
http://www.w3.org/TR/2004/CR-CSS21-20040225/sample.html suggests that textarea
should be an inline-block by default. I'm not sure if standards compliance mode
vs. quirks mode is at all an issue here, but this attachment is XHTML 1.1 and
CSS 2.1. Also, it includes a second rule to test @media print. I tested this
with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040615
and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206
Firefox/0.8.

Comment 13

[Anne (:annevk)]

Ian, any suggestions?

Comment 14

[Hixie (not reading bugmail)]

Treating <textarea>s as being equivalent to bindings that style the <textarea> 
as an inline-block with 'overflow: scroll' (or 'auto', or similar) with editor 
behaviour inside, is what I would recommend here.

By that reasoning, setting 'overflow' to 'visible' on a <textarea> should work 
the same as setting it on any 'inline-block'.

It wouldn't be very useful though...

Comment 15

[Patrick Geiller]

I ran into this bug while making an <input> autosize to its contents. In 
Firefox, <input> and <textarea> share the same problem - overflow : visible 
won't work, and their scrollWidth/scrollHeight is not updated while typing 
(Internet explorer updates them), so there is no easy way even with javascript.

Right now, i'm duplicating the <input> contents into an invisible <span>, 
measuring its width and assigning it to the <input>. I hope for a better way :)

Comment 16

[Gunar Werner]

I do not understand why this bug doesn't get fixed or even recognized as bug.
The standards clearly state that all inline-block elements are visible by
default with the exceptions of input which ist set to hidden and textarea which
is set to auto. But that doesn't mean visible shouldn't be possible for textarea
or for that matter that visible would mean scroll oder auto for textarea.
Please, please, I beg you, fix it.

Comment 17

[Hixie (not reading bugmail)]

While I agree that in theory eventually this should be fixed, I don't see why
any author would ever want this effect. It seems rather useless.

Comment 18

[cho]

(In reply to comment #17)
> While I agree that in theory eventually this should be fixed, I don't see why
> any author would ever want this effect. It seems rather useless.

We use for simple content editing of text-paragraphs in some of our
intranet-tools. In this case it is very usefull for the textarea (and input) to
expand/retract to the needed size. This, used with border: 0, gives quite a good
illusion of WYSIWYG.

Comment 19

[Boris 'lovchy' Bezrukov]

(In reply to comment #17)
> While I agree that in theory eventually this should be fixed, I don't see why
> any author would ever want this effect. It seems rather useless.

Quick sample: Table having two columns. First contains original text, second --
textarea. Making textare 'overflow: visible' and div containig table scrollable
we will get possibility to scroll both text instances together. It's probably
useless for sites, but is not for web-services making available to implement
complicated forms. This bug fix in 1.8 branch would be great addition to bug
97283 which is already fixed there.

Comment 20

[Guillaume Crico]

(In reply to comment #17)
> While I agree that in theory eventually this should be fixed, I don't see why
> any author would ever want this effect. It seems rather useless.

It is very Useful !
It makes "simple paragraph editing" app building easy.
And, in some case, it is also more usuable to display the whole text, for
example for printing.

Comment 21

[Martijn Wargers (dead)]

Attachment: testcase4

I think everybody wants this effect, which you can see in this testcase.
When pressing enter a few times, the textarea grows. (the testcase is just a
buggy way of trying to mimick this behavior)

This is something that happens with IE6 when setting the css property of a
textarea to overflow:visible.
But I think Mozilla should be doing this when the css property height is set to
auto.

Comment 22

[Dricks]

2010 and still unable to print a form with textareas showing their full content ?

An easy and simple

@media print{
TEXTAREA {overflow:visible;}
}

would be usefull.

Too bad it's much more important to have rounded corners and shadows.
Eye candy > functional  on the web?
Damn!

Comment 23

[Ioana (away)]

WFM:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0

All testcases work the same as in IE 10. Full content of textareas like the one in testcase4 is displayed.

Comment 24

[Martijn Wargers (dead)]

With IE9, the first textarea expands on https://bugzilla.mozilla.org/attachment.cgi?id=127810
Indeed, with IE10, that doesn't happen anymore.

It's more the question, if Firefox should be doing anything with overflow values on textareas.
Since there are nowadays resizers on textareas, it's not really important, I think.

Perhaps this bug should become WONTFIX?

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 12 votes.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 26

[Emilio Cobos Álvarez (:emilio)]

Textarea should always be scrollable, I don't think any other browser does something different here.

Comment 27

[:Gijs (he/him)]

(In reply to gibwalker from bug 984275 comment #2)

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

Can you elaborate on why? comment #26 seems reasonable to me but if there's something we're missing, understanding that would be useful.

Comment 28

[:Gijs (he/him)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #26)

Textarea should always be scrollable, I don't think any other browser does something different here.

Turns out people can't comment on closed bugs anymore without editbugs, so the person commenting in 984275 couldn't reply to my needinfo here. But they wrote:

(In reply to gibwalker from bug 984275 comment #6)

Two simple use cases [for using overflow:visible on a textarea]

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.

These seem reasonable to me at first glance. Is this something that the CSSWG (or whoever makes calls like this) could reconsider, and/or could we reopen this bug?

Comment 29

[Emilio Cobos Álvarez (:emilio)]

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

(In reply to Emilio Cobos Álvarez (:emilio) from comment #26)

Textarea should always be scrollable, I don't think any other browser does something different here.

Turns out people can't comment on closed bugs anymore without editbugs, so the person commenting in 984275 couldn't reply to my needinfo here. But they wrote:

(In reply to gibwalker from bug 984275 comment #6)

Two simple use cases [for using overflow:visible on a textarea]

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

But that wouldn't move e.g. elements at the bottom of the textarea, it'd just overlap with the overflowing content. It seems what you really want is a way to auto-size the textarea to its contents, which is https://github.com/whatwg/html/issues/6807

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.

Hiding the scrollbars with scrollbar-width: none seems like it'd solve this one right?

These seem reasonable to me at first glance. Is this something that the CSSWG (or whoever makes calls like this) could reconsider, and/or could we reopen this bug?

At a glance what most people want is auto-sizing. overflow: visible doesn't give you much if your size doesn't change with your contents. If we were to allow overflow: visible on textarea, I suspect the biggest issue here is going to be backwards compatibility. You could make the same case for <input type=text> and other replaced elements as well, right?

But if there's a good use case for that then a new html issue like the one linked above is the way to go.