loading...

A Modern CSS Reset

Andy Bell on October 01, 2019

I think about and enjoy very boring CSS stuff—probably much more than I should do, to be honest. One thing that I’ve probably spent too much time t... [Read Full]
markdown guide
 

How about adding an overflow-x: hidden to the body?

 
 

Not a great idea! This'll kill position: sticky for all the child elements.

The mental leap for that is a tough one for me. Why isn't my position: sticky; working?! Oh, because some parent element has hidden X overflow? 🤯

Yup. I completely forgot about that bugger. Definitely not helpful to be set as a global style in that context.

Apparently if you set the height of the element you're overflow hidden'ing on, sticky will work. So something like:

#container {
    overflow-x: hidden;
    overflow-y: scroll;
    height: 100vh; /* need to set this for child elements to be able to use display:sticky (c.f. https://github.com/w3c/csswg-drafts/issues/865) */
}
 

Just be careful with CSS and contain within something else overflow-x: hidden; as needed. Generic reset rules about body overflow just paper over cracks

 

Hello,

I just read your article, and there is one point that bothers me in this CSS reset.

For example, your idea of removing "list-style" and "padding" on "ul [class]" has too much of a too powerful selector.

Imagine that I want to change the style of UL with a "class", I will logically use ".my-list", but your selector will be more powerful. And I could not change neither the "padding" nor the "list-style", it is absolutely necessary to put more selector:

Your CSS reset is therefore not compatible with the BEM method for example. en.bem.info/methodology/css/

I would tend to let the developer choose if he needs to delete or not the style on with a "class"

 

Very nice, Andy. I'll consider using it from now on 👍

I was wondering about the box-sizing setting selector: isn't *::before equivalent to just ::before?
I'm asking because I've seen that everywhere with the asterisk, so I wonder if there are any differences I'm missing out.

 

Both will work fine! It's just a stylistic choice, really.

 

I'm not sure if it's a good idea to reset styles for only ul and ol elements that have a class. I'm guessing the rationale behind this decision was to remove default styling for elements that are semantically lists.

But consider the following case where the user is expecting default styling on a ul element, plus an added purple style for the text:

<ul class="text--purple">
  <li>Apple</li>
  <li>Orange</li>
  <li>Banana</li>
</ul>

In this case, the default margin and padding would be removed and AFAIK there isn't a way to restore the default UA styling.

 

Yeh that's valid, but I've found the styles as above more useful. It's probably better for you to create a fork in this instance.

 

Well, this list is soooo arguable.
At first, AFAIK adding list-style: none resets accessibility of lists, so it's better to apply transparent image to list-style-image.
Article with owl selector — really? I mean, if it is a reset for blogs, this thing should be boilerplated, but for all the possible cases do we all really need it? 'Cause article tag is used not just to markup text articles in magazines :)
And of course images shouldn't be blocks by default (you are proposing reset, aren't you?). If you don't like image's gap at the bottom, just add vertical-align: middle — and the 'problem' is solved.

 

I actually tend to agree with this. A reset should align browser defaults, whereas what’s been proposed is more of a boilerplate. A reset should be able to be used in any project without drastically changing things, but rules like the owl selector, image block, reduced motion query does exactly that. While these may be great for some projects, I wouldn’t be comfortable blindly dropping this in as a reset.

 

I'd properly respond but I actually can't be arsed. Maybe actually reading the post again, but you do you 👍

 

Sorry but where do you answer this in the post? You talk about how the list looks but removing the semantics is completely a different thing and I can't think why you'd want to use a list element without it carrying those semantics.

Anyway, thanks for the post, it's made me revisit what is really needed again.

 

Does this:

@media (prefers-reduced-motion: reduce) {
  * {
    animation-play-state: paused !important;
    transition: none !important;
    scroll-behavior: auto !important;
  }
}

can just be like this?

* {
  animation: unset | revert | initial !important;
  transition: unset | revert | initial !important;
  scroll-behavior: unset | revert | initial !important;
}
 

It's in the media query for if someone prefers reduced motion. Your code will just disable animations globally.

 

Yes sorry, i forgot to add the @media query. By point was about the values (unset, revert, initial). But i think forcing specific value is more stronger, while my proposed values are not predictable.

 

What do you think about adding something like this:

p:first-child, h1:first-child, h2:first-child, ... {
  margin-top: 0;
}

p:last-child, h1:last-child, h2:last-child, ... {
  margin-bottom: 0;
}

or even:

*:first-child {
  margin-top: 0;
}

*:last-child {
  margin-bottom: 0;
}

I seem to always be removing margin top on the first item and margin bottom on the last item, since it pushes a container out too far or something.

 

I'm curious whether the text-rendering: optimizeLegibility; avoidance is still applicable. That article is from 7 years ago, which is an eternity in terms of phone age. It'd be nice to see a set of updated measurements!

 

Thanks for a great reset! Really liked the smart list styling.

But can't agree with the prefers reduced motion part. This option is for people who wants reduced motion. Not no motion at all. A lot of small animation can be critical to understanding the flow or function, without triggering motion sickness or nausea.

Also opacity and color changes usually works just fine to.

Well I could rant over this for hours, but I guess you get my point 😄. Devs always need to add this media query on problematic animations (also in JS code), but that must be up to the author of the code to decide.

 

I disagree. The great thing about it being OS is that you can fork it and remove the bits you don't like 🎉

 

Absolutely. Just know how copy paste friendly this community is, many developers will just take it and don't think what it does. Just wanted to make sure people know what it does.

But will definitely try this on my next project. Thanks!

 

Pretty good stuff. One question for you. In the anchor element section you mention "This could be set on links globally, but it’s caused one or two conflicts in the past for me, so I keep it like this." I'm curious what those conflicts were.

 
 

Great list!

I always add:
font-size: 0
to the body element, to disable the gap when you use display: inline-block

 

I would only recommend doing hacks like that on the element itself, rather than globally.

 

I use inline-block pretty often. It’s a necessity for me.
But not everybody has the same approach. Thanks for your post again. Very helpful

 

Interesting technique. Does that no longer have SEO issues? Maybe the crawler is smart enough to go further into the page, but I remember that being a solid anti-pattern a while back.

 

I don't think so, but should be tested :)
My opinion is that if you put "font-size: 0" to the

element, then you don't plan to have text directly in the body element. The text should be inside of a

,

or other (all with a visible font-size). Nothing is concealed, so it should be crawled normally.

 

Thank you very much for the resetCSS and the breakdown. Will use it for the next project.

 
 

This was a very cool read - the "lobotomized owl" in particular was new to me and definitely something I'll incorporate now. Thanks! 😊

 

It's pretty heavy-handed. If you want to get more granular - check out this type of selector.

article {
  h1 + p {
    margin-top: 20px;
 } 
}
 

Thanks for the article Andy, I'll definitely create mine based on this one. :)

One question though: Why don't you use more reset on buttons?

 

Have you considered using rem instead of em on this part? (so the margin is relative to document font size)

article > * + * {
  margin-top: 1em;
}
 

em is relative to the element in question’s size, which I’ve found generates a nice, natural rhythm. I went into more detail using rem units in this article, last year,

 

Thanks for this, Andy! I've been using something similar that I have created, however, it's definitely not as robust. I'll definitely be borrowing some of this!

 
 
 
 

I prefer to keep the default margin / padding on elements, since it requires less CSS to set this back to a real value and I can't e.g. forget to style an element which is added dynamically

 

Hi, I'd like to translate this article to Chinese, and publish the translation at nextfe.com Can you give me the permission to translate it?

 

What if text-rendering: optimizespeed placed to html part rather than body part?

 
 

We still find places where a 3rd party plugin will use content-box - and that the inherit is still a win: paulirish.com/2012/box-sizing-bord... - Some of this other stuff seems like they have edge cases. We'll play with it a bit and see if we can break it.

code of conduct - report abuse