I don’t know about you, but I write these three declarations many times in my CSS:
ul {
padding: 0;
margin: 0;
list-style-type: none;
}You might yell at me and say I can just put those in my CSS resets. I wish I could, but I don‘t want to and I’ll tell you why in a second.
User agents set values to those properties in a list for a purpose, and that is to make lists more readable. These are the default styles in chromium browsers for a <ul> element:
ul {
list-style-type: disc;
margin-block-start: 1em;
margin-block-end: 1em;
margin-inline-start: 0px;
margin-inline-end: 0px;
padding-inline-start: 40px;
}So, without adding any class in HTML or style in CSS, we get those for free. That‘s a nice thing and I don‘t want to lose it. But I would appreciate it if I could make the browser understand that there is very high chance I don’t want that default feature in cases where I add a class to the element.
So here is a quick solution to reset a <ul> element that has a class:
ul[class] {
padding: 0;
margin: 0;
list-style-type: none;
}Now I don’t lose the default style except when I add a class to my <ul> element.
The problem
There is a problem with this solution. Imagine there is a list that we want to have a different list-style-type for it, like the following:
ul[class] {
padding: 0;
margin: 0;
list-style-type: none;
}
.list {
list-style-type: square;
}This doesn’t work since ul[class] has higher specificity. That’s where our solution breaks down.
We could add more weight to the selector’s specificity:
ul.list {
list-style-type: square; /* Specificity: 0, 1, 1 */
}
/* or */
.sidebar .list {
list-style-type: square; /* Specificity: 0, 2, 0 */
}If you are OK adding more weight to the selector, you are good to go. But I’m not OK with it, personally. For example, I don’t want to put the element’s name in my CSS most of the times due to a separation of concerns principle. Or, if you are following BEM methodology, problems will most certainly arise as this conflicts with it.
So what can we do?
The solution
A few months ago, I learned about some hot selectors, including :is() and :where(). One thing about these two functional pseudo selectors, is that they can change specificity, giving us the power to nullify or increase that specificity.
The key about :where() is that it always has 0 specificity. So we can get rid of our problem very easily like this:
:where(ul[class]) {
list-style: none;
}
.list {
list-style: square; /* Now this works like a charm! */
}With the power of this selector, libraries can give us style with no specificity. So there would be no specificity to compete with when we as authors write CSS.
Demo
In the following demo, you can remove :where() to see what we talked about in action:
The post Using the Specificity of :where() as a CSS Reset appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.
As a website grows, more content creators are required. With this, there are more iterations of editing in content pieces. This leads to increased complications in collaborative or synchronized working. Now, while there still are efficient tools like Google Docs and grammar checkers for this, publishing the content on websites remains super-taxing. In the coming […]
