I’m pretty sure every developer out there will disagree with me on this one. The most common approach when building a web page or template is to add CSS that completely resets the browser’s margins, padding, and natural spacing to zero before adding design CSS. The (largest) argument is that this is the only way to get your design to render identically in all browsers. It is accepted as standard practice.
I disagree. There is a reason browsers have built-in margins and padding, and those reasons are generally born from accessibility concerns. By training myself to code to the natural document flow,
- I have less CSS. When a reset is used, I now have to specify everything that was reset. Tyrannical supreme control over the design comes at a cost, one of both file size and additional code work. Coding to the natural flow usually only requires a little push here and there to the DOM.
- It’s less work in the long run. See point one, by coding to the natural document flow don’t I need additional CSS to set everything I unset, and that means less code, less work, and less billable hours to the client.
- The original premise is no longer (completely) true. A reset made sense when getting some sort of consistent result across all browsers was chaotic. I remember the Holly Hack and have used it. I remember when I kept a Mac G3 on the desk with the Apple version of IE5 on it as my "browser acid test." These struggles are a thing of the past with modern browsers, IMO this is rarely a valid argument today. Even in those days, I resisted the reset. Why?
- Future Proofing. If history has taught me anything, what works today may be a mistake I’ll have to undo tomorrow. The Holly Hack would totally break a lot of sites today. Who’s to say if a reset may become a challenge in the future? It’s not likely, but it’s another accepted practice we are relying on to live forever. The less I code, the less that can get broken.
- There is always a way. Just like my server side programming, if a solution eludes me or it appears impossible, often I find I am asking the wrong questions or am looking at the problem from the wrong angle. This has always served me and I have rarely failed. There is always a way to leverage the natural document flow and get consistency in browsers.
- Inconsistencies (probably) mean I’m doing something wrong. Related to the above point, if a design looks almost the same but has a little more margin in Chrome than FireFox, I consider the possibility I overlooked another, and often more simple, solution that does work in both. It usually means one simple code change and once found, I have learned something new. I almost never have to go down the rabbit hole and spend tons of time to find it.
- Inconsistencies are usually acceptable. Expanding on the previous point, a little difference in padding is usually acceptable. If the layout blows up, and floated elements stack on top of each other like a game of Jenga gone awry, it underlines the possibility I’ve implemented something in the wrong way. This has been an an important revelation in my career, it forces me to find the most reliable methods of manipulating the DOM without piling a fix on top of a fix to get the job done.
Coding to the natural document flow is a matter of habit in my development cycle, and it works for both myself and my clients. Their pages are a nano-byte lighter and maintenance is far more simple.