This is classic tearing.
The people who wrote the CSS specification thought it was a good idea to prevent the creation of excess white space across fields. Without this behavior, it would be much more work to control the margin / whitespace between block elements.
Literature:
CSS2 Spec - http://www.w3.org/TR/CSS2/box.html#collapsing-margins
Andy Badder article - http://andybudd.com/archives/2003/11/no_margin_for_error/
Eric Meyer Article - http://www.complexspiral.com/publications/uncollapsing-margins/
Why folding fields is a good idea
Pivot fields are a feature of the CSS Box Model, which forms the basic work unit for the visual formatting model, which allows us to have a rational environment for developing web pages.
When developing the CSS specification, the authors had to balance how the rules will be written, for example: margin: 1.0em , and how these rules will work in the CSS formatting mechanism, which requires the layout of the content block from top to bottom and from left to right (at least in Western European languages )
Following Eric Meyer's article above, suppose we have a series of paragraphs with style margins:
p { margin: 1.00em; }
For those of us who are used to seeing printed pages with a regular spacing between paragraphs, one would expect the space between any two adjacent paragraphs to be 1.00em. One might also expect that the first paragraph should have 1.00em before it, and the last paragraph should have a 1.00em margin after it. This is a reasonable and possibly simplified expectation of how the simple CSS rule for p should behave.
However, for programmers creating a CSS engine that interprets a simple p rule, there is a lot of uncertainty that needs to be addressed. If you expect an interpretation of the printed page of the CSS rule, this naturally leads to collapsing margin behavior. Thus, programmers have a more complex rule: if there are two adjacent p tags with upper and lower fields, combine the fields together.
Now the question is, how do you "combine fields together"? min or maximum adjacent upper and lower fields, the middle of the two? is the edge of the first element always? But what if you have other block elements besides p ? and if you add a border or background? what's next?
Finally, how do you compute all of these field options so that you donβt have to iterate over the entire set of HTML elements (which would make it difficult to load complex pages, especially in earlier generations of browsers)?
In my opinion, the collapse of the fields turned out to be a solution to a complex problem that balanced the ease of writing CSS rules for the fields, expecting the printed pages to be printed in our typographic heritage, and finally provide a procedure that could be implemented in a programming environment in which there are browsers.