Why use HAML (and SASS) if you already know HTML?
blog.digimonkey.com
blog.digimonkey.com
Haml and Sass are elegant tools for simplifying view code, and I never, ever use ERB or CSS anymore if I can avoid it.
Also, just out of curiosity, why do you use CSSEdit? I'm guessing you probably write your HTML or Haml markup with Textmate and not Dreamweaver, right? Why do something different with CSS?
HTML is much easier. You're just dealing with structure, so it's much easier to comprehend.
Incidentally, it's also not Turing-complete.
Wikipedia: After its initial versions, Nathan Weizenbaum and Chris Eppstein have continued to extend Sass with SassScript, a Turing Complete scripting language used in Sass files.
and http://wiseheartdesign.com/articles/2010/01/18/the-demise-of...
And I'm the guy who invented most of the programming facilities of Sass and I'll tell you, they're not very good programming tools -- but they're enough to make some really great stylesheets.
You're better off trying to convince them to include the necessary hooks in Espresso, if they add CSSEdit-style functionality to it.
In the case of Sass, abstraction is primarily provided by mixins and functions. Compass (http://compass-style.org) provides an excellent example of using these to write CSS at a much higher level.
But that's the whole discussion right there; not everyone sees them as elegant, and simply asserting them to be so is not an argument.
Thanks for the compliment, though the idea of "definitive" anything typically makes me bristle. . I stand by what I wrote, but I wrote it mostly because enough people kept asking me why I didn't care for Haml, and I'm sort of bad at keeping my mouth shut.
As a happy Python user, I absolutely resent going to languages that require code block delimiters. Since I consistently indent anyway (and have done so since long before I ever discovered Python), it just feels like pointless duplication of effort to indent and delimit using curly braces or do ... end or whatever.
Significant whitespace may not be for everyone, but there's no case to be made that it's punitive.
There's a worthwhile difference between Haml's "must be this distance, exactly" approach and the offside rule of Haskell. That I cannot add some extra indentation for clarity or ease of reading in Haml is wrong.
BTW, is there an auto-format plugin for vi that will automatically set/adjust the indentation of Haml if it is misaligned?
As far as know, it's up to the typist to ensure that each item lines up exactly so, which is extra work (i.e. punitive), but perhaps I've just failed to find the right plugin.
Horses for courses.
However I have to say, in 10+ years of working on multi-person, multi-discipline web teams, there isn't one to whom i could see having recommending something like HAML.
Just raises too high a bar for designers and front-end developers (ie CSS/HTML specialists), for whom learning a new language is actually a fairly big deal.
SASS seems to be enough like CSS that it wouldn't necessarily pose a comparable problem to the designer brain. I could see designers grokking its basic features like variables and seeing them as a thing that gave them more power.
If my experience is representative, though, configuration might be SASS' achilles heel right now. Really gave it the ol' college try and my SASS files never QUITE seemed to compile how and when i expected. Compass was even worse in that regard for me. I am getting old though, so maybe i've just lost a step or two :) Anyone else have similar experiences?
I'm sad that you found Sass's configuration difficult. What in particular did you have a hard time figuring out how to do? We're always interested in improving the documentation and UI.
I'll admit it might make things easier to navigate with the eyes. But on the other hand it seems to abstract something that's really not that complicated to begin with.
That being said, if your HTML development style is based around writing everything then I can see how it would be faster. But for me I use autocomplete+copy&paste, and then usually a lot of other stuff I (embarrassingly) google and then copy from examples.
As for SASS, maybe I'll feel the same way after I jump in, but the idea of adding a layer of abstraction to CSS seems like trouble - IE 6/7/8 is trouble enough.
=rounded-corners(!amount)
border-radius= !amount
-moz-border-radius= !amount
-webkit-border-radius= !amount
.curvybox
+rounded-corners(7px)On every professional project I've worked with, we were given markup and assets from designers, and then expected to integrate them ourselves. If you're lucky enough to have a designer on staff, train them in Sass. Otherwise, the process of converting HTML to Haml and CSS to Sass isn't any harder than converting mockup HTML to templates.
On the opposite side, if you just need a refresh or a facelift, you give them the HTML and CSS that Haml and Sass generate. It's nicer looking than ad hoc markup already.
I am longing to get to a point where the designers I work with can be expected to write templates using mustache or django template language...
Ideally the designer can check out a submodule of the project and commit ongoing UI enhancements by simply modifying mustache/django templates that they wrote in the first place.
This could easily be implemented by using a static site generator to populate the templates with static data so that the designer could check his/her work before committing.
With Haml you end up translating the whole mess over and over again, and if you decide to make a big change to HTML/CSS you are spending lots of time redoing the HAML/Sass.
The other key thing to realize is that CSS is an extremely expressive spec when used properly I really don't think that the small bit of conciseness offered by Sass is worth adding another layer...
The semantics of Haml and Sass are identical to those of HTML and CSS. The extensions they add are generally clear to anyone familiar with the base languages. And Haml has the great benefit of making HTML be written like CSS, which is much more comfortable to designers.