What are some good practices to organize CSS code?

Answer 1

By using Visual Studio Code as your IDE together with CSS snippets plugins

Answer 2

Hello,

I know I'm late to the party, but I want to say I actually wrote an article exactly about this: 3 CSS Tips for Junior Web Devs & Designers

But to answer your question, there are two things I'd recommend:

1. Add a “Credits” section

Yes, adding a Credits section at the top of your CSS file will help you and others see who originally created the file, when it was created and what technologies or syntax you used in case you used a CSS preprocessor.

This is very important in case someone working with your CSS has questions because they may be able to reach out to you.

Taken from the article, this is an example of a Credits section in the CSS looks like:

/*!

CSS file for Project Name

Syntax: xxx

Created by: Full Name

Date: xx/xx/xx

*/

2. Comment your CSS file as much as possible

As Eduardo pointed out, adding the section names on as comments in your CSS is a great way to organize your code.

The way I do it is like this.

For the top-level sections I use CAPITALS:

//** GLOBALS */

…

//** LINKS */

…

//** FORMS */

…

…and for subsections I use lower-case:

//** GLOBALS */

…

/* Subsection of Globals */

…

Hope this helps.

--

Now, one to note from Eduardo's code example albeit out of scope of your question, but important to mention in case someone decides to copy and paste that code.

Be VERY CAREFUL when resetting the margins and paddings with the 'global' selector, the '*'. Doing this is not recommended:

* {

margin: 0;

padding: 0;

}

Doing this will reset margins and paddings of ALL ELEMENTS, this means that you will have to redeclare them again, thus adding more unnecessary work to your pipeline,

In addition, using the global selector has a negative effect in performance because the bigger the page the more work the browser has to do to reset to 0 and then re-set the margins and paddings again to your declared value.

Recommendation: Do not use reset values or use a reset CSS (I've used Eric Meyer's reset CSS many times before). Instead, normalize all those values with Normalize.css.

Normalize.css is a CSS file you can use, and modify to fit your project, to "even out" all sorts of values that all browsers declare differently. Normalize.css is free. You can download Normalize.css here: https://necolas.github.io/normalize.css/

If you have any more questions, don't hesitate to ask.

Hope all this helps.

Answer 3

This is a big question and like most things in the world of the web there are no absolute right answers -- only what works best for you. ( see: https://css-tricks.com/just-try-and-do-a-good-job/)

That said, there are a lot of best practices/style guides out there. A good place to start is:

https://10up.github.io/Engineering-Best-Practices/css/#top

but see also:

1. https://cssguidelin.es/
2. https://github.com/necolas/idiomatic-css
3. https://engineering.appfolio.com/2012/11/16/css-architecture/

The first thing to recognize is that there are big differences between organizing a CSS file for a project that you will be building yourself (or mostly by yourself) and one on which you are a member of a teams of developers who are all contributing to the project.

I typically work on small projects by myself so file only has to please me. After the explanation below I've included the basic CSS file template I use when starting a new project. This file works with a basic HTML template that I also use I add a site-header and site-footer class to those elements and my main content area is wrapped in a div with the class="content-frame". All the other rules are on elements.

I begin with a project header which typically has my email address rather than my Wyzant profile. I follow that with a Table of Contents that starts with these four areas and I find that I usually only add sub-sections to the existing sections. That is followed by the colors that I use. I add to this everytime I add a color. This will keep you from having eight variations of light grey (unless of course you need them - but at least then you'll know)

I've found that having a consistent organization to my files lets me know where I'm likely to find the rule I need to edit. If I'm adding a new rule I can see it in the context of other associated rules to write my CSS more efficiently (my goal is to write as little CSS as necessary). Why do I separate the navigation rules into their own section? I've learned that these rules can be complex, but that once written they tend to be stable over the course of the project. But putting them in their own section I can basically write them and collapse that section in my editor (I use VS Code btw) and ignore that complexity.

One thing that is inherent in this structure is that my designs/implementations start with a mobile-first approach. That means I write the rules for the mobile version of the site and then add the tablet, laptop, desktop rules after the mobile rules are complete. (I may break this down by section or component - typically I'll create the header and footer first and make them work across all my breakpoints, before moving on to the content section). I find it easier to add to the minimal HTML/CSS for mobile than to re-engineer the desktop rules to work on mobile. I support this workflow by including multiple media queries in each section. I find it easier to maintain the CSS if it is organized this way.

/*

Project Name: Wyzant Examples

Author: Lee Mandell

Contact: https://www.wyzant.com/match/tutor/86262716

NOTE: Created for use with lrm page-template.html file.

*/

/*

Table of Contents

=01 RESET/GLOBAL DEFAULTS

=02 TYPOGRAPHY

=03 NAV

=04 LAYOUT

PAGE SPECIFIC STYLES

*/

/*

Colors:

#000 = black

#222 = dark gray, text default

#f8f8f8 = very light gray, background default

#fff = white

*/

/***** =01 RESET/GLOBAL DEFAULTS *****/

/*

see also:

Eric Meyer's reset: https://meyerweb.com/eric/tools/css/reset/

normalize.css - https://necolas.github.io/normalize.css/

https://scotch.io/tutorials/a-look-at-bootstrap-4s-new-reset-rebootcss

https://github.com/twbs/bootstrap/blob/v4-dev/dist/css/bootstrap-reboot.css

*/

* {

/* see https://css-tricks.com/box-sizing/ */

-webkit-box-sizing: border-box;

-moz-box-sizing: border-box;

box-sizing: border-box;

margin: 0;

padding: 0;

font-family: inherit;

line-height: inherit;

color: inherit;

}

/*

For absolutely positioning elements within containers (add more to the list if need be).

Note: z-index only affects explicitly positioned elements.

*/

div, article, section, header, footer, nav, ul, li { position: relative ; }

p { margin-bottom: 1em; }

img, .img-frame { width: 100%; }

.site-header { background-color: #ddd }

.site-footer { background-color: #333; }

/***** =02 TYPOGRAPHY *****/

html {

font-family: sans-serif;

font-size: 100%;

line-height: 1.2;

color: #222;

overflow-y: scroll;

/* Turn off auto adjust on some phone browsers */

-webkit-text-size-adjust: 100%;

-ms-text-size-adjust: 100%;

}

body {

font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, Noto Sans, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";

font-size: 1rem;

font-weight: 400;

line-height: 1.5;

}

h1, h2, h3, h4, h5, h6 {

font-weight: bold ;

line-height: 1.2 ;

}

a {

color: blue;

text-decoration: none;

}

a:hover { text-decoration: underline; }

footer {

font-size: 80%;

text-align: center;

color: #999;

}

/**** 480px/30em ****/

@media screen and ( min-width: 30em ) {

} /**** 480px/30em ends ****/

/***** =03 Nav*****/

/**** 480px/30em ****/

@media screen and ( min-width: 30em ) {

} /**** 480px/30em ends ****/

/***** =04 LAYOUT*****/

/*

Global styles, mobil first

Then Media Queries for Global styles

Then Page Specific styles with their media queries

*/

body { background-color: #fff; }

.content-frame {

width:92%;

margin: 0 auto;

}

/* All the rest of the basic mobil layout style rules */

/**** 480px/30em ****/

@media screen and ( min-width: 30em ) {

} /**** 480px/30em ends ****/

/**** 600px/37.5em ****/

@media screen and ( min-width: 37.5em ) {

} /**** 600px/37.5em ends ****/

/*** PAGE SPECIFIC STYLES ***/

/*** Some Specific Page - e.g. ABOUT page ***/

/*

page styles, mobile first

Then Page Specific styles with their media queries

*/

/*

Page styles here like this:

.page-class-name some-additional-selector

property name: propery value;

*/

/**** 480px/30em ****/

@media screen and ( min-width: 30em ) {

} /**** 480px/30em ends *****/

/*** end PAGE SPECIFIC STYLES ***/

Other reading that you may find useful:

1. https://www.youtube.com/watch?v=1OKZOV-iLj4
2. https://www.smashingmagazine.com/2016/06/battling-bem-extended-edition-common-problems-and-how-to-avoid-them/
3. https://css-tricks.com/poll-results-how-do-you-order-your-css-properties/

Answer 4

Most importantly – provide a distinct name for all of your ids and classes, then continue the same pattern when naming the rest of your objects. Secondly – add comment between major sections in html and in the corresponding location of your external CSS. Since you will likely use comment areas to keep notes and unused code, it’s helpful to comment out large areas in both files with corresponding numbers, letters, or in the case of CSS files that are more than 1,000 lines: text patterns and text based images. This can be especially helpful when using Sublime or any text editor with a ‘minimap’ view because text based images are still visible and act as markers on the page. Don't worry about taking up too much space with comments while you are editing, comments will be removed when the code is minimized.  As most people code the CSS in an external file as they code the HTML, it is simple and effective to keep the #id or .class in the same location as the <div> vertically on both pages. Don’t forget! Most text/code editors have a search function ‘ctrl + f’.

--Consistent object names

#articleHeadingOne{...}

#articleHeadingTwo{...}

--Position code vertically

<div id="thingOne">Thing.</div> || #thingOne{...}

<div id="thingTwo">thinG.</div> || #thingTwo{...}

--Comment between large areas with text or patterns

<!--area one for the image thing--> || /*area one for the image thing*/

<!--0__0__0__0__0__0__0__0--> || /*_0__0__0__0__0__0__0__*/

Answer 5

Hi, Christopher!

Organizing CSS, in many cases, is a matter of personal taste or preference.

For example, if I am only working with one .css file, I like to order my code by sections or components. In my code, before the styles of each section, I would type the name of the section and comment it out. Then I would proceed with the code. Here is what it would look like:

/* General Styles */

* {

margin: 0;

padding: 0;

box-sizing: border-box;

}

/* Navbar Styles */

nav {

width: 100%;

background: white;

}

/* Hero Styles */



.hero {

width: 90%;

margin: 0 auto;

}

...and so on.

Others, like to create a separate .css file per section or component. Instead of using one .css file, using our example above, they would create several files and would probably call them: general.css, navbar.css, and hero.css.

Hope this helps!