nesting selectors

I'll start with the easiest part. I've tried to use the nesting pattern a couple of times, but quickly reached the conclusion that it's just not for me. That said, I don't think it's really worth much discussion as I believe it firmly belongs in the category of personal preference. Depending on your preferred formatting style (1 property/line) I can see how this could be useful to some, but I found it greatly reduced readability when writing 1 full selector/line css.

Additionally, the class names I use are pretty much fixed, even across projects, so the chance that I'll be changing them afterwards is incredibly slim. Even then, A simple double click and a couple of quick copy/pastes are hardly worth the mess it creates. I guess I just miss my visualized dom tree. To each his own.

css variables

While css variables are an interesting concept their actual use is quite limited. Most of the variables I used were targeted at widths (column width, site width, floated blocks) which had to be repeated over multiple selectors. A good example of this is the grid structure I've been using (padding on parent, width and negative margin on column). It's easier to play around with the widths of the columns if you only need to adapt one value. This ties is perfectly with my ideal to eliminate as many duplicate and related values as possible, leaving less room for errors.

I also tried to list my base colors as css variables but found it counter-productive in the long run. It's actually quicker to color-pick a certain color than it is to scroll up to look for the correct variable. Sure, using variables would prove efficient if you had to change the specific color for a certain class of object while not affecting other objects with the same color applied to them, but as I'm not a designer myself (I work with psd deliverables) these calls are impossible to make for me, so this benefit is entirely lost. I also doubt if most designer could actually make that call.

I'm still looking for a nice way to format the variables according to their scope. I identified three basic types of variables: the ones that work across the whole css, the ones that work across a selection of components (like the column width of grids) and the ones that remain within the scope of one component. Coming up with a clean way to separate them from regular css is a little difficult though.

mixins

Mixins can prove to be very useful. Their capability to capture all instances of browser-specific css (border-radius) and feed them the correct parameters is quite lovely indeed. Furthermore, classes like .hidden (position:absolute; left:-999em; top:auto;) are now much easier to apply to random elements, also eliminating the need to add them to the html itself. It does save you quite some time.

Also interesting is the option to capture certain styling combinations that form a design element used on multiple objects that don't have any semantic middle ground (meaning they don't have common classes that can be used for styling). Particular box layouts or two different renderings of headings (font-family, text-transform, font-weight, ...) can now be easily captured in one class to use throughout your css when necessary.

There's still the danger of taking mixins too far, but I haven't felt that urge yet myself.

functions and operations

Probably the most powerful addition of less, but also the most dangerous one. There are some interesting cases where operations can be used (float:left - margin-left setup where the left margins equals the width of the float + the width of the gutter), but I've seen more cases where possible abuse lies right behind the corner.

I've found very few use cases for css operations because I'm used to writing css with as few width declarations as possible. I use margins and paddings where possible and rely on block behavior for elements to fill in the available width. Nothing new you say, but when confronted with other people's css you might be surprised how a left padding on the parent is often substituted for a (width - padding) + float right on the child. Giving people access to an option like this is only going to make that worse, ultimately resulting in overstated and messy css rather than letting the css do all the hard work for you.

So while definitely useful for the experienced csser, I'm afraid what will happen to those just starting out with css. I believe they'll feel more at ease using some simple math instead of figuring out how to fix it using proper css, which is definitely not the way to go.

overall conclusion

I didn't have any difficulties finding the benefits of an extra layer like less, but the gain is actually quite small. Many of its use cases should already be covered by writing decent html and css, only a few edge cases will benefit from using a extra layer like less. On the other hand, it requires minimal effort to include the less layer, so while the gain might be minimal, the effort to work with less isn't all that big either.

My main reservation remains though. I'm pretty sure all the current functionality in less (safe the css nesting, which relies on personal preference) is useful for the seasoned csser, but I also believe it's harmful for those who are just starting out using css. When used wisely it's a powerful addition to your tool set, but it still has the power to turn your css into a complete mess.

For now I'll keep on using the less layer, if only to see what else there is to uncover. If anyone could point me to a quality resource of best practice though, that would be greatly appreciated.