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.