Closed Bug 55927 Opened 25 years ago Closed 23 years ago

CSS width: auto is not working correctly

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID
Milestone:
Future

People

(Reporter: djoham, Assigned: rods)

Details

(Keywords: css3, testcase)

Attachments

(2 files)

test case
925 bytes, text/html
Details
test case with display: block included in the styles
1.00 KB, text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.15-4mdk i686; en-US; m18) Gecko/20001009 BuildID: 2000100906 CSS 1 states: The horizontal position and size of a non-floating, block-level element is determined by seven properties: 'margin-left', 'border-left', 'padding-left', 'width', 'padding-right', 'border-right' and 'margin-right'. The sum of these seven is always equal to the 'width' of the parent element. Mozilla does not seem to be following this rule. In the cases where the width is greater than what seems to be the default width of the element, the element is not resized. Reproducible: Always Steps to Reproduce: Open the test case I'll submit. Notice that the SELECT and the INPUT (that use width: auto) are not fully sized to the width of their parent element (in this case, the TD). The HR is rendered correctly, but uses width: 100% Actual Results: The SELECt and INPUT elements are not resized Expected Results: I would expect to see the SELECT and INPUT elements be resized to be just as wide as the TD tag since I'm not specifying any of the other attributes that are supposed to add up to the width of the element. Even if I do specify them to zero, the element does not render properly. I consider this a major problem since there are a number of issues with width: 100% in Mozilla. Also, it seems that width: auto is a more "correct" solution than width: 100%. Table layouts are also a very popular technique for rendering pages.
Attached file test case —
For width:auto to work you have to also say display:block.
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
<RANT type="frustration"> Ian, I have to admit to no small amount of frustration here. All I want is a silly HTML element to be the same bloody size as its containing TD tag. I feel like I'm asking for the world. Am I? I *have* tried display: block in the SELECT and INPUT tags and it still doesn't do what I want. In fact, it changes nothing. Do I need to put it somewhere else? I've also tried the following DTD's (with the display:block included) <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.2//EN"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Strict//EN"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> to no effect. Cussing didn't help either. Please don't take this the wrong way, but since I'm playing the part of QA, it is up to the developers to show me that my bug is invalid. Can *someone* please show me how to do what I'm trying to accomplish in Mozilla. If it can be done, I'll be happy to close the bug, eat crow and write a lengthy README and HOWTO. In the mean time, I'm reopening the bug and submitting a new testcase that includes display: block for the INPUT and SELECT elements. </RANT>
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Sorry to have caused frustration, that wasn't my intention at all! I should have checked that we did indeed do it as I said with width:auto. Of course, we do not, because those elements are so-called replaced elements, and replaced elements have intrinsic widths which get used when 'width' is set to 'auto'. Oops. The way to get it to work in Mozilla is: -moz-box-sigin: border-box; width: 100%; margin: 0; That does work, I just tried it. ;-) I may bring this up with the working group when we rework the box model. This may also change if we move away from replaced elements for form widgets.
Pawning this off on Hixie since its more his area.
QA Contact: lorca → py8ieh=bugzilla
Thanks Ian. Sorry if I was a little rough on you there. I would appreciate your bringing this up to the working group. Developers *need* cross platform methods for laying out web pages. Especially with tables, since that's about the only layout manager we have. What we have now borders on insanity. width: auto (as you originally described it and I read it in the CSS specs) Mozilla : no or use proprietary extension IE: no width: 100% Mozilla : partial doesn't work well for some elements in Mozilla button - hopefully fixed with my patch IFRAME - must use proprietary Mozilla extension IE: works dandy Height: 100% Mozilla: no (another bug which is not making any progress) IE 4x-5.01: yes IE 5.5: no (ARGH!!!!!) I develop web applications (not web pages) for a living. It is very painful trying to lay pages out that will scale with screen resolution without these properties being implemented correctly. IE does a fair job (minus the height thing which may just be my computer) but franky, Mozilla is a struggle. I'm always having to hack something just to make it look acceptable, or even work at all ( see bug 55987 bug 54469 bug 55913 and bug 34297 for good examples). The promise of Mozilla was a fully standards compliant browser that would be a pleasure to program for. It's not turning out that way. This is not a good method of winning developers back :) Is there anything I can do to help Netscape understand this issue better? I understand the commercial need to ship a product, but I push browsers really hard and Mozilla is just *not* ready. IE generally is up to the task and Mozilla is getting (much) better, but it still falls a little short. I'm very afraid that we'll ship Nav 6 before the kinks are worked out. Assuming AOL starts using Netscape as their default browser, this will result in me being stuck with 2 more years of hacks so that every AOL'r who decides not to upgrade can still use my system. Waiting even a couple more months and shipping a really stable product could really help address this problem. Hmmm. quite a sermon. Sorry. Just needed to get this off my chest. Please let me know if I can help in any way - including coming to CA and speaking (or preaching) to the working group myself, if needed. David
So is this bug just about form controls? Frankly, CSS (1 or 2) doesn't describe form controls, so you can't really say how *any* CSS properties should apply to them. Our support is probably the worst choice -- we apply things haphazardly. IMO, we should either not apply CSS to form controls at all (my preference), or make careful decisions about what we do and don't support. Or is this bug about something other than form controls?
As I understand it, this bug is invalid. The original report is based on an incorrect statement that I made, and which forgot that form controls were considered replaced elements. Given that they are, width:auto should not make them as wide as their parent. Another way to do this would be to place each form control in its own block, remove the borders/padding/margins on the form controls, and give the form controls width:100% and the block width:auto. There you have a fully standards compliant solution.
Ian, that's an interesting solution. Could you please (in your spare time) give me a code sample of what putting an HTML form control in its own block might look like? I'm not familiar with that syntax. Do you mean a SPAN or DIV? Marking later as I still think this issue needs to be addressed one way or the other. Any problems with that? David
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → LATER
Document fragment: <div> <input type="text"> </div> Style: div { width: auto; display: block; } input[type="text"] { margin: 0; padding: 0; border: none; width: 100%; }
Status: RESOLVED → VERIFIED
Aargh. LATER and REMIND are deprecated. Is there a bug here, or not?
There is a bug, but its more of a "we need to take a closer look at this in the future" bug rather than something that needs to be fixed now. I would disagree with an INVALID marking because something needs to be done, but if that's all we have, then go ahead. David
Since you say there's a bug here, I'm reopening and marking Future.
Status: VERIFIED → UNCONFIRMED
Resolution: LATER → ---
Target Milestone: --- → Future
setting bug status to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
XML/DOM team's turn to triage Clayton's bugs.
Assignee: clayton → joki
Changing to HTML Form Controls. Fixing this should really wait for CSS3 to define (or not) this stuff.
Assignee: joki → rods
Component: HTML Element → HTML Form Controls
Keywords: css3
QA Contact: ian → bsharma
Status: NEW → ASSIGNED
width: 100% with selects renders incorrectly as well. Konqueror and IE both get it right. Any idea when this is going to get put back on the radar? It's silly bugs like this that are the most annoying to deal with :(
Priority: P3 → --
FWIW, whether this bug is ultimately valid or not: reconfirmed using FizzillaCFM/2002071508. Setting All/All.
Keywords: testcase
OS: Linux → All
Hardware: PC → All
Could you attach a testcase showing the incorrectness with width:100%?
I just checked my old test cases with Konq, Moz 1.3a and IE6. They all render the thing the same. I would say consistancy indicates the lack of a bug. I'm OK with closing it
Marking invalid. If or when CSS3 actually defines something, please file bugs on it.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: