CSS Adventures: Avoiding CSS resets
CSS resets, though, are another story.
What is a CSS reset?
In a nutshell, a CSS reset file is a file that you can either build upon or let sit under the rest of your CSS. It is designed to ensure consistency across different browsers, particularly with regards to margins, padding, font sizes and other features that may be present in only one browser (Firefox-only or Chrome-only).
Building future-proof (and browser-proof) CSS
I started using a CSS reset about a year ago. I used normalize.css as I had used it at my workplace at the time. I was admittedly sucked in from the moment I read “consistent” and “all browsers” in the same sentence. I didn’t think much further than that. I thought that if I had base CSS like this, it would help prevent browser compatibility issues down the track.
Putting aside the fact that I test my designs meticulously in Safari, Chrome, Firefox, Opera, and IE (often right down to IE8, and IE7 if I feel like being a ninja) anyway, browser compatibility issues can’t necessarily be solved with just CSS, much less a CSS “reset” file. Browsers were built differently and naturally have their inconsistencies. A normal part of web development and building websites – especially good websites – is sweating out stuff like cross-browser compatibility, and I dare say we make our lives hard by making this seem like a chore.
There are many features of HTML and CSS that only work in modern browsers, and I personally choose to avoid them until I have a firmer grasp on how the feature works, and until more browsers support the feature. It means less headaches associated with trying to make things cross-browser compatible.
CSS wizard Harry Roberts puts forward his viewpoint on building websites to last:
You’ve got new stuff for new browsers and old stuff for old browsers. The thing is, the old stuff works. So if you need [the site] to last a long time … just use the thing that will work everywhere.
User experience over just appearance
While you are considering older browsers and attempting to give them the same experience, you are potentially including unnecessary declarations. Vendor prefixes and extra classes to target IE8 are nice hacks, but they are just that – hacks. Older browsers were not meant to support flexbox, columns and pseudo elements, because they were not originally built to support these features.
When you attempt cross-browser compatibility, consider what the user experience actually is. A (good) website will, more often than not, function with minimal CSS. Letting a browser use its default form appearance, or display content in one column instead of two, is a small sacrifice. Users will still be able to use the form and read the content.
I was working with a fellow designer last year, who wanted the placeholder text in forms to be the same colour in all browsers (they are light grey by default). Changing the colour in certain browsers proved to be difficult or impossible. Eventually, as a team, we decided that it was a small change that was not worth the effort, would not improve the user experience, and, quite simply – that placeholder text should not be altered from its default, due to potential accessibility issues.
Building without a CSS reset
I believe it was in one of Jonathan Snook’s SMACSS videos that he made the point of not using normalise or reset CSS as a base because “you end up overriding it anyway”. I had never tested his hypothesis until recently, but he suggested removing your normalise.css or reset.css, and seeing how much actually changed. Chances are, there will be very little that has changed. Craig Buckler also makes this suggestion, along with the advantages and disadvantages of CSS resets.
CSS resets were designed to be modified and built upon, though if you’re just launching a quick-and-dirty prototype or simple website, it may make sense to use one. It depends on the situation. At my previous workplace, we used it as a base, and just laid styles on top of it, with the idea that – if reset.css was ever updated – we could easily overwrite our copy with the updated version without needing to worry about affecting the rest of our code.
I have tested in different browsers from the day I realised other browsers existed. When you’re young, in the early 2000s, and you’ve constantly built websites and only checked in one browser (usually IE), and finally learn that other browsers exist – everything kind of becomes a big deal. Because I’ve been meticulous about that kind of thing, CSS resets seem redundant to my workflow.
Removing normalise.css from my blog
Yes, I spell in British English, so for me it is “normalise”, not “normalize”.
A few days ago I pushed an updated CSS file to my blog. I only cut the file size down a tiny bit, but by removing normalise.css, I shaved off 2KB (minified).
I noticed that a lot of elements in normalise.css were elements I didn’t even use:
- some HTML5 elements, such as
- a lot of rules for forms that I didn’t consider important because I only have a couple of simple forms on my website,
tablerules – there are no tables on my website at all.
There were a couple of miscellaneous things I did keep, but it’s true that a lot of it was overridden by my own rules, and normalise.css was just sitting under the rest of my code serving no good purpose.
Are CSS resets really necessary?
CSS resets don’t provide much presentation, and aren’t a “complete” framework, considering CSS is just one ingredient of an complete website. They are easily lost under everything else, and don’t really perform as a fire blanket or safety net the way other types of frameworks do.
I would go so far as to not call it a framework, not even a tool, but just a guide. A guide that can provide reference for what you may want to include in your CSS – but is entirely optional.
This is a really interesting post. I’ve never heard of CSS reset before, but I will definitely look into it.
I’m currently working on a new WordPress theme for my blog and I’ve found it so frustrating trying to get certain features to work in different browsers. I give up quite easily and then just scrap the feature altogether for something I know works.
I’m going to bookmark this for future reference. :)
I have never used a CSS Reset, however I have used Bootstrap once to test it out, because I was that person who preferred to make their own Media Queries. Bootstrap through as I quickly learned is really heavy. I use it at a company website of mine, but I will be changing that asap. I would not call myself framework dependent but I also do not see the use in avoiding certain tools. I currently love PureCSS.io by Yahoo. I have it for my blog and will probably use their grid while I revamp my website, I find its extremely flexible so there is no cookie cutter look to it. But I agree with the whole CSS reset. Never have used it and probably never will. Everyone in my computer science courses live off bootstrap, its hilarious they have no sense of design, and its sad to say a lot of website (major ones) seem to be taking the same route of using that cookie cutter feel.
I couldn’t have said it better, Domenica! That cookie cutter feel is definitely the part that makes me feel a bit iffy about using frameworks. Passionate self-motivated developers like you and I understand the flexibility that comes with making your own code and keeping it clean in the way you like. I just couldn’t understand the hype about Bootstrap, especially when I first heard about it.
I can understand why a lot of the companies both you and I work/ed for like to use Bootstrap or some kind of framework, but at the same time, it is a really heavy framework, and most people don’t need everything it offers. I think that’s why responsive frameworks were created – to reduce the bloat that comes from the extra stuff like buttons, lists, menus, and so on. It seems that a lot of people praise Bootstrap, and some developers even check to see if a website is based off Bootstrap. Perhaps because it is painfully obvious most of the time. Again (and I am not taking sides) they should be used as a base when you need it, but a good website shouldn’t need to rely on a framework.
The idea of CSS resets is intriguing. Years ago I was extremely active in coding but am now getting back on to my feet so there seems to be a lot of new techniques.
Compatibility can be so frustrating especially when you are on the viewers side. Not be able to full access a website can be quite annoying so double checking other browsers is just as you said, “a chore.”
Great post, love the site!
Thanks Danielle! I don’t think I’ve stopped coding since I started learning, but it has been a gradual learning curve and I remember that it was many years before I learned how to code well. I only just started writing about web development on my blog so I hope to keep writing about it, and hope my posts help you too. :)
Ugh… I’ve used these in the past, more so when I finally gave in and just tested Genesis out. They’re kind of a huge pain in the ass to deal with, I think, as I have had a lot of trouble with CSS in the style.css file through working with the reset, which… I guess it goes back to frameworks. I’ve learned the hard, expensive way that I, too, hate frameworks. I just prefer those fancier features to be available in plugins and themes to not require parent themes, etc. to change shit about them… I also can’t tolerate Bootstrap. >.>