Howdy, I thought I might ask what is considered the best practice for Css layout, example should elements such as font go first or perhaps should body colors and classes be in order up the top. At the moment I seem to be doing my css as I come across a problem/requirement. As these are early days I thought I might ask is there a best practice/standard layout? Many thanks
Is this about how you order your rules in a css?
I’m not sure there is one system to go with. But probably best there is some kind of system and stick to it. But what you choose is down to preference.
I’m not the most organised with my code, but try to keep things in some kind of order.
For example, I may start with a bit of reset, then style some generic un-classed elements, then maybe just a few utility classes. After that I may have some more specific classes, possibly in groups, so there may be a whole block just about the nav system, then one for another part of the page.
Eventually you get to a media query, and it starts over again, dealing with the various elements. Though likely not everything needs to be there this time around, just what needs to change.
Thanks for your opinions
I start with general rules which apply to all pages. First of all html and body, then any outer wrapper. After that I do the page structure in order - header, nav, main content, footer. Then come any rules for images, headings, links or other items which are consistent across the site. After that I do any rules which are specific to particular pages - in the same order that the pages come in the navigation, and with notes to show where each starts and finishes.
All the sites I work on are quite small, so while this works well for me, it probably wouldn’t work for everyone.
I tend to have my reset, then general site styles starting with the main containers, then to main elements such as headings, paragraphs, lists, etc then to site-wide class styles. Then I go from top to bottom - header, navigation, main content (general, then page-specific styles organized by page), then footer last. I use CSS comments to name each main section of CSS.
Within my selectors, I tend to do things in this order: display, size (width, height), background, typography.
My media queries are split up to fit into their relevant sections so I find them easy to locate.
It doesn’t really matter how you organize your CSS, just as long as it works for you, and you are consistent and logical with your groupings. If you have a CSS file with thousands of lines, and you need to go back and change something, it really helps if you can find the rule you want to change quickly and easily.
These are good answers. Just remember that CSS stands for Cascading Style Sheets, meaning that what you put later may override an earlier style, so in that sense order in the CSS is important.
Hi, while I agree with what is already given, I happend to have the coding style I prefer described in a text to be handy.
My personal CSS code formatting guide:
CSS-coding-practice.html (6.0 KB)
The goal is an intuitive style order and a compact code format to
maximize overview and with consistently arranged rules to help quick
code scanning.
Organizing the style sheet to easily find current style for any element in the html:
General structure of the document:
- in top are comments with document properties and recent updates,
- eventual custom chapters are listed and explained in a TOC comment,
- common chapters for resets and shaping like colors or fonts comes first,
- custom chapters can end with their specific media queries,
- or all media queries in a chapter last in document to be easily managed
General arrangement of rule-blocks:
- common styles for current generic selectors comes first,
- order of generic elements are according to type or nesting in the html,
- named selectors follows the order they appear in the html,
- named selectors in group are arranged according to their elements in html,
Formatting the ruleblocks:
Multi-line ruleblock format:
- one selector per line,
- opening bracket comes directly after the selector,
- no space before opening and closing brackets,
- no space after the property colon,
- one space after a value comma,
- no zero character before a decimal period,
- no empty line after the closing bracket.
Indentation in multi-line ruleblocks:
- real tabs that will expand to whatever coworkers are used to.
- one tab per level. In my editor set to two spaces.
Comments in multi-line ruleblocks:
- are non obvious and follows on the same line.
Single-line ruleblock format:
- multiple selectors wrap line after the comma, the last selector starts the block line,
- only short selectors can be comma-space separated on the same line as the block,
- no space between the last selector and the opening bracket,
- one space after the opening bracket and then between all declarations,
- the last semicolon before the end bracket is removed when code is finished.
- no empty lines before or between single line blocks,
- one empty line after when it’s followed by a multi line block,
- no comments (if necessary:comment in a line before or change to multi line block).
Sorting the declarations by context in descending order:
External influence, e.g:
- display,
- float,
- position,
- z-index,
- coordinates:top,right,bottom,left,
- margins in shorthand order,
Element appearence, e.g:
- outline and outline-offset,
- border-properties in shorthand order,
- border-sizes in shorthand order,
Element shaping, e.g:
- box-shadow,
- change of box-sizing,
- padding in shorthand order,
- width,
- min-max-width,
- height,
- min-max-height,
- flex-self and current item properties,
Content containing, e.g:
- flex-container properties,
- flex-content properties,
- flex-items properties,
- overflow,
- background-properties in shorthand order,
- color, (appearence exception)
Content appearence, e.g:
- transition,
- animation,
- opacity,
- vertical-align,
Content shaping, e.g:
- text-align,
- white-space,
- font-properties in shorthand order,
- text-decoration,
Internal properties, e.g:
- cursor,
- pseudo-content, (goes last in the block)
Temporary overrides and testing:
- N.b. precluded by a commented out line break for disabled test declarations,
- overrides of current declarations,
- additional declarations of any kind,
Rule block examples:
html, body{ margin:0; height:100%; background:lightgoldenrodyellow}
h1, h2, h3{ margin:.5em 0; text-align:center; font-weight:bolder}
selector-one,
selector-two,
selector-three,
selector-ten{ display:inline-block; width:500px; hight:200px; background:red}
selector-one{ background:none}
selector-two{ display:block; vertical-align:top}
selector-five{
display:inline-block;
position:absolute;
z-index:0;
top:auto;
left:auto;
margin:auto;
box-sizing:border-box;
border:0;
padding:0;
width:auto;
height:auto;
overflow:hidden;
background:gold;
color:inherit;
transition:4s linear 2s;
opacity:.5;
vertical-align:middle;
text-align:left;
white-space:normal;
font:1em/1.2 sans-serif;
cursor:pointer;
content:normal;
}
selector-eight{
margin:auto;
width:auto;
height:inherit;
font:inherit;
/*
*/
display:table;
width:100%;
}
Thanks Gang
I’m prone to error everywhere, and then waste time correcting harmless things.
Just for the record, in this doc I misplaced the box-shadow and border property examples in the list.
My guide doc is now corrected:
Element appearence, e.g:
- outline and outline-offset,
- box-shadow,
Element shaping, e.g:
- change of box-sizing,
- border-properties in shorthand order,
- border-sizes in shorthand order,
- padding in shorthand order,
- width,
- min-max-width,
- height,
- min-max-height,
- flex-self and current item properties,
(The ruleblock examples was ok though.)
I’ve always liked the approach described in @csswizardry’s ITCSS. There’s a rather long, but worthwhile video of a talk Harry Roberts (@csswizardry) did on the subject a couple of years back on YouTube - Managing Projects with ITCSS, which describes the structure below.
I just watched the YouTube video, one hour and 13 minutes! I would have preferred more examples.
My simple approach to CSS is similar to the video:
- set global body variables first
- set Three Letter Acronyms classes for dimensions, floats, colours, etc
- set specific ID’s
/* https://booking.design/implementing-system-fonts-on-booking-com-a-lesson-learned-bdc984df627f */
body {font: 16px/1.2 BlinkMacSystemFont, -apple-system, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;}
body {border:0; margin:0; padding:0 0 2em;}
.caption {background-color:#cff; margin-top:2.2em; padding:0.21em 4.2em 0.21em 0.112em;}
/* Three Letter Acronyms */
.bdr {border-radius: 0.88em;}
.bdt {border-radius: 0.88em 0.88em 0 0;}
.bdb {border-radius: 0 0 0.88em 0.88em;}
.bd1 {border: solid 1px #333;}
.bd2 {border: solid 1px #9f9;}
.bd3 {border: solid 1px #f00;}
.bd4 {border: solid 1px #ff9;}
.bot {border-bottom:solid 3px #000;}
.btn {background-color:#0f0; color:#000; padding:0.42em 0.88em; border: solid 3px #000;}
.btn {background-color: blue; color: #fff; padding:0.42em 0.88em; border: solid 3px #0ff;}
.bg0 {background-color: #ffffff;}
.bg1 {background-color: #efefff;}
.bg2 {background-color: #dddddd;}
.bg3 {background-color: #aaaaaa;}
.cl0 {color:#fff;}
.cl1 {color:#333;}
.cl2 {color:#090;}
.cl3 {color:#a00;}
.clb {clear: both;}
.dib {display: inline-block;}
.fll {float:left;}
.flr {float: right;}
.fss {font-size: small;} .fsx {font-size:xx-small;color:green;}
.fs2 {font-size:large;} .fsl {font-size:x-large;}
..ftr {bottom:0; left:0; width:100%;}
.fwb {font-weight:700;}
.hhh {display:none;}
.hvr:hover {background-color:#eff;}
.lh2 {line-height:2.00em;} .lh3 {line-height:3.00em;}
.lsn {list-style: none;}
.mga {margin: 0 auto;}
.mgb,
.ooo {border: 0; margin:0; padding:0;}
.ova {overflow: auto;}
.p42 {padding: 0.42em;}
.poa {position:absolute;}
.pof {position:fixed;}
.por {position: relative;}
.rnd {border-radius: 1em;}
.tac {text-align: center;}
.tal {text-align: left;}
.tar {text-align: right;}
.tdn {text-decoration:none;}
.vam {vertical-align: middle;}
.w88 {width: 88%; max-width: 1024px;}
.w42 {width: 42%;} .w08 {width:08%;}
.w48 {width: 48%;} .w98 {width: 98%;}
.wrp {white-space: pre-wrap; white-space: pre-line;}
#specific-identifiers {}
The basic idea is the Don’t Repeat Yourself and it is also far easier to change dimensions, colours, etc
Implementation:
<body>
<div class="w88 mga bg1 cg2">
<h1 class="caption"> Title goes here </h1>
<p class="w88 mga bg2 cg3">
Blurb goes here
</p>
</div>
<div class="poa ftr bg3 cg4 tac">
footer goes here
</div>
<body>
</html>
Thanks for all the replies, I am just getting back to all this and will be asking questions again soon
Ive mostly given up order my classes according to any order. Obviously cascading takes priority.
What I do for ordering properties is:
General Position & Display (position, display, flex properties, float, etc)
Box Element styles (background, border, outline, shadow, etc)
Font (font, text color/decoration, color, text shadow, etc)
Dimensions ([max] width, height)
Padding & margin
Transforms
The best and less complicated option is to save each css rule as a different file ( color.css, font.css, general.css etc), this will help you easily find problems and sort them out, or edit your designs.
Are you serious?
Try it, and you will see that whenever you want to make changes, it will be so easy, since you know where to go to direct to make color change or text change etc, plus it reduces the stress of going through as long line of css codes
That’s all very well and fine, but it will increase the load time of your page significantly with so many HTTP requests.
Oh! I see, good point.
I dislike that approach as experience tells me that I will hardly ever go back and edit just one property and your method now requires me to search through 3 files instead of one!
I like my rules on the same block and then I get an immediate picture of what’s going on and can make changes easily to all aspects.
There is no real need to search through stylesheets because if you have the web inspector handy you have the exact line number listed anyway.
Everyone has their own preference of course but when you do this hundreds of times a day then a simple logical approach is usually best.
Whilst I agree that breaking the css into smaller files is not a good approach (especially having a new file for every rule).
Using a CSS preprocessor will surely give you the best of both approaches by allowing you to create a more modular structure to your styling which then get processed into fewer files to help keep the http requests down.