Looking back at Strapless

It's been over two years since I finished it, but Strapless, the Less library for providing a base of HTML element support, colors and contrast, still ends up in my projects regularly.

Adam, who worked on it with me, described it as "making colored boxes." But no! We were automating the making of colored boxes.

I've thought about forking it but I'm not sure where I would take it. It's a bit of a monolith in terms of CSS libraries. I've thought to atomize it but then the results just seem so... lonely. Turbo-powered color schemes is the best example of this.

Less's lazy loading just makes it too fun and easy to use something like Strapless, which pollutes the global Less namespace with tons and tons of variables. It just defines everything and then you have everything at your fingertips.

It doesn't play well with others. But you also don't need to use anything else.

None of the variables are namespaced, either, relying on the simplest possible variable names. It's so easy to namespace after the fact in Less, though. Why not just leave it for later, if it even happens?

Strapless gets downright abusive of this, even using variable names in lists, further baking them into the code.

But it's easy to generate theme upon theme within the same stylesheet by using namespacing, as the demo site shows. So why not do that? And then do it some more?

This will make some programmers nervous. They'll probably end up using Sass. Some of the especially lost will end up with some CSS-in-JS solution. When they perfect their mechanisms of component control, they'll come to realize they control nothing. Their designs, pixel-perfect, will lack the flexibility needed to play with anything else. Each component will look like Winamp, perfectly executed within its own world but sticking out from its environment.

Ironically, despite being monolithic, Strapless avoids this by providing a laissez-faire design environment which flavors components instead of bowling them over. I called what I did with Strapless "relative color design" but it really should have been more like "relative everything design." Where not just colors are stripped of their semantic meaning, but everything is. We shouldn't be defining a component's padding, but defining whether they have padding. The padding should come from the environment. Otherwise everything has different padding and then, what's the point? Why would we define these things so specifically within a component, and especially then why do it in JS?

Anything I work on now uses relative color design, and more and more this relative everything design. I've moved away from Strapless-style generic palette names to strictly semantic palette names, as in TPCS. I've got a great set of mixins for working within a beautiful palette while carving as much semantic meaning out of the color space as possible. And I'm still just polluting the heck out of the global variable space. Everything bubbles up in Less! If you define it, and then use it, it will end up as a global variable.

A new Strapless?

If I do fork it (or create a "spiritual successor") into some new project, I think it will be a lot less ambitious in many ways.

Here's a dream list of features:

Ultimately, I think I'll wait a while and just stick with using Strapless. The CSS world feels like it's in limbo. It also feels like Less is just what it needs. But who knows, a year from now I might be stitching my CSS together with some weird JS package... weirder than Less, I mean.