So, what I know is that in the W3C box model, padding adds to the width of a box, because the width represents the width of the box's content. I believe CSS3's calc() function, which allows you to do arithmetic operations such as subtracting a pixel width from a percentage width, was made to counter problems caused my this (imo terrible) box model.
However, both Firefox and chrome give me the same strange result when using calc() like this:
.feedpost_form {
position: relative;
height: 80px;
border-bottom: 1px solid #999999;
margin: 0;
padding: 8px;
width: calc(100% - 8px*2);
background-color: rgba(0,0,0,0.1);
}
.feedpost_form textarea {
width: calc(100%);
}
The element width of .feedpost_form is 100%, as expected. The padding seems to be 8px, as expected, because I notice the textarea is 8px from the left. This means the css width, and therefore width of the content, should be the element width minus net horizontal padding. For example, if the .feedpost_form element is 116px wide, I believe its css width (the content width) to be 100px.
I believe the textarea should then span the width of its parent's content width, because it has a width of 100%. For example, if .feedpost_form's element width is 116px and css width is 100px, I believe the textarea's width should be 100px and stay within the padding.
The actual result I get is the textarea's width being larger than expected. The most confusing part is that it doesn't overflow it's container, but only cuts into the right padding. I'm supposing this means the resulting width of the textarea is the .feedpost_form's css width + 1/2 net padding, and setting the textarea's width to calc(100% - 8px) does solve the problem.
So here's my question: Is this the intended result, or are both browsers making the same mistake? If it is intented, what am I missing? Doesn't it contradict the box model?
8px * 2doesn't make any sense seeing as it can't ever be changed dynamically.8px-- he wants it to match up.calc( 100% - 16px ); /* double of padding */