Hey! My name is Cindy. No, not Sydney, just Cindy. People tell me that I “look like a Megan.” Have you ever had someone tell you that you look like you have a certain name?  Yeah … that makes no sense. That’s not what our names are for. Names don’t describe what you look like. We use our names to identify each other.

“There are only two hard things in Computer Science: cache invalidation and naming things.” —Phil Karlton

Y’know, Phil has a point. Let’s be honest, names are hard to remember and even harder to come up with. As a front-end web development intern, I initially thought if I just knew the right syntax, I would become a master programmer. But good code is about more than just syntax. I’m learning to maintain my code by writing semantic class names and avoiding using presentational words.

This is fancy talk for making sure elements say what they are, not what they look like.

At work, I mostly write HTML and CSS. When I collaborate with designers and another developer, we often run into issues with naming design elements. If I’m referring to a design element as a *widget*, the designers are calling it a *blue box*, while the other developer wrote code that defines it as a *doodad* … yeah, this gets confusing. If we start the process by using a common language, things will run smoothly.

“Authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.”

— HTML 5.1 2nd Edition (section 3.2.5.7)

Just because a section of a website is periwinkle blue does not mean the class name for the section should be “periwinkle.” It’s key to avoid presentation-specific words when naming your selectors. In order to write code that’s maintainable, you need to make sure your class names describe the type of content you’re working with. By naming the class “periwinkle,” you’re basically going against the design principle “separation of concerns” when it comes to working with front-end development. The HTML is strictly for defining the structure and presentation of information, while CSS is strictly for describing the presentation, and Javascript focuses on the behavior.

Let’s pretend I’m building a site for a client who sells widgets, and they want each block to represent a widget with a red background.

<div class=”widget”>

Semantic: This class name is not specifying the style or presentation of the element, it describes what the content is. The name “widget” refers to the content within the HTML and in the CSS document, I’ll define what a widget looks like.

<div class=“red“>

Presentational: The class name is an attempt to give an overview of the presentation that’s being applied. If all widgets currently have a blue background, what happens if the client changes their mind? What if the client wants to change the red background to a blue background? It’ll be a hassle to change every instance of class=”red” to class=”blue”. However, if you were to change the class name to “widget”, it would be easier to go ahead and change the .section {background:red} to blue.

By using values that describe the content, I write code that is self-explanatory, and this semantic approach will help the developer spends less time refining the code. Presentational class names usually aren’t recommended, as it may be hard to analyze the code and come to the conclusion about its purpose and use.

So here’s the 411: If the style changes, you should edit the style, and if the content changes, you should edit the content. Plain and simple. If my only concern regards style changes, I should not be editing the style AND the content, just the style, as this establishes an efficient workflow.

Here at Redhead, we make sure details are done properly in development to help our client maintain a stable and well-tuned website. Most of Red’s clients don’t think about making sure the code is written well. But that’s OK because it’s our job to make sure our clients don’t worry about the details. We have their backs.