Change default styles css

Pop quiz! Measuring by the visible pink border, how wide is the .box element in the following scenario, assuming no other CSS has been applied? Our .box element has width: 100% . Because its parent is 200px wide, that 100% will resolve to 200px. But where does it apply that 200px width? By default, it will apply that size to the content box. If you’re not familiar, the “content box” is the rectangle in the box model that actually holds the content, inside the border and the padding: The width: 100% declaration will set the .box ‘s content-box to 200px. The padding will add an extra 40px (20px on each side). The border adds a final 4px (2px on each side). When we do the math, the visible pink rectangle will be 244px wide. When we try and cram a 244px box into a 200px-wide parent, it overflows:

Code Playground

style> 
 
.parent  
 
width: 200px; 
 
border: 2px solid black; 
 
> 
 
.box  
 
width: 100%; 
 
border: 2px solid hotpink; 
 
padding: 20px; 
 
> 
 
style> 
 
div class="parent"> 
 
div class="box">div> 
 
div>

With this rule applied, percentages will resolve based on the border-box. In the example above, our pink box would be 200px, and the inner content-box would shrink down to 156px (200px — 40px — 4px). This is a must-have rule, in my opinion. It makes CSS significantly nicer to work with. We apply it to all elements and pseudo-elements using the wildcard selector ( * ). Contrary to popular belief, this is not bad for performance.

This can be a helpful strategy if you’re trying to migrate a large pre-existing project to use border-box. It isn’t necessary if you’re starting a brand new project from scratch. To keep things simple, I’ve omitted it from my CSS reset. Expand to see an example of when this might be helpful. Show more

Browsers make common-sense assumptions around margin. For example, an h1 will include more margin by default than a paragraph. These assumptions are reasonable within the context of a word-processing document, but they might not be accurate for a modern web application. Margin is a tricky devil, and more often than not, I find myself wishing elements didn’t have any by default. So I’ve decided to remove it all. 🔥 If/when I do want to add some margin to specific tags, I can do so in my custom project styles. The wildcard selector ( * ) has extremely low specificity, so it’ll be easy to override this rule.

line-height controls the vertical spacing between each line of text in a paragraph. The default value varies between browsers, but it tends to be around 1.2. This unitless number is a ratio based on the font size. It functions just like the em unit. With a line-height of 1.2, each line will be 20% larger than the element’s font size. Here’s the problem: for those who are dyslexic, these lines are packed too closely together, making it harder to read. The WCAG criteria states that line-height should be at least 1.5. Now, this number does tend to produce quite-large lines on headings and other elements with large type:

Code Playground

style> 
 
*  
 
line-height: 1.5; 
 
> 
 
style> 
 
p> 
 This paragraph has a 1.5x ratio
 for line-height, and it feels
 pretty good, right? I think
 this text is legible and pleasant.
 
p> 
 
h1> 
 But it's a bit much on headings!
 
h1>

You may wish to override this value on headings. My understanding is that the WCAG criteria is meant for «body» text, not headings.

This is a pretty advanced little snippet, and it’s beyond the scope of this blog post, but here’s a quick explanation. Show more

Alright, so this one is a bit controversial. On MacOS computers, the browser will use “subpixel antialiasing” by default. This is a technique that aims to make text easier to read, by leveraging the R/G/B lights within each pixel. In the past, this was seen as an accessibility win, because it improved text contrast. You may have read a popular blog post, Stop “Fixing” Font Smoothing, that advocates against switching to “antialiased”. Here’s the problem: that article was written in 2012, before the era of high-DPI “retina” displays. Today’s pixels are much smaller, invisible to the naked eye. The physical arrangement of pixel LEDs has changed as well. If you look at a modern monitor under a microscope, you won’t see an orderly grid of R/G/B lines anymore. In MacOS Mojave, released in 2018, Apple disabled subpixel antialiasing across the operating system. I’m guessing they realized that it was doing more harm than good on modern hardware. Confusingly, MacOS browsers like Chrome and Safari still use subpixel antialiasing by default. We need to explicitly turn it off, by setting -webkit-font-smoothing to antialiased . Here’s the difference:

Antialiasing

Subpixel Antialiasing

MacOS is the only operating system to use subpixel-antialiasing, and so this rule has no effect on Windows, Linux, or mobile devices. If you’re on a MacOS computer, you can experiment with a live render:

Code Playground

p> 
 This paragraph uses the default subpixel antialiasing.
 
p> 
 
p class="antialiased"> 
 This paragraph does not use subpixel antialiasing.
 
p>

So here’s a weird thing: images are considered «inline» elements. This implies that they should be used in the middle of paragraphs, like or . This doesn’t jive with how I use images most of the time. Typically, I treat images the same way I treat paragraphs or headers or sidebars; they’re layout elements. If we try to use an inline element in our layout, though, weird things happen. If you’ve ever had a mysterious 4px gap that wasn’t margin or padding or border, it was probably the “inline magic space” that browsers add with line-height . By setting display: block on all images by default, we sidestep a whole category of funky issues. I also set max-width: 100% . This is done to keep large images from overflowing, if they’re placed in a container that isn’t wide enough to contain them. Most block-level elements will automatically grow/shrink to fit their parent, but media elements like are special: they’re known as replaced elements, and they don’t follow the same rules. If an image has a «native» size of 800×600, the element will also be 800px wide, even if we plop it into a 500px-wide parent. This rule will prevent that image from growing beyond its container, which feels like much more sensible default behavior to me.