[FIXr]The input control, when set to text, does not render its border correctly (according to the box model)

RESOLVED FIXED in mozilla1.3beta



16 years ago
10 years ago


(Reporter: dan, Assigned: bzbarsky)



Firefox Tracking Flags

(Not tracked)




(4 attachments)



16 years ago
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.

Comment 1

16 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
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

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.
Last Resolved: 16 years ago
Resolution: --- → INVALID

Comment 3

16 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.
Resolution: INVALID → ---
Yeah, I just read the part about IE6 doing it differetly in standards mode... 
Confirming pending testing on MacIE as well.

Assignee: form → bzbarsky
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Created attachment 108768 [details]
comprehensive testcase -- standards

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
    only in standards mode.
Created attachment 108769 [details]
comprehensive testcase -- quirks
Created attachment 108770 [details] [diff] [review]
something like this
John? David? fantasai?  Ian?  Thoughts?


16 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
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
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

16 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...
Attachment #108770 - Flags: review+

Comment 13

16 years ago
Created attachment 109156 [details]
the bug in action, destroying usability of an interface

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.
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


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+
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)
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED


10 years ago
Duplicate of this bug: 398716
You need to log in before you can comment on or make changes to this bug.