Closed Bug 106682 Opened 24 years ago Closed 22 years ago

Rendering error for forms with multiple 100% width table cells

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: mozilla, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: highrisk)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011 BuildID: 20011011 If I create a form with multiple 100% width cells in the same row, then when includign a form in one of the rows, the submit button and images are never kept on the same line, even if there is plenty of space. A near-minimal example can be found on http://pieter-bas.ijdens.com/tmp/deformed.html. The page is shown correctly in both IE and Netscape 4. The result of displaying this page in a sufficiently wide browser screen must be that in all cases all form elements (input box and blue arrow) are on the same line. Note: Also a 'submit' or any other kind of button is moved to the next line. This is *not* exclusive for images. Other form elements suffer from the same problem. Reproducible: Always Steps to Reproduce: 1. Browse to the link http://pieter-bas.ijdens.com/tmp/deformed.html Actual Results: The little blue arrow was not on the same line as the input box. [this is actually part of a larger page, where this is the search box construct, therefore the mis-renderign is very annoying] Expected Results: The little blue arrow must stay on the same line as the input box, provided the page is wide enough.
> If I create a form with multiple 100% width cells in the same row You realize that this means the form is overconstrained and the browser should randomly choose which 100% settings to ignore? :) Over to HTML tables.
Assignee: rods → karnaze
Component: HTML Form Controls → HTMLTables
QA Contact: madhur → amar
I think it doesn't have anything to do with this bug but in your testpage the > in <html> is missing. Just wanted to notice that ;)
I added a second page, which more clearly shows the bug. After receiving comments on the bad html in the first (too quickly created) sample. This sample appears to be more or less correct HTML. I left in the overconstrained table (2 * 100% width columns) but also added a table which only has one 100% column, but also triggers this rendering error. The URL is: http://pieter-bas.ijdens.com/tmp/deformed_ok.html
confirmed
Status: UNCONFIRMED → NEW
Ever confirmed: true
This doesn't seem to be a bug. I think our algorithm is trying to give as much space to the width=100% cell as possible, and is wrapping between image and input to do so. This can be suppressed by setting the nowrap attribute on the td. Closing as INVALID.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
The following argument is not technical, but it's rational instead: I understand the actions of your algorithm. It attempts to give the 100% width cell all the space and therefore wraps he other cells where possible. As far as I can see this behavior is correct and is exactly what other browsers do with normal cells with text and images in tables. However, other browsers make an exception for the case shown here where a form submitting element is wrapped around. Therefore, the question is, is it right to knowingly introduce an incompatibility between Mozilla and the other browsers? Another question is: What is the impact of this incompatibility? Internet explorer shows these pages as intended by the author. Netscape 4 shows these pages as intended by the author And I remember testing it on Opera as well, but I cannot 100% certainly say that this was rendered correctly. Because of this, I would say that many developers will be un-aware of this difference and thus the impact of this incompatibility is high. So, I would like to re-open the bug because I think the real question is 'if knowingly introducing an incompatibility, especially in a technique that is used more often by designers, is right or wrong'. In my opinion this is wrong. Developers of current pages will be unaware of this issue and therefore Mozilla will incorrectly display their pages. Mozilla will be blamed for this. I suggest you at least take action to see if the specification does suggest or enforce making an exception for these specific form elements [submit buttons and images], and otherwise figure out why other browsers make this rendering decission. I would "strongly recommend" you to render these samples the same as other browsers do, and treat these form elements as if they are non-breakable.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
> figure out why other browsers make this rendering decission. Very simple. The "other browsers" have, in my experience" a much narrower concept of allowed places to line-break. In my testing they will never break between two form controls unless there is a space in the source between them. This actually makes it very hard to create designs that resize usefully with the viewport (because stuff that should wrap just does not). Pages which really care about disallowing wrapping use "nobr" (or "white-space: nowrap" if they care about standards) on the <td>. All that aside, I agree that this particular instance bears investigation, especially in quirks mode.
This bug is very similiar to bug 97619. This has been the worst enterprise I've been involved at mozilla. Fixing the bug means to reimplement the bugs from IE. Reassigning to Marc, even if it could hurt our good patchee/sr relationship. The fix of this bug includes a high risk as shows the history of bug 97619. I doubt, it is good to take this risk before 1.0. This will be ugly and and cause a bunch of regressions. Unless you have WRMB pressure like hell, don't do this ( my prefered resolution is WONTFIX, as standard compliant pages can easily deal with that).
Assignee: karnaze → attinasi
Status: REOPENED → NEW
Keywords: highrisk
Severity: major → normal
Target Milestone: --- → Future
Well, Marc's certainly not going to fix this; resolving WONTFIX, since Bernd is one of the few people who knows what's going on in table layout and this hasn't attracted strong negative attention.
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.