5 ms·

Wow an NPM package for 5 css rules. Reading the description this guy seems to be searching for normalize.css https://github.com/necolas/normalize.css/blob/maste

Wow an NPM package for 5 css rules. Reading the description this guy seems to be searching for normalize.css https://github.com/necolas/normalize.css/blob/master/normalize.css https://github.com/necolas/normalize.css/blob/master/normali...

pornel 8y ago
You're missing the point here. The author is not looking for normalize.css, but advises against such nuke-it-from-the-orbit approaches. It's just 5 rules, because you don't need more. And you can copy'n'paste them if you don't want to bother with npm.
- yoz-y 8y ago
  The reset parent posted does better job of explaining what it does than this micro reset. Which is something the author advocates. I agree with him that you do not need to use rules that do not apply on elements you don't use. However, the multi cascade can be handled by a css preprocessor.
- rootlocus 8y ago
  You mean the original author doesn't need more? I'm all for minimalism, but my minimalism doesn't necessary mean everyone's minimalism. And while the readme mentions you might not need it, or you might need to add to it, IMHO if it's not something that meaningfully solves the problem for a majority of users, and if it's trivially small then it probably isn't that useful.
  - fortyseven 8y ago
    So... guess you don't use it then, eh?
  - birdtime 8y ago
    It's not really useful, no. But it's interesting. I read the readme and the five lines of code as a blog post. It makes a couple good points. First, there's no need to reset elements that aren't being used. Second, a reset file is redundant by nature since it's overwriting a "reset" provided by the browser, that's subsequently overwritten by any custom styling. But yes, in virtually every scenario it's more practical to not think about it and use normalize.
- dosy 8y ago
  Always appreciate a good Aliens reference. Especially when it's helping point out what the parent didn't understand about the approach. I think a minimal set of cross-browser CSS reset rules is a very interesting thing.
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 ago
  That 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 ago
  Ideally, 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...

pornel 8y ago

You're missing the point here. The author is not looking for normalize.css, but advises against such nuke-it-from-the-orbit approaches. It's just 5 rules, because you don't need more. And you can copy'n'paste them if you don't want to bother with npm.

yoz-y 8y ago
The reset parent posted does better job of explaining what it does than this micro reset. Which is something the author advocates. I agree with him that you do not need to use rules that do not apply on elements you don't use. However, the multi cascade can be handled by a css preprocessor.
rootlocus 8y ago
You mean the original author doesn't need more? I'm all for minimalism, but my minimalism doesn't necessary mean everyone's minimalism. And while the readme mentions you might not need it, or you might need to add to it, IMHO if it's not something that meaningfully solves the problem for a majority of users, and if it's trivially small then it probably isn't that useful.
- fortyseven 8y ago
  So... guess you don't use it then, eh?
- birdtime 8y ago
  It's not really useful, no. But it's interesting. I read the readme and the five lines of code as a blog post. It makes a couple good points. First, there's no need to reset elements that aren't being used. Second, a reset file is redundant by nature since it's overwriting a "reset" provided by the browser, that's subsequently overwritten by any custom styling. But yes, in virtually every scenario it's more practical to not think about it and use normalize.
dosy 8y ago
Always appreciate a good Aliens reference. Especially when it's helping point out what the parent didn't understand about the approach. I think a minimal set of cross-browser CSS reset rules is a very interesting thing.

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 ago
That 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 ago
Ideally, 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...