4 ms·
I got a completely different idea from reading the description. He's saying the whole point why this thing is small is that you don't need to keep stacking chan
by lhorie 8y ago
I got a completely different idea from reading the description. He's saying the whole point why this thing is small is that you don't need to keep stacking changes to the same properties, i.e. why do this:
/*reset*/
h1 {margin: 0;}
/*your pretty styles*/
h1 {margin: 0 0 10px;}
He argues that you can just drop the first rule because you're going to be setting it to something else later anyways; you should only reset properties that are likely to be final and only tags you actually use.
- masklinn 8y agoThat seems like an argument to post-process the CSS and avoid double-setting properties. The point of a reset/normalise stylesheet is to create a coherent and consistent baseline for work, in theory you could actually stop there. Or just alter the reset itself.
- Bluestrike2 8y agoIdeally, I don't disagree with the concept behind that approach. Clean, streamlined CSS is nice because it's generally easier to work with. Browser page inspectors help with that, though. You aren't searching up and down a file sheet to figure out what rules are applicable in a given context. Resets (normalize.css or any other) are about consistency. Both between browsers and between projects. When you import one, you know what you're getting and don't have to think about it outside some edge cases. This micro reset eliminates that and forces you to figure out your reset needs each and every time. Odds are, you'll miss something at some point. That's especially likely when it comes to accessibility; good resets try to take it into account to avoid screwing users who rely on screen readers and other assistive tech, for instance. They don't always manage it, but their shortcomings are at least consistent. That makes it easier to fix. Besides, there are already a lot of tools and options to accomplish the stated goals. You could wrap less commonly used reset rules in conditionals and set variables to disable certain ones (forms being the example given). Build tools have improved a lot in recent years. You can use things like cssnano[0] to help you optimize your stylesheets when they're built. On the other hand, how important is this anyhow? Browsers are highly optimized. Having tons of duplicate media queries throughout a stylesheet (common when dealing with preprocessors and media query mixins) doesn't impact performance, for instance.[1] No reset is going to have a measurable performance impact in adding a handful of duplicate selectors. As for file size, gzip is extraordinarily efficient when it comes to dealing with property and selector names. If you're implementing something like this for performance reasons, the time spent crafting the smallest possible reset for each site you work on would be better spent elsewhere. 0. http://cssnano.co/ http://cssnano.co/ 1. https://helloanselm.com/2014/web-performance-one-or-thousand-media-queries/ https://helloanselm.com/2014/web-performance-one-or-thousand...
- lhorie 8y agoIt goes both ways. One can argue that setting up css build tooling would be time better spent elsewhere (and if you ever did corporate or legacy work that can be painfully true) In many cases, a mindset of not doing needless extraneous work is the result of having seen crushing complexity, and it's a mindset that goes a long way. As the saying goes, better to be the master of your tools than a slave to them.