What you think about LESS CSS?

HTML & CSS
61

Using Sencha Touch with SASS I was able to get 50% of the design complete I am working to achieve for a project, with 10 lines of CSS/SASS. I think that is pretty nifty. There is no way in hell that would be possible without mixins and variables – no way.

In regards to being DRY it is dry – you don’t have to repeat yourself – the computer does. Which that is going to happen anyway with the nature of CSS, repeating colors, etc. I mean… it all has to compile down to plane-jane CSS in the end anyway, no getting away from that.

Than again I am referring to SASS with compass (compile SASS files to plane-jane CSS). So you can pretty much write all your SASS than compile down to a compessed plain-jane CSS file and link to that. Which si pretty nice considering SASS is merely use as a tool to aid development.

62

Well, no matter how you organize your CSS sheet, you are going to run into situations where common elements share the same values within different classes and IDs. When that happens, groupings will occur naturally. So you could do NO division with commenting, which makes the concept of a variable even more useful because you end up with a giant SEA of CSS code without any maintainable breakdown, or you can divide the sections logically, with the same situation. The idea is that you have ONE hexidecimal in ONE place, and you only have to change it once no matter how many elements share the same color all throughout the stylesheet. That’s definitely a positive for me.

63

Man… I must say after diving into SASS loops, nesting, variables and mixins I gotta say it is pretty cool and nice to actually be able to represent hierarchy. Once you get it, which doesn’t take to long it heavily improves efficiency and readability for me anyways. It is pretty nice to be able to write 3 lines of SASS to position a spite of 20 frames… just saying.

64

This problem is no different in my mind than people learning jQuery, prototype or other JS framework without first coming to terms with what JS itself. It’s going to happen - people are going to use chainsaws when scapels are required. But that isn’t a reason not to make the chainsaw.

My apologies for being overly harsh in my language up thread.

DRY (Acronym Don’t Repeat Yourself for the designers wondering what we’re babbling about) isn’t about preventing the computer from repeating itself. It’s about you repeating yourself. The computer can repeat itself all it wants.

You’re slightly missing the point Jason by taking the acronym too literally. DRY isn’t about preventing literal repetition of code. It’s about preventing redundant statements about application state, and only defining methods of operation once. Using your own example - the first method, a loop, is what most programmers would write when drafting out the code the first time. When time comes to optimize the second method might get used.

The principle of DRY states the method should be defined only once so that changing once is all that is necessary. Same for application state - the programmer defines it once so that it is changed only once.

Which one’s more efficient, uses less code, and is easier to perform mass edits with? Only if you’re a total {expletive about one’s intelligence omitted} redeclaring the same values over again instead of adding them to like targets would any of this ‘variables in CSS’ nonsense actually be useful. You want to have multiple elements sharing the same value you can edit in one place – DECLARE THEM TOGETHER!!! DUH!?!

Counter example.



@schoolDark: #009;
@schoolLight: #fff;

section {
  color: @schoolDark;
  background: @schoolLight;
}

header {
  color: @schoolLight;
  background: @schoolDark;
}

While busy calling designers dumb you are forgetting context switching. Most good designs only really use 2 to 4 colors, but the roles of those colors will change by region and may get swapped. University of Kentucky blue is #009 I think, but say I’m wrong and it’s #00A; Without a variable on a site I’d have to use search replace to change this in all the contexts that it was used. A full design will swap these out to box borders and other color elements as well. CSS, even with cascading, cannot address this situation. It has no way of knowing that the color of one element, the border of another and the background of a third should match.

Less’ output code can be very repetitive. Who cares? DRY isn’t about the state of the final CSS the less compiler shoots out to the browser. Your assembly code example itself is ridiculous because modern compilers will often do what you suggest on their own anyway, as well as other optimization that might not even occur to a human programmer, even one as smart as you.

Though admittedly, I see wasteful CSS with people redeclaring the same things over and over again for no good reason all the time – goes with that nobody seems to bother realizing not every element needs a DIV around it, class on it… much less that presentational classes are zero improvement over just writing HTML 3.2 without CSS… which is why we still see dumbass coding like: class=“red bigfont centered clearfix” – Net improvement ZERO.

Even in your own “dumb ass” example, the designer has the ability to determine which shade of red and size of font, so it isn’t an entire loss. Sometimes in your arrogance you lose sight of things like that. This said, class chaining like this is what mixins in less are attempting to address.

Misuse can and will occur. Human beings aren’t perfect. You cannot design a tool smart enough to prevent its misuse. And it follow that misuse shouldn’t usually be the first criteria by which a tool is judged. Unlike you though I give my fellow human beings credit for trying instead of constantly being demeaning (though I lapse on occasion).

65

See, I would find that confusing in a stylesheet because you aren’t saying WHAT you’re applying the color to – it’s like recursive constant in Prolog… it ends up being so much effort to backtrace (or in this case forward trace) it offsets the advantage of setting it in just one place.

You’d end up like being back in the days of BASIC programmers using cross-referencing software to build a var list… oh wait, it’s called Firebug/Dragonfly :smiley:

(which I still say if you need to use FB/DF on your own code, there’s something horrendously wrong with said code)

66

Well I can’t really say I’m much of a programmer (yet). I’m a graphic design major, but I’ve been learning and using html and css for a few months. Honestly oddz, your opening thread is not confusing to me at all. I understand what you mean by less code, but whether or not you decide to use less or more really depends on the circumstance. (At least as far as I know, but feel free to counter my comment if you have good reasoning to the contrary.)

67

Fair enough. The only reason I even came back to this thread is that I’m working on a Sencha Touch application. Had I not been introduced to Sencha Touch I would probably have never gave this stuff a second thought. None the less, I think there is much to gain from many of concepts in [url=http://lesscss.org/]LESS and [url=http://sass-lang.com/]SASS having now had used them during a real project. I think SASS is a little more mature than LESS though considering it has [url=http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#id11]loops and some other goodies which are not present in LESS. By far my favorite thing is rule [url=http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#nested_rules]nesting considering it makes the CSS more readable when done properly. At least in terms of the normal practices to mimic rule nesting. I’m not sure if something like [url=http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#nested_rules]compass exists for LESS but it is essentially a command line tool for compiling SASS to plain-jane CSS for deployment. One of the biggest problems I had with this all initially was using JavaScript, which completely sucks and compass eliminates that entirely. Not to mention compass provides a hosts of extra mixins to achieving design goals. I haven’t really used many of those, but one the less they are there if you have compass with SASS.

68

The only reason I even came back to this thread is that I’m working on a Sencha Touch application. Had I not been introduced to Sencha Touch I would probably have never gave this stuff a second thought. None the less, I think there is much to gain from many of concepts in LESS and SASS having now had used them during a real project.

This is a good point… what thing about Sencha Touch made SASS helpful in your work?

69

You aren’t that stupid so stop pretending to be. If you truly are that stupid then you fooled the Hell out of me.

(which I still say if you need to use FB/DF on your own code, there’s something horrendously wrong with said code)

And yet more trolling. If you don’t want to use those tools, fine. Go for it sparky, spend 2 hours figuring out something those tools can make apparent in 2 minutes – and if you claim that never happens in your code then I say you’re lying through your teeth. That or you don’t have any experience with javascript files longer than 20 lines.

70

Stupid, no… how I percieve things is just different. Remember, I’m the guy who finds color syntax highlighting HARDER to read (I find having the colors all over the place make my eyes refuse to focus on the text), the common use of extra spaces on elements even HARDER to read (I’m not punctuation blind so I try to assume each section spaced apart is a SECTION, not a single statement), and find tabbed editing to be a colossal step BACKWARDS in functionality (especially if the editor doesn’t let you drag windows out of the tabs).

I do use those tools – when cleaning up other people’s messes… they are great tools for collaboration when the person you’re dealing with has little to no common sense much less organizational skills. You know, the type of people who saw nothing wrong with transitional, and are flocking to HTML 5 as if it offers anything USEFUL.

Though this:

Has me scratching my head a bit – I mean the breakpoint and code tracking tools are useful enough… but I don’t really think of Firebug or Dragonfly as tools for working with Javascript… I generally find the error consoles much more informative (Opera user, go figure), I generally have my logic flow worked out before I lay down code… They’re primary use is supposed to be for HTML/CSS debugging… which if you bother to use semantic names on elements, don’t try to declare widths the same time as padding/border, don’t waste your time declaring widths on EVERYTHING or waste time doing APO on everything and SHOCK let flow do it’s job… Much less actually practice semantic markup and separation of presentation from content… sectional inheritance to prevent specificity issues…

NOT really sure what purpose either tool would serve when working with my own code.

Generally speaking, I don’t see those types of issues – Though I do often laugh at people struggling to make nonsensical “non-viable for web deployment” crap vomited up by photoshop junkies who know jack about things like accessibility, sustainability, maintainability, or even the concept of hosting costs and practical bandwidth loads… Probably why most of the time I can take layouts people have “struggled with for weeks” and spit it out in an hour or two… typically in half the markup.

Which I think my posting record here in the CSS area can show in action.

Though it could just be that I’ve been writing code for three decades – So I have a little different a viewpoint and get a bit tired of seeing people making the same mistakes and bad choices over and over again… Stuff we learned our lessons on ages ago but people keep bringing back… either out of ignorance or because somebody that’s a “name” in the industry said so.

It’s like chiclet keyboards – they sucked on the Aquarius, they sucked on the Trash 80 Coco, they sucked on the MSX, they sucked on the Sinclair Spectrum, the worst keyboard of all time was the one for the PC Jr… but slap an Apple logo and a two dollar stamped aluminum shell around it, and it’s “trendy” enough for people to ignore that it still sucks. Hell, people will still even pay unicomp scale prices for them when it’s unlikely they cost more than five bucks to manufacture.

(and before some “AAH, that’s off topic” putz get their panties in a wad… that is a literary device called a “simile”)

What’s old is new, and that’s not always a good thing. You can call it “boot cut”, it’s still a bell-bottom.

Though to drag myself back on topic, I think a lot of those tools would be a lot less needed if people bothered having code targets – a limit on how big a page is allowed to be. I still practice 70k ideal / 140k max – that’s HTML + CSS + SCRIPTS + THEME images. (I don’t count content images towards that total). If you can’t fit a normal website into those limits, you’re probably making an annoying, slow crap websites.

To the same end there’s the code to content ratio – how much HTML do you have for the content? If it’s more than a 2:1 ratio when you have more than 5k of plaintext, there’s probably something disastrously wrong with how the page is written. There’s CSS – if you need more than 48k of CSS there’s probably something horrendously wrong/inconsistent/needlessly convoluted with how you applied your style. Then of course there’s these idiotic scripting libraries where the library ALONE served COMPRESSED sucks down half my target; where people use a 100k library compressed to 30k to write a 30k script to do what I usually do in 4 to 6k without jquery, mootools or any of the rest of that nonsense. (Or it’s animated nonsense that is more annoyance than help when it comes to the page being useful, informative, or would even reach the point of me allowing to load entirely)

See why Mr. “Don’t use e-mail clients, use webmail” of the past decade is suddenly switching back to using M2 because of all the annoying, broken, painful to use ajax for nothing BS webmail is being bloated down with… making hotmail, yahoo mail, and gmail effectively useless by comparison. Getting sad when they make Squirrelmail look good. Even more sad when the suits were sold on that scripting as “saving bandwidth” when it in fact typically doubles the traffic load. The joke we used to make about flash applies to 90% of the javascript used on websites these days – there’s a reason it’s called “flash” and not “substance”.

71

In response to Oddz last post:

Interesting. I’d like to learn more about web design and development. I’ll admit you seem to have your reasons and know more about them than I do. You should though since you’ve been doing it longer than I have.

72
Off Topic:

It’s like chiclet keyboards – they sucked on the Aquarius, they sucked on the Trash 80 Coco, they sucked on the MSX, they sucked on the Sinclair Spectrum, the worst keyboard of all time was the one for the PC Jr… but slap an Apple logo and a two dollar stamped aluminum shell around it, and it’s “trendy” enough for people to ignore that it still sucks. Hell, people will still even pay unicomp scale prices for them when it’s unlikely they cost more than five bucks to manufacture.

oh gawd, I was looking for a new laptop and the only one I could find that didn’t have chicklets was the Lenovo Stinkpads… and the only one that would’ve run Linux was slow and heavy and expensive. (can’t run linux on a lot of newer laptops nowadays because they’ll have an Intel chip and then an Nvidia graphics card with something called Optimus, which switches between the graphics card and the Intel processor for more power savings etc… Does. Not. Work. In. Non-Windows. Arg. You’re either stuck with just the basic Intel if it’s changeable in the BIOS, or you get no graphics whatsoever. Nvidia has zero plans to remedy this.)

73

Even more off topic:

(1) I didn’t know that about Linux and laptops - thanks for the warning.

(2) What on earth is a chicklet keyboard?

74

It’s the Poes’s meow version of a chiclet http://en.wikipedia.org/wiki/Chiclet_keyboard the cat’s paws like breaking them and stuff so she needs a rugged keyboard.

75
Off Topic:

[url=http://www.cutcodedown.com/cocoProject/images/cocoKeyboards.jpg]
Click for Larger

Chiclet is the one on top… it refers to the keys looking like the candy… Top is from an original Coco, bottom is from a Coco 2.

http://www.digibarn.com/collections/devices/pcjr-chicklet-keyboard/Image09.jpg
That’s the PC Jr. one, usually comes up as the worst piece of computer hardware ever developed.

… and it is a good comparison in terms of things that we should know better by now, but always comes back because it’s cheaper to make. See why most of the public suffers by on what were once called “melted” keys (what today is a ‘low profile’ or laptop style keyboard) or rubber domes. You see the same thing with HTML/CSS/Scripting and web development as a whole – the same stuff we learned pre-dotcom bust being repeated by people either too young to know it or with too short term a memory to recognize it…

See “advertising can pay for everything”, “popups don’t annoy users” and “who cares about accessibility”. What’s next? “Does it work in IE, who cares about the rest”

Oh wait, we have that last one with FF/Chrome instead of IE… IE? Who still uses that? Opera, what’s Opera?!? – which is when the “percenters” come out of the woodwork not realizing that saying “oh this group is only xxx% and this group is only xxx% and this group is only xxx%” until there’s no percent of audience left.

Off Topic:

Oh, and @sp, I’d kill for a laptop with full travel cherry switches or even better, buckling springs. Someday I’m gonna build my own laptop starting with a Model M and just bolting crap onto it.

76

Someday I’m gonna build my own laptop starting with a Model M and just bolting crap onto it.

Make it wood and brass and steampunky and I’m in!

Though if it were practical I’d really like a regular laptop with that Model M style. Arg, my keys are squeaking as i pound them now :frowning:

77

Yes you are. You are applying #009 to the variable “schoolDark.” Then you just look at where schoolDark occurs, and you know that’s #009. What’s so hard about that? I don’t get what is so hard about that.

78

I think he might have meant that, the example shows main structural boxes (section, header) getting styles applied, whereas if you were setting those styles for specific reasons you might set them to tokens with better names (telling code readers “why” something is those colours, because the content is… “whatever”).

Since I tend to avoid setting things like font sizes and families on containers (because I size stuff in ems), I find I also don’t tend to set colours on containers either. Though obviously it’s less code if everyone in a particular container has the same for-and background colours to just set it on the container.

79

I’m not sure I understand that.

80

That’s a good deal of it… but you know my philosophy on that when others may not… To me the application of any style or appearance starts with the question “why is it getting style” or “what is the element”… and if you can’t come up with a good explanation of how/why/what, it shouldn’t get that.

More so though it’s that it’s another layer of abstraction in something that already has layers of abstraction – along with dividing up things by ‘section’ instead of by ‘what it is’ leads to confusing code that… well…

Might explain why other people find tools like Firebug or Dragonfly so useful when working with their code when I don’t on my own… since it basically acts like the old cross-reference utilities for ROM Basic from three decades ago – where you were restricted to single letter variable names making keeping track of anything impossible… As such coders HAD to rely on those types of tools.

Today we can actually put meaningful names on things, so there’s no reason to add more code and another layer of abstraction to it… It really seems like today people WANT to just keep tossing more and more libraries and layers of abstraction atop things just making it more and more needlessly complicated, bloated and slow… and I just don’t get it.

It’s not like we’re talking a compiled language where DEFINE’s are folded in when you build your binary… to put it in ASM terms, the difference between STATIC and DB… in an interpreted language or parsed document they’re effectively all DB.