Wed, July 31, 2024

Little bit of a correction: The purpose of reset.css at least was (it's been some time since first written) about browser standards compliance. Chromium based browsers are now 70% of the world market share, with Safari another 21%, and Samsung at 4%, Firefox at 3%, and all others at 3%. I've read Safari has some differences, no surprise, but also Safari is mainly mobile, and probably a good chunk of chromium. According to perplexity.ai:

While traditional CSS resets like Eric Meyer’s Reset CSS are still in use, modern alternatives like Normalize.css provide a more balanced approach. Normalize.css maintains useful default styles while correcting common bugs, offering a middle ground between a full reset and browser defaults.

However, Andy Bell's normalize.css leans heavily on customization and closes with the suggestion that no reset or normalize css file may even be needed. Still, I agree with some of the normalize proposals like reduced header line heights. Perplexity.ai followed:

Modern approaches like the one described by Andy Bell focus more on setting sensible defaults rather than stripping all styles. … In practice, most developers today use tools like autoprefixer, CSS preprocessors, and modern frameworks that help manage these minor differences. The focus has shifted from fighting browser inconsistencies to optimizing for performance, accessibility, and user experience across a wide range of devices and screen sizes.

So, reset.css is about browser standards, mobile first, a fluid, responsive design, and if you go deeper, maybe framework theory. Some Codecademy projects have been around awhile, with recent style enhancements. Whether I'd choose a css reset, normalize, or none would depend on project needs, but normalize seems well considered.

I've started on assessments but need to close this out for home reasons and will follow up tomorrow with results.