Post Image

Effective Code Conventions Don’t Rely on Effects

by
Ben Gremillion
Ben Gremillion

Our new Spec Mode feature gives designers and front-end developers control over the final code. But as the saying goes, with power comes responsibility.

In this case it means writing smart, reusable code that your team can get behind. Here are some helpful guidelines to follow when writing HTML in Spec Mode.

On naming conventions for the “prototype” stage

Prototypes, especially lo-fis, are prone to change. That’s their job: to help explore ideas. So when adding code to design elements in early work, we need to take change into account.

You don’t want to chase down code just because you move a column from the right to the left. For example:

  • Color, e.g. .red or .purple
  • Location, e.g. .top or .left-col
  • Size, e.g. .large, .xx-small
  • Time, e.g. .yesterday, .future, .to-do

You’ll quickly discover if your code uses naming conventions that don’t change well because you’ll find yourself having to rewrite them. To prevent that, we suggest naming things based on their purpose.

  • Priority, e.g. .secondary or .principle
  • Use case, e.g. .supplemental or .main
  • Specificity, e.g. .container
  • Audience, e.g. .user or .admin or .guest or .member
  • Media, e.g. .video or .photo or .feed (but use with caution — this can still change!)

Efficient code saves precious time

Browsers have to parse a ton of code when rendering a page. These days they’re pretty quick … but when milliseconds matter, we want the fastest HTML and CSS possible. The key is efficient selectors.

Most browsers render different selectors with more efficiency. From fastest to slowest:

  • ID, as in #name
  • Class, like .name
  • Tag name, such as div
  • Adjacent siblings, like article + aside
  • Children, e.g. section > h2

That’s great in principle, but how do we apply it to real-world design?

Practical guidelines

If certain selectors are inefficient, then writing smart selectors is critical.

Let IDs be IDs: If you’re using an ID, don’t also specify the HTML element. For example, #call-to-action, not button#call-to-action. The latter is redundant since the former is unique on the page.

Don’t pair tags and classes unnecessarily: li.primary {…} is less efficient than .primary-item {…} since browsers look for “.primary”, then re-scan those for instances of “li” within that list.

Avoid descendent selectors: header > .main > h2 is inefficient. Instead we recommend using something like “.main” on the h2 itself.

Avoid verbose selectors: div ul li a span is terrible for efficiency. Give that span a class!

Use native elements when possible: Check caniuse.com for supported native tags, like figure and article.

Use CSS shorthand whenever possible: “Shorthand” combines many properties in one. For example:

background: #fff url(…) top center no-repeat;

instead of:

background-color: #fff;

background-image: url(…);

background-position: top center;

background-repeat: no-repeat;

Varying schools of thought

While there’s no single “right” way to write code, there are many strategies.

  • BEM notation: Block-Element-Modifier style is verbose and tricky to grasp at first. But it’s also modular, efficient, and not bad for semantics.
  • OOCSS: While this approach isn’t semantic and is prone to class-itis, it’s reputedly good for developers and render speed. The idea is to write very reusable classes that describe their function within the page.
  • SMACSS: Naming elements with Scalable Modular Architecture for CSS makes code super-readable — once you get used to its rules.
  • Foundation or Bootstrap: If you want someone else to do the heavy lifting, you might consider a framework with pre-built (and well-tested) class names and JS widgets.
  • Roll your own: Nothing’s stopping you or your team from developing a naming convention. In some cases, it’s better than any other approach: your team would understand it because you wrote it together; it would be tailor-made for your workflow; and it would only include the code you need.

Going forward

Should designers learn to write code? That’s up for debate. But Spec Mode makes it possible. Anyone on a design team have the authority — and responsibility — for the HTML, CSS, and more. Let’s name elements intelligently.

Ben Gremillion

by Ben Gremillion

Ben Gremillion is a Content Strategist at UXPin. He’s worked as both a web designer and a back-end developer. On the side he builds and maintains a CMS for webcomic artists, and participates in annual NaNoWriMo challenges.

Still hungry for the design?

UXPin is a product design platform used by the best designers on the planet. Let your team easily design, collaborate, and present from low-fidelity wireframes to fully-interactive prototypes.

Start your free trial

These e-Books might interest you