CSS filter

[Norman Clarke]

Hello Haml devs,

I'm working on a Haml implementation in Lua and am wrapping up support
for filters right now.

Something that seems conspiciously absent from Haml is a :css filter,
that wraps CSS inside a <style> tag like :javascript wraps its content
in a script tag.

I realize that :plain pretty much accomplishes this already.

However, I think its presence would make Haml more consistent, would
make the code's intent more clear and would be trivial to implement.
An additional benefit would be allowing vim and emacs to highlight css
filter scopes with CSS highlighting.

I considered simply adding this to my version of Haml in Lua, but I
would prefer to get as close to 100% compatibility as possible without
introducing any extensions not supported by Ruby's Haml.

Regards,

Norman

[Chris Eppstein]

I would add that the :sass filter should have the same behavior of creating a <style> tag. 

The inconsistency between :javascript and :sass is very confusing.

chris

[Hampton]

I think a :css one is totally in-the-spirit. It should be guessable.

[Nathan Weizenbaum]

I'm up for :css. I'll add it on GitHub issues.

As for :sass, I agree that it's inconsistent, but new behavior would be completely backwards incompatible, and I don't think I've heard a suggestion for a good migration path.

[Chris Eppstein]

Release notes?

Hunt & pecked on my iPhone... Sorry if it's brief!

[Nathan Weizenbaum]

I'm not sure what you mean...

[Chris Eppstein]

Not every change has to be backwards compatible. I can grep for :sass in my haml files and adjust it accordingly in about 10 min. So you just make a note in the release notes about the behavior change.

[Norman Clarke]

I think it could be handy to allow filters to accept attributes, for example:

:sass { :css_tag => true }

With this in place, the current behavior could become a default, but those who want a CSS tag can get one. Eventually we can do a deprecation process to gracefully change the default behavior.

This would be useful for quite a few filters actually.

Regards,

Norman

On Sep 12, 2009 11:39 AM, "Chris Eppstein" <ch...@eppsteins.net> wrote:

Not every change has to be backwards compatible. I can grep for :sass in my haml files and adjust it accordingly in about 10 min. So you just make a note in the release notes about the behavior change.

On Fri, Sep 11, 2009 at 11:57 PM, Nathan Weizenbaum <nex...@gmail.com> wrote: > > I'm not sure wha...

[Chris Eppstein]

I like that idea, but I still think the default should change to emitting a <style> tag for consistancy

That syntax would also make it easier to turn off universal interpolation, etc.

:javascript{:suppress_eval => true}

Also, for some time now, there's been no way to specify haml options for a part of the page or just one haml file. If we made a haml filter this syntax would enable that:

:haml{:format => :html5}

  !!!

  %html

    ...

chris

[Norman Clarke]

I agree that that would be a more sensible default, I just think it
could be a big annoyance for current Haml users if it were switched
abruptly. Having at least one release cycle to deprecate the current
behavior would be kinder.

I suppose the Haml interpreters could also check to see if the :sass
filter is being used inside a <style> tag, and if not, then emit one.
That could be a PITA to implement but might be a more elegant
solution.

Anyway, that is now officially 3 feature suggestions in ONE thread.
I'll stop now. :-)

Regards,

Norman

[Norman Clarke]

Oh, and +1 on adding a :haml filter If parameters are added to
filiters. This would also allow us to specify the names of the various
configuration options in the language rather than only in the
implementation, so it would help with interoperability.

My goal is for Lua Haml to be able to run regular Haml, within
reasonable boundaries (i.e., no Ruby code). Being able to rely on the
same configuration options specified in a portable way in the document
itself would be really neat.

[Nathan Weizenbaum]

I am definitely not willing to change the behavior without adding a deprecation step first. Maintaining compatibility at least between adjacent releases is very important. Our users expect not to be broken without adequate warning.

For parameterized filters: I'd like to see more cases where this would be useful. If it's just for making this compatible, we might just as easily implement a :sass-with-tag filter or some such.

For in-file configuration: I've considered this in the past, and come up against one major problem. In mos uses of (at least Ruby) Haml, the files aren't just handled individually. Each file can also include partials, which are themselves individual Haml templates. To make things more complicated, there are also layout files that wrap the individual templates. If we allowed per-template options, we would need some sensible way for them to be communicated from layouts to templates, and from templates to partials. Since we have no knowledge of how a given framework handles templates and partials, and indeed many of them compile templates before layouts, this just isn't really possible.

[Norman Clarke]

On Sat, Sep 12, 2009 at 8:04 PM, Nathan Weizenbaum <nex...@gmail.com> wrote:

> I am definitely not willing to change the behavior without adding a
> deprecation step first. Maintaining compatibility at least between adjacent
> releases is very important. Our users expect not to be broken without
> adequate warning.

I agree 100%. I've already lost track of sites I've created that would
break with a simple "gem update haml".

> For parameterized filters: I'd like to see more cases where this would be
> useful. If it's just for making this compatible, we might just as easily
> implement a :sass-with-tag filter or some such.

Well, I was really brainstorming, not totally arguing for the idea.
But here are some ideas that come to mind:

:css {:media => "screen"}, :css(media = "print")
:sass { :style => "compact" }
:escaped { "ó" => "&oacute;" }
:markdown { :use => "BlueCloth" }

You could possibly even deprecate :escaped and :maruku in favor of:

:plain { :escaped => true }
:markdown { :use => "maruku" }

Another example; imagine a custom filter that takes text and pipes it
through a formatting utility like Unix's "fmt" or "par" to wrap and
justify plain text into paragraphs. Yeah, it would be slow and dumb,
but just consider it for the sake of argument. Here would be some
useful options:

:paragraph { :use => "par", :width => 72, :justify => true }

> For in-file configuration: I've considered this in the past, and come up
> against one major problem. In mos uses of (at least Ruby) Haml, the files
> aren't just handled individually. Each file can also include partials, which
> are themselves individual Haml templates. To make things more complicated,
> there are also layout files that wrap the individual templates. If we
> allowed per-template options, we would need some sensible way for them to be
> communicated from layouts to templates, and from templates to partials.
> Since we have no knowledge of how a given framework handles templates and
> partials, and indeed many of them compile templates before layouts, this
> just isn't really possible.

I see where you're coming from. Too bad, it would be a nice feature.
But yeah, way more trouble than it's worth.

[Nathan Weizenbaum]

Norman Clarke wrote:
> Well, I was really brainstorming, not totally arguing for the idea.
> But here are some ideas that come to mind:
>
> :css {:media => "screen"}, :css(media = "print")
> :sass { :style => "compact" }
> :escaped { "ó" => "&oacute;" }
> :markdown { :use => "BlueCloth" }
>
> You could possibly even deprecate :escaped and :maruku in favor of:
>
> :plain { :escaped => true }
> :markdown { :use => "maruku" }
>
> Another example; imagine a custom filter that takes text and pipes it
> through a formatting utility like Unix's "fmt" or "par" to wrap and
> justify plain text into paragraphs. Yeah, it would be slow and dumb,
> but just consider it for the sake of argument. Here would be some
> useful options:
>
> :paragraph { :use => "par", :width => 72, :justify => true }
>

For escaping, I'm planning on allow filters to be composed, so you could
do :escaped:plain (or :javascript:escaped, say). Setting the engine for
Markdown might be nice... but I think most filters with arguments would
work better as helper methods. I'll keep mulling it.