I think it’s helpful to separate questions about naming conventions (u- prefixes) from questions about using classes vs. inlining style rules.

There’s no technical reason why we use u- as our utility prefix. Before I started on this project, we already had a few utility classes—such as u-hide—so it made sense to follow the convention. The convention itself was not a coincidence given that there was an overlap between front-end engineers at Medium and Twitter. Since then we heard from you and a couple of others that u- prefixes conflicted with microformats. However, as far as I know, no existing client supports u- microformats so it’s hard to justify the switch for purely ideological reasons. If this isn’t the case and there’s an ecosystem of clients that support this format, we’ll be happy to revisit this issue.

As for inlining styles, the reason here is convenience: u-borderLighter is much shorter than border: 1px solid #12345 !important. Think of them as constants: they’re shorter, they’re consistent, and they’re all in one place.

Additionally, not all utility classes cover only one rule. For example, u-size80x80 covers both height and width properties.

Finally, we use LESS variables and mixins to make sure we have consistent colors and fonts throughout the website and we auto-generate some utility classes for margins, paddings, and sizing.

Written by

If you point your cart north, when you want to go south, how will you arrive?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store