options for formatting output css / keep the same as input

[mStudios]

I'm using CodeKit and running into the issue that when I compile the .less files (regular, not minified) of which Bryan from Incident57 tells me that these are not CodeKit but Less compiler issues :

1. When compiling it does not keep the less structure but breaks lines after a comma

   • for example ul,ol,li {} are put on 3 lines

2. Linebreaks are not kept

   • for example /blabla/ (new line) /morebla/ compile to /blabla//morebla/

[lukeapage]

yes.. less does not store any whitespace information and purposefully re-formats the output css.

Why are the above issues for you?

[mStudios]

The problem is less of whitespace but that sometimes it removes LINEB REAKS and sometimes it adds it.

1. it ADDS (see point 1 above), i.e. it ads line breaks unnecessarily. EXAMPLE: instead of keeping a 1-line of

article,aside,details,figcaption,figure,footer,header,hgroup,menu,nav,section {display:block;}

it becomes

article,
aside,
details,
figcaption,
figure,
footer,
header,
hgroup,
menu,
nav,
section {
    display:block;
}

2. then it REMOVES line breaks when it should be kept. It does not always do it, as far as I could track, it mainly happens when within one comment there is an @ symbol. Plus, it will then not put the next selector on its own line (see attached image for visuals):

top-left image : how I expect it to be
top-right image : how it computes
bottom image : how the top code is being used / shows in (MacRabbit) Espresso

Point 1) ads a lot of extra lines to the code and point 2) becomes an issue for reading the final output, next to the fact that along the line Espresso no longer shows groups properly and it gets really "messy" to read.

Hope this makes now more sense.

[slightlyfaulty]

I second this, and I think it warrants a bit more priority than a 9-month open issue.

Good formatting of the compiled css is very important when working for a client whom may or may not want to edit it down the line. They are not always comfortable or have the means to edit less and compile it themselves, and the current css formatting just looks hideous.

@mStudios illustrates these issues perfectly. Please reconsider this simple request.

[Soviut]

If the request is so simple why not fork it yourself and do a pull request?

On Saturday, November 16, 2013, Saul Fautley wrote:

I second this, and I think it warrants a bit more priority than a 9-month
open issue.

Good formatting of the compiled css is very important when working for a
client whom may or may not want to edit it down the line. They are not
always comfortable or have the means to edit less and compile it
themselves, and the current css formatting just looks hideous.

@mStudios https://github.com/mStudios illustrates these issues
perfectly. Please reconsider this simple request.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1183#issuecomment-28634650
.

[slightlyfaulty]

I said the request was simple; I said nothing of the implementation... :P

[Soviut]

Sorry, I didn't mean to sound as harsh as it did.

In the mean time, you may want to check out the css-beautifier grunt task https://github.com/sexnothing/grunt-cssbeautifier

It's as easy to integrate into a grunt workflow as cssmin and uglify but it does the opposite and will format your code based on a set of rules you can define.

[slightlyfaulty]

No worries man. Thanks for the tip, I'll check it out.

[lukeapage]

Merging to #2176