Why exactly is the padding calculated differently between a and button elements?
HTML
<button type="button">CLICK</button>
LINK
CSS
button {
padding: 10px;
height: 30px;
border: 0;
background: #ccc;
line-height: 30px;
}
a {
display: inline-block;
padding: 10px;
height: 30px;
background: #ccc;
line-height: 30px;
}
The default box-sizing value for buttons in Chrome (and Firefox) is border-box:
DEMO
I.e. the total height, including padding (and border and margin), of the element is 30px, not 50px like for the link. You can fix this by setting
box-sizing: content-box;
explicitly.
DEMO
More info about the box model.
Why the border-box is the default value I cannot say. I haven't found a specification for it. Chrome, Firefox and Safari seem to do this (didn't test other browsers).
<a href...>
Links never have a set-height, if you inspect the html, you can see that; what is really done is giving it a line-height and padding. when you write height: 30px, it is useless.
With respect to that, you are defining a height for the <button>, which is why it does not look the same as how you styled your link
Here is a fiddle to show how to make them the same, by removing the set-height of the <button>
Related
Code snippet (jsFiddle):
.root * {
cursor: default;
font-family: Arial;
font-size: 16px;
padding: 0px;
outline: none;
border: none;
text-align: center;
display: inline-block;
vertical-align: middle;
line-height: 0px;
}
.clickable {
background: orange;
margin: 5px;
box-sizing: content-box;
width: 100px;
height: 40px;
}
.clickable .label {
margin: 0px;
}
<div class="root" style="padding: 60px;"><!--
--><button class="clickable"><span class="label">label</span></button><!--
--><div class="clickable"><span class="label">label</span></div ><!--
--></div>
Even though the CSS directives for the button (on the left) and the div, and for their contents, are identical, the vertical positioning of these contents is completely different:
I would like to know
what other CSS setting accounts for this difference?
(Note: by "other CSS setting" I mean one that is not explicitly set in the example's CSS.)
EDIT:
I've created another jsFiddle to demonstrate why #Jim's suggestion (in his comment) does not always work. In this jsFiddle, all the CSS properties (including the inherited/computed/browser-assigned/you-name-it ones) for the .clickable and .clickable .label classes are given explicit values.
Even though these settings make no explicit distinction between buttons and divs, the observed difference in vertical positioning between buttons and divs persists.
This means that the explanation has to be that some setting (probably one that has value like auto or normal) is getting interpreted differently depending on whether the context is a button or a div. Such context-dependence contributes much to making CSS the living hell that it is.
It's your line-height: 0px; value that is affecting the div. On block level elements, the line-height properties specifies the minimum height of line boxes within the element. Elements such as buttons or other input elements, line-height has no effect.
Update
I should say that in some cases line-height is allowed to have affects on buttons.
I have a question on something weird that is rendering on the latest IE and Chrome browsers. I have a div that is supposed to span 100% of a parent. So clumsily, I gave it - width: 100%px; as a CSS property. Here is my entire item:
.loc_vendiv{
position: relative;
margin-top: 5px;
left: 0px;
width: 100%px;
height: 120px;
border: 1px solid #333;
background-color: #fff;
}
The weird thing - that worked perfectly. So much so, that I just noticed today that this was wrong. Not wanting an ugly style sheet, I removed the px from the end. And... the div was two pixels too wide. Any explanation as to why this is happening? Here is the parent div:
#loc_catlist{
position: absolute;
width: 612px;
height: 720px;
top: 50px;
left: 0px;
background-color: #eee;
overflow-y: auto;
overflow-x: hidden;
}
I'm mildly annoyed, as the bad code works, yet the correct code doesn't do what I want. I don't think I can leave it, though. I don't like little hiccups like this...
It's because of your border.
Try adding :
box-sizing: border-box;
to your .loc_vendiv class, it will take the border in account.
Browsers usually ignore invalid css rules like width: 100%px; which means that to get the style you had with the mistake. you only have to remove the width rule.
2px too wide is likely caused because you have a width of 100% in addition to a border of 1px (all around adds up to 2px width).
A fix can be found here from "Paul Irish" about
box-sizing
what happens is that when the width value is wrong (100%px;) this part of the CSS is simply ignored by the browser. If this part of the css was deleted, the result would be the same.
About the 2 extra pixels, this happens because of the border set to the div.loc_vendiv.
The width of div.loc_vendiv is equal to the width of div#loc_catlist and to this is added the border value (1px for the left border and 1px for the right border = 2px).
Remember that the border width is added to the size of the object while the padding creates an internal space.
I have an issue with Firefox when applying -moz-box-sizing : border-box; to inputs, seems like the text I type in is somewhere hidden or overflown or something.
You can see the issue in here : Test ( resize your window to a size smaller than 980px because it's a mobile version );
So what could be the issue there ? Because I tried everything I could find, and the only thing that worked is removing the -moz-box-sizing : border-box; property (:
You should set the height to 100%. I tried the following CSS for your input fields, and it helped:
input[type="text"] {
-moz-box-sizing: border-box;
font-size: 16px;
height: 100%;
padding: 20px;
width: 100%;
}
==> The reason is, that your padding of 20px is too much. Try first removing the padding. You will see that the input field's text gets visible suddenly ;-). After I saw this, I set the height to 100%. Now you can decrease the padding to e.g. 10px and everything looks fine.
I had this problem but initially in Safari 6+. Some text inputs respected padding top/bottom, but others didn't and ended up shorter. By using height: 100% on all of them as suggested here, they did all become consistent and seemed to respect padding top/bottom. However, it added a couple extra pixels in height.
In the end, I ended up doing box-sizing: content-box on all of them, which made them respect padding top/bottom but without the extra added pixels in height.
Had to chase this with a width: calc(100% - <padding L+R>) though, which is a disadvantage.
I solved this problem differently by adding a custom padding for the input text tags
input[type="text"] {
padding: 6px 12px 12px 6px;
}
input[type="email"] {
padding: 6px 12px 12px 6px;
}
input[type="password"] {
padding: 6px 12px 12px 6px;
}
input[type="text"] {
padding-top:0;
padding-bottom:0;
vertical-align:middle;
}
I have an input element inside a div element:
...
<div id="calculator-container">
<input type="text" />
</div>
....
In CSS I make the input width 100%:
#calculator-container {
border: 1px solid black;
background-color: lightgrey;
width: 200px;
padding: 10px;
}
#calculator-container input {
width: 100%;
}
I can't figure out why is there less free space on the right side of the input than on the left (please see the screenshot below). Maybe somebody can advise. Thanks.
Pointing out that on jsfiddle it looks fine but if you copy it locally it looks bad in both IE and Firefox. Here is the jsfiddle link just so you can copy the code: jsfiddle just to get the code
It’s because width means the width of the element’s content area. The <input>’s content area is surrounded by its padding and border.
http://jsfiddle.net/3f7RB/
If you set those to 0, the input no longer takes up more space than is available:
input {
width: 100%;
border-style: none;
padding: 0;
}
http://jsfiddle.net/3f7RB/1/
(Of course, form elements are often rendered a bit differently from regular elements, so different browsers may do different things.)
If you want padding on the <input>, you can either declare that as a percentage too:
input {
width: 96%;
border-style: none;
padding: 4px 2%;
}
http://jsfiddle.net/3f7RB/5/
Or use box-sizing (not supported in IE 6 or 7) so that width: 100% applies to the <input>’s content, padding and border combined:
input {
width: 100%;
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}
http://jsfiddle.net/3f7RB/6/
Because the input element gets width:100% which is 200px. this however doesnt take into account that it has a border of 2px, meaning it actually should be 196px.
try this:
http://jsfiddle.net/QLFrj/
#calculator-container input {
width: 196px;
}
Only problem is that it is no longer a percentage...
the reason why it's to right because of the border because it's to the width of input field means the width of input field is 100% + 2px. So, you can use box-sizing property got this:
Check this
http://jsfiddle.net/3f7RB/4/
OR
you can use outline property also . like this:
Check this
http://jsfiddle.net/3f7RB/7/
I've tried here and it works fine. Maybe another CSS statement is overriding some attributes of your div or input. You may try to inspect the elements with Firebug (on Firefox) or Google Chrome.
This happens because your input element wants to be 200px too. The width: 100% applies to the parent-element. In this case the #calculator-container.
I'm attempting to provide a consistent width per line in pixels inside of a textarea across IE8, Firefox and Safari, so that text content wraps lines as predictably and consistently as possible.
Firefox is doing something a little bit odd: it has an extra pixel of padding eating out of the content space of the textarea vs the other two browsers, and vs a similarly equipped div block.
When applying this class to both a textarea and a div the difference is visible, with the text in the div touching the outer left edge of the red background but the text in the textarea have 1 px padding-like offset in spite of padding being zero:
.testbox{
padding:0;
margin:0;
border:0;
background: red;
width: 40px;
height: 40px;
font-size: 12px;
line-height: 16px;
}
Other values for padding wind up displaying one extra pixel of offset vs a div.
Any ideas on if there's a way to trick Firefox to render a textarea as if it were a div, or to adjust this not-padding-but-looks-like-padding property for a textarea?
I have recently been doing some researching on the problem described by OP for a similar question on SO. It seems that a bug in Firefox is causing the rendering of this so called "not-padding-but-looks-like-padding" on textarea elements.
Usually this extra padding is not really an issue, but it becomes an issue when you want to keep two elements the same width, and you care about getting its content to wrap the same way in both elements.
Getting textarea's to wrap content the same as e.g. div elements in Firefox
It seems to be impossible to get rid of this 1.5px wide padding on the textarea in Firefox, so if you want to ensure that the content wrapping inside a div in Firefox behaves exactly the same as the content wrapping inside a textarea in Firefox, the best approach seems to be to add an additional 1.5px of padding on the right and the left hand side inside the div, but only in Firefox. You can accomplish this by setting the following vendor specific prefixed CSS properties on your div:
-moz-box-sizing: border-box;
-moz-padding-end: 1.5px;
-moz-padding-start: 1.5px;
The first ensures that the padding set on the div does not increase the width of the div, and the next two ensure that 1.5px of padding will be set on the right and the left hand side of the div.
This approach does not affect the rendering of the div's in any other browsers, it doesn't need to, as textarea's in other browsers don't render any extra padding. But it ensures that there are no content wrapping differences between div's and textarea's inside Firefox as long as they share the same font-family and font-size properties and so on.
Here's a jsFiddle for demonstration purposes.
Getting textarea's to wrap content consistently across browsers
If you only wanted to ensure that a textarea in Firefox has the same width and wrapping behaviour as a textarea in other browsers, you can set its box-sizing to border-box, add a padding on both sides of 5.5px and set -moz-padding-end and -moz-padding-start to 0px.
textarea {
padding: 0 5.5px 0 5.5px;
-moz-padding-end: 0px;
-moz-padding-start: 0px;
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}
Here's a jsFiddle showing this approach.
Wow, I don't know the answer yet but I did try some stuff, and it appears as though a textarea, when you apply borders, margins and padding to it, doesn't change its width but puts the borders etc. on the inside. Try this:
.testbox {
padding: 10;
margin: 10;
border: 5px solid black;
background: red;
width: 40px;
height: 40px;
font-size: 12px;
line-height: 16px;
}
You could work around this by using something like this:
<div class="testbox">
<textarea class="testarea"></textarea>
</div>
css:
.testbox {
padding: 0;
margin: 0;
border: 0;
background: red;
width: 40px;
height: 40px;
font-size: 12px;
line-height: 16px;
}
.testarea {
padding: 0;
margin: 0 -1px;
border: 0;
background: red;
width: 100%;
height: 100%;
font-size: 12px;
line-height: 16px;
}
This also seems to work in IE, except for the -1px, which throws the layout off (by one).
This is a bug in firefox which got fixed a few days ago. The fix will be released with Firefox 29.
I already tried the latest nightly build and the textara bug is gone!
I was facing the same problem and although my solution seemed like bending backwards too much for that one pixle, but it fixed the problem, here goes: To unify the width because of this weird behavior, Instead of using a div, i used a disabled textarea with a white background and a default cursor to act as a mimic the div.
I was having a similar problem, a link tag with a background image and padding did not display well on firefox. The padding and background seemed to apply to the line of text, not the block of text, when multiline. I tested out a few things, and ended up using a "display:block;" on the element css. Worked for me.