3

In Nicolas Gallaghers' write up about HTML semantics, he outlines a method of structuring html and css in a modular way (influenced by the BEM architecture). He gives an example, which I don’t completely understand:

/* Utility */
.u-utilityName {}

/* Component */
.ComponentName {}

/* Component modifier */
.ComponentName--modifierName {}

/* Component descendant */
.ComponentName-descendant {}

/* Component descendant modifier */
.ComponentName-descendant--modifierName {}

/* Component state (scoped to component) */
.ComponentName.is-stateOfComponent {}
  • First, what I don’t understand is: what is the difference between a utility and a component?
  • And where does the difference in notation between these two come from (the utility classname is prefixed with a “u-”)?
  • Last; what is the difference between a state and a modifier (they both have separate notation)?

He does not explain this in depth in his article, and I would still like to understand. So I hope someone can answer this.

  • Or is a utility something that is more related to java app design than webdesign (as in regular html/css website dev)? –  Mar 20 '14 at 09:54

2 Answers2

2

The utility classes are essentially presentational classes in that modify one presentational aspect of an element. These are useful because they are broadly applicable. You may apply a utility class to a variety of components. Since it isn't specific to a particular component, it isn't necessary to create it as a component modifier.

State classes are a little different from modifier classes in that state is often added, changed, or removed through JavaScript. So the state classes are just a convention that helps keep straight what classes need to be shared between your stylesheet and scripts. You wouldn't normally want to access your modifier classes in your scripts because this starts to unnecessarily couple them to a specific presentation or component.

Jack
  • 9,448
  • 3
  • 29
  • 33
  • Thank you! Would you agree with my interpretation of the difference between a component state and a utility (even though it is a little vague), am I on the right track? Or would defining a state outside of the scope of its component also make sense? (in which case the difference between a utility and a state would be smaller imo) –  Mar 21 '14 at 13:36
  • 1
    I would say a state wouldn't convey any particular style/presentation. Say, if you had several components that have an 'is-active' state, each would probably set it's own styles for that. The utility classes would have a consistent meaning anywhere they were used. Since state classes doesn't carry a specific presentational meaning, you maintain a better separation of concerns when changing state classes through script than you would presentational classes. – Jack Mar 21 '14 at 13:45
  • So if I understand correct; a state class doesn't convey presentational meaning through its name in the HTML, but it can still have presentational rules attached to it via css (as in a greyed out disabled button for .is-Disabled), right? Like the difference between .u-paintedRed and .is-completelyDestroyed? –  Mar 21 '14 at 13:54
  • 1
    That's my understanding. – Jack Mar 21 '14 at 13:56
  • One last question; should you always define a state while scoped to its parent (because in Nicolas' example it is defined that way, but not explained why)? –  Mar 21 '14 at 13:58
  • Wait, I found some documentation explaining that states should never be defined directly [here](https://github.com/suitcss/suit/blob/master/doc/naming-conventions.md). Thanks for helping, much appreciated! –  Mar 21 '14 at 14:10
0

Ok, so I've looked at his sourcecode, and it looks like the utilities are classes that "do" something, instead of "being" something. So a utility would be something like ".u-textAlignLeft", and a component something like ".EnormousHeader".

This however raises a new question: what is the exact difference between a component state and a utility? If I had to define it it would be that a utility "does" something (.u-textLeft) and a state "does" something that only makes sense in the scope of its component (.is-Disabled for example).

Hope this rambling is of use to anyone!