Technical Development

CSS Best Practices For AEM: Part II

CSS Best Practices for AEM

In our last post on CSS best practices for AEM, we touched on some CSS design decisions that you should think about before developing with AEM, or any large scale site for that matter. But we have just begun to scratch the surface of CSS best practices. There are many more including selector priority, accessibility, and how to better organize and maintain your CSS; I’ll cover those here.

Selector Priority

For all of AEM’s great features, perhaps one of its pain points is the amount of additional markup it adds to your page. This makes both scoping your CSS properly, and understanding selector priority, extremely important so that you’re not conflicting with other elements on your site. Generally, the more specific a selector is, the higher priority it has.  Selectors get a point for each instance of a category, where the categories are as follows:
!important > style attribute > id attribute > classes or other attributes > element type
You can think of each category as a different “digit” than the others, where categories on the left trend higher.  So for example, a selector with an id attribute will always override selectors with only class attributes.

*{}  /* a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 */
li{}  /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */

li:first-line{}  /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */
ul li{}  /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */

ul ol+li{}  /* a=0 b=0 c=0 d=3 -> specificity = 0,0,0,3 */
h1 + *[rel=up]{}  /* a=0 b=0 c=1 d=1 -> specificity = 0,0,1,1 */
ul ol li.red{}  /* a=0 b=0 c=1 d=3 -> specificity = 0,0,1,3 */
li.red.level{}  /* a=0 b=0 c=2 d=1 -> specificity = 0,0,2,1 */
#x34y{}  /* a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 */
style=””/* a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */

Web Accessibility

Don’t forget your end-users who need additional accessibility!  User-defined styles will generally override your CSS.  There’s not much you can do about it directly, but you can still try to account for common accessibility cases, such as larger text, color-blindness, and contrast reversal to name a few. Here’s a few more accessibility tips to keep in mind when building your site:

    • Label all form input elements
    • Supply alt tags for images
    • Specify the correct Doc-Type
    • Supply proper meta tags (language, description, and keywords)
    • Use as much text as possible, don’t use images with text on them
  • Using fallback fonts and avoid using tiny fonts

Floating vs Display: Inline-Block

In most cases, floating elements are outdated for browsers newer than IE7.  Floating elements put them in a separate flow from other elements on the page, requiring that you maintain the layout by working around these elements, rather than letting the browser do it for you.
Parent elements are particularly notorious for having issues, as they only expand to contain non-floated elements.  Layout designers try to work around this by using clear:both and .clearfix to re-add the floated section to the flow, but why go through the effort?
Inline-block was invented to remove these complexities and simplify layout understanding.  It’s also far easier to maintain and change, because the elements keep their influence on the rest of the layout.

Properly Naming Your CSS

This seems like a no-brainer, but we’ve all been in situations where we’re in a rush to get something out of the door, and poorly named either a file or a selector. When dealing with an enterprise level site, you’re bound to come back to that CSS at some point and have no idea why you named it the way you did. Or if you don’t come back to it, someone on your team spends an extra 20 minutes tracking down the file. Properly naming your selectors, CSS files, and adding comments, can save you and your team a ton of time in the future maintaining the site.
We’ve just touched the surface of CSS best practices in Part I and Part II of our series. With technology evolving as quickly as it does, and new versions of CSS on the horizon, there will continually be new best practices and strategies for designing your CSS.  However, a few things that will never go away are properly maintaining and future proofing your code, so that you don’t run into conflicts in the future.

Paul Goodrich
Paul is a web development consultant at iCiDIGITAL with a long history of system analysis. He has a strong commitment to leveraging the best-fit technology and processes for the situation. His current development focuses are in AEM, Java, JavaScript, and responsive design. In his spare time he can be found reading, practicing the viola, enjoying the great outdoors, or planning for and playing any number of team-based tactical games such as Ultimate Frisbee.
View All Posts By This Author

Subscribe to Our Newsletter

Get the latest insights from Blue Acorn iCi

Let's build something together.