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

Status: RESOLVED FIXED

Description

[Dan Williams]

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

[Dan Williams]

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.

Comment 2

[Boris Zbarsky [:bzbarsky, bz on IRC]]

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.

Comment 3

[Dan Williams]

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.

Comment 4

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Yeah, I just read the part about IE6 doing it differetly in standards mode... 
Confirming pending testing on MacIE as well.

Taking.

Comment 5

[Boris Zbarsky [:bzbarsky, bz on IRC]]

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
and
    only in standards mode.

Comment 6

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Created attachment 108769 [details]
comprehensive testcase -- quirks

Comment 7

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Created attachment 108770 [details] [diff] [review]
something like this

Comment 8

[Boris Zbarsky [:bzbarsky, bz on IRC]]

John? David? fantasai?  Ian?  Thoughts?

Comment 9

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Comment on attachment 108770 [details] [diff] [review]
something like this

hixie say's r=him on this change...

Comment 10

[David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-8 (if account gets disabled due to email bounces, ask a bugzilla admin to reenable it)]

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.

Comment 11

[Boris Zbarsky [:bzbarsky, bz on IRC]]

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

[fantasai]

FWIW, Opera 7 seems to use content-box sizing for everything except textarea.
Some things render a little weird inside the box, though...

Comment 13

[david nicol]

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.

Comment 14

[Boris Zbarsky [:bzbarsky, bz on IRC]]

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 15

[David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-8 (if account gets disabled due to email bounces, ask a bugzilla admin to reenable 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.

Comment 16

[Boris Zbarsky [:bzbarsky, bz on IRC]]

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

Comment 17

[Boris Zbarsky [:bzbarsky, bz on IRC]]

fixed