Experimenting with component-based HTML/CSS naming and patterns

README.md

NOTE I now use the conventions detailed in the SUIT framework

Template Components

Used to provide structural templates.

Pattern

t-template-name
t-template-name--modifier-name
t-template-name__subcomponent-name--subcomponent-modifier-name

Examples

t-icon
t-icon--large

t-btn
t-btn--large

t-media
t-media__img
t-media__img--large
t-media__opt
t-media__body

State Components

Used to indicate the state of a component

Pattern

is-state-type

Examples

is-hidden
is-collapsed
is-expanded
is-selected

JavaScript Components

Used to provide JS-only hooks for a component. Can be used to provide a JS-enhanced UI or to abstract other JS behaviours.

Pattern

js-action-name

Examples

js-submit
js-action-save
js-ui-collapsible
js-ui-dropdown
js-ui-dropdown--control
js-ui-dropdown--menu
js-ui-carousel

About theming Components

Could reuse the Template Component naming convention, for example:

specific-name
specific-name--modifier-name
specific-name__subcomponent-name
specific-name__subcomponent-name--subcomponent-modifier-name

Or just let anything go.

html-example.html

<!-- 
What if we used more white-space around class values? 
Does it make the code more readable and surface/separate the components 
among the rest of the info in the HTML?
-->

<div class=" t-unit  t-media ">
    <div class=" t-media__img ">
        <a href="#">
            <img class=" product-img " src="http://example.com" alt="">
        </a>
    </div>
    <form class=" t-media__opt  js-action-rate ">
        <button class=" product-rating " type="submit">
            <div class=" product-rating__panel ">
                <span class=" product-rating__points ">
                    5
                </span>
                <span class=" product-rating__label ">
                    upvotes
                </span>
            </div>
            <strong class=" product-rating__action  t-btn  btn-normal ">
                Upvote
            </strong>
        </button>
    </form>
    <div class=" t-media__body ">
        <h2 class=" h2 ">
            <a href="#">Product title</a>
        </h2>
        <p>[content]</p>
        <ul class=" t-uilist--hz ">
            <li><a class=" tag " href="#">tag name</a></li>
            <li><a class=" tag " href="#">tag name</a></li>
            <li><a class=" tag " href="#">tag name</a></li>
        </ul>
    </div>
</div>

This is pt-br version https://gist.github.com/suissa/5750562

Here's a pattern I've been experimenting with:

http://jsfiddle.net/mindplay/XmfBa/

I know the leading hyphen looks odd at first glance, but give it a chance - read through the description in the comments and review the example.

I'd love to get your feedback.

We've been playing around with the BEM syntax since late 2012, and we arrived at the following naming convention:

.componentName {...}
.componentName_Element {...}
.componentName_Element.componentName_Element--modifier {...}

• camelCase is used for names that a single word can't depict (ex: displaySwitcher)
• A single underscore is used to separate Blocks and Elements (Perhaps we'll get back to __ if we realize that some coders in our team use the _ wrongfully, but for now _ seems enough)
• We separate modifiers with two dashes to make it stick out and make its role obvious. Also text editors will usually stop the selection on the hyphen when double-clicking, so it makes sense to use it there and not in any other separator.
• We prefix all modifier classes with the non modified class to ensure the specificity will always be a bit higher, as we've had issues with that (due to modernizr classes iirc).

This convention along with the use of Sass and a semantical file system organisation has boosted our productivity and made maintenance a breathe.

I love the BEM approach in cases where there's a strict hierarchy, but I find it very verbose when working with more global components.

For example:

.header {}
.article .header {}

is much more flexible and reusable than:

.article__header {}

which is very specific to that block.

I use BEM mainly for widgets and cases where I know I really need the namespace, but doing everything the BEM way kind of defeats the Cascading part of CSS in my opinion.

I totally love the states and js hooks though, I think that's great practice as it instantly shows what the component is for.

Let's say I have a menu and within this menu I have the list of items. What's the correct naming then?

Menu and menu list should be:

.menu {}
.menu--list {}

But what about the items? Should be .menu--list--item or .menu__list--item?

rafaelrinaldi

.menu {}
.menu--list {}

The item naming would then fall like this if you needed to modify the menu item

.menu__item--list {}

You could call the modifier what you wanted but it makes sense to keep the modifier name the same as the parent modifier. Then you can couple the new menu item modifier with the parent modifier.

Gotcha! Thanks @mykz.

Zeokat interesting code, i have to adjust it a little. Thanks.

Another variant of writing css-rules is using AMCSS.
For example: http://codepen.io/viT-1/pen/VjXybd

Hi nicolas,

What is the different between a Template Components and theming Component? I can see some of your classes start with a t and some don't. I just want to know the reason and the logic please. Thanks

http://tailwindcss.com + http://getbem.com