If you were to hop in a time machine and nip back a decade or two you’d find The CSS Reset was a standard requirement when creating UI’s, emerging in the early-mid days of The Web.
Håkon Wium Lie, who first proposed the concept of Cascading Style Sheets while working at CERN in October of 1994. CSS formalised in 2006
The goal of The CSS Reset was achieving consistent rendering, or appearance, of web pages across all browsers by nullifying (resetting) all the proprietary, default styles applied by browsers (excluding any pre version 9 Internet Explorer, they needed a whole separate stylesheet).
In the hope of giving developers a standard starting point for styling, allowing developers to apply only their intended styles without having worry about the inconsistent and varying defaults implemented by web browsers.
When you perform a CSS “reset,” you are essentially overriding the fundamental, native, stylesheet that each web browser applies to format a web page. If a website has no CSS, the default stylesheet of the browser will take over and distort its design. CSS is an essential part of front end web technologies. It controls all visual aspects of a website. CSS regulates your website’s typography, colours, page layouts, and any other graphical elements.
The History of The CSS Reset:
The evolution of The CSS Reset has seen several key milestones that have shaped its development and adoption in web development practice:
- Early Web Development (1990s – 2000s): During the early days of the web, different web browsers had their own default styles for HTML elements. This led to inconsistencies in how web pages were displayed across different browsers. To address this, web developers had to include specific CSS, somewhat hacky, rules to target specific browsers and account for these default styles. Alternatively developers could apply a universal ‘Hard Reset‘, wiping the margins and padding from all HTML elements.
- YUI Reset (2006): Yahoo’s User Interface (YUI) library introduced its own reset stylesheet as part of its CSS components. Almost every HTML element had its margins and padding zeroed out. Images had no borders. Lists lost bullets and numbering, all headings were reset to the same size. YUI’s reset was the first that could truly be considered a global CSS reset by current standards.
- The Jeff Starr Collection (2007): In 2007 Jeff Starr rounded up a bunch of different CSS resets. The oldest one, dated from 2004, is Tantek Çelik’s undohtml.css.
- Eric Meyer’s Reset (2007): Eric Meyer pioneered the Reset CSS stylesheet and further popularised the concept with one of the most influential contributions. He released a widely known CSS Reset stylesheet to reset the default styles of HTML elements across all main web browsers. This reset stylesheet included rules to also remove margins, paddings, plus other default stylings that caused discrepancies. It was widely adopted and helped establish the era of the CSS Reset.
- CSS Frameworks Released (2011): With the rise of CSS frameworks like Bootstrap (2011) and Foundation (2011), the concept of a CSS Reset evolved further. These frameworks included their own baseline styles and often integrated normalization techniques, reducing the necessity for developers to manually implement CSS Resets.
- Normalize.css & Sanitize.css (2011-2015): As the web evolved, developers realised that a complete reset was too aggressive, as it could remove some useful default styles and behaviors. In response, Normalize.css was introduced by Nicolas Gallagher and Jonathan Neal. Unlike a full reset, Normalize.css aimed to preserve some useful default styles while still achieving a consistent baseline across browsers. Later Sanitize.css was introduced with additional focus on maintaining the user experience and accessibility. By retaining some default styles and targeting developers expectations, it ensured that the content remained readable and usable for all, including those who rely on assistive technologies.
- Sass, Less, PostCSS and Autoprefixer (2006-2013): The gradual adoption of CSS preprocessors like Sass and Less introduced a new layer of flexibility to the CSS Reset concept. Developers began creating reset or normalisation styles using these preprocessors, allowing for a more modular and organised approach to styling. Sass mixins and Less variables made it easier to customise and tailor the reset styles to specific project needs. PostCSS, a popular CSS preprocessor, emerged as a versatile tool for transforming CSS with plugins. One notable plugin, Autoprefixer, aimed to automatically add vendor prefixes to CSS properties, reducing the need for manual prefixing and enhancing cross-browser compatibility. These approved laid the foundation for approaches still used with task runners, like Gulp, and bundlers, like Webpack today.
- Browser Standardisation and Improved Compatibility (2010s – Present): Over time, with some encouragement from organisations like The W3C, The Web Standards Project and The ECMA, browser vendors made significant efforts to standardise rendering behaviors, leading to reduced browser inconsistencies. This development reduced the reliance on extensive CSS Resets and dependence on feature detection tools such as Modernizer for achieving cross-browser consistency.
- CSS-in-JS and Component-Based Styling (2010s – Present): The rise of JavaScript frameworks for building Single Page Applications began to affect the development world. AngularJS emerged in October of 2010, EmberJS in December of 2011, ReactJS in March of 2013, VueJS in February of 2014. Component based architecture brought with it a new styling paradigm. The shift toward component-based development and the emergence of CSS-in-JS solutions like Styled Components and Emotion offered new ways to manage styling, where the need for a comprehensive CSS Reset became less critical. These approaches encapsulate styles within the components, reducing global styling conflicts.
Where We Are Today: Is The CSS Reset Still Relevant?
Many would claim we are now in the Post CSS Reset Era.
It’s undeniable that with pre-processors, post-processors and modern development pipelines, as well as the improvement in browser standardisation, browser inconsistencies have become less of a concern and the need for extensive CSS resets has diminished.
However, as much of the content on the internet is written by less experienced developers building a reputation, content writers regurgitating what they’ve read online or, more recently, AI’s formulating probability based sentences based on what they’ve consumed from online. You cannot always rely on what you read on the internet.
While the traditional concept of a CSS reset may not be as relevant in today’s web development landscape, the technologies live on the internet and browsers used are, in the majority, not cutting edge so the need for normalised styles and consistent starting points still exists.
Many modern CSS frameworks like Bootstrap and Foundation come with their own baseline styles. Taking a look at how Bootstrap, still the most popular CSS framework, evolved in version 4 (Nicholas Cerminara goes into more detail in his article where he takes a Look at Bootstrap 4’s New Reset: Reboot.css) and what is currently used in the version 5 reboot, you can see that solutions based on The CSS Reset (specifically normalize.css) do indeed live on, and likely will still be around for a while yet.
I’ve worked with CSS so long that I don’t see the lack of local scope as a huge problem, thinking back to the 2010s and the guidance given to me when building landing pages for E-commerce sites, CSS specificity is your friend. Learn it and understand it. Traditionally, if you wanted to ensure any custom styling you applied to a page or block didn’t leak out and unintentionally impact on global styles you would target styles within an ID applied to the page or code block.
Whilst the use of IDs has been diminished due to component reusability requirements, similar work arounds for the global scope issues via naming conventions can be seen in methodologies like OOCSS, SMACSS, BEM and SUIT. Each providing us with ways to avoid naming collisions and emulate local scoping of CSS styles.
So Do I need a CSS Reset?
As a developer you can consider approaches like normalisation libraries, baseline styles from CSS frameworks, or tailored styles for specific components.
Most reset methods are less cumbersome than they once were, therefore is useful to know generally what issues you may face or want to address, Josh Comeau maintains a modern reset and gives a good rationale which is worth a read.
As a rule of thumb you don’t really need a reset when using, minimal (JS frameworks/libraries, flexbox, CSS-IN-JS) systems. However, fundamentally the decision to use a CSS reset should be based on the project’s requirements, target user base, the development tech. stack to be utilised, the level of control needed over default styles and the overall styling strategy being employed.
