55285 - [FIX]newlines within <button> (and <input type="button">) are displayed

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect, P1)

Description

[Jesse Ruderman]

Mozilla displays

<button>a
b</button>

as

/-\
|a|
|b|
\-/

instead of

/--\
|ab|
\--/

.

Comment 1

[Pierre Saslawsky]

Attachment: testcase

Comment 2

[Pierre Saslawsky]

Dump Content shows "a\nb".
Reassigned to Parser. (Why was this bug assigned to Ian?)

Comment 3

[Hixie (not reading bugmail)]

Pierre: it was assigned to me because I asked it to be filed and assigned to me.
I am entirely unsure that this is a bug. The parser is doing the right thing,
the problem is almost certainly that we have a 'white-space' rule somewhere
that is affecting buttons, possibly hardcoded in the widget code. If this is the
case then this error will just drop out when we XBLify widgets.

What's more, I am unsure what the expected default UA style (per HTML) should 
be. Thus I do not know if this is really a bug at all or not.

Taking the bug back. Thanks Jesse!

Comment 4

[Hixie (not reading bugmail)]

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

Comment 5

[Hixie (not reading bugmail)]

Ok, I found the problem. It's my fault. :-/

In Ye Olde html.css, <input type="button"> was set to white-space:pre, and
<button> had no white-space declaration. When I merged them, I missed the
difference, and this did not get caught in any of the testing.

The fix is either to change the 'pre' in the 'button' rule to 'nowrap' or to
remove the declaration altogether. It was originally added to fix 37193, 
however it seems to me that the fix was the wrong fix.

So here we are at a crossroads:
   1. We can fix this and reopen bug 37193.
   2. We can leave the stats quo as is.

RELEASE NOTE ITEM
   Mozilla currently assumes that all white-space within a <button> element is
   significant. This can be changed as required by using stylesheets. For 
   example, to allow the text in a button to wrap, you would use this:

      button { white-space: normal; }

   Note that doing this with small labels may make buttons appear too small,
   in which case judicious use of the 'padding' and 'width' properties may
   be of use.

Reassigning to Marc, cc'ing Rod since it was his fix that originally introduced
white-space:pre into the issue, so he may be interested.

Comment 6

[Dave Nichols]

The key part of the HTML 4.01 spec seems to be this:
"Buttons created with the BUTTON element function just like buttons created with
the INPUT element, but they offer richer rendering possibilities: the BUTTON
element may have content. For example, a BUTTON element that contains an image
functions like and may resemble an INPUT element whose type is set to "image",
but the BUTTON element type allows content."
http://www.w3.org/TR/html4/interact/forms.html#edef-BUTTON

If a newline counts as 'content' then this 'allows' a newline to be displayed
but doesn't seem to insist on it. The 'may resemble' suggests that that a BUTTON
with an IMG should be displayed as an INPUT with type=image - currently not the
case.

On NT, IE 5.5 and Nav 4.6 don't display the newline so I would guess that few
people would be expecting the newline to appear (it surprised me). But there
could be pages with stray newlines in which Moz would now add an unexpected
newline and alter the appearance of their BUTTONs.

Another situation to the existing testcase is when the <BUTTON> contains a
single <IMG>. Getting extra space in this case seems counter-intuitive.
I see this on NT.

So, arguments in favour of the newline appearing:

1. A newline counts as 'content' so ought to be represented on screen.

Against:

1. Consistency with IE 5.5 and Nav 4.x, leading to
2. Possibility of altering the appearance of lots of buttons on the Web
3. The HTML spec seemingly doesn't require the newline to appear and suggests
parity with the INPUT type=image case

http://www.cs.waikato.ac.nz/~daven/vw/buttontest.html
shows several testcases (and what IE 5.5 does)

Comment 7

[Keith Lesch]

In reference to the "newline counting as content," the only argument FOR 
displaying the newline:

The ONLY element that currently displays newlines (to my knowledge) is the 
TEXTAREA.  There is no other HTML tag that renders these newlines as anything 
other than whitespace.  And all whitespace is always rendered as a single space 
when rendering a page.  This is what I believe is intended by "content" - HTML 
content, not text content.  Therefore voiding the argument "for" rendering 
physical line breaks.  The line breaks that should be rendered are the <BR>s.

Comment 8

[ekrock's old account (dead)]

Endorsing for nsbeta1. Correctness of HTML data handling.

Comment 9

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 10

[Hixie (not reading bugmail)]

_really_ reassigning to Marc.

Marc: I suggest WONTFIX as this will eventually be fixed by the XBL widgets.

Comment 11

[Jesse Ruderman]

How about making this bug depend on the xbl widgets bug?

Comment 12

[Hixie (not reading bugmail)]

Reassigning to Marc for the third time :-/

As noted above:

In Ye Olde html.css, <input type="button"> was set to white-space:pre, and
<button> had no white-space declaration. When I merged them, I missed the
difference, and this did not get caught in any of the testing.

The fix is either to change the 'pre' in the 'button' rule to 'nowrap' or to
remove the declaration altogether. It was originally added to fix 37193, 
however it seems to me that the fix was the wrong fix.

So here we are at a crossroads:
   1. We can fix this and reopen bug 37193.
   2. We can leave the stats quo as is.

Comment 13

[Hixie (not reading bugmail)]

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

Comment 14

[Marc Attinasi]

Thanks, accepting.

Comment 15

[Skewer]

Attachment: Expanded button testcase

Comment 16

[rods (gone)]

Isn't there a special pre with nowrap? I thought I remembered peterl showing me 
this ages ago.

Comment 17

[Håkan Waara]

I think <button/> should, as per the spec cited above, display content and
"real" linebreaks such as <br/>. However, it should not break for linebreaks in
the actual source code.

I will post a fix for this.

For this bit of source code:

<button>foo
bar <br/>foo</button>

It looks, roughly, like this without my fix:
_______
| foo |
| bar |
|_foo_|

with my fix:
__________
| foo bar |
|_foo_____|

Does that sounds feasible?

Comment 18

[Skewer]

That's what we need, but it won't work for <INPUT TYPE="button">. In that case,
the <BR> tag should either be escaped or removed.

Comment 19

[Hixie (not reading bugmail)]

Yes, guys, we're not disagreeing with that. However if you do that, we'd have
to reopen bug 37193. Please read my comments dated 2001-05-17 17:01, and also
those dated 2000-10-11 18:24. The reasoning behind not fixing this bug is that
with the coming of XBL form controls, the relevant code to fix this bug and the
related bug 37193 would be moot, so it would possible be a waste of time on the
long run, especially considering how many bugs we have which are _not_ going to
be obsoleted any time soon.

Comment 20

[Skewer]

Excuse me for being a little dense...

...but what is this XBL form controls, and when is it coming out? I can't find
any mention of it on the site.

Comment 21

[Hixie (not reading bugmail)]

Skewer: XBL form controls are covered by bug 57209.

Comment 22

[basic]

Shouldn't this be fixed by 1.0 ? bug 57209 is targeted for 1.1!

Comment 23

[Jesse Ruderman]

Sounds related: bug 61902, [BTN]<button> should softwrap contents.

Comment 24

[Christopher Cobb]

I'm using 1.0rc1 and see that this bug is still present.

It's quite an eye sore when a button which renders (correctly) in a single line
on IE renders in two or three or four lines in mozilla.  Granted that this will
be fixed in 1.1, I don't think that's a good reason not to fix it in 1.0,
especially if it is an easy fix.

Just my two cents.

Comment 25

[Jesse Ruderman]

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

Comment 26

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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

Comment 27

[Skewer]

Regression has occurred. Now we are destroying everything after the first
newline in the <input> buttons.

Comment 28

[Boris Zbarsky [:bzbarsky]]

A of the checkin for bug 167236, the regression is no more and neither is the
problem bug 37193 was trying to address.

Comment 29

[Boris Zbarsky [:bzbarsky]]

Attachment: the obvious patch

Comment 30

[John Keiser (jkeiser)]

Comment on attachment 106069 [details] [diff] [review]
the obvious patch

This is right for button, but not for input type=button, which *does* need
white-space: pre.

Comment 31

[John Keiser (jkeiser)]

Attachment: Testcase

This shows that IE expands spaces and newlines on <input type=button>, but does
normal white-space on <button>.  I think it can be argued that this is the
right behavior (I know it's what I expected when I was just a forms developer)
because the input takes only text and there is no other way to format it. 
Button takes arbitrary HTML and so should act like HTML.

Comment 32

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 106069 [details] [diff] [review]
the obvious patch

Ok.  Agreed.

Comment 33

[Boris Zbarsky [:bzbarsky]]

Attachment: more like this, then

Comment 34

[Hixie (not reading bugmail)]

r=hixie, as if you needed it

Comment 35

[Boris Zbarsky [:bzbarsky]]

fixed

Comment 36

[Boris Zbarsky [:bzbarsky]]

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