Closed
Bug 55285
Opened 24 years ago
Closed 22 years ago
[FIX]newlines within <button> (and <input type="button">) are displayed
Categories
(Core :: Layout: Form Controls, defect, P1)
Core
Layout: Form Controls
Tracking
()
RESOLVED
FIXED
mozilla1.3alpha
People
(Reporter: jruderman, Assigned: bzbarsky)
References
Details
(Keywords: regression, relnote, testcase, Whiteboard: WONTFIX ? -- minor issue, will be fixed by XBL widgets | relnote-devel (py8ieh:make sure regression tests check this!))
Attachments
(4 files, 1 obsolete file)
20 bytes,
text/html
|
Details | |
733 bytes,
text/html
|
Details | |
289 bytes,
text/html
|
Details | |
643 bytes,
patch
|
john
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
Mozilla displays <button>a b</button> as /-\ |a| |b| \-/ instead of /--\ |ab| \--/ .
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
Dump Content shows "a\nb". Reassigned to Parser. (Why was this bug assigned to Ian?)
Assignee: ianh → rickg
Component: HTML Form Controls → Parser
QA Contact: bsharma → janc
Comment 3•24 years ago
|
||
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!
Assignee: rickg → py8ieh=bugzilla
Priority: P3 → P4
Whiteboard: (py8ieh:research)
Target Milestone: --- → Future
Comment 5•24 years ago
|
||
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.
Blocks: html4.01
Component: Parser → HTML Form Controls
Keywords: correctness,
relnote
QA Contact: janc → lorca
Whiteboard: (py8ieh:research) → (py8ieh:make sure regression tests check this!)
Updated•24 years ago
|
Whiteboard: (py8ieh:make sure regression tests check this!) → relnote-devel (py8ieh:make sure regression tests check this!)
Comment 6•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
Endorsing for nsbeta1. Correctness of HTML data handling.
Comment 9•24 years ago
|
||
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Updated•24 years ago
|
Keywords: mozilla1.0
Comment 10•24 years ago
|
||
_really_ reassigning to Marc. Marc: I suggest WONTFIX as this will eventually be fixed by the XBL widgets.
Whiteboard: relnote-devel (py8ieh:make sure regression tests check this!) → WONTFIX ? -- minor issue, will be fixed by XBL widgets | relnote-devel (py8ieh:make sure regression tests check this!)
Reporter | ||
Comment 11•23 years ago
|
||
How about making this bug depend on the xbl widgets bug?
Comment 12•23 years ago
|
||
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.
Assignee: ian → attinasi
Depends on: 37193
Summary: newlines within <button> are displayed → newlines within <button> (and <input type="button">) are displayed
Comment 13•23 years ago
|
||
*** Bug 79863 has been marked as a duplicate of this bug. ***
Comment 15•23 years ago
|
||
Comment 16•23 years ago
|
||
Isn't there a special pre with nowrap? I thought I remembered peterl showing me this ages ago.
Comment 17•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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 22•23 years ago
|
||
Shouldn't this be fixed by 1.0 ? bug 57209 is targeted for 1.1!
Reporter | ||
Comment 23•23 years ago
|
||
Sounds related: bug 61902, [BTN]<button> should softwrap contents.
Comment 24•22 years ago
|
||
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.
Reporter | ||
Comment 25•22 years ago
|
||
*** Bug 145001 has been marked as a duplicate of this bug. ***
*** Bug 169852 has been marked as a duplicate of this bug. ***
Comment 27•22 years ago
|
||
Regression has occurred. Now we are destroying everything after the first newline in the <input> buttons.
Keywords: regression
Assignee | ||
Comment 28•22 years ago
|
||
A of the checkin for bug 167236, the regression is no more and neither is the problem bug 37193 was trying to address.
Assignee: attinasi → bzbarsky
Status: ASSIGNED → NEW
Assignee | ||
Updated•22 years ago
|
OS: Windows 98 → All
Priority: P4 → P1
Hardware: PC → All
Target Milestone: Future → mozilla1.3alpha
Assignee | ||
Comment 29•22 years ago
|
||
Assignee | ||
Updated•22 years ago
|
Attachment #106069 -
Flags: superreview?(dbaron)
Attachment #106069 -
Flags: review?(jkeiser)
Assignee | ||
Updated•22 years ago
|
Summary: newlines within <button> (and <input type="button">) are displayed → [FIX]newlines within <button> (and <input type="button">) are displayed
Comment 30•22 years ago
|
||
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.
Attachment #106069 -
Flags: review?(jkeiser) → review-
Comment 31•22 years ago
|
||
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.
Assignee | ||
Comment 32•22 years ago
|
||
Comment on attachment 106069 [details] [diff] [review] the obvious patch Ok. Agreed.
Attachment #106069 -
Flags: superreview?(dbaron) → superreview-
Assignee | ||
Comment 33•22 years ago
|
||
Attachment #106069 -
Attachment is obsolete: true
Assignee | ||
Updated•22 years ago
|
Attachment #106134 -
Flags: superreview?(dbaron)
Attachment #106134 -
Flags: review?(jkeiser)
Updated•22 years ago
|
Attachment #106134 -
Flags: review?(jkeiser) → review+
Comment 34•22 years ago
|
||
r=hixie, as if you needed it
Attachment #106134 -
Flags: superreview?(dbaron) → superreview+
Assignee | ||
Comment 35•22 years ago
|
||
fixed
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 36•22 years ago
|
||
*** Bug 188520 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•