nex3 / haml
- Source
- Commits
- Network (95)
- Issues (17)
- Downloads (50)
- Wiki (1)
- Graphs
-
Branch:
master
click here to add a description
click here to add a homepage
-
Run
rip install git://github.com/nex3/haml.git.Now, try and require Haml. It fails as the Version class tries to look for the VERSION file in the root directory of the Haml package. Uh oh. Rip doesn't keep anything around other than the lib directory of the gem so there is no VERSION file.
Comments
-
Allow multiple filters to be composed in Haml - first apply the rightmost one, then work your way left. For example,
:preserve:escaped <foo> <bar /> </foo>should produce
<foo>
 <bar />
</foo>Comments
Please log in to comment. -
3 comments Created 5 months ago by nex3HamlxImplement a :no_interpolation filter.EasyxThis filter should be the same as
:plain, except that it should interpret#{}within it as literal text, not interpolation. For example,:no_interpolation foo #{bar} bazshould compile to
foo #{bar} bazComments
no_interpolationis kinda long and geeky. I offer the (not great) suggestion for an alternative name of:no_rubyor:plain_no_ruby.Please log in to comment.I feel like
:no_interpolationis substantially more descriptive than those, though, especially given that there's already a:rubyfilter that this wouldn't really have anything to do with. -
0 comments Created 5 months ago by nex3HamlxAllow variable indentation under certain circumstancesHardxCurrently, Haml insists that all indentation in a file be completely consistent. However, this means that it's not possible to get rid of a line without re-indenting everything beneath it, which is annoying when debugging code.
We want to allow variable indentation as long as it's unambiguous. For example, the following:
%foo %bar %baz bang boomshould be the same as
%foo %bar %baz bang boomHowever, wherever we currently would raise an error, a warning should be printed.
Ambiguous cases should still be marked as erroneous. For example, the following
%foo up four spaces down two spacesshould raise an error on the "down two spaces" line.
This is conceptually the same as issue #29, but since Sass and Haml don't share parser code, they're listed separately.
Comments
Please log in to comment. -
0 comments Created 5 months ago by nex3SassxAllow variable indentation under certain circumstancesHardxCurrently, Sass insists that all indentation in a file be completely consistent. However, this means that it's not possible to get rid of a line without re-indenting everything beneath it, which is annoying when debugging code.
We want to allow variable indentation as long as it's unambiguous. For example, the following:
foo bar baz bang: bop boom: bipshould be the same as
foo bar baz bang: bop boom: bipHowever, wherever we currently would raise an error, a warning should be printed.
Ambiguous cases should still be marked as erroneous. For example, the following
foo up: four spaces down: two spacesshould raise an error on the "down: two spaces" line.
This is conceptually the same as issue #28, but since Sass and Haml don't share parser code, they're listed separately.
Comments
Please log in to comment. -
0 comments Created 5 months ago by nex3HamlxDon't quote attributes that don't require it with :uglyMediumxWhen running with
:ugly => trueand:format => :html4or:format => :html5, don't put quotes around attributes that don't require them. See the HTML4 spec for a precise definition of when they're not required.Comments
Please log in to comment. -
1 comment Created 5 months ago by nex3HamlxDon't output unnecessary closing tags with :uglyHardxWhen running with
:ugly => trueand:format => :html4or:format => :html5, don't output closing tags that aren't required. A list of closing tags that aren't required is given here. Note that sometimes these closing tags should be printed. In particular, if the closing tag isn't followed immediately by an opening or tag - one generated by Haml - output it. For example, in all of the following situations:%p foo <strong>bar</strong> %p foo = "<strong>bar</strong>" %p foo :plain <strong>bar</strong>the closing tag should be preserved.
Warning: it's likely to be very difficult to figure out exactly when you may and may not output a closing tag.
Comments
Please log in to comment.See my hack. Note that it doesn't do any checks described above
-
0 comments Created 5 months ago by jsmestadhaml single string quoting should highlight properlyEmacsxcurrently only double quotes will highlight as a string, single quotes are just as valid and should be highlighted also.
Comments
Please log in to comment. -
This should behave just like the
:javascriptfilter, except with<style>tags instead of<script>tags.Comments
Please log in to comment. -
Raising an issue to open discussion. I don't know either Haml or Mustache codebase well enough to start work on this straight away.
Chris Wanstrath (aka defunkt) has just released a great template engine 'Mustache' based on Google's CTemplate.
As a templating solution Mustache is great, but I don't think anybody can deny the cleanness and readability of HAML code.
I don't think it would be too difficult to modify HAML to support Mustache-like generation. This could even be an option on HAML which could be turned on an off.
I'm thinking something like:
a) no ruby code evalution, so (-, =) no longer evaluate.
b) new syntax
{{#boolean}},{{helper}},{{{non_interpreted_helper}}}can be used anywhere in the code(ie as nodes and inside text nodes) and will be evaluated as expected.c) integration into rails could be very simple. All template logic now goes into the helpers files.
Comments
I think this would make the most sense as a separate library that integrated Haml and Mustache, probably most easily by simply passing the output of a slightly-modified Haml to Mustache. Haml has a
:suppress_evaloption that will suppress Ruby evaluation, which would help.For Mustache nodes that take blocks (e.g.
{{#foo}}), there could be some integration with Haml. This could be done hopefully without much difficulty by subclassing Haml::Precompiler.
adamsalter
Sun Oct 04 21:08:31 -0700 2009
| link
That doesn't sound too painful. I'll have a look at it an get back to you.
Please log in to comment.Note that technicalpickles has a gem to use mustache with rails:
http://github.com/technicalpickles/mustache-ride
Best gem name ever. -
Sass comments should be able to output variable values
3 comments Created 2 months ago by richardadayHaving the ability to output variable values in comments are a needed informative tool.
Example:
=font-size-pixels-to-ems( !pixels ) !ems = !pixels / 16 font-size = !ems+em /* 16 x !ems = !pixels p +font-size-pixels-to-ems(18)Should print out:
p { font-size: 1.125em; /* 16 x 1.125 = 18 */ }However, it is currently printing out:
p { font-size: 1.125em; /* 16 x !ems = !pixels */ }Comments
If this is supported, it will likely be with the syntax
=font-size-pixels-to-ems( !pixels ) !ems = !pixels / 16 font-size = !ems+em /* 16 x #{!ems} = #{!pixels}As a side note, you can use numbers with units directly. That is, you could write your snippet as
=font-size-pixels-to-ems( !pixels ) !ems = !pixels * 1em / 16px font-size = !ems p +font-size-pixels-to-ems(18px)
richardaday
Tue Nov 24 06:17:29 -0800 2009
| link
Great suggestion with the unit refactoring.
Anyways, I tried your method of string interpolation and it didn't work.
=font-size-pixels-to-ems( !pixels ) !ems = !pixels * 1em / 16px /* 16 x #{!ems} = #{!pixels} font-size = !ems p +font-size-pixels-to-ems(18px)renders:
p { /* 16 x #{!ems} = #{!pixels} */ font-size: 1.125em; }(PS: I am running my sass through http://sass-lang.com/try.html )
Please log in to comment.I just meant that if this feature becomes supported, that's the syntax it'll use. It's not supported right now.
-
When outputting normal html with haml, it shouldn't wrap javascript in CDATA.
Haml/Sass 2.2.14 (Powerful Penny)
Rails 2.3.5Comments
I was tempted to report this myself once.
But note that the CDATA tags are prefixed with Javascript // comments; this is an old trick to make HTML/XHTML compatible markup. It should be perfectly valid HTML 4.
It might be nicer style not to include them for HTML 4, but the current output is perfectly valid markup.
Well, yes it's valid, but if you look at http://hixie.ch/advocacy/xhtml you'll see that in reality it's lacking due to mixed support for xhtml between browsers.
I do prefer the nicer style though, so I simply used:
%script{:type => 'text/javascript'} :plain <script here>Anyway, you're right, due to the javascript comments it doesn't really matter.
CDATA is supported in HTML5, I believe. Would it be preferable to use
<!-- -->on HTML pages?According to this piece, even for XHTML, CDATA isn't necessary unless the document is served as
application/xhtml+xml, which is rarely the case.I think the
:javascriptfilter should just create the script tag and let me write JavaScript. If I want/need them, I can open a:cdatablock myself. Right now if I don't want the ugly CDATA stuff, I need to do the phaza's workaround above.Lots of XHTML things work reasonably well independent of the MIME type. I was under the impression that CDATA worked like this.
There are several options here. We could use CDATA for XHTML documents and comments for HTML; we could use CDATA for everything like we do now; or we could just HTML-escape the content. The first two warrant some compatibility testing, I think. What do people think?
Forgive my ignorance, but why are comments needed for HTML?
Please log in to comment.The ultimate reason for all of this is so that HTML-active characters,
<,>, and&, will be considered to have their HTML meanings. This can cause annoying and unforseen bugs. Comments are one way of ensuring that these characters are interpreted properly. -
There are a number of functions that can be succinctly expressed in SassScript. Can we provide a way in Sass for defining functions using SassScript in Sass files instead of in ruby?
@function px-to-em($pxval, $baseline = 12px) $pxval / $baseline * 1emThen this could be used just like a ruby-defined function:
div font-size= px-to-em(18px)Comments
This is something I'll consider for the version after 2.4.
yes please. most (all?) of Susy would move into sass script, and become more flexible to use at the same time.
Excellent idea, very badly needed to keep libraries clean IMO.
Please log in to comment.This will also be important for the css3 module where gradients should be possible to use with multiple backgrounds:
background-image= +h-gradient(...details...), image_url(...details...), +v-gradient(...details...) -
Mixins Definitions should be able to include itself
3 comments Created 21 days ago by richardadayMixins should be allowed to include themselves. A good example for this is when you are creating a theming environment in your CSS.
For example, lets say you have theme1 and theme2.
The folder directory would look like
theme1/ pages/ 1.sass 2.sass 3.sass theme2/ pages/If the pages for theme 2 were very similar to theme1 then there is no point in copying in branching the sass files from theme1 and putting them in theme2 (now you are forced to maintain 2 different versions). Instead, this approach is prefered (assume we are trying to override page 1 for theme2.
theme1/pages/1.sass :
=page-1-css color: red font-family: ArialNow theme 2 has an option, it can redefine +page-1-css or choose to extend or overwrite it.
Extending it would look like:
@import ../theme1/1.css =page-1-css +page-1-css font-family: ArialOverwriting it would look like:
=page-1-css display: blockNow, depending on your theme, you import all pages for that theme, and one page's CSS could extend another theme's page. So you reduce the amount of SASS you have to maintain.
The problem is that mixins will not allow you to include itself currently.
=test-mixin color: red =test-mixin +test-mixin font-weight: bold div +test-mixin font-family: Arialreturns this error:
stack level too deepComments
richardaday
Wed Jan 20 00:30:42 -0800 2010
| link
Actually, I think writing the above made me figure out a different solution. Theme 2's page1.sass can import theme1's page1.sass file if it wants to extend it, if not it just redefines everything itself.
Also, theme1's page.css would look like
div#page-1 color:red font-family: Arial(Instead of being defined as a mixin and trying to override it).
Closing as long at my solution will solve all my uses cases (will open if not :) ).
This has been discussed on the Compass mailing list as well. I'd say keep it open; it's something we'll want to consider supporting.
Please log in to comment.@richardaday the only caveat is if you only want to override a single rule from the theme1 file -- then you have to copy over every rule from theme1 and just modify the one you want. Practically speaking, this may be an edge case though :)
-
Stick multibyte characters anywhere in the haml layout file and rails crashes with
invalid byte sequence in US-ASCIITo replicate this, add
%p== अंशुलanywhere in application.html.hamlruby 1.9.1
rails 2.3.5
haml 2.2.17
Comments
Do you have
Encoding.default_internalset to something other than utf-8? Haml should be setting the internal buffer to adefault_internal-encoded string (or utf-8-encoded ifdefault_internalisn't set).Very odd.
$ script/console Loading development environment (Rails 2.3.5) >> puts Encoding.default_internal => nilI did not change any defaults anywhere. Anyway, it appears that on my system, setting
Encoding.default_externalmakes the problem go away. So, I have added,Encoding.default_internal = 'utf-8' Encoding.default_external = 'utf-8'to the top of my
config/environment.rband things are working fine now. Ummm... would it be a good idea to check whetherEncoding.default_externalis set tonil?And thanks!
Please log in to comment.I don't think Haml does anything with
Encoding.default_external, onlyEncoding.default_internal. I'll leave this issue open for now so I remember to investigate and see if something's going wrong. -
I just reported this on bundler http://github.com/carlhuda/bundler/issues/issue/44 they in turn said its a haml gemspec issue.
The fix seems rather easy, just do not source any files from the gemspec.
Comments
Please log in to comment.




I'm of the opinion that packages should have access to their root directories. Haml uses this not only for reading the VERSION file, which could plausibly be moved into lib (although I don't think it actually belongs there), but for checking for git revision information and checking to ensure that the init.rb file for the Rails plugin is up-to-date.
Until there's some way to get access to this information from within Rip (or I'm convinced that it's not necessary to access it), Haml won't support Rip - or more accurately, Rip won't support Haml.
"Grit" library, which is used in official examples for rip, doesn't have a ripfile in its canonical repository. Instead, defunkt created a fork to add this ripfile, thus making it compatible with rip. You are free to do the same with Haml and maintain it.
You can get around this by adding this snippet before you
require 'haml'