Closed
Bug 43721
Opened 25 years ago
Closed 25 years ago
[INVALID]WIDTH and HEIGHT of DIV not inclusive of PADDING and BORDER
Categories
(Core :: Layout, defect, P3)
Tracking
()
VERIFIED
INVALID
People
(Reporter: val, Assigned: clayton)
References
Details
(Keywords: css1)
Attachments
(1 file)
|
386 bytes,
text/html
|
Details |
From Bugzilla Helper:
User-Agent: Mozilla/4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (Win98; I)
BuildID: 2000061311
If the WIDTH and/or HEIGHT of a DIV is set explicitly by a style, either inline
or otherwise, and PADDING and/or BORDER are also defined, then the dimensions of
the resulting DIV will be WIDTH/HEIGHT plus the PADDING and/or BORDER.
Shouldn't WIDTH be inclusive of PADDING and BORDER?
Reproducible: Always
Steps to Reproduce:
For example:
1.<div style="height:300; width:200; padding:30; border-width:4px;
border-style:solid"></div>
Actual Results: DIV on the screen has actual width of 268px and height of 368px
Expected Results: DIV should have actual width of 200px and height of 300px -
ie contents should make room for padding and border.
Comment 1•25 years ago
|
||
Nope, sorry. See http://www.w3.org/TR/REC-CSS2/ for more details.
Note that IE5 gets this wrong.
If you have a specified with (100%) and you specify a border-width, your element
expands beyond 100%.
Im sorry, it makes absolutely no sense to have
an element expand beyond the specified width.
say I wanted a DIV to take up 100% of a cell, and I wanted a 3px border and 3px
padding. I could not do this because it would over lap the cell border.
please reconsider this behavior. I can forsee allot of problems.
You mean 'width: auto' instead of 'width: 100%'. You could also create an extra
element in the markup. (And I bet you'd expect it to work the right way for
images! This way is also more flexible.)
Summary: WIDTH and HEIGHT of DIV not inclusive of PADDING and BORDER → [INVALID]WIDTH and HEIGHT of DIV not inclusive of PADDING and BORDER
I'm not quite sure what you mean.
I still do not agree with the behavior, but my opinion doesnt count for much:)
I created the above attachment to display the "problem".
Realised pretty quickly back in June that Mozilla is correct here.
(Mislead by other browsers, and should have read the spec!)
Have since come to believe however that for _percentage_ widths/heights (esp.
for percentages less than 100%) it does seem to be counter-intuitive, and makes
precision in layout less easy.
But this is a W3C rather than a Mozilla issue.
Posted, with possibly inane suggestion, to the www-style newsgroup - "Percentage
values for Height and Width properties" - Mon, 28 Aug 2000) - to no effect.
Comment 9•19 years ago
|
||
*** Bug 361950 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•