I've been wanting to write this article for a long time - since August 25, 2015 to be exact. It's been in the back of my mind and bugging me forever. I'm glad I'm finally going to sit down and bang this post out despite there probably being a ton of great resources out there on this.

If you don't already know, Bootstrap is an awesome front-end framework! I've been using it for a really long time, and I think it helps out all types of developers. It doesn't matter if you are front-end or back-end developer, complete noob or an advanced coding robot from the future. Bootstrap is a robust and flexible set of tools that helps you code awesome websites for all use cases.

Bootstrap 4 recently came out of alpha and into Beta after being in it that super-early build for like a year. If you're thinking, "Wow, it's taking forever and is still in beta...", don't. What the Bootstrap core team is doing is no small task. They're literally pushing out code that is used by *gazillions* of people and websites (seriously, like over 20% of the web)! On top of that, CSS exist in a land where every individual developer is super opinionated about the right and wrong way to do things. It's no easy task.

With all that being said...

Let's talk about a really neat new feature in Bootstrap 4 called Reboot. In this post, I'll blab a bit about the history of resets, Bootstrap, some cool features of Reboot, and how you can start using it today.

Reboot in the simplest terms possible is Bootstrap 4's "reset". It's a little bit different than your typical reset though.

The Eric Meyer Reset

I'm pretty sure the term "reset" first came around when Eric Meyer, a guy who is kind of like the godfather of CSS, came out with a stylesheet to literally reset all browsers to look the exact same. The problem with this is, it really reset things. Literally everything looked the same regardless of the element. Elements like h1 s were the same as h2 s. This meant front-end people would have to build their own base styles. This is both a good and bad thing.

Many front-end people in the early days would build out their own "resets" on top of this since their base styles stayed consistent.** This also unfortunately left some noobs / beginners in the dust who never really grasped the importance of having a base.** For example, people who would do something like this:

h2 { color : #13335f ; font-weight : 700 ; margin : 10 px 0 20 px ; font-size : 30 px ; FLOAT : LEFT ; }

This went on for what felt like forever. If you're old enough to have lived through these small hustle projects, congratulations on being a survivor. In my humble opinion, a lot of back-end developers hate CSS to this day because of dealing with things like this.

Normalize.css

Upgrade Your JS Go from vanilla JavaScript 👉 React

Watch for FREE

So after these dark-ages of having to deal with some really messed up stylesheets, a lot of people's personal "base" resets started becoming popular and shared. The most popular was definitely normalize.css.

Normalize was different because it reset your browser styles and gave you some dead-simple, super pretty base styles. It made building some nice projects a breeze. It gained serious popularity.

Normlalize.css doesn't use border-box by default though, requiring that you add it somehow. I can't imagine doing any front-end development without this property. Normalize.css is still active today, widely used, and you can you can still easily swap this. I honestly don't know why it's not default for all elements, but I'm sure there's some good reason since many projects still use normalize as their go-to reset.

Incoming Reboot.css

Now comes Reboot.css . Reboot.css is like a normalize.css 2.0 in my opinion. It has some awesome "reset" type features:

It uses box-size: border-box; by default on all elements.

by default on all elements. "Resets" browser styles for consistent cross-browser development.

Keeps a simple and natural base-style on elements.

Carries a little bit of an opinion on how to write your CSS for the modern web.

Made by the Bootstrap people (lots of trust)

Bootstrap 4 puts all this into a single page making it dead-simple to use.

The Eventual Future of Frameworks

CSS is becoming more and more featured-pack by the day. Things like "Flexbox" or "Grid" are getting wider browser-adoption making frameworks less necessary for doing complex layouts easily.

On top of that, you have some ridiculously cool tools like LESS , SASS/SCSS , and PostCSS becoming the default go-to for writing styles making it easier to automate tedious tasks such as creating a set of button styles.

In enough time, I can easily see frameworks becoming 95% smaller or the birth of a new, super simple, bare-naked framework that gains massive popularity. We're not quite there yet, but, heck, that might be even be Reboot one day.

So, how can we test Reboot.css out now and actually see what the heck it is?

You could go to the Official Bootstrap 4 Documentation and just dig through the docs and get going, or you can just mess with this codepen I made. It has every single element on a single webpage and lets you easily swap out different resets to see the difference.

If you want to just find the CSS and test yourself, check these resources:

If you read the intro paragraphs, you'll already know this. Reboot.css uses box-sizing: border-box; by default for all elements. This in my opinion is the most distinguished difference between normalize.css .

So, it's safe to say it's "responsive ready" out-of-the-box. Here's what it looks like at the top of the file:

*, * ::before , * ::after { box-sizing : border-box ; }

If you're familiar with this, it's taken from Paul Irish's arguably super famous post.

A Quick REM Demo

REMs are just not for font-sizing, it can be used for all spacing. To show you just how much Reboot.css embraces this, checkout the demo below:

Unit of Measurement Differences Explained

CSS3 introduced a new unit of measurement called rem . There's kind of a huge debate amongst us nerds on the best use for sizing on the web. These rem s have a pretty darn good solution to the whole debate. It all comes down to accessibility for users (resizing of font-sizes / screen-sizes) and maintainability / consistency for front-end developers.

Here it is summarized:

px : Good for consistency, bad for accessibility

: em : Good for accessibility, just okay for maintainability / consistency

: rem : Good for accessibility, really good for maintainability / consistency

That's a huge TL;DR: of the whole debate, but there's a ton of good resources to learn a bit more about units of measurement.

How REMs Work

Let's assume you know nothing more than pixels as a unit of length. Going to try to break this down in laymen terms without code.

So, you know that 100 pixels is always going to be 100 pixels long regardless if you're have your operating system show large fonts, are on a 4k monitor, or those 100 pixels are in a 1000 or 5000 pixel sized container. It doesn't matter. 100 pixels is 100 pixels. This is good for consistency but bad for usability since it doesn't scale well to user-specifc preferences.

The unit em was first introduced to try and help with this "scaling" issue by being a computed unit of measurement. This means the sizing is always relative to something, in this case the parent. So in a basic example, you could say: "Instead of being 100px long, be 10% of the 1000px long container" or 0.1em ". This way if the container was resized by the user / device / system / whatever it would remain consistent in perceived length.

This is cool, except it gets real crazy when you have an em be relative to another em . Or worse, an em that is relative to an em that is relative to an em . Things get complicated and messy and become impossible to deal with overtime.

I like to think of rem s as a simple em . Everything is always relative to the root (aka, the body tag or html tag). So if your root was 1000px , your length is 0.1rem regardless of container, settings, whatever.

Have you ever designed a website to see slight differences between operating systems? Mac's probably look the best but sometimes fonts will look not as crisp on Windows?

This is because of how systems render fonts. Reboot.css embraces using whatever their native font stack is to the operating system.

This actually means 2 things.

Near-zero load time for the default font Uses the font the user wants / looks best for them

Here's the code. Check-out all the fallbacks!

$font-family-sans-serif : -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI" , "Roboto" , "Helvetica Neue" , Arial, sans-serif !default ; font-family : -apple-system, BlinkMacSystemFont, "Segoe UI" , Roboto, "Helvetica Neue" , Arial, sans-serif, "Apple Color Emoji" , "Segoe UI Emoji" , "Segoe UI Symbol" ;

Okay, maybe it's not dead, but reboot.css makes the following elements no longer have any top margin:

h1

h2

h3

h4

h5

h6

p

ul

ol

dl

pre

This actually makes a ton of sense. I can vouche for this method. I never use margin-top in any of my base css that I have ever done. It makes things fall into place a lot easier when things are CMS powered and the content can be anything. I would even suggest adding table to this list.

Reboot also provides a clean and naked style to all common elements. Things like blockquote , tables , forms and much more. This goes a bit more to be able to have clean and simple form fields to get up and running with.

By default Reboot.css uses touch-action: manipulation to speed up any delay that might exist for touch users.

Here's the full code:

a, area, button, [role="button"] , input :not([type=range]) , label, select, summary, textarea { -ms-touch-action : manipulation ; touch-action : manipulation ; }

You can see that clicking links, buttons, and form fields will be a lot quicker and responsive on touch devices.

Overall, I would say Reboot.css is a great project and continuation of standardizing the modern web with familiar web practices. You can learn more about reboot.css at the following links:

Like this article? Follow @whatnicktweets on Twitter