Closed
Bug 184478
Opened 23 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•23 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•23 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: 23 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 3•23 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•23 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•23 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•23 years ago
|
||
![]() |
Assignee | |
Comment 7•23 years ago
|
||
![]() |
Assignee | |
Comment 8•23 years ago
|
||
John? David? fantasai? Ian? Thoughts?
![]() |
Assignee | |
Updated•23 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•23 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•23 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•23 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•23 years ago
|
Attachment #108770 -
Flags: review+
Comment 13•23 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•23 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: 23 years ago → 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•