I have a set of default styles I use with new projects and want to know whether there are any issues or imperfections with them. Can anyone see anything that could be detrimental or bad in any way?

Be as picky as you like.

* {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
html {
    font-size: 62.5% /* makes 1rem 10px */
body {
    font-size: 1.6em; /* default font of 16px */
    font-family: 'Verdana', 'Arial', sans-serif;
    line-height: 1.3;
    color: #373737;
/* fonts */
h1 { font-size: 3rem }
h2 { font-size: 2.4rem }
h3 { font-size: 2rem }
h4, li, label, input, textarea, select, p {
    font-size: 1.8rem;
h5 { font-size: 1.6rem }
h6 { font-size: 1.4rem }
ol, ul { padding-left: 2em }
a {
    text-decoration: underline;
    color: blue;
a:hover { color: pink }
a:focus { color: orange }
a:active { color: red }
a:visited { color: purple }

Additionally I may also add the following:

button, textarea, input, select, label { all: unset }

I'd be curious to know your thoughts or any feedback.

  • 1
    \$\begingroup\$ Maybe I'm wrong, but CSS is design and design is inherently subjective, or at least not something that most programmers are likely to be able to give reliable feedback on. If you deal with web projects relatively regularly and value your time over your sanity I'd suggest you do what I and most web designers do and take advantage of something like Bootstrap, or Tailwind/Bulma/Pure if you want it more lightweight, because I can almost guarantee you 20 lines or a few hundred lines are not going to be enough to make an average-sized site look good. \$\endgroup\$ Feb 4, 2022 at 4:32
  • 2
    \$\begingroup\$ Call me old-fashioned, but I don't think it's a great idea to carry around boilerplate styles for every new project. Projects should be brought up to being semantically and functionally correct well before you worry about styles, and I don't particularly think that there's a one-size-fits-all. \$\endgroup\$
    – Reinderien
    Feb 7, 2022 at 15:44
  • \$\begingroup\$ Perhaps, but the idea of these would be to adjust them to fit the project and to ensure that you don’t forget to account for accessibility practices, hence the pseudo classes. These aren’t set in stone and I’d assume they’d be handy as having to style without a border-box for example would be a pain \$\endgroup\$ Feb 8, 2022 at 19:32

2 Answers 2


Body font size: There doesn't seem much point in setting the body element's font size to 1.6em if you're going to set paragraphs and other typographic tags to 1.8rem. Would recommend just setting the body to 1.8em and removing the rulesets for the typographic tags.

Color accessibility: Some of your link colors styles will be hard to read and fail accessibility standards on white backgrounds. Regular-sized text needs a color contrast ratio of at least 4.5:1 to be accessible.

There's not much benefit to overriding in a boilerplate the default link colors that people are used to, so I'd recommend removing. If you want to keep them, choose more accessible colors.

Margin and padding: Many elements have useful default margins and paddings from user-agents, and removing them (as you do in the first ruleset) will make elements look strange or unrecognizable. Some examples would be: figure, dl, blockquote—and your paragraphs will run together without some kind of margin. Would recommend only removing the padding/margin from the body element and leaving other elements' default margin/padding until you override them.

Font family: Tachyons CSS has a really nice font stack that defaults to system fonts with a lot of good fallbacks. A little nicer than Verdana.

Text color: Would recommend going slightly darker with the default text color.

All of these changes, plus some formatting tweaks and semicolons, would look like this:

* { box-sizing: border-box; }
html { font-size: 62.5%; } /* makes 1rem 10px */
body {
  margin: 0;
  padding: 0;
  font-size: 1.8em;
  font-family: -apple-system, BlinkMacSystemFont, 'avenir next', avenir, 'helvetica neue', helvetica, ubuntu, roboto, noto, 'segoe ui', arial, sans-serif;
  line-height: 1.3;
  color: #292929;
/* headings */
h1 { font-size: 3rem; }
h2 { font-size: 2.4rem; }
h3 { font-size: 2rem; }
h4 { font-size: 1.8rem; }
h5 { font-size: 1.6rem; }
h6 { font-size: 1.4rem; }
  • \$\begingroup\$ Those are some interesting points, thank you. The only thing about adding a margin of 0 to the body is that now elements like buttons have them, and possibly other elements. I could be being picky here but don't know whether that would bother some people, and wonder whether there could be other elements than buttons doing the same. Adding the all: unset would fix that but also rid all the non-inheritable defaults. I guess what others have said about there not being a one-size-fits-all solution is right \$\endgroup\$ Feb 12, 2022 at 16:43
  • \$\begingroup\$ @user8758206 Buttons don't inherit margin from the body element \$\endgroup\$
    – Sean
    Feb 13, 2022 at 0:05

The styles contain no errors per the W3C CSS validator.

In terms of selectors and ordering- there are multiple style guides and while there may not be a canonical style guide some are widely accepted - e.g. AirBnB CSS, Google HTML/CSS Style Guide with its CSS section, Wordpress CSS Coding Standards.

The AirBnB style guide states:

When using multiple selectors in a rule declaration, give each selector its own line.1

The Google style guide states:

Always start a new line for each selector and declaration. 2

And similarly the wordpress style guide states:

  • Each selector should be on its own line, ending in either a comma or an opening curly brace. Property-value pairs should be on their own line, with one tab of indentation and an ending semicolon. The closing brace should be flush left, using the same level of indentation as the opening selector.2

And while neither seems to state that the selectors should be in alphabetical order it does help in finding selectors if one needs to be updated.

Thus some may prefer to have:

h4, li, label, input, textarea, select, p

rewritten as

textarea {

Additionally, the Google Style guide states:

Use a semicolon after every declaration.

End every declaration with a semicolon for consistency and extensibility reasons.4

Adherence to this would lead to lines like:

color: pink

being updated like this:

color: pink;

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.