Hello, my name’s Chris Landtiser, and welcome once again to Front End Center.

Cascading Style Sheets. CSS. This presentational markup language is the source of equal amounts joy and heart break for many front-end developers. It forms part of the traditional web holy trinity – HTML, CSS, and JavaScript.

While there are constantly developers pushing the borders on everyone’s expectations, these three languages usually handle very specific roles:

• HTML provides the semantic structure of a page. It is literally the content and building blocks underlying everything.

• CSS styles the content. Font colors, layout positions, image width and more fall under its responsibilities.

• JavaScript provides triggers and moving parts, changing the HTML and CSS in interesting and helpful ways.

CSS proves a unique challenge for many developers and designers alike. As a style-centric language, it straddles an odd gap between visually creative design and pseudo-code logical processes. To make the most of CSS, you have to understand how to translate a visual design into the most effective format of code with minimal repetition or unneeded fluff.

There’s regular contention about the “best” way to handle CSS. Many developers support using the built in functionality the language was named for, Cascading. Being able to apply a red border to every image within a certain container class is a really powerful tool. Leveraging this innate cascade means you can use a minimum number of classes and IDs, keeping your HTML especially pristine.

Other teams favor verbose use of classes and IDs to abstract away from that cascading and implement their own methods of styling. This style of CSS writing is often favored by larger teams, or groups working on longstanding projects like open source software.

My team is making the slow but steady progress towards mobile-first projects in our enterprise environment. Part of that deliberate process is considering what unified front-end processes will be going into our work now, and form the foundation of our work in the future.

On one hand, the team has multiple developers, front and back-end alike. We have members across continents in different time zones. One of the biggest goals was to create a simple and recognizable method that everyone on the team could access and use.

On the other hand, we work in some very large and complex environments. Every universal class or edge-case override we added would be held against us when it was multiplied endlessly across development and production environments. Our path had to be picked carefully down the middle of code efficiency and future maintainability.

A solid foundation for the basis of a CSS architecture is the BEM, or Block Element Modifier, methodology. This is a specific method within the larger idea of Object Oriented CSS.

“Object Oriented” might be a familiar phrase for you if you’re more experienced with modern development practices in any number of languages. Essentially, it means that your code is organized around defined “objects”, rather than actions, logic, or any other method of order.

For example, you might have an “Important Button” object in your CSS. All of the styles related to this “Important Button” would be together and interrelated, since it’s all part of a single object. Another similar (but separate!) object might be something like an “Email Me” button.

The BEM method of CSS architecture breaks this down in a very style-focused way. Blocks are generally their own objects, like a button. Elements are the parts that make up that block. The wording on the button would be a considered one of its elements. Finally, Modifiers are pretty self-explanatory. On your home page, your button may be blue, while everywhere else it draws attention by being orange. It’s still the same Block, just with a small modification. Size, color, or internal layout are all common modifications.

Like any created method of coding, there is flexibility in these definitions. At times, a Block is a literal button. At others, it’s the header of your website, which contains a banner under two text fields… and a button.

When deciding what’s a Block and what’s a contained Element, consider how you’re going to use the object in question. A website header, login form, or other section that will be routinely reused across the site is a prime candidate for a Block. This even lets you get fancy and use modifiers to change how the Block is presented, with minimal extra code.

If your header changes largely across pages, maybe the smaller portions should be considered their own unique Blocks instead. If every third page has an advertisement, and there’s not always a need for a login form, then you don’t really have a coherent Header Block – and that’s okay!

BEM and other methodologies are here to help you, not to dictate the nuances of how you can code. As long as you and your team are able to use them as an accessible organizing method, they’re working just fine.

While this makes organization and communication much simpler, we do have to account for the challenges of large scale enterprise solutions. BEM tends to be very verbose by nature, which can add a lot of code weight to your files. It denotes Elements and Modifiers with double underscores and double hyphens respectively, which many developers consider both ugly and costly.

.login-form__button—highlighted IS a mouthful of code. Combine that with other elements of similar length, and how many times they may be called in the HTML, and suddenly things can look pretty unwieldy.

Thankfully, very little is set in stone when you’re a developer. You don’t HAVE to Block and Element and Modify every bit of your stylesheet. If you’re working on a Block that looks like a card with a person’s picture, consider your options. If this unique Block will, to the best of your knowledge, only ever have that single image inside it… just CSS’s natural cascade to target it! No need to add utterly redundant classes to clutter up your CSS and HTML again and again.

Ultimately, CSS can be a pretty gray area for planning methods. With all the best BEM architecting in the world, a content management system like SharePoint might still require the heavy use of cascading styles to reach un-classed elements throughout the site. Other systems reject cascading violently by playing loosely with semantic order, but will religiously follow class and ID names that make Object Oriented CSS invaluable.

Interestingly, a lot of the topics that created and refined ideas like Object Oriented CSS have been considered in the ongoing creation of the actual, official growth of the CSS language. HTML, CSS, and JavaScript alike are entering strange new chapters in their goals and use. Many processes that were impossible five years ago are perfectly simple now.

Other areas, like each languages roles we discussed earlier, are growing fuzzy. HTML is taking on a vast amount of functionality that used to be fielded by Adobe’s Flash, and, more recently, JavaScript. CSS is encroaching on this “logical programming” territory as well, to the joy of some and the horror of others.

Thankfully we can begin to learn lessons about what we want and what we need using ideas like the BEM methodology. Before we ever have to write a new standard in stone, we can try out new ideas and see what gets used and what is completely ignored.

And if you thought CSS was moving and changing quickly, wait until we just begin to dip a toe into the pool of modern JavaScript methods and resources next week. Until then, this has been Chris Landtiser and Front End Center.