Just days before [1]Andy revamped his (more) Modern CSS Reset, [2]Dave
  and I were line-by-lining it on ShopTalk Show. Mouthblogging is fun and
  all, but so is Writemouthblogging, known colloquially as “blogging”.

  Allow me to do it again with my fingers on this new version.

  Obviously this is all subjective and you can and should do whatever you
  want with your life.
    __________________________________________________________________

*,
*::before,
*::after {
 box-sizing: border-box;
}Code language: CSS (css)

  You gotta do it. This is one of the things that makes me wish we could
  do a CSS version of "use strict"; at the top to opt into a version of
  CSS with all the [3]mistakes fixed. The psuedos make that selector so
  ugly, don’t they? Ughghk. Since setting width and height is getting
  rarer in a world of flexbox and grid anyway (which is what box-sizing
  “fixes”), and the pseudo usage rarer still, it makes me want to start
  omitting this entirely, but every time I try it, I regret it, and put
  it back.

  This was a popular alternative for a minute, I think credit to Jon Neal
  for thinking it through:
html {
 box-sizing: border-box;
}
*, *:before, *:after {
 box-sizing: inherit;
}Code language: CSS (css)

  The idea is that on any given element you could set a different
  box-sizing value and it would change it not only for that DOM node but
  all its descendants, which is maybe what you want. But it didn’t seem
  to catch on, probably because it’s so niche. I also don’t like looking
  at the slightly incorrect single colons, even though they will work
  fine forever.
    __________________________________________________________________

html {
 -moz-text-size-adjust: none;
 -webkit-text-size-adjust: none;
 text-size-adjust: none;
}Code language: CSS (css)

  This makes it so iPhones don’t dork up the font size in landscape mode,
  [4]as Kilian documented. Dumb. Apple should ditch that behavior. But
  for now, fine.
    __________________________________________________________________

body, h1, h2, h3, h4, p,
figure, blockquote, dl, dd {
 margin: 0;
}Code language: CSS (css)

  I like the idea of nuking margins. Definitely on the body. That one is
  extra annoying. 8px lol go to bed. Why? [5]why. But I get it. We can’t
  have text touching the edge of the browser window that would be worse.
  I think 1rem would be a heck of a lot nicer, if not some exotic max()
  calculation with viewport units so large screens get more than small
  screens. But you can’t just change things on the web, lest it decent
  into chaos (cats/dogs/living together/etc).

  I’d probably be a little more comprehensive here though. The list
  sisters ol and ul for sure, and pre, just to pick one more. And clearly
  Andy hates h5 and h6 👀. personally.
    __________________________________________________________________

ul[role='list'],
ol[role='list'] {
 list-style: none;
}Code language: CSS (css)

  This was a head-scratcher to me, but Andy explains it’s to make sure
  Safari doesn’t wipe out the correct accessible role:

    … to make sure that a role is added, I remove the list styling by
    default for it as a little reward.

  lol that is so weird that now I like it again. It reminds me of those
  selectors [6]like Adrian likes where you are only awarded the correct
  styles if you use all the correct attributes…
  … like this beauty.
[role="region"][aria-labelledby][tabindex] {
 overflow: auto;
}

[role="region"][aria-labelledby][tabindex]:focus {
 outline: .1em solid rgba(0,0,0,.1);
}Code language: CSS (css)

  A more sober me might do something like this instead:
ul[class],
ol[class] {
 margin: 0;
 padding: 0;
 list-style: none;
}Code language: CSS (css)

  … where I’m like: hey if you’re adding a class to this list, you’re
  probably doing something fancy to it, so boot it back to normal town
  first.

  Maybe we need “JavaScript resets”? Like if we’re worried about roles
  getting wiped out, let’s force the issue.
document
 .querySelectorAll("ul, ol")
 .forEach(list => list.setAttribute("role", "list"));Code language: PHP (php)

  I can forsee no problems with that — ship it.
    __________________________________________________________________

body {
 min-height: 100vh;
 line-height: 1.5;
}Code language: CSS (css)

  First of all I’d smash that line-height on the html element instead,
  mostly because I think that high-level “inherit me!!” typography stuff
  should happen there. The r in rem means “root” and only responds to
  changes in size there. Likewise there is new units like rlh that mean
  “root line height” and it makes sense to me to just use the root in
  case we want to use that value.

  Every part of me wants to use dvh instead of vh on that min-height
  because when browser chrome and crap comes up it makes sense to me that
  that size shrinks to the new area. But apparently it [7]can be a
  performance issue (??) so maybe not. Would like to see some testing
  there. Although I might just need to adjust my thinking and [8]embrace
  the svh.
    __________________________________________________________________

h1, h2, h3, h4,
button, input, label {
 line-height: 1.1;
}Code language: CSS (css)

  Heck yeah, if you’re going to go with that luxuriously tall line-height
  for the page, you gotta suck it back down for headers. Except h5 and h6
  who can apparently suck it. Makes sense on the inputs too, I’ve never
  seen that in a reset before and I like it.
    __________________________________________________________________

h1, h2,
h3, h4 {
 text-wrap: balance;
}Code language: CSS (css)

  Hell yeah. This makes me think we should also be putting text-wrap:
  pretty; on all the Small But Long Text elements like p, li,
  .intro-text, dd, and whatnot. But that makes me feel like that’s maybe
  over-reaching? Doesn’t it bail out on elements over 4 lines or
  something anyway?
    __________________________________________________________________

a:not([class]) {
 text-decoration-skip-ink: auto;
 color: currentColor;
}Code language: CSS (css)

  auto is already the default on text-decoration-skip-ink so I’m not sure
  how useful that is. I kinda like the currentColor idea, but it means
  you really need to keep the underlines then or have some other really
  obvious link style. “Links are supposed to be blue” and all that.
    __________________________________________________________________

input,
button,
textarea,
select {
 font: inherit;
}Code language: CSS (css)

  Love it. I like that that even works on select now, I could have sworn
  it didn’t. I wonder if we should add selectmenu now too? Isn’t that
  getting close? I bet it would even cascade down into the options then,
  maybe?
textarea:not([rows]) {
 min-height: 10em;
}Code language: CSS (css)

  Fair. A rare case I like the em instead of rem. My optimisitically
  chuck on form-sizing: normal; also.
    __________________________________________________________________

:target {
 scroll-margin-block: 5ex;
}Code language: CSS (css)

  Like it. Browsers butt targets too high. The ex unit is showing off a
  little lol. I vote for 1rlh.

References

  1. https://andy-bell.co.uk/a-more-modern-css-reset/
  2. https://shoptalkshow.com/582/#t=43:01
  3. https://wiki.csswg.org/ideas/mistakes
  4. https://kilianvalkhof.com/2022/css-html/your-css-reset-needs-text-size-adjust-probably/
  5. https://www.miriamsuzanne.com/2022/07/04/body-margin-8px/#:~:text=All browsers add an 8px,own 'user agent' styles.
  6. https://adrianroselli.com/2020/11/under-engineered-responsive-tables.html#CSS
  7. https://ishadeed.com/article/new-viewport-units/#:~:text=Be careful with the dvh,is scrolling up or down.
  8. https://mastodon.social/@simevidas/111088262361593466

You are viewing proxied material from 1436.ninja. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.