“The second case, :not(svg *) is done with a separate :not() only because it is for a different issue. Touching the inner elements of an SVG can break the visual image, and this is one of those things that there isn’t any reasonable cause to interrupt the browser.”

It is entirely unclear to me what that means. Further, in the actual GitHub file, that latter clause is given as:

:not(svg *, symbol *))

And the comment is the “symbol *” part is to solve a “Firefox SVG sprite bug.” But it’s hard to determine what the bug being referred to actually is. In looking things up, it looks like Firefox has had SVG sprite issues for awhile.

I feel like resets or even normalize type stuff should reference specific bug numbers or at least some reference that says exactly what’s being solved by the inclusion. I say this because I feel like a lot of stuff in various resets is taken on faith and then propagates for a long time.

I’m not saying that’s the case here. I just have no way to know. Case in point is I see a lot sources quoting this reset but none of them actually seem to know exactly why that particular bit is in there.

I understand the purpose of the hard reset for sure. But I just wonder how necessary that truly is with modern browsers and why the more opinionated approaches of Normalize or Sanitize aren’t better.

I feel like that’s one question that would be worth asking but wasn’t really asked here. I do see Elad’s description of how he prefers the hard and gentle approach. But what’s not clear is why the hard approach is really needed at all if you’re going to use the gentle approach anyway.

I think part of this is my natural inclination, not always well-founded, to avoid things that do “all” or “never” style blanket changes to everything.

Elad says: “The CSS resets we have are built on old CSS features. But in the last several years, we’ve gotten new features built specifically for resetting things in CSS…”

This would imply that clearly the CSS maintainers feel that the resets are necessary if we’re getting new features specifically to reset things. But then why are so many people conflicted on whether to use resets at all?

All this said, I do agree that if the goal is to do a hard reset of everything, this definitely seems like the most concise way to do it.

As a final point, if I was using Normalize or Sanitize with this approach, it’s very unclear to my why I would put those BEFORE the hard reset. It seems the hard reset would just then remove whatever Normalize/Sanitize puts in place that isn’t just Shadow DOM related.

The all:unset is already removing the padding and margin from all other elements.

margin:0
padding: 0

here

*,
*::before,
*::after {
box-sizing: border-box;
margin: 0;
padding: 0;
}
?

Oh, right, it wasn’t in the original version that I had copied (and is not in this article).

Here’s the replication of my original issue: https://codepen.io/hyvyys/pen/poWMgMj. The hyphenation is off in Chrome.

I wonder how you go about fixing these things! Since DevTools don’t list all the properties overridden by all (and don’t list all vendor-prefixed properties in the Computed tab), do you just go with an index of all properties and check them one by one, or just are a genius like that? :)

Hi Adam,
You kind of resetting my CSS reset, if you put all:revert; for every DIV.

If you add all:revert; without my CSS reset the contenteditable won’t work.

The contenteditable specific getting separate fix to bring it back, as you can see in the CSS reset:

/* revert for bug in Chromium browsers
– fix for the content editable attribute will work properly. */
:where([contenteditable]){
-moz-user-modify: read-write;
-webkit-user-modify: read-write;
overflow-wrap: break-word;
-webkit-line-break: after-white-space;
}

Hi Adam,
Please add CodePen with the specific problem. Then, it will be easier to see the problem and play with the code to understand if there is a problem. And if there is to find a way to solve it :-).

View post on imgur.com

all: unset;
all: revert;

is not the same as if there was nothing at all. I was making a font demo with features applied to <span>s sprinkled within text. The first rule messed up the hyphenation and positioning of some of these spans (see last line on the image). The second rule didn’t fix that, and I was unable to debug this as the issue was only present in Chrome, which no longer allows showing UA styles.

Ian, you might look at how Andy Bell approaches this. He targets lists that have the attribute role="list" explicitly set:

/* Remove list styles on ul, ol elements with a list role, which suggests default styling will be removed */
ul[role='list'],
ol[role='list'] {
list-style: none;
}

See https://piccalil.li/blog/a-modern-css-reset/

pre { white-space: revert; }

OR

pre { white-space: pre; }

(white-space: pre sauce: https://webmasters.stackexchange.com/a/16597)

The only situation where I used all was in transitions (and even there I only made rare use of it).

This article just changed my view on this property. I’m definitely gonna use this reset sheet along with Heydon Pickering’s Lobotomized Owl Selector in my next project :D

After a bit more testing, I found that font-size: 0 is needed as well otherwise markers would still take up spaces.

You can design checkbox for example:

And if you don’t want the reset on them, you can revert the input element back, for example:

 input,
 textarea,
 select {
    all: revert;
 }