CSS Micro Reset
github.com
github.com
This is one of those lessens that took me a while to learn. I spent a lot of my time early in my career trying to get every pixel the same between between IE and Firefox until someone asked my why I cared. I never gave the "why" much thought until that point; it was just something I felt I needed to do. As long as the site functions correctly and looks good in the various browsers, getting them exactly the same is nothing but a fool's errand.
But I know people who are perfectionists and still care about that level of control and I'm just happy that I am not.
I guess you supply your developers fully documented fluid-resizable, responsive, dynamic mockups with all possible states? That’s one lucky developer.
As a designer and developer, most (extremely talented!) designers that I end up working with still send me their designs as static PSD’s, and they also don’t understand enough HTML to know which design-choices are costly and which are not, and which don’t scale well with the screen / text / content, etc.
If the designer and developer don’t work together at the UI/UX stage then it’s completely understandable for the coded-up site to not be a pixel perfect carbon copy.
Every time I see someone go, "Hey, have you ever thought of a page design, like, not being consistent between browsers?" and seeming to expect readers' minds to be blown, it makes me want to ask, "Have you ever considered doing this, like, as a job?"
Neither have I, funnily enough.
The problem without resets is not that some client/manager/designer wants to see a pixel perfect page, but that differently sized default elements in different browsers can cause whole layouts to break / become non-functional.
If your layout is robust enough to compensate such variations, that's fine and you probably don't need a reset CSS at all, but the idea of reset CSS is not about efficiency in terms of lines of code, but about efficiency of developer resources. Developing something on top of a 100% defined state is much easier than constantly having to worry about different initial states.
Yes, resets aren't pretty, they are pragmatic.
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.
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.
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.
I think a minimal set of cross-browser CSS reset rules is a very interesting thing.
/*reset*/
h1 {margin: 0;}
/*your pretty styles*/
h1 {margin: 0 0 10px;}
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.
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.
1. https://helloanselm.com/2014/web-performance-one-or-thousand...
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.
/* CSS Micro Reset */
body { margin: 0 }
h1, h2, h3, h4, h5, h6 { font-weight:normal }
table
{
border-collapse: collapse;
border-spacing: 0
}
th, td
{
text-align: left;
vertical-align: top
}
img, iframe { border: 0 } * {box-sizing: border-box;}I'm not clear on what you're saying. It sounds like you're saying today it's absolutely something you should use but you don't want to force it?
Yes, correct.
Let me explain.. that is the most important decision you make when you plan your CSS layout. But is your decision to make. You can absolutely add this in the reset. Feel free to add stuff in the reset.
*{margin:0;padding:0}
Later I found that was considered a bad practice, but honestly? I found CSS is very unlikely to be the bottleneck for performance in most things I deal with nowadays.
Anyway, I like this micro-reset but I rarely start css from scratch these days, otherwise I would just memorize these rules.
I get the feeling the author doesn’t completely understand how this all works and what normalize.css and other resets are for.
There is no “browser reset”. There are browser defaults which vary slightly from one to another.
The point of normalize.css and other resets is to level the foundation when starting a new project.
`box-sizing` can be more nuanced than a wild card approach. On production stuff, I tend to use Tachyons’ module, http://tachyons.io/docs/layout/box-sizing/.
The problem is that even such basic things as lists and paragraphs will look differently in different browsers (different offsets, sizes, line heights etc.). Unless you cover every single element with a "correctly isolated CSS class", you need a global reset.
Resets are used precisely because browser defaults are not isolated but applied everywhere.
Could you copy or classes or styles everywhere? Yes, you could add a class to every element to reset it, or add full style override to every class.
All was going well with the layout but I wanted to avoid margins and padding, instead I wanted to use grid gaps.
Initially I did not have the 'bravery' to strip out all 10000 lines of cruft, I assumed some of it was 'important'.
However, just 'for a laugh' I thought of getting rid of the normalize.css buried in there, complete with rules for things like IE6/7/8. Much to my surprise my layout suddenly looked awesome, all margin and padding issues resolved. I checked on a few browsers and all is looking very good.
The biggest bonus was on the input boxes. These now work much better for layout and usability on all screen sizes. I can use things like the 'size' attribute and make the boxes sensible for what is going to be entered.
Fluid width type and no fixed breakpoints are also a huge discovery along with CSS variables. I also gave up on divs and spans, not to mention class tags. Instead of these empty calories I use HTML5 tags with schema.org attributes. If a product has a name, description, price or other attribute, I mark it up for the screen readers first then the CSS can work on those attributes. No need for 37 layers of containing 'div' boxes each with class tags for some lame 'Foundation' style framework.
It seems absurd to remove the margin/padding and then have layers of Jenga CSS on top to get it to be as per the some designer's drawing.
The major benefit is in speed, I am sure that people who have been creating this unmaintainable CSS bloat for the last decade or find my approach heretical but the scores on the doors of what 'Lighthouse audit' says don't matter to them either.
I urge anyone to get rid of the resets as well as the inflatable arm bands and to let go of the hand-rails. Some people have never ventured out without their CSS resets, a bit like those children that have never gone anywhere without being in a car.
Probably, to clone normalize.css and comment out every lines as starter style is better than this micro reset (applying the same concept)
I agree with everything else the author is saying, though. But there's no point in this existing when normalize.css does. Even then, you really shouldn't be using that in my opinion for the same reasons the author specifies.
Here is the webkit style: https://trac.webkit.org/browser/trunk/Source/WebCore/css/htm...