32102 - [FIX-html.css]border/margin/padding in INPUT elements

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P1)

Description

[msuencks]

type checkbox, radio seem to work ,
with "text" the viewable area of the
element is not expanded  and
"submit" somehow messes around. maybe
other , but maybe it's just my Gtk lib :-)

Comment 1

[Pierre Saslawsky]

<[e-mail]>: the description is really vague, there is no testcase, no 
URL, not even the build number. Sorry: I'm closing it as Invalid. Could you 
please describe the problem according to the bug writing guidelines on http://
www.mozilla.org/quality/bug-writing-guidelines.html and reopen the bug? Thanks.

Comment 2

[Christine Hoffman]

Verifying as invalid. Need more specific info.

Comment 3

[msuencks]

you are right .. here is a test case (see URL). 
should also apply to bug #32104. seen on latest
nightly build (2000032109)

the test URL contains some descriptions and
a comparison against NS4.72. 

concerning paddings, borders and margins - with
NS4.x the seem to basically not work right. I guess
borders, margins und padding were treated as
3 layers around a form element.

IMO "border" should apply to the actual border of
the form element (e.g. input box) as seen by the user.

the "padding" should be between the border
and the content of the form element (e.g.
the text with an input=text)

in a former build I think I have seen such
behaviour already (sorry can't remember which one)
at least with "padding".

but there was then the bug that with assigning a
bigger "padding" the form element would not grow
accordingly but the content for the e.g. "Input type=text" 
would disappear "into" the element because of the
big padding (e.g. 50pt)

maybe not many users would use these features anyway.
so I mark it with severity=minor

Comment 4

[Pierre Saslawsky]

The submitted testcase is invalid because the 'class' attribute is case-sensitive 
(http://www.w3.org/TR/html4/struct/global.html#adef-class). However after fixing 
it, I noticed different problems with border, margin and padding in INPUT 
elements.

I'm going to reopen the bug, assign it to HTMLForms and attach a nifty testcase.

Comment 5

[Pierre Saslawsky]

Reassigned to HTML Form Controls

Comment 6

[Pierre Saslawsky]

Attachment: testcase

Comment 7

[Pierre Saslawsky]

Removed the URL because the code is invalid. FYI, it was
http://www.marcant.net/~msuencks/styletest.html

Comment 8

[rods (gone)]

Attachment: form control test

Comment 9

[rods (gone)]

The tests need to be done in "Standard" or "strict" mode. Change the doc type 
of the document. I try to get close to Nav 4.x sizing when I can and the browser 
is in NavQuirks mode. ou will get the desired results when in Standard or strict 
mode.

marking this invalid.

Comment 10

[Pierre Saslawsky]

Reopening: my testase was in strict mode. Basically, the bug is that the border 
and padding should go *outside* the content area. An element with a thick border 
should be larger than an element with a thin border. That's how all the elements 
work (see http://www.w3.org/TR/REC-CSS2/box.html#box-dimensions and
http://www.w3.org/TR/REC-CSS2/visudet.html#q6). My testcase illustrates this: the 
static fields work correctly while the form controls such as edit fields have 
their content area reduced when we increase the border or the padding. It's a 
bug.

Comment 11

[rods (gone)]

No, it is not a bug. 

A couple of things all the form controls have "box-sizing: border-box;" and all 
the controls grow in size except for the radio and checkbox. Which have there 
size statically set in the html.css 

This makes it very confusing and thus bugs get filed. The problem is that 
radio and checkbox controls have no inherent size, so we statically set the 
height and width in the html.css file and with box-sizing set to border-box it 
causes behavior that is correct but confusing.

If you want to change this bug to: Radio and checkbox controls should have an 
inherent content size so that once you set border and padding, they size 
correctly. The inherent content size could come from the LookAndFeel class. In 
fact, it already has a metric "eMetric_CheckboxSize" which used to represent the 
outside of the radiobox but we could change it to mean the content area.

The only place it is being used is:
http://lxr.mozilla.org/mozilla/source/layout/html/forms/src/nsNativeCheckboxCont
rolFram.cpp#63

which is no longer being used.

I thik this would be a good approach and make things less confusing.

Comment 12

[Pierre Saslawsky]

Right, I had forgotten about that. Still, I added this rule to the testcase:

   * {box-sizing: content-box}

The checkboxes started to work as I wanted but the edit fields did not change: 
they are still displayed as if 'box-sizing' were 'border-box'. It's in fact the 
problem which was originaly reported and I did not find a workaround. It seems 
like the edit field has a fixed size no matter what.

I don't think we should use native metrics to draw GFX widgets like checkboxes 
and radio buttons, we have a unique set of widgets on all plaforms and that's a 
good thing. However I believe that these widgets should behave like normal 
elements and have their box-sizing left to content-box. There is no reason to 
declare in html.css:

      box-sizing: border-box;
      border:  2px;
      width:  13px;
      height: 13px;

instead of:

      border:  2px;
      width:  11px;
      height: 11px;

Comment 13

[rods (gone)]

Yes, I got hung up on the boxising needing to be border-box. If we set it to 
content-box. Everything works as it user think it should. Also, I am not having 
problems with intput type=text. It grows in size when in struct/standard mode.

Comment 14

[rods (gone)]

mass-move to M16

Comment 15

[rods (gone)]

moving bugs to M17

Comment 16

[Hixie (not reading bugmail)]

See also bug 41629.

Comment 17

[rods (gone)]

Easy fix, this will enable user to resize the comboboxes via style

Comment 18

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 19

[rods (gone)]

setting to M17

Comment 20

[Kevin McCluskey (gone)]

Marking nsbeta3+

Comment 21

[rods (gone)]

fixed

Comment 22

[ckritzer (gone)]

Marking VERIFIED FIXED on:
- LinuxRH62 2000-09-07-08-M18 Commercial
- Win98     2000-09-07-08-M18 Mozilla
- MacOS86   2000-09-07-04-M18 Commercial