CSS -> LESS

[gustavohenke]

Hey,
What about enabling conversion from CSS to LESS also? Would be very cool!

Thanks :)

[bfricka]

I'm definitely interested. I think it makes a lot of sense for people who aren't familiar with LESS to be able write CSS and see what it might look like in LESS.

That being said, it's a much bigger project, and it requires some discussion to define what rules / options should be implemented to produce the LESS. For example, in my experience, creating LESS that is too deeply-nested can make for hard to read / maintain code. I would like to implement a default option that limits nesting depth to 3-4 levels (but could be switched off for infinite nesting recursion, for those who like their code to look like sideways Vs).

Another question: What do we convert to variables? All strings (urls), colors? Or just those that are reused?

Should we try to dynamically create mixins as well based on common combinations of rulesets? It would be an interesting challenge at the very least.

Anyways. I think a simple implementation would be fairly straightforward, but to create something that produces GOOD LESS, would be a much bigger task.

That said, I think it's a worthy task. I love js2coffee as it makes converting JS projects much easier. I think this could potential serve a similar purpose.

Let me know what you think.

[gustavohenke]

I don't think that those complex things should be done for a start.. being able to only nest selectors, for now, is great.

I've created a jQuery UI Bootstrap theme, and, as all Bootstrap related things, I wanted to make a LESS version. Then I discovered your great tool in the less.js repo and thought it would make the CSS -> LESS pass ;)

[scottrippey]

Well, here's a site that does this:
http://css2less.cc/ (https://github.com/thomaspierson/libcss2less)
But I assumed it was client-side, but now I realize it's Ruby. I think a JS implementation is worthy of an attempt!

However, as @brian-frichette said, doing anything more than reverse-nesting would definitely be tricky. And I'm guessing that reverse-nesting is probably the best feature, too.

[gustavohenke]

OMG, I knew this site and it was offline two hours ago when I answered here :O
Thanks anyway, I'll be watching your repo ;) GJ guys.

[bfricka]

Awesome, thanks Scott. Should be easy to port to JS and then refactor as needed. :)

[scottrippey]

Here's a possible way to implement this:
Start by using the LESS parser. That's right, parse the CSS as if it's a LESS file. It's a great parser, and ideally, it's backwards compatible with CSS, so it could parse the entire CSS file into a (shallow) tree.

Once parsed into a tree, I think it would be much more feasible to implement some of these advanced features.

[lukeapage]

@scottrippey I would love it if the less AST supported visiting and did its eval and tocss operations through that.. then you could make a visitor that output less and a visitor that "uneval'd" and you would be there.. lots of work till thats possible though :(

[scottrippey]

@agatronic Yeah, but I like the idea that the individual tree nodes are responsible for the toCSS methods ... decoupling the logic into a visitor would be difficult and would unfortunately obscure the code.
I think that the usefulness of a CSS decompiler is pretty limited -- mostly educational, so it's not too high of a priority IMO.

[lukeapage]

@gustavohenke I came across this too

https://github.com/sellside/dry

[bfricka]

Looks pretty cool. I'll check it out. Thanks

[jonschlinkert]

@brian-frichette and @agatronic fyi the Dry project was moved to https://github.com/assemble/dry

@doowb and I haven't done much more work with Dry because I got distracted creating the spec for Pre and we're working on other stuff related to LESS. But if you guys do find Dry interesting, it might be fun to collaborate on it. (@doowb?)

this comment was made earlier

being able to only nest selectors, for now, is great.

Completely agree, but if you think about it, there is only incremental benefit from nesting when compared with the "transformational" benefit other features, such as mixins and variables.

So in addition to nesting it would be really interesting to start with variables and approach it from the standpoint of what a user would want to know about their styles. Answering the question "how many times does each color appear in my styles?" can give a CSS user all the motivation they need to start using a pre-processor lol. The information could either be presented in the command line, like with a summary of the top 20 colors used, or actually converted to variables which would be output to a file called variables.less like this:

@color1:   #900; /*  120 instances replaced */
@color2:   #000; /*  90 instances replaced */
@color3:   #222; /*  47 instances replaced */

/* and... 75 more colors, 68 of which are probably unnecessary! */
...

I think this approach to "summarizing" values and converting them to variables would be pretty useful for anyone. If we can collaborate on this and start getting some buzz out about it then we can start adding other features upon demand.

Another thought, we played around with giving the user an option to run Twitter Recess first to "normalize" certain styles so that the conversion from CSS to LESS would be more predictable.

I'd tell you to just visit the Dry repo and consider contributing, but I'm not even sure if we pushed up the latest stuff we did or what the state of it is. But I've always found the idea of Dry pretty interesting, so if you have any interest please let @doowb or I know and we'll look at getting things back in motion.

(@brian-frichette I'd like to get in touch about less2css.org. I'm working on some projects for Less.js and @agatronic pointed me to this project as a tool that we should link to - you've done a nice job. We might even be able to leverage this in other ways. Let me know if you are interested in discussing. )

[doowb]

I almost forgot about the dry project. It was one of my first attempts at working with node.js. If anyone wants more information on it, let me know, I'm glad to help where I can. Looks like I'll have to revisit it and update it to the latest grunt build and handle async better, but it shouldn't be too bad.

I think the intent was to be able to add rules and refactors that would get called while the css was parsed. After glancing through the code, it looks like it works like map-reduce, where a rule is the map (figure out what css rules to grab and return their information), and a refactor is the reduce (use the data from the rules to turn into valuable less).

[scottrippey]

@jonschlinkert You've got some good points ... extracting variables is definitely useful, and I didn't think about it as being a way to advertise the benefit of using less.

[jonschlinkert]

@scottrippey I guess my thinking is that there are still a fair number of developers who haven't made the jump to a pre-process for some reason, and stuff like this might make it more obvious what the benefit is. For some reason a lot of write-ups about pre-processors seem to focus on nesting as like the "quintessential, must-have feature" of pre-processors.

[bfricka]

@jonschlinkert @doowb Let's talk this weekend if you've got a minute. I apologize, I have been really tied up lately, but I'd be happy to talk about how we could collaborate.