I've always considered SASS the only true successor to CSS.
LESS and SCSS are syntactically conservative. I feel they retain the grammatical conventions of CSS (curly braces) as a way to ease the learning curve for conservative developers.
They introduce developers to the powerful features (mixins, variables) of extended CSS. But retain their familiar CSS curly bracket syntax.
Eventually it makes sense for said conservative developers to take the next step and adopt SASS's clean syntax.
There is also another advantage to Less/SCSS, which is that existing CSS files are already compatible, so you can start a gradual migration without effort.
This means for instance that an outside designer, that does not know Sass, can come in and contribute directly to the codebase without his workflow being disrupted and without me having to tutor him in Sass. This is how design works anyway - you start with a bunch of PSDs that get accepted, you transform that into static HTML and CSS (that have to be emailed around and approved), then you start adding dynamic features, you then go back to the designer to fix the design in case the dynamic content doesn't blend well, then you start refactoring the HTML/CSS to be clean and easy to maintain ... but this is only the last step, because the other steps, like getting the design right, are more important.
When you say that Sass should be the true successor to CSS, you're thinking like a programmer. I also wish that Gimp would be the true successor to Photoshop, but that won't happen.
> There is also another advantage to Less/SCSS, which is that existing CSS files are already compatible
Not sure about SCSS, but in my case Less choked on some complex hacks like IE filters. Not arguing about their evilness, but the fact remains—not always you can simply rename .css to .less and gradually start using new features. (In the end I kept CSS as is, with a separate Stylus file with overrides and new styles. SCSS wasn't an option, and I have a feeling it also suffers from these issues.)
I'm assuming you did not mean to come off so sneeringly, but your claims that LESS retains bracing because it's "easier" reads as contempt rather than the recognition that maybe, just maybe, the syntax you call "clean" is what someone else--like, say, me--would call "unreadable and annoying".
Personally, I like bracing, because it is a better visual indicator, for me, of structure. I dislike indent-based blocking (Python, SASS) because I think it looks cluttered; I like brace-based blocking (C, LESS) because they're unambiguous and stand-out 'signposts' for my eyes as I read code. (I'd use SCSS if it wasn't Ruby-based. I like tools I can hack on and working in Ruby is, for me, a miserable experience.)
There are more reasons make that stylistic decision than "it's easier", even if you don't like it and even if, heaven forfend, it's not part of what you consider "the only true successor".
Definitely seconding this, sass is a much better syntax than CSS, it's the difference between coffeescript and javascript, simply much less line noise and very sane defaults.
That said, I'm not sure why haml isn't as popular as sass.
LESS and SCSS are syntactically conservative. I feel they retain the grammatical conventions of CSS (curly braces) as a way to ease the learning curve for conservative developers.
They introduce developers to the powerful features (mixins, variables) of extended CSS. But retain their familiar CSS curly bracket syntax.
Eventually it makes sense for said conservative developers to take the next step and adopt SASS's clean syntax.