Number 2 because it doesn’t need any magic numbers and restricts calculations to the element concerned rather than spreading the routine over 2 different elements.
Note also that negative margins can be affected by the display of the element or whether the element has a width defined and can give different results if you don’t understand what you are doing.
For example give a width to the element in your first example and see what happens.
.nav {
margin: -6px -2px;
width:100%;
}
If you know what you are doing the negative margins are fine and a useful tool. If you don’t know what you are doing then you use them at your peril.
I know you have a tendency to use JSFiddle, which can be fine. But I strongly suggest you not work up designs inside of it. It is “javascript fiddle” not “css fiddle” after all.
If you open your dev tools network tab and look at CSS that JSFiddle is using, you will see an extensive amount of minified CSS.
True, you can see what styles are being overwritten by what, and modify your work to compensate, but IMHO it would be best to work up your designs in browsers and use JSFiddle only as a tool for sharing JavaScript code.
You need to understand the box model as the space an element takes up in its containing block is made up with its width plus its margins (plus padding and borders). All must be resolved.
In your example you can use anything from 270px upwards and it will work i.e. (266px + 4px). If you use negative margins on that fixed width element then that effectively makes the element smaller by the amount of the negative margin. (The outer parent is hiding the overflow so you don’t see the bigger inner element.)
The answer is not to give a width at all and let it be auto width.
All of which is why I said that you need to understand how negative margins work before you can use them properly. This isn’t the end of the story either because it will vary depending on what elements you apply the margins to (e.g. on a float a negative margin will drag the next element towards it and possible overlap but on a non floated widthless element the element is enlarged).
You keep messing about with things without a full understanding of what you are doing. There are subtle differences in all these examples that you fail to understand the nuances of why things work.
In my original I put a height and width on the parent and hid the overflow which hid the bottom margin and contained the floats without the need to do anything else.
e.g. It was something like this:
You’ve experimented with many things and removed a lot of the safeguards that were in place because you couldn’t visually see a difference and yet there would be differences depending on circumstance.
As we’ve all said many times there are many ways to accomplish a task but all have consequences in one way or another that you have to accommodate. Using display:table on the parent means that height is treated as a minimum which means that overflow:hidden does not work to contain the height. This is a consequence of using display:table and therefore you would need to do other things top maintain the layout.
If you keep chopping and changing then you really need to start from scratch and test every scenario again. Experimenting is fine but you need to know why things are in place before you remove them. Sometimes its not easy to remember why code was in place when you disassemble which is why simpler code is often better.