Being picky about a CSS reset for fun | Hacker News Reader

Being picky about a CSS reset for fun

chriscoyier.net

144 pointssurprisetalk88 comments

In the past month or so I finally managed to get into web development (using cloudlfare workers/pages, they are amazing), and I tried to do a bottom up approach. I really dont like huge frameworks that you install with a sleek small command but they add 100s of weird files to your repository that you have no idea what they are for and cant really all read. So I started off with just HTML, vanilla js and ofcourse CSS. Now after a weeks of using that stack, Im slowly starting to understand why there is certain software (frameworks, packages) that everyone seems to be using, and I may switch as well.

One of the first things I ditched was CSS and I switched to tailwind. Apart from making it easier to make stuff look good, it just generally seems to make building layouts so much easier. Maybe I just did not go enough into CSS, but I can not see myself ever going back to vanilla CSS now that I have started using tailwind, so articles like these I always find interesting as they show experienced people not using tailwind so they probably have some good reasons why they prefer CSS.

I applaud your pragmatism. And I wish this pragmatic attitude was more common here, it’s refreshing in a sea of negativity whenever anything about web dev is posted.

Re: CSS layout. It’s actually just a very big, complex practice to become proficient in. If you’re ever inclined to go back and relearn it, it helps to accept that from the outset. Once you’ve accepted that it’s a fairly involved learning process, the successes should feel more significant and the failures hopefully more temporary. But!

Re tailwind: if it’s working for you, and you never feel compelled to drop into lower level styling concerns, that’s fine. Great even. You’re getting stuff done that you want to do, with tooling that addresses your needs! I don’t personally love tailwind, and I much prefer to write styles directly… but it’s obvious tailwind solves this well for you and others who don’t share my preference.

Re CSS vis tailwind: probably overly pedantic, but you are still using CSS. You’re just not authoring it directly. I’m only pointing this out because you may find a time when tailwind doesn’t do everything you want/need, and it’ll help to know it isn’t some styling black box. It’s just a very thoroughly robust abstraction around the styles you could write directly if you choose. And if that abstraction, however robust, doesn’t fit your needs, plain CSS is always there to supplement it.

Thanks for you words, comments like these make me appreciate sharing my thoughts here! Regarding your points, I don't see myself getting deeper into CSS in the near future, but I can't say it will never happen. For now though, I see both CSS and tailwind as means to an end and I am not yet interested in understanding how they work.

I've been through your journey, and CSS was by far the hardest to wrap my head around. Once JS clicks the journey is smooth, but CSS always feels like it'll be hard.

And then one day ... there it is. It all just makes sense. Not as much sense as JS! But enough sense for me to think, huh, I never thought I'd get this.

My one criticism of Tailwind, which I enjoy but do not currently use, is that it's likely to delay if not prevent this ultimate moment. If your long-term goal is to be a proficient front-end developer, I think you should try getting dirty with CSS sometimes.

Not always! Use Tailwind when you have a thing you need to get done. But sometimes.

Same!

Really wanted to start from scratch and I'm just using vanilla html/css/js for

https://ameye.dev/

Haven't found the need yet for any frameworks.

i really like the design of your page, good job!

> Haven't found the need yet for any frameworks

This is a static page, CSS framework shine for dynamic page where style needs to change beaded on state.

Tailwind is vanilla CSS though right? If someone created a stylesheet that just mapped one class to one CSS rule, and did that over and over for all the kinds of rules (with sensible spacing variations), you've got 90% of what tailwind is as far as I understand.

It's just CSS classes.

> mapped one class to one CSS rule

So they essentially reinvented the style attribute in a less verbose form?

Yes, along with the variations. So you can do things like “text-green hover:text-red”

Some of the other 10% is stuff around theming and design systems. This isn't something that injects cleanly into inline styles. Also media queries and hover states etc can't be done inline.

If it's a reinvention it's objectively better at least.

I think you're confused. What they're saying is it's a reinvention of

  ```css
   .card {
     ...
   }
  ```
  ```html
   <div class="card" />
  ```

RATHER than a reinvention of

  ```html
   <div style="..." />
  ```

I meant this tailwind framework looks like a reinvention of style="..." inline styles.

  <div class="block">...</div>
  <div style="display: block;">...</div>

https://tailwindcss.com/docs/display

So we've gone from inline styling to separating markup and presentation with CSS but now we've gone back to inline styling.

The whole separating markup from presentation doesn't quite work for any non trivial web-app type of webpage.

Because the presentation affects markup. You'll have to add wrapping divs to accomplish any kind of complex layout for example.

Once you can't separate it in your mental space, it doesn't matter that its in two different files.

But the solution is to turn CSS into inline styles?

> You'll have to add wrapping divs to accomplish any kind of complex layout for example.

I don't know about that. I think selectors are pretty powerful. Have managed to avoid littering the HTML with structural nodes by using them creatively. CSS has gained a huge number of features since I first learned it, there's even better ways to do stuff now.

Less verbose? Ha, far from it. Look at the tailwind examples. One div tag now has 6 or more classes attached

Well I suppose it's less verbose than a lengthy style="..." attribute that accomplishes the same thing.

Now it's a lengthy css instead. It seems to me we are going backwards...

Out of interest, have you built anything non-trivial with tailwind?

I've used CSS, and Tailwind and not worrying about naming everything correctly and not skipping around different files is a dream for me. Perhaps that's my brain, Idk.

Further I have gone over old code, and haven't had any problem with maintainability

> Well I suppose it's less verbose than a lengthy style="..." attribute that accomplishes the same thing.

It's not actually the same thing. What you're talking about is inline styling which takes precedence over class-based styling. It's generally considered bad practice to rely on inline styles. The traditional approach is `style="card"` not `style="...a bunch of rules..."`

  <div class="block text-black">...</div>
  <div style="display: block; color: black;">...</div>

Looks like the same thing to me. Only shorter.

With traditional css you'd most likely have a class for all the relevant attributes.

Of course. That's how I learned CSS and how I wrote the CSS for my site. Apparently that's not how things are done these days. People have one class for every property and value combination now and essentially write the entire class inside the class="..." attribute. Can't understand why.

Like I said. It's not at all the same thing. Inline styles have different behavior from class-based styling

Which was always what anyone with any sense wanted. CSS selectors were a mistake, no-one actually writes web pages like the CSS Zen Garden nor should they. The only problem with inline styling was the verbosity (and even then, we've had transparent compression in HTTP for about 30 years now).

I think it's nice I can change "color: red" to "color: blue" and "padding: 1rem" to "padding: 1.5rem" in one place and have it take effect everywhere it's relevant.

You can do this with CSS variables now I suppose, but this very quickly becomes "CSS classes, but with extra steps".

> I think it's nice I can change "color: red" to "color: blue" and "padding: 1rem" to "padding: 1.5rem" in one place and have it take effect everywhere it's relevant.

I agree, but that place is normally the code/templating engine that generates your webpage. So it really shouldn't matter if it's repeated on the wire.

> You can do this with CSS variables now I suppose, but this very quickly becomes "CSS classes, but with extra steps".

Variables are much simpler and easier to understand than selectors.

> CSS selectors were a mistake, no-one actually writes web pages like the CSS Zen Garden nor should they.

I see, we finally reached the root of the issue.

Why are CSS selectors a mistake? Doesn't seem that way to me. Why shouldn't I use them?

Complete lack of encapsulation. You never know when changing one element is going to change another, seemingly unrelated element - e.g. you add a class to a high-level element expecting to get a border around your page, and it gives you a border around your page but also around some small elements on your page that are picked up by that same selector. You can't reliably reuse your styling or components between pages, because the exact same element placed in two different pages might end up with radically different styling.

> You never know when changing one element is going to change another, seemingly unrelated element

Isn't this a symptom of the selectors not being specific enough?

> You can't reliably reuse your styling or components between pages, because the exact same element placed in two different pages might end up with radically different styling

Can you give concrete examples of this happening?

I can provide an example I think is a good use case for highly specific selectors: turning HTML lists into file system trees.

https://www.matheusmoreira.com/css/tree.css

  ul.tree,
  ul.tree ul {
    list-style-type: none;
    padding: 0;
  }

  ul.tree li {
    margin-left: 1em;
    border-left: 2px solid var(--tree-color);
  }

  ul.tree li code {
    display: block;
    position: relative;
    padding-left: 1em;
    padding-bottom: 0;
    line-height: 1em;
  }

  ul.tree li:not(ul.tree > li:first-child) code::before {
    content: "";
    position: absolute;
    left: -2px;
    width: 0.75em;
    height: 0.5em;
    border: 2px solid var(--tree-color);
    border-top: 0 none transparent;
    border-right: 0 none transparent;
  }

  ul.tree li:last-child {
    border-left: 2px solid transparent;
  }

  ul.tree li:has(ul) > code::after {
    content: "/";
  }

  <ul class="tree">
    <li><code>~/.files</code>
        <ul>
          <li><code>~</code>
              <ul>
                <li><code>.bash_profile</code></li>
                <li><code>.bashrc</code></li>
                <li><code>.vimrc</code></li>
                <li><code>...</code></li>
              </ul>
          </li>
          <li><code>GNUmakefile</code></li>
        </ul>
    </li>
  </ul>

That sort of thing feels like a perfect fit for CSS selectors to me. I admit it's not a super complex design (or even a beautiful one, I suck at design) but it does demonstrate the value of selectors.

> Isn't this a symptom of the selectors not being specific enough?

Well, yeah, but that's a "you're holding it wrong" argument. If you make your selectors specific enough then they will apply to the right elements, and if they applied to the wrong elements, well, they weren't specific enough. In practice people resort to only ever using a classname as a selector because anything else is too likely to break; there's no way to find out which selectors apply to which elements or which elements are covered by which selectors (e.g. you can't do the equivalent of "find references" on a variable).

> Can you give concrete examples of this happening?

Only on the level of, like, "my company's whole webapp" (but I've seen it cause real bugs in prod if that's what you're getting at). Getting surprised by which selectors get applied isn't a problem you can show in small examples, because it doesn't happen with small examples; it's only when the selectors and DOMs are too complex to keep in your head that you have a problem.

> That sort of thing feels like a perfect fit for CSS selectors to me.

Why does it need selectors though? It doesn't change based things at higher level (which is the failed ideology that the likes of the CSS Zen Garden were pushing - the idea that you want your component's styling to magically change to fit in with the page it's on or what's happening around it). What are you doing here that you couldn't do with a self-contained component that knew how to style itself?

You can think of it like the style attribute, but with support for CSS media queries, pseudo classes, variables and everything else. If the style attribute let you do that from the beginning of the web, would we have ever felt the need for separate stylesheets? Web development might have turned out quite different.

It is just CSS, but I would not consider equating tailwind to CSS. Instead, I write tailwind utility classes that seem more friendly and approachable to me and their behaviour is also much more predictable to be at least so far. While it does get mapped to CSS in the end, I dont really have to read/understand that generated CSS and just enjoy tailwind handling it for me.

It's more than just CSS classes. If it was just CSS classes I think people should just make their own utility classes. It adds a build step for things like, for example, tree-shaking (it'd be a massive amount of wasted CSS to add classes for EVERYTHING). It's also yet another configuration to manage

I really like the minimal approach. I started my site as just a GitHub Pages repository with hand-written HTML and CSS. Eventually that became too painful due to the layout repetition and verbosity of HTML. I wanted a lightweight HTML templating language. Pug was great back then but it is now unmaintained. So I forked it into a new project and customized it for my needs.

My experience with Tailwind was with Fresh which did NOT allow you to use regular CSS. I found that Tailwind was far from enough to accomplish everything you need and often made it particularly hard to build an accessible web app of any complexity. In addition, anyone looking to mess around with psuedo classes or even just have a more unique style will likely find Tailwind to get in the way more than it helps. At least when it's the only tool you're allowed to use. I understand being forced to ONLY use Tailwind is not how most people have had to experience the tool but my personal experience has made me extremely weary of it

I also just don't really understand. It adds a complicated build step. I already previously heavily used "utility classes" in my own vanilla CSS projects and so can anyone else without adding a complex build step. This also inherently provides something like tree-shaking. You don't have any css code you're not using since you only define the classes you want. You also get to know all the CSS variable names.

For small projects, Tailwind feels like an overengineered solution to a non-problem (though I respect that it has helped a ton of people bad at CSS make decent looking websites). For large projects, it quickly becomes more of a crutch than a help. For frameworks like React, styled-components already solves issues TW supposedly helps alleviate in a much more elegant way.

It seems like the niches TW is helpful for is medium-sized projects and for people who are just... not that good at CSS and not interested in improving

Why does it help people who are not good at css though? That part I've never understood

For example if you type "center" into the search engine on their docs you'll get a modern reasonable way to center things (flexbox or grid). Whereas if you Google for css centering you'll run into all sorts of different ideas.

> body, h1, h2, h3, h4, p, figure, blockquote, dl, dd { margin: 0; }

Why?

I mean, I kinda get this on `body`. But I've never understood why people do this on block level elements like paragraphs and headers where default behavior should definitely be margins.

Closest I've ever come to a rationale is so that you'll see the unset margins and intentionally specify them into whatever design systems you're using. But even that doesn't really make sense: if you've got an off-the-shelf design system, it will do that job, you don't need your reset to do it. If you've got the time/inclination to DIY, you are almost certainly the kind of person who will pay attention to this. And if you're neither of those, your reset should do something sane by default.

Resets should be about standardizing sane cross-browser defaults for quasi-naked HTML. This kind of behavior goes beyond that into nuking sane behavior for naked HTML. Why?

To play the devil's advocate: so that you notice that something is amiss and you fix it. The problem with margins on these elements (at least, this used to be true - not sure if this is fixed nowadays) is that every browser implements its own defaults. Some of them might be suitable, but that will only mean that if the designer doesn't set them, these settings will be off in other browsers. So someone who cares might just as well set everything to 0 and then set as needed. Also, less likely that some margin will be set where 0 is appropriate.

On the other hand not much is lost with this. If css is ignored, cool. If not, other settings will fix layout as needed.

There are two schools of thought for CSS resets. 1. Minimize differences between browsers, keep some things like default padding, and styling where it makes sense 2. Nuke everything, standarize box-sizing, etc.. And I lied, there are also some that are more in between, but that's the jist.

The main argument for #1 is that it's closer to vanilla and lighter weight.

The main argument for #2 is that of you're making a comprehensive style, it's nicer to not have to worry about how for input elements have wierd legacy behavior, or to have to have a list of non standard box-sizing elements and a bunch of other weird legacy style anachronisms open all the time.

I personally, and I've seen this happen to others started out in camp #1 and eventually transitioned to camp #2 after I realized just how weird some stuff is. It definitely didn't mame sense to me until I had a lot of CSS experience.

Yup. In my experience, the main argument for #2 is that it's just too hard to remember/bother with what some default margin or padding is in the first place.

If it's nonzero, it's always going to be something extremely arbitrary, and will almost never be the value that matches your design anyways.

Best to just nuke it all and make every positioning decision consciously. And when you forget to set something, it'll be quite obvious where it needs to be fixed.

I guess I'm definitely a #1 person, because I don't understand how #2 relates. By all means, standardize all the things to remove variation -- that resonates pretty strongly with me. But I don't get how "standardize" shifts to "zero-out."

When you standardize on any other number you have to remember it and account for it.

For instance if you settle for 2em margins, all you other margin calculations need to remember that 2em value, and you also need to teach all your new coworkers the 2em value. That's dramatically less needed if it's 0.

Remembering / managing multiple margin values is a conversation that I can definitely relate to having about a design system or custom CSS.

For a reset/normalization sheet focused on sane standardized defaults? Seems like we'd be talking about two numbers: whatever vertical margin you want for your block level elements that you'd expect to have margins (most likely 1em) and 0.

Where are the other numbers coming from in the context of a reset?

There's other stuff besides numbers, like box-sizing and display that you uave to remember if you don't reset them.

> I've never understood why people do this on block level elements like paragraphs and headers where default behavior should definitely be margins.

IMO it’s more correct semantically. An <h1> means the top level of page heading, it doesn’t mean “1em of margin at the top and bottom”. A CSS reset that also resets all margins etc lets you derive your own formatting rules from semantic HTML. In most cases this is all a nitpick but I do get the rationale.

It's to avoid vertical margin collapsing. The rules for margin collapsing are complex, counter-intuitive, and often considered misconceived. (https://wiki.csswg.org/ideas/mistakes)

It's typically easier to work out a layout if you use padding in preference so you don't have to worry about them, but first you have to reset the margins the browser gives you.

I'd agree vertical margin collapse rules have some counterintuitive cases. And I've definitely seen (and used) something like:

h1, h2, h3, h4, h5, h6 { margin: 0 0 1em 0; }

which fits with the expectation that headers don't need to kick off with a vertical margin along with overflow containment rules to manage that behavior.

I don't know if I've seen using padding values to do margin's job lead to less pain.

Nice to see the real CSS tricks back.

What is the difference between a reset.css and a normalize.css? They both seem like they are doing the same or similar things. Is it a naming preference? Is one better than the other? Do some people use both?

Different browsers provide different default styles. Reset removes these styles while normalize tries to make the default styles consistent between the browsers.

I wonder how much the style difference among browsers is today. Maybe, we only need a one liner to align all browsers but nobody bothered to check again.

There are a ton of significant differences between browsers, especially when it comes to input elements, and around focus.

There are even OS differences between the same browser!

This site shows some of the default styles for different elements:

https://browserdefaultstyles.com

Awesome source, thank you!

Reset removes all default styles, so paragraphs become without margins, lists without bullets, tables without borders etc. Normalize tries to fix default styles so that they look the same in every browser.

Reset wants to remove browser defaults.

Normalize wants to make browsers have the same defaults. Usually with a particular focus on accessibility and more "invisible" behaviors.

For me the article link returns a JSON response. Tested in two browsers. Other articles on that site work normally.

Everything is opinionated, including resets.

Give me that warm 2014 feelings again

Once upon a time an interviewer in a job application that I participated was expressed his disappointment when he see that I didn't use css reset in the challenge they sent to me. I'm glad he is disappointed. I feel irritated when the people in tech so picky about the things that has an answer "hmm, yes, probably we should use", "lets not use, not worth it in this case". There was 2 html tags and an svg graph something like that in the page. I suspect he wasn't a tech person either, he was probably reading a google docs about how to interview fe person.

I personally don't use reset css and my web pages look ok. There are so many web pages that doesn't use reset css, they look ok.

I also don't like when people are being picky about things for fun. This is a job that people take seriously.

Pity there’s no discussion of grid/flex by default, especially for someone that dislikes margins.

Put grid/flex on most block elements. Spacing between boxes and their children is always handled with padding, spacing between siblings is always handled with gap. Everything else becomes way easier.

Sometimes I want more control than gap can provide, especially in grid. Suppose I want different gaps between different columns in a CSS grid - how would I accomplish that?

What’s stopping you from defining the gaps as individual entries in your template?

First column ‘fr’ gap ‘15px’ second column ‘fr’ gap ‘30px’ third column ‘fr’ and now you have three equal columns with two different gaps?

The downside with this approach is that I often want the element itself to define how much space is around it. When you conditionally include elements in a layout, I find margin more expressive and less cumbersome than changing the grid-template-column property of the parent.

> Suppose I want different gaps between different columns in a CSS grid - how would I accomplish that?

Good question. That sounds like you have different groups.

eg: you're thinking of it as:

   .items
   .item1 
      (thin gap)
   .item2
      (thick gap) 
   .item3

But it's actually:

   .items
      .sale (thin gap)
         .item1 
         .item2
      .regular (thick gap) 
         .item3

Yea but you need css sub grid to make that work if you want everything to line up. Unfortunately that’s not quite here yet

Sorry about the wait. This works with just grid.

I've been exploring this idea in my more recent code and so far no regrets. I'd go so far as to say that grid is often the better flexbox because (1) the DSL that allows arbitrary names is so nice for specifying alternative responsive designs and (2) it lowers the temptation to create unnecessary divs for the sole purpose of layout.

I found these four reset options best for my use cases:

https://pilabor.com/blog/2021/03/html-and-css-tricks/#normal...

Warning that Chrome has an old bug that kills performance on things like * selectors:

https://github.com/elad2412/the-new-css-reset/issues/66

It's not the * selector that's the problem in that case though - it's the `all:unset` declaration

Mozilla should use that extensively on MDN to give Google some of its own medicine. Unless of course performance problems of Google's sites on Firefox are just a coincidence...

Somewhat off topic, but it annoys me that CSS resets kill the margins on p, h1, h2, and ul. As well as the list-style.

I basically don’t use those elements for UI components, and in the rare cases where I would want to, I could just do a one-off to override them. Or, more likely I’d just do something like <div role="heading" aria-level="1">

I find in applications you eventually need some little places where you have some basic document styles: paragraphs, headings, bullets, and it’s nice to be able to use those basic semantic tags for that stuff.

Because collapsing margins are annoying. Doing this removes that. All you have to do is just use margin-top or margin-bottom on them.

Since the article is about being picky, here's something that stood out:

> -moz-text-size-adjust: none;

> This makes it so iPhones...

Why is a -moz- prefix needed for a Safari workaround?

The linked Kilian article [0] explains that it’s for Firefox on Android devices.

[0]: https://kilianvalkhof.com/2022/css-html/your-css-reset-needs...

Note that page says that "The New CSS Reset" has this issue, but it doesn't, it was added recently, for better or worse. I did touch base with Kilian about it, but he hasn't updated the article. He might have a newer article, I don't know.

the prefixes don't really mean much nowadays. Most browsers will support all other browser prefixes. There are simply CSS problems that haven't been solved by the CSS standard itself. Sometimes different browsers come up with their own solution that is not in the standard (though this rarely happens anymore). In order to prevent "this website looks weird on <SOME_BROWSER>", SOME_BROWSER needs to implement support for it. There are very few prefixed CSS properties that aren't supported by all browsers nowadays. Think of them as stopgap solutions until the actual CSS standard catches up

I didn't realize ShopTalk Show was still going on. I was an avid listener waaay back in the day.

I've been using a postcss module that implements the reset property. It's pretty nice.

CSS resets are bad idea and shouldn't exist. Every time you see paragraphs without margins, or lists without bullets, it is probably a fault of CSS reset.

No you see giving users any agency over how your website is displayed is a bug and needs to be fixed. User agents be damned.

...and by all means, ignore how it looks printed.

CSS resets wouldn't be necessary if browser default styles weren't awful, but here we are. The default browser styling is the worst of all worlds: not enough to make an unstyled page look good (partly the result of the terrible text size inflation trend, which is a whole other rant), but enough to get in the way for a page that's been deliberately styled.

CSS reset is worse than any default browser style: in browser paragraphs are separated and lists have bullets. With CSS reset, there are no styles at all, and the page looks like unformatted text.

I don't think anyone ever uses a CSS reset on its own, the point is to reset and then put your own style on.

Browser default styles aren't really good enough to be usable IMO; yes they have paragraphs but with zero margin and tiny text they're not exactly readable. Twitter Bootstrap is pretty much a bug report against the browser default style. Given that current browser default styles are half-assed at best, I'm sympathetic to the idea that not having a default browser style at all would be better.

You use a css reset and then apply your own styles…

The whole point is to make everything look the same across every browser in existence. Also to remove collapsing margins.

Collapsing margins are actually a good thing. If I designed CSS from scratch, I would make all margins collapsing, because you typically want 1em margin between paragraphs, not 1 + 1 em.

Reply on news.ycombinator.com