LessEfficient CSS output

[RyanR]

I've noticed when LESS compiles the CSS it lengthens colors, for
example #fff becomes #ffffff which seems silly to me and increases the
file size on a large style sheet.

But more annoyingly it will convert the following:

#div h1, #div h2, #div h3 {…}

into:

#div h1 {…}
#div h2 {…}
#div h3 {…}

Which significantly decreases the compiled CSS readability and
efficiency as well as the file size.

Is there a way around this, have a missed something?

[RyanR]

Another example from a real world situation:

#brochure-download h4, #hotel-info h4 {
background: @brandColourSecondary;
border-top: 4px solid #eaeaea;
}

Becomes:

#brochure-download h4 {
background: #cd9a3b;
border-top: 4px solid #eaeaea;
}

#hotel-info h4 {
background: #cd9a3b;
border-top: 4px solid #eaeaea;
}

This doesn't make sense at all to me.

Thanks.

[Ryan Roberts]

On 15 February 2010 17:27, Colin Shea <co...@evaryont.me> wrote:

--
You received this message because you are subscribed to the Google Groups "LESS - Leaner CSS" group.
To post to this group, send email to les...@googlegroups.com.
To unsubscribe from this group, send email to lesscss+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lesscss?hl=en.

From my experiences, the compiled CSS isn't supposed to be beautiful - that's why you're using LESS, no? Also, unless you have a single massive style sheet (which is a bad idea IMO) or you are really hurting / paranoid about file sizes, the expanded version of the CSS is not noticable.

If you really want to reduce the size of the style sheet, try using a CSS minifier. There were links in a previous thread about this very thing. Search for it in the group page.

I think you're maybe misunderstanding my point. I'm not bothered about minifying or compressing the CSS, it's not about reducing the size. What bothers me is the compiler takes perfectly valid, efficient CSS and bloats it out into significantly more code than is necessary.

I use LESS to make writing CSS more efficient, I don't mind if it's not "beautiful" but at some point it's highly likely someone without LESS is going to be maintaining the CSS (maybe even me!). I don't wish to give them significantly more code to wade through and update for absolutely no reason.

[Doug Avery]

Ryan, it looks like LESS has mixed behavior on this - selectors that
use element names do fine:

INPUT:
html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p,
blockquote {

OUTPUT:
html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p,
blockquote {

...but complex selectors have difficulties:

INPUT:
. #campusnav li, #campusnav a {

OUTPUT:
#campusnav li { float: left; }
#campusnav a { float: left; }

I agree with Ryan 100% about this being a big issue - it works against
the CSS best practice of combining redundant rules into multiple
selectors. In my stylesheets, LESS converts a 20+ selector declaration
with 5 properties (6 lines) into 20 declarations and 120 lines - not
so good.

It looks like the issue is selectors with more than one object. "body,
div#content, .sidebar" works fine, but "body, #content .sidebar"
splits into two declarations. Something about the process of
determining hierarchy seems to be causing this.

[Stephen Lovell]

I'm also confirming my agreement with the fact that a resolution in
this matter is greatly needed.

To me the ideology behind LESS is less, this just undermines reasons
to us LESS in the first place.

[Rizky Syazuli]

agree on that.. someone should fix this..
fyi, this is my first time using LESS. i really love the whole idea.
but i must say this is not the best first impression.

in my case it converts this:

input[type=text], input[type=password],
input.text, textarea, select, div.select {

...

:focus {
...
}
}

into this:

input[type=text] { ... }
input[type=text]:focus { .. }

input[type=password] { .. }
input[type=password]:focus { .. }

input.text { .. }
input.text:focus { .. }

textarea { ... }
textarea:focus { ... }

select { .. }
select:focus { ... }

div.select { ... }
div.select:focus { ... }

On Feb 17, 10:59 am, Stephen Lovell <stephen.ldesi...@gmail.com>
wrote:

[Pier Paolo Ramon]

As others says, I believe this behaviour is not such a big issue. You
can use minifiers after the compile has been.
As far as I can see, LESS just makes you do less. Because multiple
selectors have often semantic meaning, it's important that in
your .less (therefore the source) files there're semantics. Compiled
files have not this need.

I find LESS awesome, and perfectly coherent. If in the future it will
include a minifier, thats good of course. But that's just for time
reduction.

______________________________
Pier Paolo Ramon, www.memome.it
Projectmoon srl, projectmoon.pjoon.com

[Pat Hawks]

I think a minifier is beyond the scope of LESS, but it may be a good
idea to have an option to specify an external minifier to run on the
compiled LESS CSS.

[RyanR]

Sorry a minifier is not the solution, and no offense intended but
you've
completely missed the point of the problem.

LESS is significantly bloating out clean CSS for no reason at all,
this
leads to more code and more for others without LESS to maintain in
the future... for no good reason.

Thanks,
Ryan

[Ryan Heneise]

I'm just getting into LESS, so I'm not really clear on what the rules
are supposed to be regarding the combining of selectors. It seems that
it does combine selectors for non-named HTML entities, but not for
nested entities or entities named by classes or ids, as the following
example shows:

h1, h2, div#foo h1, div#foo h2{background: green;}
div h1, div h2 {background: red;}
p, div, code{background: blue;}

produces:

h1, h2 { background: green; }
div#foo h1 { background: green; }
div#foo h2 { background: green; }
div h1 { background: red; }
div h2 { background: red; }
p, div, code { background: blue; }

[buymeasoda]

I agree.

4 minutes into using LESS for the first time on a real project, I see
my hand crafted CSS that's written as:

#news h3, #contact h3, #bio h3, #elsewhere h3 {
font-family: Georgia, Times, serif;
font-size: 16px;
/* etc */
}

Turned into this by LESS:

#news h3 {
/* duplicated rules */
}

#contact h3 {
/* duplicated rules */
}

#bio h3 {
/* duplicated rules */
}

#elsewhere h3 {
/* duplicated rules */
}

/* etc */

For a project that's tag line is "Leaner CSS", I'm a bit confused by
this. The expansion in the output makes no sense to me. What's the
logic here? And I concur with others "minifiers will fix it" is not an
explanation as to why this is happening.

Is it a limitation of the parser / processor? Something that is going
to be addressed?

Ian

[Ben Schwarz]

Its not a limitation. The "less css" factor comes from WHAT YOU WRITE.
Not what the browser reads. Use a minifier, gzip your static assets.

If you're this concerned about performance, you'd be doing both of
those and a bunch of other things too.

[Randall Hansen]

On Mar 13, 2010, at 3:01 AM, Ben Schwarz wrote:

> Its not a limitation. The "less css" factor comes from WHAT YOU WRITE.
> Not what the browser reads. Use a minifier, gzip your static assets.
>
> If you're this concerned about performance, you'd be doing both of
> those and a bunch of other things too.

The point isn't performance, it's maintainability. Several people in this thread have already said that. We all know we can minify, g-zip, etc our CSS 'til it's squeaky fast.

LESS-generated CSS is hard to maintain. What if a client wants to tweak something themselves after you finish a project? That person will think better of you if the CSS you've delivered is as well-structured as the LESS you started with.

This isn't a deal-breaker for me; I still love LESS and use it often. I don't know enough Ruby to offer a patch.

r

[J0hnsmith]

> The point isn't performance, it's maintainability.  Several people in this thread have already said that.  We all know we can minify, g-zip, etc our CSS 'til it's squeaky fast.
>
> LESS-generated CSS is hard to maintain.  What if a client wants to tweak something themselves after you finish a project?  That person will think better of you if the CSS you've delivered is as well-structured as the LESS you started with.
>
> This isn't a deal-breaker for me; I still love LESS and use it often.  I don't know enough Ruby to offer a patch.
>
> r

I understand the points you (and others are making) entirely, the
actual CSS output by less is far from efficient.

There don't seem to be any tools that can do a decent job (I admit
it's been a looong time since I've looked) of combining css well eg

#foo a {
margin: 1em;
}
#bar a {
margin: 1em;
}

to

#foo a, #bar a {
margin: 1em;
}

For a case as simple as that there probably are tools but there comes
a point when using complex CSS selectors that combining them
inevitably changes the order they're declared in and/or specificity,
so the CSS rules that come out differ to what was originally intended.
I suspect it's for this reason that the developers chose to keep the
output simple but verbose, I'd rather have verbose CSS output that
works than elegant buggy output. I'd still love to see better output
though, but I'm not holding my breath.

I always check in/upload .less files to the same place as the .css so
hopefully if clients want to make changes in the future they find
them, a quick google search should tell them what they're for.

[Jonhoo]

The issue here has nothing to do with merging multiple selectors with
duplicate content into a single selector. That is a complicated
process and I think everyone here understands that.
The problem is that {LESS} takes complex CSS selectors and splits them
into multiple identical definition blocks with each of the different
selectors. It does in fact not even do this consistently. From the
comments above it is clear that it only splits complex selectors where
one or more of the subselectors themselves are more than a single
selector.

This is most definitely a bug, and one that really should be looked at
ASAP.