>Another thing: It's Ok for some elements to be different between browsers.
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.
To me it feels like the author of that project didn't get the point of resets.
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.
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:
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.
That will force you to use completely different CSS layout model. Yes today is common practice the use of box-sizing: border-box and it should be the first line of code when you set your layout. I don't what to force anyone to use box-sizing: border-box.
You don't need to reset things you won't use... then proceeds to reset tables, table properties, and iframe borders? This is the most nonsensical thing I've seen on here. Also resetting all h elements to weight normal when they're the most likely elements to have non-normal weights.
Persisting an npm package to your project for 5 css rules is a far more egregious case of "you might not need..." than a simple css reset could ever be.
at the start of every project and call it a day. That was my reset.
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 have always been strongly opposed to CSS resets and global CSS styling rules in general. There really is bo need for it if you know how to isolate your classes correctly. Some Atlassian plugins create global styling rules and they tend to break things.
The problem isn't with "isolating classes correctly" (how do you isolate classes correctly in CSS' flat namespace?).
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.
I recently started using CSS Grid with a view to writing concise, maintainable CSS that wasn't 'Jenga CSS' that people only add on to. I also wanted to get away from the 10000+ lines of cruft that many projects seem to think you need.
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.
I like the reasoning behind this, but am surprised it doesn't include resets for the (fairly opinionated) user agent styles for lists, which I'd argue for most sites get used more often than tables.
There's no such thing, to my knowledge, as a "browser reset"; there is a standardized normative default user-agent style sheet for HTML4 as specified in CSS level 2.
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.
[+] [-] slg|7 years ago|reply
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.
[+] [-] arendtio|7 years ago|reply
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.
[+] [-] Brockenstein|7 years ago|reply
[+] [-] hit8run|7 years ago|reply
[+] [-] pornel|7 years ago|reply
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.
[+] [-] lhorie|7 years ago|reply
[+] [-] thex10|7 years ago|reply
[+] [-] Reedx|7 years ago|reply
[+] [-] danyim|7 years ago|reply
[+] [-] saudioger|7 years ago|reply
[+] [-] vladocar|7 years ago|reply
[+] [-] escaper|7 years ago|reply
[+] [-] Kequc|7 years ago|reply
[+] [-] armandososa|7 years ago|reply
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.
[+] [-] geuis|7 years ago|reply
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.
[+] [-] brianzelip|7 years ago|reply
`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/.
[+] [-] temporallobe|7 years ago|reply
[+] [-] dmitriid|7 years ago|reply
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.
[+] [-] paulddraper|7 years ago|reply
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.
[+] [-] Theodores|7 years ago|reply
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.
[+] [-] KayL|7 years ago|reply
Probably, to clone normalize.css and comment out every lines as starter style is better than this micro reset (applying the same concept)
[+] [-] ericwood|7 years ago|reply
[+] [-] andrewmcwatters|7 years ago|reply
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.
[+] [-] vladocar|7 years ago|reply
Here is the webkit style: https://trac.webkit.org/browser/trunk/Source/WebCore/css/htm...