45 Replies
Most elements already inherit a lot of these already which is where the 'cascade' comes in.
While there is limited chances for any of these rules to cause issues, the fact that you are specifying them allows those situations to happen. The specificity won't be a problem but it is more likely that you will need to over specify things in heavily nested elements as they may not return back to the expected color or font size etc
I tend to stay away from writing css unless it's needed.
I do it because of this:
Yes, that’s a bad approach. All the things you have listed as inherit are already inherited. And nuking padding/margin on all elements is bad practice. Removing text decoration is really bad since many is the defaults are what people expect on the web. Links are underlined, people know and expect this. Why are you changing that?
The only thing you have there that is best practice is the box sizing.
Heck, check out Kevin’s most-recent video:
https://www.youtube.com/watch?v=gxbBg6dyvhM
Kevin Powell
YouTube
Please NEVER do this in your CSS
🎓 I have a FREE course on creating responsive layouts: https://courses.kevinpowell.co/conquering-responsive-layouts
For whatever reason, I’ve been seeing a lot of people running into issues because they’re declaring way too many things on their universal selector these days, so in this video I take a quick look at the type of issues that it can...
he is talking about bad practice to set specific color and background-color
I am setting inherit; because by default links and buttons are set with specific color, background-color, font-sizes and font-family
I don't want to go thru all tags and specify - that I want inherited background color, color and font
My point is that people expect links to look a certain way. If you change that odds are good that they won’t know it’s a link. Which means it may as well not be since no one will know it is and it’ll never be used as such
I can specify link how I want
If you want links to look a certain way then it’s best practice to style the link tag and not style literally ever tag just to make the link look a certain way
Same goes for buttons. Or any element. If you want an element to look a certain way you should style that element, not all elements
I want to style tags the way I need. I don't want that browsers put their defaults
correct - I style them all
I just set kinda default state for them
Which, again, is not good practice
where it is written?
do you know any resource to check?
Best practices are usually passed down and not written in any one place. But look at it like this:
- The browser sets defaults
- You override the defaults on all elements (just to style one or two)
- You now need to re-reset the overridden styles on all elements that need the defaults
That's three times the browser sets/unsets/resets the DOM. That's a lot of work. And it's done on all elements. Or you could target the specific elements you want styled and style them specifically and the browser only needs to change the way those elements look. That's a lot less cycles for the browser
- You override the defaults on all elements (just to style one or two)
no - I override defaults to say use inheritance and don't set margins and paddings
The browser sets margin and padding to all elements, so you're now un-setting them
Then you need to go back in and re-set that padding to prevent elements from touching
Or you could not nuke margin/padding and only change the spacing you specifically want to change
Less work for you, less work for the browser. Win/win
The only margin that really needs removing is the one that's set on the
body element due to legacy reasons (there's 8px of margin by default)how many tags have paddings or margins? body, p, ul, ol ?
headers, too
so I need to go thru all of them
and I need to know all of them
to change defaults
instead of that I say for all of them (right now 5) set padding and margin 0
But why are you doing that? Why do you feel like you need to remove it?
What's the goal?
Paragraphs, headings, etc need vertical spacing. Why are you removing it?
with colors - I have that problem in example
At a quick search:
default padding: fieldset, legend, ol, ul
default margin: blockquote, body, dd, dl, fieldset, figure, form, h1-6. hr, menu, ol, p, pre, ul
paddings and margin - I cant remember real reason but there was something long time ago when developers used bootstrap
Using bad practices for a long time doesn't make it a good practice 😉
pretty sure font-family is already inherited, the colors are probably better left to default as well.
Setting just the border color is kinda pointless, you can easily set that whenever you turn on a border.
transparent is a better default for background-color than inherit for the exact reason demonstrated in Kevin's video.
color inherits already I think?
same with font-sizebut for me it is whitelisting things... like everything has no format and only things I use in application has styles
and that's a bad practice
let the browser handle the default styles, you're only creating more work for yourself having to set everything back up
But again: why???
check that example - if you remove that inherit, you get that link is in specific color and also button has background and color (it is not inherited by default) also fonts are not used from body
Why do you feel the need to set everything to 0? That means you need to re-set it all. Which is the problem I outlined above. The browser sets sane defaults. You remove them all. Then you add them back in a piece at a time. That's three steps to achieve what's being given right away for one step
Buttons are an exception, they have relatively strict default styles, but you shouldn't reset absolutely everything just to fix the buttons
just reset
button {} if you don't want to add a classso every time you create class which can be used on links and buttons you have to specify colors and fonts - that will be best practice?
background-color is a nightmare if it's inherited. In the video Beck linked above, I declared an actual color, but this would have the same effect, and just be so much more work in the long run.
The only reason you'd want to declare the font properties is for buttons and whatnot, so for me, this makes a lot more sense:
If you want to throw color in there too, you could I guess.
a should never inherit the color, since links should stand out. They should also have a text-decoration, so both of those would be no-nos from an accessibility standpoint.
As for margin and padding, I get what Beck is saying, but it's also not a hill I'd die on, personally. If you want to nuke those then build them back in, go for it 🤷. I'd say this is pretty project dependent though.
Also, please don't set the font-size on the html in pixels. If you really want to work off a base-10, then use font-size: 62.5% instead. Users who've changed their browser preferences will thank you.what about font properties for links?
I am going thru tags right now, but this is interesting that by default border color is text color. only when you set
border-color: inherit it will inherit color for most of the tags
I think button/input/textarea/select are the only ones that don't use
currentColor for the border-color by default?mark and link also sets another border color
and all elements by default inherits text color as border color
I would argue that it is the reason you add style for all elements so that by default everything looks the same - and when new tags will be introduced they will not standout like <mark> for example.
like right now these tags have different fonts
if there will be added new tag, and they will decide to set different font - I will have to go thru all applications and add that tag to this list. but if I added this to * than I will never have to do that...
I would argue that
code and pre should have a different font. We don't want things like that looking like regular text... same with links, they shouldn't look the same.
If you're going to change them anyway (like, say, the color of the link to an accent color or whatever, or the pre and code to a different mono-spaced font), you might as well leave the default and just set those to the new thing you're going to be using.
The input, select, button, I'll grant you, is annoying, but we're stuck with it at this point.
If you go back in time, we used to have Eric Myers CSS reset ( https://meyerweb.com/eric/tools/css/reset/reset200802.css ) which was more or less a nuclear option.
There were a few reasons that we used it though:
- It removed most of the defaults people overwrite anyway
- Back in 2008, there were a lot of inconsistencies between the browsers user agent styles (default styles). This helped start things all on the same foot. More like starting with a blank canvas.
Over time, people moved away from that though, as we realized that trying to "reset" the user agent styles wasn't really as helpful as we thought. Normalize.css became very popular (https://necolas.github.io/normalize.css/8.0.1/normalize.css).
Instead of "resetting" things to 0, it's purpose was simply to remove the inconsistencies between the browsers user agent styles.
Over the last few years, luckily, browsers have improved their user agent styles, and for the most part, they all follow the spec now, and they are mostly consistent from one browser to the next (for the default styles).
That's why most new CSS "resets" are actually pretty gentle, and really they are more opinionated starting points rather than anything else. I personally use a slightly modified version of Andy Bell's (https://andy-bell.co.uk/a-modern-css-reset/) - adding svg and video to the img, picture is useful 😄 - and if you look at it, it's not doing very much.
Another one is Josh Comeau's, which is pretty similar with a few little differences: https://www.joshwcomeau.com/css/custom-css-reset/
And there are others out there too, that do the same thing.
At the end of the day, the approach you take is your choice, and if you'd rather go the nuclear approach, you're free to do that!
I think the gentle approach that we're seeing now is more common though, because we've realized that we're doing more work (and making the browser do more work) when we reset things, only to re-style them again later.
But I do think having an opinionated starting point makes sense (unless you're trying to make something like Normalize, for everyone to use), because we all have different ways that we like to work.If we're talking about CSS "resets" you can't not mention Jen Simmon's and her CSS Remedy!
CSS Remedy sets CSS properties or values to what they would be if the CSSWG were creating the CSS today, from scratch, and didn't have to worry about backwards compatibility.–https://github.com/jensimmons/cssremedy#guiding-ideas It's the "Hindsight" approach. If we only knew then what we know now :p The CSS file has a plethora of comments to let you know exactly why something was done the way it was done: https://github.com/jensimmons/cssremedy/blob/master/css/remedy.css
Links at the bottom of that one are great for more history too! Should have included that one for sure
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
"It has a high probability of causing problems in the future"
no - there is no problems and crazy things happening when you say use inheritance for font and colors. so argument that is braking something is false. better argument was, why you set something that is kinda happening by default
@cvanilla13eck @Kevin
this one is interesting (from
remedy.css) - nested h1. Shouldn't there be only one h1 per page?
There should be, yes. But it used to be that you could have one h1 per section, IIRC
One h1 per page is an accessibility thing to keep the heading tree single instead of branching
The official HTML spec says you should be able to have more than one h1 per page. They added a document outline, where the browser would be able to figure things out and create a smarter flow, so if you used an
h1 inside an article or section, it would know that's the title for the article/section, and create a proper outline taking that into account.
Then all the browsers were like "that sounds nice, but nope", and no one ever implemented it, so while it's still in the spec, there's a note saying don't do it or something 😅Imho it’s not just accessibility, but kinda weird from a semantic/content strategy perspective, and a hack that probably stems from wanting to style titles a certain way?
If I create an information arcitecture for ie. articles or product pages, I would never have multiple ‘main headings’.