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.
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:
- A layout engine where the user could easily define elements while the correct code would be generated by mixins.
- Layout elements would be abstracted more completely.
- Responsive typography that didn't use calc() or vw anywhere.
- Less conventions, but wider conventions. For example, variable names by default for every CSS attribute.
- More typography options.
- Actually, truly, on-the-dot accurate color contrasting. Strapless is very close but the results are always just a bit off. I could never quite figure out where it happened— I seemed to be faithfully implementing the standard. If I did a new library, I'd rectify this for on-the-nose AA-level and AAA-level contrast.
- I would maybe split out the "elements" portion and the "variables" portion. The people who want the elements want just the elements (and maybe an online builder of sorts) while the people who want the variables usually want just the variables, unless they're greenfielding a new project.
- In general, I'd just make the thing less prescriptive.
- Each element would support a variety of standard settings, such as having borders, padding, background, etc. Strapless always had room for this, with each element having its own dedicated file, but we never included it. At least not in an official, robust way.
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.