Standardizing CSS Property Order

Working on a team of developers has its advantages and disadvantages like any team, but one way in which our industry is unique is that so many of us are self-taught or have no standardized background (having worked at three different agencies and freelancing for half a decade have only worked with two individuals who have an educational background in Computer Science). This of course brings that benefit of having many unique experiences which shape into creative solutions that one may never have thought of, but also brings that burden of non-unified practices along with it.

Since joining the WordPress Theme Review Team last month, I’ve been focusing a lot on best-practices and standards in front-end web development. This has translated into a lot of heavy discussion at my agency but one consensus is that standardizing development practices can lead to nothing but improvement, speed, and a higher quality of code.

I first got interested in how to “properly” order CSS properties when, about a year ago, I stumbled across CSS Comb and have since been following the practices of industry leaders like Harry Clark and Nicholas Gallagher and their methodologies for CSS syntax styling. However, the accepted consensus is that there is no “real” or “proper” way to order CSS properties. But when someone like Chris Coyier admits that even he order his CSS properties at random I began thinking “What really would be the best approach to CSS Standardization?”

Taking my own advice I’ve laid out a new proposal for CSS property order standardization, based largely on the Box Model, Object Oriented CSS, a few suggestions from Mark Otto’s blog, with an original thought of my own here and there.  This approach focuses on same pattern of thought that a front-end developer might experience when a visual layout is completely FUBAR – that is, first debugging properties which have the greatest visual impact on an element, and working your way down from there.

I look at ordering CSS properties in the following way: by placing order of importance primarily on potentially visually-obstructive properties, then on structural properties, followed by element-specific, aesthetic, font, and UI/UX specific properties, the readability of the element syntax follows the same order of operations that one debugs a front-end error. By including the final three sections, we ensure for a future-proof stylesheet that’s easy to debug and refactor. Ordering our properties in this way would follow this pattern:

• Visually obstructive properties
  • ex: display: none; visiblity: hidden;
• All properties which define the elements visibility
  • ex: visiblity, overflow, opactiy, etc.
• Properties which define element position relative to others
  • ex: position, float, z-index, clear, etc.
• The Box Model
  • First, by declaring properties which limit or enable the element’s structure
    • ex: display, max-width, max-height, etc.
  • Then all other Box Model properties
    • ex: top, width, margin, padding, etc.
• Element Specific Properties
  • ex: list-style, border-collapse, resize, etc.
• Aesthetic Display Properties; order properties by those which have the greatest amount visual impact to the least amount of visual impact
  • ex: filter, background, border, transform, box-shadow, etc.
• Font Properties
  • Primary font properties (those that effect structure):
    • ex: font-size, line-height, font-weight, font-family
  • Secondary font properties (those that effect visual aesthetics):
    • ex: content, text-align, text-transform, font-style, etc.
  • Tertiary font properties (purely visual effect):
    • ex: color, text-shadow, letter-spacing, etc.
• UI-Bound Properties
  • ex: animation, transition, etc.
• Browser-specific properties and hacks
• Any properties containing the “!important” rule.
• Deprecated properties, or candidates for removal

It should be noted that, as a best practice, any properties extrapolated from their short-form into long-form should follow the same order and format laid out on their W3C page.  For example:

.element {
	border: 3px solid #fff;
	transition: 150ms ease-in-out width;
}

would be listed as:

.element {
	border-width: 3px;
	border-style: solid;
	border-color: #fff;
	transition-duration: 150ms;
	transition-timing-function: ease-in-out;
	transition-property: width;
}

*Please note, however, I am not advocating for expanding all properties simply for the sake of expansion. The above example is for demonstrative purposes only.

All directional specifications should follow the order of “top”, “right”, “bottom”, “left” – the same order when declaring a four-dimensional property specification (like padding, or border-width).

For a more detailed example of an element containing properties in this order I’ve created the following example element which contains a greater number of properties in the same order using the methodology above:

/* ==============================
   CSS Property List

	.element {
		// If the element is hidden initially, display those properties first
			display: none;
			visibility: hidden;
			opacity: 0;

		// Properties affecting visibility
			box-sizing
			visibility
			overflow
			opacity
			clip

		// Element position and relativity
			position
			z-index
			flexbox
			float
			clear

		// Box Model
			* Properties limiting/enabling element structure
				display
				max-width
				max-height
				min-width
				min-height
			* Properties affecting element size and aesthetic scope
				width
				height
				top
				right
				bottom
				left
				padding (following TRBL order)
				margin (following TRBL order)

		// Element-specific properties
			list-style (for ul, ol, li)
			border-collapse (for table, tr, td, etc.)
			resize (for textarea)

		// Aesthetic Display Properties (properties with most amount of visual impact listed first, then tier down to properties with least amount of visual impact)
			filter (CSS3 Property)
			background
				*background-color
				*background-image
				*background-position
				*background-repeat
			filter (MS Property)
			border
				*border-width
				*border-style
				*borer-color
			outline
				*outline-width
				*outline-style
				*outline-color
				*outline-offset
			border-radius
			box-shadow
			transform

		// Font Properties
			// Primary Font Properties
			font
				*font-size
				*line-height
				*font-weight
				*font-family

			// Secondary font-properties (affecting visual style)
			color
			text-align
			text-transform
			font-style
			text-decoration
			word-wrap

			// Tertiary Font Properties (purely aesthetic)
			content
			letter-spacing
			word-spacing
			text-shadow

		// UI Bound Properties
			// Basic user interaction
			cursor

			// Additional UI properties
			animation
				* name
				* duration
				* play-state
				* timing-function
				* delay
				* iteration count
				* direction
			transition
				* duration
				* timing-function
				* delay
				* property

		/***

		The final three segments below are areas where properties that do not seem to fit in the normal model are placed.  The are used to future-proof a stylesheet and ensure ease of debugging and refactoring later.

		***/

		// Browser-specific properties & hacks
			ex: background-color: #999 \9;
			ex: *zoom: 1;

		// Any !important properties (while there should be none in a stylesheet, we all do this in times of necessity)
			ex: height: 10px !important;

		// Deprecated properties, or those not needed (found during refactoring or inheritance of project)
			ex: -ms-zoom: 1;
			ex: -ms-filter: ...

	}

   ============================== */

This example can be downloaded as a .css file, or found on GitHub which I would ask you fork and pull at your leisure if you have any suggestions.

If you have any suggestions, questions, or a different/preferred way of ordering your CSS properties, I’d love to hear your ideas in the comments below.