Closed
Bug 184478
Opened 22 years ago
Closed 22 years ago
[FIXr]The input control, when set to text, does not render its border correctly (according to the box model)
Categories
(Core :: Layout: Form Controls, defect, P1)
Core
Layout: Form Controls
Tracking
()
RESOLVED
FIXED
mozilla1.3beta
People
(Reporter: dan, Assigned: bzbarsky)
References
()
Details
Attachments
(4 files)
2.58 KB,
text/html
|
Details | |
2.48 KB,
text/html
|
Details | |
3.32 KB,
patch
|
john
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
12.04 KB,
image/gif
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 I have just encountered this problem and it is rather annoying! Mozilla obeys the proper box model, which says that an element of width 150px and border 5px wither side should occupy a space 150 + 5 + 5 = 160px. However, when using a text box, the border is rendered INSIDE the text box!!! This is behaviour I would expect from Internet Explorer! (lol!) I have done a search and no-one else seems to have picked up on this... hopefully it is a bug and will be fixed soon, because it has caused me quite a headache until realising it was a bug in Mozilla. I have created a very simple example page and placed it on one of my websites (link is above). Reproducible: Always Steps to Reproduce: 1. Create a text box (input control type set to text) 2. Set it's borders to say, 5px, and the width to say, 150px 3. Create a div element and do the same 4. Compare the two. The div renders correctly, the text box does not! Actual Results: The text box border renders INSIDE instead of OUTSIDE the boundaries set by the height and width properties. Expected Results: Mozilla should have obeyed the box model, as it does with other elements, and rendered the border OUTSIDE the element. I used XHTML for the example that I uploaded for you to see. The bug occurs regardless of the page type. I was not able to fix the bug in any way, no matter what I tried. I have a 3 day old build of Mozilla, and I have not currently got access to any other testing platform except Windows XP Pro SP1, although I got a friend to test it, and he saw the same problem. He is on Windows 98.
Reporter | ||
Comment 1•22 years ago
|
||
After some further testing and collaboration with some fellow developers, I have ascertained that this bug also applies to the implementation of the padding property on text boxes. It can be noted in exactly the same way as the border bug that I documented previously - simply alter the padding on both elements and notice that they do not respond in the same way. It is interesting to note that, for once, IE 6 gets this implementation correct for both text boxes and other elements (i.e. divs) when forced to use strict processing.
Assignee | ||
Comment 2•22 years ago
|
||
This is done on purpose, for compatibility reasons (and because the CSS box model does not really apply to form inputs anyway, it is not a violation of the spec). If you want, there is a CSS3 property called "box-sizing" that is used to affect this; the Mozilla implementation is called -moz-box-sizing since the property is not yet part of a candidate recommendation. In other words, setting -moz-box-sizing: content-box should do what you want (if you care, you can do "* { -moz-box-sizing: content-box }" to have it apply to all elements, such as iframes and such, which set box-sizing.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 3•22 years ago
|
||
Well, I am not convinced that this should not be treated as a bug. If this is intentional, 'for compatibility reasons', then I am not too impressed... surely the more appropriate method would be to OBEY the same implementation as every other object, and provide your workaround for those uses that require this alternate rendering method...? Plus, as IE is the most used browser, and renders this correctly (or, what I see as correctly!) I think that even for compatibility, this should be changed. So I still think is is wrong, whether bug or mistake.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Assignee | ||
Comment 4•22 years ago
|
||
Yeah, I just read the part about IE6 doing it differetly in standards mode... Confirming pending testing on MacIE as well. Taking.
Assignee: form → bzbarsky
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Assignee | ||
Comment 5•22 years ago
|
||
Verdict is: 1) IE/Mac uses content-box sizing for all of those. 2) IE6/Windows uses content-box sizing for text/password/textarea inputs only and only in standards mode.
Assignee | ||
Comment 6•22 years ago
|
||
Assignee | ||
Comment 7•22 years ago
|
||
Assignee | ||
Comment 8•22 years ago
|
||
John? David? fantasai? Ian? Thoughts?
Assignee | ||
Updated•22 years ago
|
Priority: -- → P3
Summary: The input control, when set to text, does not render its border correctly (according to the box model) → [FIX]The input control, when set to text, does not render its border correctly (according to the box model)
Target Milestone: --- → mozilla1.3beta
Assignee | ||
Comment 9•22 years ago
|
||
Comment on attachment 108770 [details] [diff] [review] something like this hixie say's r=him on this change...
Attachment #108770 -
Flags: superreview?(dbaron)
Comment on attachment 108770 [details] [diff] [review] something like this Will this break radio buttons and checkboxes badly? (Do the border properties work on them? Not that I think they should work on any form controls...) This seems to make hidden inputs quirkier than before, and perhaps others as well.
Assignee | ||
Comment 11•22 years ago
|
||
Comment on attachment 108770 [details] [diff] [review] something like this This won't affect radio or checkboxes at all -- that's why I added the box-sizing declaration to that decl block. And no, the border properties don't really work on them (or rather we have a !important rule preventing them from being changed). But the padding does work, as the testcases show. You're right that this makes the hidden input more quirky than before. If we care, I could add an explicit rule to quirk.css overriding the box sizing (like we used to have in html.css). But I'm not sure we really need to worry about the rendering of <input type="hidden"> on all those quirks-mode pages where someone changes it from display:none... ;)
Comment 12•22 years ago
|
||
FWIW, Opera 7 seems to use content-box sizing for everything except textarea. Some things render a little weird inside the box, though...
Updated•22 years ago
|
Attachment #108770 -
Flags: review+
Comment 13•22 years ago
|
||
This bug (or a very near friend to it) breaks perfectly sensible html-forms interfaces. It _is_ a bug, and it _affects_ usability. For instance, the "domain deletion" interface at zoneedit.com. It is not possible to enter text into this weird sliver that is supposed to be a text input.
Assignee | ||
Comment 14•22 years ago
|
||
That page has nothing to do with this one that I can tell (neither the border or the padding are set on that text input). Further, IE5.x/Windows has this same exact bug, and I doubt that page is broken in it....
Comment on attachment 108770 [details] [diff] [review] something like this sr=dbaron. I guess on the controls where we allow the border to be stylable we should be doing content-box. (Is that the guideline this is following?) I'm against the border being stylable, but given that it is, this makes sense.
Attachment #108770 -
Flags: superreview?(dbaron) → superreview+
Assignee | ||
Comment 16•22 years ago
|
||
Right now the guideline I'm following is "render like IE", which is a common theme of our existing form control implementation... eg, we allow the border on buttons to be stylable, but this patch leaves them as border-box...
Priority: P3 → P1
Summary: [FIX]The input control, when set to text, does not render its border correctly (according to the box model) → [FIXr]The input control, when set to text, does not render its border correctly (according to the box model)
Assignee | ||
Comment 17•22 years ago
|
||
fixed
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•