About Me
Feed
A Timeline for Haml/Sass 3
I’ve mentioned earlier that I had set for myself a tentative deadline of March 29 for the release of Haml and Sass 3.0. It’s becoming quite clear to me that that’s not going to happen.
It’s possible that I could get all the technical work, such as coding and testing and documentation, done by then. However, I try to give a broad overview of upcoming releases by way of blog posts here, and moreover I try to only introduce new features when they’re ready to use. I’m sure I’d be unable to develop and write at the necessary pace to get a full 3.0 release out the door in a week.
So here’s what I’m thinking right now: I’ll set out some minorly ambitious goals that I’ll try to meet, as well as some more conservative ones that I’ll commit to meeting.
I will try to release a beta version of Haml/Sass 3 by the 29th, one week from today. This release will not be feature-complete, but it’ll be most of the way there. Nor will all the features be given a full overview here.
I will then try to push out a release candidate by April 5th, two weeks from today. This will be feature-complete; from that point forward, the goal will be to squash bugs in preparation for the full release. There will likely be several release candidates before…
I will try to release the full Haml/Sass 3 by April 19th.
It’s possible, even likely, that stuff will come up and those deadlines will slip. I’d like to give our users some more solid commitment. So I will commit to releasing a beta version of Haml/Sass 3 by April 12th, a release candidate by the end of April, and the full version by May 17th. I expect I will not push up snugly against those deadlines, though.
Finally, I feel I should say that as much as I love Haml and Sass, I do have a life outside of them and it’s remotely possible that this will interfere even to the extent that my more conservative goals are missed. In this most unlikely case, I apologize profusely in advance.
FireSass Bridges the Gap Between Sass and Firebug
Nathan,
Good luck! Don’t forget to rely on the community behind you—we can write text and code too :)
Please Nathan, do not apologise! We are grateful for all the awesome work you have done so far. It is great to have a rough timeline as you have mentioned here though.
The sass compiler should output lean CSS, not Microsoft-style syntax with spaces after the colon. I don’t understand why anyone adds pointless whitespace like that to client-side code, but it’s especially disappointing to see it coming from something called a “compiler”.
@Scooby: I don’t like you :-)
Scooby: Personally, I find “property: value” style more readable than “property:value”. When I see a colon in that position, I think “namespace” rather than “property”. I’m curious why you prefer it the other way. If it’s just a matter of unnecessary whitespace, the Sass
:compressedoutput mode eliminates unnecessary whitespace entirely. If it’s purely aesthetic, this monkeypatch will make it work to your liking.buhrmi: Let’s try to keep discussion here constructive.
Do you have any recommendations for a good PHP based SASS-compiler? I don’t speak Ruby all the Time ;-)
Gerrit: Just use the Sass command-line interface. Especially with the new auto-compilation feature, it’s perfectly easy to integrate with projects in any language.
Hi this is great news I have a question would it be possible to add support for PHP code inside HAML? I have used PHP code inside haml templates using the plain tag, If you can allow a similar action for php code to be parsed like – if($name == “boob) echo $name; That would be great this way HAML can be a standard rather there numerous HAML versions in different languages.
Not sure if this is possible?
Thanks Mo
Keep up the good work.
Since so many aspects of Haml – the attributes, interpolation syntax, etc. – are language-specific, I think the current system of having per-language implementations works well.