This has not been the best practice for like a decade.
*::before,
*::after {
box-sizing: inherit;
}
:root { /* or html or body */
box-sizing: border-box;
}
is what you want for things to inherit as expected else you need to override each instance.
¿Removing link color by default unless there is a class? So much for accessibility & default styles. Those with poor vision generally appreciate the colors and you have the default color: LinkText. Use that unless you have a serious design reason to mess with the defaults (meaning it shouldn’t be a default).
I understand the difference between reset vs. normalize, but setting everything to zero & then overriding seems wasteful versus nudging browsers in who are straying from the other back to a default one would expect if no CSS were added by the user. Generally I suggest vendoring https://csstools.github.io/sanitize.css if you want a modern normalize …tho its maintenance seems to lead toward abandoned with old, open merge requests.
Design of the site tho: ::highlight background color being the same as the code blocks means you can’t see what you are selecting. Uses JavaScript for syntax highlighting of static content when you shouldn’t. With blue generally signifying links in body copy, it’s weird being used as inline code element coloring (I would argue most body copy shouldn’t be monospace so it’s clearer to stylistically tell the difference, but devs seem to like it as a stylistic choice for one reason or another). I don’t generally know why the base paragraph size is using clamp() & scales up with the screen size–a bigger viewport does not mean you should try to fill up more of that space & unless you have a good reason, it should almost always be the default 1rem set by the user agent to respect the user’s settings. I can understand some headings getting some different treatment, but don’t mess with the body size as users who need bigger type on a bigger screen probably already adjusted it with an OS or user agent setting.
¿Removing link color by default unless there is a class? So much for accessibility & default styles. Those with poor vision generally appreciate the colors and you have the default color: LinkText. Use that unless you have a serious design reason to mess with the defaults (meaning it shouldn’t be a default).
I disagree pretty strongly with this. Yes, all links should get some color or something to show what they are, but unless you’re talking about a content well (which is its own thing and has its own rules for how to style it), you should be setting that color on a per-component basis. Otherwise you have to jump through crazy hoops when you have some card which can be wrapped in a link and now all the text inside the card is blue and underlined and you’re adding !important to try to reset it to normal.
If there’s some section of the page where arbitrary rich text is going to be dropped, then you need to mark that as a content well to ensure all the links inside are styled, but you also have to do a lot of other things, like make sure bullet lists will work and whatnot. I think a lot of the disagreements about CSS are from people who only ever style content wells and then they wonder why the rest of us are always banging on about BEM and atomic CSS and whatnot. Content wells are special and the normal rules don’t apply.
The “does this link have a class tag on it?” rule strikes me as a good compromise: if you’re not styling the link yourself, you get the default style, but once you touch the link, you own it and are responsible for styling it correctly.
To be clear, I’m not suggesting a { color: LinkText } but rather don’t touch the default color in many cases unless you have a specific design to be follow. I was pointing out that there is a <system-color> value that’s meant to be used for links & link-like things such as button.link { color: LinkText }. In body copy, a lot of folks should be respecting the user agent for a11y or user customization concerns.
I can see your (and probably the author’s) use case tho now so thanks for explaining–I was locked in thinking about designing blogs. In the context of a blog/text-heavy design then I could see something like .Content a { color: revert } or unset to go back to the defaults in the actual post content but let other supporting UI elements do the inherit color.
Well that’s egg on my face, I had an issue with it a while ago and removing it from my code made the site look fine - the issue must’ve been a Layer 8 configuration issue. Thanks for clearing that up.
What’s the purpose of this? The author only says that it “is pretty handy too, especially if you’re gonna be setting decorative elements,” which tells me nothing.
I wouldn’t want it in a reset because it’s an opinionated choice, but it’s useful for when you have short pages (potentially not a whole screenful) and you want the footer to be at the bottom of the screen without any blank space under it. The alternative is the footer is in the middle of the screen and followed by blank space, which can be ugly.
Most sites however can fill a screen between just the header and the footer so it’s not always necessary. Also, and this is niche but it comes up a lot in the news industry, if you try to make a seamless iframe, it screws up the page height detection.
To get a footer stick to the bottom of the body, you need a lot more CSS.
To me this rule alone is just asking for trouble with unwanted scrollbars (there’s a half dozen different definitions of viewport height depending on toolbars, keyboard, dead areas, etc.)
To be clear, it’s not for sticky footers, just growing the content area until the footer is at the viewport bottom. But I agree, it’s mostly unnecessary and it can be wrong if you need dvh or whatever instead.
This has not been the best practice for like a decade.
is what you want for things to inherit as expected else you need to override each instance.
¿Removing link color by default unless there is a class? So much for accessibility & default styles. Those with poor vision generally appreciate the colors and you have the default
color: LinkText. Use that unless you have a serious design reason to mess with the defaults (meaning it shouldn’t be a default).I understand the difference between reset vs. normalize, but setting everything to zero & then overriding seems wasteful versus nudging browsers in who are straying from the other back to a default one would expect if no CSS were added by the user. Generally I suggest vendoring https://csstools.github.io/sanitize.css if you want a modern normalize …tho its maintenance seems to lead toward abandoned with old, open merge requests.
Design of the site tho:
::highlightbackground color being the same as the code blocks means you can’t see what you are selecting. Uses JavaScript for syntax highlighting of static content when you shouldn’t. With blue generally signifying links in body copy, it’s weird being used as inline code element coloring (I would argue most body copy shouldn’t bemonospaceso it’s clearer to stylistically tell the difference, but devs seem to like it as a stylistic choice for one reason or another). I don’t generally know why the base paragraph size is usingclamp()& scales up with the screen size–a bigger viewport does not mean you should try to fill up more of that space & unless you have a good reason, it should almost always be the default 1rem set by the user agent to respect the user’s settings. I can understand some headings getting some different treatment, but don’t mess with the body size as users who need bigger type on a bigger screen probably already adjusted it with an OS or user agent setting.I disagree pretty strongly with this. Yes, all links should get some color or something to show what they are, but unless you’re talking about a content well (which is its own thing and has its own rules for how to style it), you should be setting that color on a per-component basis. Otherwise you have to jump through crazy hoops when you have some card which can be wrapped in a link and now all the text inside the card is blue and underlined and you’re adding !important to try to reset it to normal.
If there’s some section of the page where arbitrary rich text is going to be dropped, then you need to mark that as a content well to ensure all the links inside are styled, but you also have to do a lot of other things, like make sure bullet lists will work and whatnot. I think a lot of the disagreements about CSS are from people who only ever style content wells and then they wonder why the rest of us are always banging on about BEM and atomic CSS and whatnot. Content wells are special and the normal rules don’t apply.
The “does this link have a class tag on it?” rule strikes me as a good compromise: if you’re not styling the link yourself, you get the default style, but once you touch the link, you own it and are responsible for styling it correctly.
To be clear, I’m not suggesting
a { color: LinkText }but rather don’t touch the default color in many cases unless you have a specific design to be follow. I was pointing out that there is a<system-color>value that’s meant to be used for links & link-like things such asbutton.link { color: LinkText }. In body copy, a lot of folks should be respecting the user agent for a11y or user customization concerns.I can see your (and probably the author’s) use case tho now so thanks for explaining–I was locked in thinking about designing blogs. In the context of a blog/text-heavy design then I could see something like
.Content a { color: revert }orunsetto go back to the defaults in the actual post content but let other supporting UI elements do the inherit color.I like the idea, but without @media (prefers-color-scheme: dark) it is not modern enough for me.
I don’t prefers-color-scheme: dark, though. Neither do your eyes, which prefers-color-scheme: ambient-lighting.
The media query is asking if the user prefers a dark scheme, it isn’t making an assertion.
Well that’s egg on my face, I had an issue with it a while ago and removing it from my code made the site look fine - the issue must’ve been a Layer 8 configuration issue. Thanks for clearing that up.
Oh, now this is something I’ve been wanting without even knowing it…
What’s the purpose of this? The author only says that it “is pretty handy too, especially if you’re gonna be setting decorative elements,” which tells me nothing.
I wouldn’t want it in a reset because it’s an opinionated choice, but it’s useful for when you have short pages (potentially not a whole screenful) and you want the footer to be at the bottom of the screen without any blank space under it. The alternative is the footer is in the middle of the screen and followed by blank space, which can be ugly.
Most sites however can fill a screen between just the header and the footer so it’s not always necessary. Also, and this is niche but it comes up a lot in the news industry, if you try to make a seamless iframe, it screws up the page height detection.
To get a footer stick to the bottom of the body, you need a lot more CSS.
To me this rule alone is just asking for trouble with unwanted scrollbars (there’s a half dozen different definitions of viewport height depending on toolbars, keyboard, dead areas, etc.)
To be clear, it’s not for sticky footers, just growing the content area until the footer is at the viewport bottom. But I agree, it’s mostly unnecessary and it can be wrong if you need dvh or whatever instead.
Not a big fan of CSS resets anymore, just overwrite what you have to overwrite.