SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 85

Hybrid View

  1. #1
    SitePoint Enthusiast AntunTun's Avatar
    Join Date
    Sep 2010
    Posts
    35
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    What you think about LESS CSS?

    Like I said in the title... What you all think about LESS CSS or The dynamic stylesheet language.

    More info on this subject can be found here LESS « The Dynamic Stylesheet language and here The Semantic Grid System: Page Layout For Tomorrow - Smashing Magazine but I would like to hear something from the first hand.

    So, any experiences with this LESS CSS?
    My site is Croatia property

  2. #2
    SitePoint Wizard bronze trophy PicnicTutorials's Avatar
    Join Date
    Dec 2007
    Location
    Carlsbad, California, United States
    Posts
    3,656
    Mentioned
    15 Post(s)
    Tagged
    0 Thread(s)
    Me thinks it's stupid.

  3. #3
    SitePoint Enthusiast AntunTun's Avatar
    Join Date
    Sep 2010
    Posts
    35
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by EricWatson View Post
    Me thinks it's stupid.
    Any arguments?
    My site is Croatia property

  4. #4
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    I've looked into both of them, out of curiosity. I tend to disagree with almost everything that comes out of Stubbornella's mouth for some reason : ) I apparently do CSS in a completely different way from how she does it.

    For the work I do, they (LESS or SASS) would be
    -adding extra work (converting the made-up new syntax to what I really am trying to say, installing stuff on my server)

    -adding Yet Another Layer Where Things Can Go Wrong between me and my rendered page (I hear there's a firebug plugin/patch that lets it help you debug your LESS'd or SASS's CSS, but dunno about the other browsers' dev tools)

    It seems to be one of those things where, programmers are constantly complaining about how much CSS sucks because... because it's not a programming language. So that is one thing LESS/SASS does is let programmers pretend it is a programming language, by adding things like loops, variables, scope, conditions... and lets them avoid some of the syntax of CSS (complicated stuff like... comma-separated values, or vendor prefixes. Darn, that stuff's so hard and takes me so long to type. Oh wait, it doesn't, I have an excellent text editor! Using non-crappy tools really does help).

    It also seems like something a group of developers trying to stay coherent and know/understand what everyone else is doing would use, especially if they are working with lots and lots of crappy HTML. Crappy HTML leads to crappy CSS, and it seems LESS or SASS would help a developer's head not explode trying to write CSS for crappy HTML.

    It kinda reminds me of CoffeeScript, in that you basically learn a whole new syntax... to write Javascript. Instead of writing... Javascript. If your project is big, you can use that same syntax for other languages and whatnot, and it can become a benefit in that situation.

    LESS has the option of sitting on your dev server, and you can write your styles in LESS and then when you're done just have it spit out regular CSS (like what it feeds your browser) so that you don't have to burden users with a steaming pile of Javascript simply to see styles (and you can more easily debug). The other option is to have Ruby installed on your server (which would be perfect if you're already using Ruby to serve your pages and does all your scripting needs) and run SASS back there.

    The second link about CSS grids I think shows my point. I don't write CSS for crappy grid HTML, so I don't need to go install some tool to help me do that. All those arguments about using LESS to me are arguments against using grids, and I don't use grids, because I don't like all those reasons the guy points out.

    But again, if you are some poor guy stuck with using grids because they are the Hot New iThing!, then LESS or SASS may help your head not explode while you try to style them.

  5. #5
    SitePoint Enthusiast AntunTun's Avatar
    Join Date
    Sep 2010
    Posts
    35
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I also got feeling that LESS is made only for grid system layouts and I must admit that I don't use it when I make layouts. It kind of seems too complicated without any really good reason for that.
    My site is Croatia property

  6. #6
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,147
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Heaving read the documentation and being responsible for building medium scale web applications there are many aspects of LESS that look appealing. That said, I would never deploy it without a server-side parser and proper caching because client-side parsing would be an efficiency nightmare.

    I think it is unfair to say it is only used to offset *****y HTML. All concepts shared between LESS and SASS aid in code consolidation, reuse and maintenance regardless of good or bad HTML. For small websites it would probably be an over kill but for web applications deployed multiple times with client-side customization having the tools it provides would improve workflow.

    CSS variables would be nice to have I always have a need for variables. Right now I meet that need by passing CSS files through server-side code, which works but it would be nice to have in CSS itself. That is probably the one thing I wish there was native support, everything else I can probably do without.
    The only code I hate more than my own is everyone else's.

  7. #7
    SitePoint Addict
    Join Date
    Jul 2011
    Posts
    365
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    Heaving read the documentation and being responsible for building medium scale web applications there are many aspects of LESS that look appealing. That said, I would never deploy it without a server-side parser and proper caching because client-side parsing would be an efficiency nightmare.
    What do you think of a tool like Less.app: LESS.app For Mac OS X where you basically write the .less file save it, and it automatically compiles the css directly into your chosen folder and you upload the compiled CSS. Personally, I would never rely on javascript for my CSS to work. I hate the idea of something solving the developer's problem at the expense of the user. Web devs should be solving the user's problems.

    However, if you can upload the straight CSS, you could enjoy the scripting conventions, without worrying about that. I haven't used LESS yet, but I am more than just a little intrigued at the possibility of setting variables, not for the creation of the CSS, but for the maintenance.

    There definitley is something to be said, though, for staying familiar with the standard, because if you get used to LESS, and then have to work in an environment without it, that could become pretty distressing.

  8. #8
    Community Advisor silver trophybronze trophy
    dresden_phoenix's Avatar
    Join Date
    Jun 2008
    Location
    Madison, WI
    Posts
    2,800
    Mentioned
    34 Post(s)
    Tagged
    2 Thread(s)
    Using js to simulate CSS seems self defeating. You could use js to do ALL your styling in a site. This would get kinda complicated quick and would immediately ruin your site if js is off; I suppose I am a purist. Am also a minimalist, add a library just so you can do CSS differently ( read: non standard)? change your class structures so that the js can work?


    I agree with Stommes, it seems LESS was develop as a way to "correct" poor code ( or rather .. poor code planning that was executed as poor code)... It just seems as something that would make more work instead of LESS in the end.

  9. #9
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,147
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by dresden_phoenix
    I agree with Stommes, it seems LESS was develop as a way to "correct" poor code ( or rather .. poor code planning that was executed as poor code)
    I fail to understand the rational behind that.
    The only code I hate more than my own is everyone else's.

  10. #10
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    I think it is unfair to say it is only used to offset *****y HTML.
    It may be unfair. But I have never seen the accompanying HTML look anything close to good.

    Off Topic:


    Then again, my HTML standards are very high, and it seems anything touched by robots (like a CMS) always fails my standards. And maybe that's unfair, because if a site is ginormous, we likely need robots to write and manage it for us. And I have worked on sites who were not products of ginormous CMSes.

    But for example, I write HTML forms, and I like them. I am happy.
    Then a colleague has his back-end build them using something called a "form builder". I don't know what it is, except that it was an English-language program who kept trying to turn my "jaar" into "year" for some reason.

    The code coming out of that form builder was a poor imitation of the excellent HTML I had started with (so, the work of writing the HTML was already done and maybe this is where the problem was, I dunno). This is why I have a poor view of all template systems and all builders. I have yet to see one not rake my code to shreds and then pathetically glue the bloody pieces together and call it "alive".


    That is probably the one thing I wish there was native support, everything else I can probably do without.
    I would like parent selectors, and LESS/SASS kinda can imitate the result in a roundabout way.

    But when the articles do the "don't you hate it having to look up a colour..." thing. Why don't I have that problem? It's like those late-night ads where you see someone pathetically trying to "clean" something, like OJ Simpson trying to fit his hand into a glove: it's theatrical. I watched a man horribly trying to shave, throwing up his hands like "omidog! it's just not possible!"

    and then the product appears. The one that will allow housemoms to clean tiles and men to shave and OJ to fit his hand in a glove. It slices! It dices! It does Windows!

    Again, this isn't the fault of LESS or SASS, but the poor arguments articles use to show why they are better: o noes front-enders just can't easily find and copy colours! (or something)
    Hm, not an issue I have. I recognise most of my colours and I have an excellent text editor that finds things for me and changes them on the fly. Likely someone has written a plugin that will actually even show me the colour right in the editor, if I wasn't so lazy I could go install it.

    Using js to simulate CSS seems self defeating. You could use js to do ALL your styling in a site. This would get kinda complicated quick and would immediately ruin your site if js is off;
    You don't have to do it this way, though.

  11. #11
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,147
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by Stomme poes
    Again, this isn't the fault of LESS or SASS, but the poor arguments articles use to show why they are better: o noes front-enders just can't easily find and copy colours! (or something)
    Hm, not an issue I have. I recognise most of my colours and I have an excellent text editor that finds things for me and changes them on the fly. Likely someone has written a plugin that will actually even show me the colour right in the editor, if I wasn't so lazy I could go install it.

    Here is the situation they are referring to which I can relate.

    We have a single website, that is deployed multiple times with small CSS changes for colors and images. It would be an efficiency nightmare to copy the styles sheets only to change one or two things every time the site is deployed for a new customer. Instead one single code set exists and CSS changes are made by passing the style sheets through the server-side code so that variable replacements can take place. That prevents duplicating the style sheets and ultimately those style sheets becoming out of sync, or worse when a change needs to be made having to go through all the duplicates and update those as well. Obviously this would not be a need with a single site, but when managing multiple sites using the same code et, keeping everything in one place avoiding duplicating the code set for a single customer to make a small change promotes ease of maintaining the software.

    Just to put this in perspective I work for company that owns several newspapers and we have about 3 separate code sets for news, autos and real estate management. There are about 13 individual news papers that deploy these products with slight changes to match their individual branding. So we don't have 36 separate code sets floating around CSS variable replacement is necessary to keep everything together, yet make it possible to slightly customize the deployments. If CSS supported variables there could be a single style sheet to assign server side variables to CSS variables avoiding the need to pass all style sheets through server-side code and output dynamically.
    The only code I hate more than my own is everyone else's.

  12. #12
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    My husband does that in Perl since they kinda have the same thing: multiple pages with mostly the same styles except each is for a different newspaper, so there are small changes that match the paper's house style.

    It might not be exactly true, but for whatever reason Ruby does have this reputation of being slower than other interpreted languages. I wonder if the Perl solution is just so much better for such a situation than something like LESS or SASS?

  13. #13
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,147
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Well the only thing you can really achieve by passing CSS through server-side code is really variables without getting creative and probably quit convoluted. Of course its more efficient then LESS, since LESS needs to actually run parsing where as merely serving a php file with CSS content type does not require any additional server-side parsing. That is always required in some capacity if there is a need to change styles dynamically. The only other alternatives are inline (which sucks), embedded (which sucks) and JavaScript application (which sucks).

    Less functions are pretty neat though if you think about the idea of decoupling implementation from interface especially in terms of CSS3. While it may not be that big of a deal to repeat 5+ lines of CSS to support many CSS3 properties in all capable browsers, it does quickly become a pain. Even worst is if implementation changes there isn't a single thing to change, you need to go through and update all occurrances of the code. Using less a single function can be created to apply the CSS3 and easily updates once if something changes.
    The only code I hate more than my own is everyone else's.

  14. #14
    Mazel tov! bronze trophy kohoutek's Avatar
    Join Date
    Aug 2004
    Location
    Hamburg, Germany
    Posts
    4,248
    Mentioned
    30 Post(s)
    Tagged
    0 Thread(s)
    I have to agree with Stomme poes. I've tried both and found that they took up more time than going straight to my editor of choice and hand-coding the design right away. It's indeed an extra layer that I neither need nor want. Besides, I'm a control freak, I want to write each line of my code. I memorize things a lot better that way. Such systems take away lots of work for the grey matter, and especially with CSS, that isn't necessarily a good thing. Not for me, anyway. For the same reason, I have problems using pre-made templates like HTML Boilerplate and their kin. It just doesn't feel like a pragmatic choice to me, though it's intended to be just that. Then again, I'm pretty inflexible with changing my ways. I started learning HTML and CSS through coding manually, having any parts auto-inserted by a tool, makes me uneasy.
    Maleika E. A. | Rockatee | Twitter | Dribbble



  15. #15
    Utopia, Inc. silver trophy
    ScallioXTX's Avatar
    Join Date
    Aug 2008
    Location
    The Netherlands
    Posts
    9,069
    Mentioned
    153 Post(s)
    Tagged
    2 Thread(s)
    I've toyed around with PHPLess a while back, and after I'd finally set it up to work with my PHP framework of choice (Yii) correctly I ditched it because I didn't like it after all (why do you always figure that out after hours of testing and implementing).

    Anyway, what I didn't like about it was:

    - My editor (NetBeans) has auto complete for classes and ids when I'm editing HTML. So I can type <div class=" and then hit ctrl+space and it will show me a list of all classes available in all css files in the project. Very handy, especially if you're not entirely sure what name you gave the class; you can just look for it without opening up the CSS file and looking for it there -- this saves me quite some time. But, this doesn't work with LESS files, which sucks.
    (unless they have been compiled --o.e. I've looked at the website after I'd changed the LESS file -- requesting the page parsed the LESS to CSS, but I can switch from HTML to CSS -- or indeed LESS -- a lot without looking at the website once).
    - There was no decent plugin for my editor. There was a plugin, but it didn't retain the color settings I set, so I had to redo that every I restarted my editor. Annoying.
    - Last but not least, it is my opinion that LESS promotes bad CSS code practice by allowing to nest like they do. It's very easy to lose track of how deep you're nesting using their markup, so you can end up (and I did) with 4 levels deep where in pure CSS I would have never done that (my person aim is to go no further than 2, or 3 if I really have to). This was just an abstraction too far where you lose sight of what you're actually doing.

    The one thing I really did like are the variables and how you can use calculations in there. For example with sticky footers there are some values that turn up repeatedly all over the CSS. With less you just define variables footerheight, footerborderheight, footerpadding, etc somewhere, and use that everywhere. When you need to change one of these values you just change the variable and everything will automatically be changed to suit.
    This doesn't weight up against the cons I listed above though (especially because you really don't change the height of a sticky footer all that often ...)
    Rémon - Hosting Advisor

    SitePoint forums will switch to Discourse soon! Make sure you're ready for it!

    Minimal Bookmarks Tree
    My Google Chrome extension: browsing bookmarks made easy

  16. #16
    Under Construction silver trophybronze trophy AussieJohn's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    776
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    If I were to use something like LESS it would be for:
    • mixins Because I get sick of adding:
      Code:
      -webkit-border-radius: 8px;
      -moz-border-radius: 8px;
      border-radius: 8px;
      in 20 (exaggeration!) different places.
    • variables because variables are more DRY than #fe045 in 20 places
    • Math!!!!!! Because all the cool kids are doing it.


    I think the one thing I would probably skip out on for sure is the nesting. As was mentioned before, it could potentially be quite easy to lose where you're at, and since selector specificity is affected, it is something that could potentially prove troublesome.

    Having said all that, I still haven't convinced myself that I should use LESS since there will inevitably be some hassle associated with it. For most things I work on, the hassle/time/pain involved would outweigh the benefits of it.

    I do agree however that if you would start building a big application or framework, that LESS might be worth using. Especially for frameworks where the aim is to have a sort of boilerplate of stuff there that requires some tweaking for your Next Big Thing Project.
    var details = {
    . . web: "afterlight.com.au",
    . . photos: "jvdl.id.au",
    . . psa: "usethelatestversion.com"
    }

  17. #17
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Grid idiocy and an unnecessary framework... Oh yeah, bloody brilliant. RIGHT.

    LESS is just more... more work, something new to learn, and doesn't do anything you couldn't just handle in a more reasonable fashion. It also makes pages harder to maintain as it just adds another step to it. Put this into the same category as other idiocy like jquery, mootools, YUI, etc...

    Then "semantic grid" -- it's not semantic, and it defeats the entire POINT of using CSS in the first place as saying "grid_6" is still saying what it should look like in the CSS -- so when it comes time for "responsive" design you've pretty well shtupped yourself with an enormous schwanzstucker.

    CSS frameworks -- more idiotic than javascript frameworks and that's really saying something... but of course such idiocy is how one ends up with megabyte sized pages to deliver 4k of plaintext -- right Yahoo?

    Of course that the entire site is from someone who has apparently embraced the whole HTML 5 bull is hardly shocking -- given I bet they never once actually wrote a page practicing separation of presentation from content or semantic markup... and just two years ago was probably vomiting up HTML 3.2, slapping a tranny doctype on it and saying "close enough".

    Besides, if you have to shove 34k of javascript (12k after compression) at a page just to have a CSS file be 10% smaller than if you wrote it properly, that's BS no matter how you color it.... Naturally though it tries to hide what a fat bloated mess it is since no tool out there will even tell you exactly how big the .less files actually are... which btw ends up 5k in five files once you deal with all the @import idiocy. Because of course saving a few bytes is so worth it when you quintuple the number of handshakes. RIGHT.

  18. #18
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Actually, let's do a fair comparison... take their simple demo page which consists of the following files:

    The Semantic Grid System | Fixed-width Example = 883 bytes
    http://semantic.gs/examples/fixed/fixed.less = 603 bytes
    http://semantic.gs/css/reset.less = 1062 bytes
    http://semantic.gs/css/grid.less = 861 bytes
    http://semantic.gs/css/demo.less = 438 bytes
    http://semantic.gs/js/less-1.1.3.min.js = 33.9k

    So that's six files in 37.7k -- about 2k of which is what the coder had to write... let's redo it using a RECOMMENDATION doctype, PROPER separation of presentation from content, and normal CSS. Just to make it as fair as possible I'll use XHTML 1.0 with ALL the extra stuff that HTML 5 supposedly "saves you time not having to do" since I'm going to be axing a few elements. I'll also toss in some closing comments:

    Code:
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html
    	xmlns="http://www.w3.org/1999/xhtml"
    	lang="en"
    	xml:lang="en"
    ><head>
    
    <meta
    	http-equiv="Content-Type"
    	content="text/html; charset=utf-8"
    />
    
    <meta
    	http-equiv="Content-Language"
    	content="en"
    />
    
    <link
    	type="text/css"
    	rel="stylesheet"
    	href="screen.css"
    	media="screen,projection,tv"
    />
    
    </head><body>
    
    <div id="pageWrapper">
    	<h1>
    		<a href="http://semantic.gs/">
    			The Semantic Grid System
    		</a>
    	</h1>
    	
    	<div id="content">
    		<h2>Main</h2>
    	<!-- #content --></div>
    	
    	<div id="sidebar">
    		<h2>Sidebar</h2>
    	<!-- #sideBar --></div>
    		
    <!-- #pageWrapper --></div>
    
    </body></html>
    751 bytes, so our markup is certainly smaller... Their demo being a PERFECT example of why I think elements like HEADER are pointless wasteful bloat and HTML 5 so far as markup is concerned is nothing more than "because we could" instead of "because it's better".

    Then identical functioning CSS as a single file. Again to try and give their approach as much advantage as possible, I'll code in some IE5 support... and bother with things they skipped like say... fallback font-families?

    Code:
    /* null margins and padding to give good cross-browser baseline */
    html,body,address,blockquote,div,
    form,fieldset,caption,
    h1,h2,h3,h4,h5,h6,
    hr,ul,li,ol,ul,
    table,tr,td,th,p,img {
    	margin:0;
    	padding:0;
    }
    
    img,fieldset {
    	border:none;
    }
    
    body {
    	text-align:center; /* center #pageWrapper IE 5.x */
    }
    
    #pageWrapper {
    	overflow:hidden; /* wrap floats */
    	width:960px; /* also trips haslayout, so IE is float wrapping */
    	margin:0 auto;
    }
    
    h1 {
    	padding:1em;
    	margin:0 10px 20px;
    	text-align:left;
    	font:normal 200%/120% georgia,times,serif;
    	color:#FFF;
    	background:#000;
    }
    
    h1 a {
    	text-decoration:none;
    	color:#FFF;
    }
    
    h2 {
    	font:normal 150%/120% georgia,times,serif;
    	padding:5.25em 0;
    }
    
    #content,
    #sidebar {
    	float:left;
    	display:inline; /* prevent IE margin bugs */
    	width:220px;
    	color:#666;
    	background:#CCC;
    }
    
    #content {
    	width:700px;
    	margin:0 20px 0 10px;
    }
    Which comes out to 924 bytes. Where's the big savings in effort or code from using that nonsense again? Especially since their example breaks javascript off, their example doesn't work in IE7 or lower due to faulty CSS, etc, etc... When mine works just fine all the way back to IE 5.01

    ... and of course i can *SHOCK* easily make it a fluid layout, something NONE of these idiotic grid systems can even attempt to do... I can send print an entirely different layout since I'm targeting things by what they ARE, NOT what they look like.

    Notice that even if we omit the javascript AND the grid framework AND their reset -- I'm still using less code overall... 1,924 bytes for their html, demo.css and fixed.css combined vs. 1,729 for mine... with mine not needing the additional 34+k of framework bloat. It's honestly why I think the people who come up with these types of systems to make things "easier" have failed to grasp how HTML and CSS even work in the first place! This is why whenever I see things like <div class="center"> I feel like screaming at them "At that point just go back to coding HTML 3.2 as apparently that's all you're good at!"

    Someone needs to explain to the nimrods who come up with these types of garbage exactly what semantic markup IS. It takes giant bronzed monkey cojones to call that grid system of theirs "semantic" -- as if that's what they think it means, they need to do the world a favor, back the devil away from the keyboard, and go take up something a bit simpler like bocce or horseshoes.

  19. #19
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,147
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Actually, let's do a fair comparison... take their simple demo page which consists of the following files:

    The Semantic Grid System | Fixed-width Example = 883 bytes
    http://semantic.gs/examples/fixed/fixed.less = 603 bytes
    http://semantic.gs/css/reset.less = 1062 bytes
    http://semantic.gs/css/grid.less = 861 bytes
    http://semantic.gs/css/demo.less = 438 bytes
    http://semantic.gs/js/less-1.1.3.min.js = 33.9k

    So that's six files in 37.7k -- about 2k of which is what the coder had to write... let's redo it using a RECOMMENDATION doctype, PROPER separation of presentation from content, and normal CSS. Just to make it as fair as possible I'll use XHTML 1.0 with ALL the extra stuff that HTML 5 supposedly "saves you time not having to do" since I'm going to be axing a few elements. I'll also toss in some closing comments:

    Code:
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html
    	xmlns="http://www.w3.org/1999/xhtml"
    	lang="en"
    	xml:lang="en"
    ><head>
    
    <meta
    	http-equiv="Content-Type"
    	content="text/html; charset=utf-8"
    />
    
    <meta
    	http-equiv="Content-Language"
    	content="en"
    />
    
    <link
    	type="text/css"
    	rel="stylesheet"
    	href="screen.css"
    	media="screen,projection,tv"
    />
    
    </head><body>
    
    <div id="pageWrapper">
    	<h1>
    		<a href="http://semantic.gs/">
    			The Semantic Grid System
    		</a>
    	</h1>
    	
    	<div id="content">
    		<h2>Main</h2>
    	<!-- #content --></div>
    	
    	<div id="sidebar">
    		<h2>Sidebar</h2>
    	<!-- #sideBar --></div>
    		
    <!-- #pageWrapper --></div>
    
    </body></html>
    751 bytes, so our markup is certainly smaller... Their demo being a PERFECT example of why I think elements like HEADER are pointless wasteful bloat and HTML 5 so far as markup is concerned is nothing more than "because we could" instead of "because it's better".

    Then identical functioning CSS as a single file. Again to try and give their approach as much advantage as possible, I'll code in some IE5 support... and bother with things they skipped like say... fallback font-families?

    Code:
    /* null margins and padding to give good cross-browser baseline */
    html,body,address,blockquote,div,
    form,fieldset,caption,
    h1,h2,h3,h4,h5,h6,
    hr,ul,li,ol,ul,
    table,tr,td,th,p,img {
    	margin:0;
    	padding:0;
    }
    
    img,fieldset {
    	border:none;
    }
    
    body {
    	text-align:center; /* center #pageWrapper IE 5.x */
    }
    
    #pageWrapper {
    	overflow:hidden; /* wrap floats */
    	width:960px; /* also trips haslayout, so IE is float wrapping */
    	margin:0 auto;
    }
    
    h1 {
    	padding:1em;
    	margin:0 10px 20px;
    	text-align:left;
    	font:normal 200%/120% georgia,times,serif;
    	color:#FFF;
    	background:#000;
    }
    
    h1 a {
    	text-decoration:none;
    	color:#FFF;
    }
    
    h2 {
    	font:normal 150%/120% georgia,times,serif;
    	padding:5.25em 0;
    }
    
    #content,
    #sidebar {
    	float:left;
    	display:inline; /* prevent IE margin bugs */
    	width:220px;
    	color:#666;
    	background:#CCC;
    }
    
    #content {
    	width:700px;
    	margin:0 20px 0 10px;
    }
    Which comes out to 924 bytes. Where's the big savings in effort or code from using that nonsense again? Especially since their example breaks javascript off, their example doesn't work in IE7 or lower due to faulty CSS, etc, etc... When mine works just fine all the way back to IE 5.01

    ... and of course i can *SHOCK* easily make it a fluid layout, something NONE of these idiotic grid systems can even attempt to do... I can send print an entirely different layout since I'm targeting things by what they ARE, NOT what they look like.

    Notice that even if we omit the javascript AND the grid framework AND their reset -- I'm still using less code overall... 1,924 bytes for their html, demo.css and fixed.css combined vs. 1,729 for mine... with mine not needing the additional 34+k of framework bloat. It's honestly why I think the people who come up with these types of systems to make things "easier" have failed to grasp how HTML and CSS even work in the first place! This is why whenever I see things like <div class="center"> I feel like screaming at them "At that point just go back to coding HTML 3.2 as apparently that's all you're good at!"

    Someone needs to explain to the nimrods who come up with these types of garbage exactly what semantic markup IS. It takes giant bronzed monkey cojones to call that grid system of theirs "semantic" -- as if that's what they think it means, they need to do the world a favor, back the devil away from the keyboard, and go take up something a bit simpler like bocce or horseshoes.
    I don't really understand how any of this relates to the discussion at hand. The discussion is not about this grid system and how improperly it uses less its about less itself. LESS is a tool, like any tool it can be used in a good and bad way.
    The only code I hate more than my own is everyone else's.

  20. #20
    Under Construction silver trophybronze trophy AussieJohn's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    776
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    LESS is a tool.
    Oddz nailed it

    Srlsy though, I think all of us agree that even if we would use LESS, that the client side version is a horrible idea. If we get over the fact that a JS implementation for this obviously sucks, there are some niceties to be had.

    Quote Originally Posted by Stomme Poes
    Regular expressions in CSS is definitely tempting.
    Not surprised *you* agree with regular expressions. Agreed though, regex selectors *would* be awesome.


    I see a lot of people saying "Why use variables, why not use search-replace". Would you use text strings that are the same, spread out in your [insert language of choice] applications? Nawwww, you'd create a variable. Why shouldn't we treat CSS the same way?
    If nothing else, the variables and functions (mixins) would be the perfect solution to keep CSS more DRY.

    While I realise CSS is supposed to be *cascading* ... the theory behind defining global properties in place and letting them cascade down works well... until you have large site with lots of selectors. Having 1 style rule that cascades with 30 selectors in it isn't very nice and can make it harder to keep track of what styles are applied to a particular selector. (I know there's always Firebug, but I'm talking about looking in the CSS file directly, after you've written 1000 lines, it might not necessarily be easy or clear what's happening if you have selectors all over the place with different styles being applied. Maybe this is just my way of writing CSS)


    Regards, Devil's Advocate (& lover of variables)
    var details = {
    . . web: "afterlight.com.au",
    . . photos: "jvdl.id.au",
    . . psa: "usethelatestversion.com"
    }

  21. #21
    SitePoint Evangelist
    Join Date
    Jun 2008
    Posts
    455
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Personally, I love it.
    It's perfect for rapid development.
    I've saved so much time when prototyping or just toying with ideas.

    I'm yet to come across a reason not to use it. However, saying that there are a few issues where the likes of filter: progidXImageT.... causes an output error (at least in the JS version it does). I use the PHP lesscss parser.

    Cheers.

  22. #22
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,147
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Yeah… I mean variables are pretty easily replicated by passing the file through server-side code but mixins, functions and nested rules is not. Granted, I have never needed them I would use them had they been apart of CSS from the start. I'm developing a project with Sencha Touch and it uses SASS, for something like that it seems pretty useful. Had Sencha Touch not been built using SASS it would be much more difficult to customize.

    There is a place for this stuff (and no deathshadow the trash is not what I'm referring to). In terms of maintainability I agree. To often than not most people here seem not care about how easy it is to maintain something even if it means fairly small sacrifices. Professionally though maintainability is at the top of my list, considering nothing that I build is ever "complete"… it always gets modified over time. Being able to come back to code and understand what is happening or to easily change something globally with a single key stroke is a big plus for my day to day.
    The only code I hate more than my own is everyone else's.

  23. #23
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I like a lot of the ideas in it, but wish they were in CSS natively. The nesting is one thing that seems like a good idea but actually isn't that useful when you look at it. Variables, mixins, expressions etc I can see being quite useful. Even regular expressions being used in the selectors would be useful as well, with back references being able to be used in the rule as part of an expression or something.

    I don't understand the resistance to change on these things, for the very artificial reason that people don't want CSS to become a 'programming language'. The primary purpose of the language should be to make it useful, not to please some people who don't want to have learn some new concepts. Oh well.

  24. #24
    Utopia, Inc. silver trophy
    ScallioXTX's Avatar
    Join Date
    Aug 2008
    Location
    The Netherlands
    Posts
    9,069
    Mentioned
    153 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Stormrider View Post
    I don't understand the resistance to change on these things, for the very artificial reason that people don't want CSS to become a 'programming language'. The primary purpose of the language should be to make it useful, not to please some people who don't want to have learn some new concepts. Oh well.
    Even more so because it will only be adding stuff and thus be completely backward compatible. If you don't want to use it you're completely free to use

    Code css:
    h1 { 
      font-size: 2em;
    }
    h2 {
      front-size: 1.5em;
    }
    h3 {
      font-size: 1em;
    }

    While I'll be using

    Code css:
    h([1-3]{1}) { 
      font-size: 1em + (3-$1) * 0.5em;
    }

    I can see how that would be confusing to non-programmers though if they ever saw that, especially the regex parts.
    Rémon - Hosting Advisor

    SitePoint forums will switch to Discourse soon! Make sure you're ready for it!

    Minimal Bookmarks Tree
    My Google Chrome extension: browsing bookmarks made easy

  25. #25
    SitePoint Zealot marbly's Avatar
    Join Date
    Nov 2005
    Location
    Croatia
    Posts
    176
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ScallioXTX View Post
    While I'll be using

    Code css:
    h([1-3]{1}) { 
      font-size: 1em + (3-$1) * 0.5em;
    }
    What less implementation are you using? I'm using lessphp through a Drupal module but this doesn't work. Does it only work on .js implementation?

    BTW to stay on topic I learned most of the LESS stuff in two hours, have been applying it since without problems and I'm loving it!

    Variables are something I've always wanted in CSS, but I also absolutely love mixins and other features too. You save more time if you invest a bit in strategy, I guess it helps if you also do the design too so you already have the concept of design elements figured out, so it's easier to decide which mixins to make.

    I see a lot of potential in how to write reusable chunks of code even for different designs, it really speeds thing up.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •