You need a “style sized solution to a style sized problem”. As the sibling posters have said, you can use reset stylesheets, or write your own. At a deeper lev

You need a “style sized solution to a style sized problem”. As the sibling posters have said, you can use reset stylesheets, or write your own. At a deeper level, you have to appreciate that browsers are built around the “separation of concerns”: - html for content - css for layout, look and feel - javascript for behaviour The front-end community has some loud voices at the moment telling us that these are the wrong separations; that the styles for a component go hand-in-hand with their behaviour and semantics. I’m not getting into that debate here. But I do want to say that this newer interpretation of the “concerns” applies to code you write for your application, and is (currently) not how browsers are constructed. It may make more sense for you as a web application developer to structure your code by colocating your layout and behaviour solutions in one file, and in that way you’re more likely to use <div> and <span> over more expressive elements. But that’s not what your users’ browsers are expecting you to do. They’re built around the older separation of concerns. And they’re built to amplify the strengths of the three languages they interpret. So that <div> tells the browser “i want you to treat this content just the same as you treat any other content”, where a <h1> tells the browser “add this content to your document outline, expose it as a section heading to the accessibility tree” as well as reminding it to apply the default styles. Attack the problem (unwanted styles) at the right level of separation (at the styles level).