| SitePoint Sponsor |
Make it wood and brass and steampunky and I'm in!Someday I'm gonna build my own laptop starting with a Model M and just bolting crap onto it.
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
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.Originally Posted by deathshadow60
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.
I'm not sure I understand that.
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.
Forgive me, but honestly this all sounds like Theory, rather than practicality. It sounds like a university discussion of lofty things rather than a real reason why LESS is such a negative in a practical way. Today we can put names on things. Right. Like rather than a number code, we can say "red" or better yet, rather than settling for the ugly default "red" we can say "Company-Color." So any time I see "Company-Color" I know what I am looking at. If I want to change that, I just change it in one place.
Apart from theory, I still do not see what is so negative about it. I just gotta shrug.
Primarily the mixins and variables that have been provided to customize widgets.
When I started looking under the hood I really liked the way they had organized their SASS also. Each widget is a separate mixin. So if you your not using a particular "module" the include for the mixin can be commented out reducing code. After looking at it I took to the idea and all my SASS is organized in the same exact way. Each view (think page if your not familiar with MVC) that requires CSS tweaks is its own mixin. Than I merely include my application level mixins in the main file for all the views.
Having styles across many different files would normally be a maintenance issue but since compass compiles SASS into a single file w/ compression and neatness options (tabs) it is not.The only downside I think to this workflow is the need to recompile after any change in the SASS. However, even that can be eliminated by using a special compass watch command I heard.
Other than that though, I really really really like the nesting. In my opinion it results in more readable and condensed code which is awesome.
Also, I can't say this for LESS but I have not ran into any bugs with SASS, other than those caused due to my own misunderstanding of something. Though, the SASS documentation is great, so any issues have been easily over come.
Oh… and loops. Working on a mobile site with 5 sprites loops are great. I was able to write about 6 lines of SASS to output the changing background position for each state. I can't say that is pretty cool, because it is. Before using Sencha Touch in a previous "prototype" of the project I was actually using PHP to generate a stylesheet to do it for me. However, it is much much nicer eliminating the "need" for PHP, well it isn't a need but sure as a hell helps.
Granted, everything mentioned here can be achieved using plain CSS, but I think it is oh so much nicer with the add-ons that SASS and compass provide.Than again… I wouldn't be saying that all had I not been introduced and in active development with Sencha Touch.
Lastly, SASS and compass themselves are not bloat, well at least in terms of bloat that has an impact on the end user experience. They remain completely transparent if you are compiling the SASS and deploying it as regular CSS. The only thing that is happening is SASS/compass is doing what you would have to do anyway. Compass I think even has options for it's provided mixins to reduce code by eliminating support for certain browsers. That said, it is another layer of complexity but like I said I have not ran into any bugs with it and I have about oh… I would say 20 hours with it.
The only code I hate more than my own is everyone else's.
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.
It was a hypothetical case, it doesn't actually run anywhere
Rémon - Hosting Advisor
Minimal Bookmarks Tree
My Google Chrome extension: browsing bookmarks made easy
Though it does remind me an awful lot of:It was a hypothetical case, it doesn't actually run anywhere
for(;P("n"),R-;P("|"))for(e=3DC;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);
... and that's not a good thing either.
Posting Permissions
Reply With Quote
Bookmarks