Sass mixins and syntax

[priit....@gmail.com]

Hi!

I think Sass mixins with variables rocks! [1]

I haven't investigate Sass engine much yet myself, however does it
make
scene to support new syntax for mixins where we use ':' instead of
'=' (or along with):

Right now:

.content
+column(300px)
.sidebar
+column(300px)

But it would be cool if it is like:

.content
+column: 300px
.sidebar
+column: 200px

This way I can make mixins, what feel similar than CSS shortcuts like
background, border etc. Ah, I know that some love different syntax
where ':' is
in front of like :column 200px. However for them, perhaps
simple +column 200px would be ok.

What do you think?

Cheers,
Priit

[1] I use git://github.com/chriseppstein/haml.git fork at the moment
for Sass Base http://gitorious.org/projects/sass-base

[Chris Eppstein]

> [1] I use git://github.com/chriseppstein/haml.git fork at the moment
> for Sass Basehttp://gitorious.org/projects/sass-base

You needn't use my fork anymore. All my changes are in nex3's master
branch at this time.

Re: the syntax of mixin arguments. I think the idea of making them
more CSS-like is a good one. How would you handle multiple arguments?
Your examples only show a single argument. Would they be space
delimited instead of comma delimited like CSS?

Chris

[schroedi]

How do I import a tracking Code of google analytics into haml file?

schroedi
http://www.poppster.de

[Hampton]

Just put it in!

And make sure its all aligned to the same level.

That's what I do!

-hampton.

[Evgeny]

Actually CSS is using space for multiple arguments, like in ...

  border: 2 dottted blue

[schroedi]

Yes with Google It works fine.

But It wont work for the tracking code from etracker.de ;-)

schroedi

--

Mario Schröder | http://www.poppster.de
Phone: +49 34464 62301 Cell: +49 163 27 09 807
PGP-Key: follows

[priit....@gmail.com]

> You needn't use my fork anymore. All my changes are in nex3's master
> branch at this time.

Wow, very good news!

> Re: the syntax of mixin arguments. I think the idea of making them
> more CSS-like is a good one. How would you handle multiple arguments?
> Your examples only show a single argument. Would they be space
> delimited instead of comma delimited like CSS?

First I thought everything should be more ruby-like syntax in haml/
sass, but nowadays I would prefer more close to CSS spirit, because
many people might not be ruby programmers and don't care so much about
ruby syntax. For example I hated variable starting with "!" (why not
with "@"), but now it's ok cos its more close to CSS spirit.

So from user perspective (still not knowing Sass engine much) I would
be happy with syntax similar to CSS (without commas):

.content
+column: 600px
.sidebar
+column: 300px last

Cheers,
Priit

[Chris Eppstein]

Yes, I agree this is nicer. Nathan ought to weigh in though... he's
the man in charge. I could put together a changeset if he's too busy
but wants the change.

chris

[Nathan Weizenbaum]

I'm a little worried about the ambiguity here. "300px last" is valid
SassScript, evaluating as the string "300px last". That makes this
syntax much trickier to parse and inherently ambiguous. It's not a
horrible ambiguity, but it's there. Mainly for that reason, I think I
prefer the current syntax.

[Chris Eppstein]

Hmmm. I think the need to include spaces in an argument would be the
exception and if desired should be achievable in an evaluated context:

+mixin= "300px last" #ccc

I find the value of using a more CSS-like syntax to be worth making
passing spaces more complicated.

Chris

[pimpmaster]

Wow, this looks pretty cool!

I am already using mixins with great success and had no idea you could
pass variables

How exactly is this done??

[Chris Eppstein]

There was a series of checkins a couple weeks ago that added some
great new capabilities to sass. There's still a few missing bits and
as you can see from this thread the syntax may still in flux. Since
none of this has been documented nor part of an official sass release,
use them at your own risk.

That said here's a bullet list of the new features that Nathan added:
* Passing arguments to mixins
=my-mixin(!width, !color = #000)
:border= !width solid !color
.selector
+my-mixin(5px, #ccc)
.another-selector
+my-mixin(5px)
* Selector interpolation
.selector-#{!foo}
* Iterative looping (for)
@for !n from 1 to 11
.border-#{!n}
:border-width= !n+px
* Conditional looping (while)
!n = 1
@while !n != 16
.gray-#{!n}
:color= #111 * !n
!n = !n + 1
* Conditionals
@if !n = 5px
:border= !n dashed #ccc
(@else is still pending)
* Boolean logic (to support the above features)

I use most of these features to render the blueprint grid (which was
the primary use-case for this feature). You can find an example here:
http://github.com/chriseppstein/compass/tree/master/frameworks/blueprint/stylesheets/blueprint/modules/_grid.sass

Cheers,
Chris

[Hampton]

I mean.... any javascript is fine...

[schroedi]

Yeap, but I wont to place the Etracker Code with an Partial into the
haml file

Mario

Hampton wrote:
> I mean.... any javascript is fine...
>
> On Sun, Aug 24, 2008 at 4:15 AM, schroedi <schroe...@gmail.com
> <mailto:schroe...@gmail.com>> wrote:
>
>
> Yes with Google It works fine.
>
> But It wont work for the tracking code from etracker.de

> <http://etracker.de> ;-)

>
> schroedi
>
> Hampton wrote:
> > Just put it in!
> >
> > And make sure its all aligned to the same level.
> >
> > That's what I do!
> >
> > -hampton.
> >
> > On Sat, Aug 23, 2008 at 2:58 PM, schroedi
> <schroe...@gmail.com <mailto:schroe...@gmail.com>

> > <mailto:schroe...@gmail.com <mailto:schroe...@gmail.com>>>

[Hampton]

Well, I can't read the etracker site.

What makes it unique?

[pimpmaster]

Thanks for clarifying that Chris

I went ahead and grabbed the latest source from github yet for some
reason still cannot get this new syntax to work

=round-corners(!radius=7px)
:border-radius = !radius
:-webkit-border-radius = !radius
:-moz-border-radius = !radius

Sass freaks out because the !radius constant is not defined.

I am wondering if there is a special branch I need to check out??

[Chris Eppstein]

Your example works fine for me. I'm guessing you have an install
issue... maybe you've got an old gem or something?

-chris

[Hunt Jon]

Generally, you can find out how to use "script" tag in the official
HAML documentation.

http://haml.hamptoncatlin.com/docs/rdoc/classes/Haml.html

Quote:

Brackets represent a Ruby hash that is used for specifying the
attributes of an element. It is literally evaluated as a Ruby hash, so
logic will work in it and local variables may be used. Quote
characters within the attribute will be replaced by appropriate escape
sequences. The hash is placed after the tag is defined. For example:

%head{ :name => "doc_head" }
%script{ 'type' => "text/" + "javascript",
:src => "javascripts/script_#{2 + 7}" }

is compiled to:

<head name="doc_head">
<script src='/docs/rdoc/javascripts/script_9' type='text/javascript'>
</script>
</head>

:Unquote

Does this give you an idea?

[Hunt Jon]

I tried mine:

%script{:src => "http://www.google-analytics.com/urchin.js", :type
=> "text/javascript"}
%script{:type => "text/javascript"}
_uacct = "UA-1234567-1";
urchinTracker();

Converts to

<script src='http://www.google-analytics.com/urchin.js'
type='text/javascript'></script>
<script type='text/javascript'>
_uacct = "UA-438638-1";
urchinTracker();
</script>

Hope this helps.

[pimpmaster]

Chris,

I installed 2.1.0 gem from source

Am I using the correct version/branch?

[Chris Eppstein]

No. These features are part of the forthcoming 2.2 release.

git clone git://github.com/nex3/haml.git
cd haml
rake install

I'm using the master branch in production... it's rock solid. Nex3 is
a great coder, a ruthless code reviewer, and the code-base is very
well tested.

chris

[pimpmaster]

I finally got this working.

Realized that there must be a space on either side of the equals, like
so

=cool(!var = #fff)
:color = !var

I was doing it like this and it bombed

=cool(!var=#fff)
:color = !var

Thanks for your help!! :D

[Chris Eppstein]

That sounds like a bug, but I added a test case for it and cannot
reproduce your error. I also read the code again and it should be
tolerant of any amount of whitespace around the equals sign in the
mixin definition (including none).

But I'm glad you've got things working.
chris

http://github.com/chriseppstein/haml/commit/1bb0ac3ba7b1fcbc625f91065d0967015282e5bc

[Nathan Weizenbaum]

Just to clarify, 2.1.0 is the version of the development branch that
will eventually become the 2.2 release.

[Nathan Weizenbaum]

The second example works for me, as well. If you can get a snippet that
fails on a plain master checkout, let me know.

[Nathan Weizenbaum]

I don't think it's really worth testing for this if it works now and
there's no reason to think it'll stop working.

[schroedi]

Yes, now i got it.
I put the code in the wrong position in the source. So we had a open
html Tag follows by a closing html tag. The whole site was outside the
html tags. Hope Google is not so restrictiv with me an indexed the site,
too.

Thanx.

Mario

[Chris Eppstein]

I made some changes this morning that allow space delimited mixin
arguments without parens when the arguments are not interpolated. So
the following mixin includes are equivalent:

+my-mixin 2px #ccc
+my-mixin(1px + 1px, #ccc)

http://github.com/chriseppstein/haml/commits/mixin_syntax

On Aug 26, 1:14 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:

> I'm a little worried about the ambiguity here. "300px last" is valid
> SassScript, evaluating as the string "300px last". That makes this
> syntax much trickier to parse and inherently ambiguous. It's not a
> horrible ambiguity, but it's there. Mainly for that reason, I think I
> prefer the current syntax.
>
> Chris Eppstein wrote:
> > Yes, I agree this is nicer. Nathan ought to weigh in though... he's
> > the man in charge. I could put together a changeset if he's too busy
> > but wants the change.
>
> > chris
>
> > On Aug 25, 12:53 am, "pr...@mx.ee" <priit.tamb...@gmail.com> wrote:
>
> >>> You needn't use my fork anymore. All my changes are in nex3's master
> >>> branch at this time.
>
> >> Wow, very good news!
>

> >>> Re: the syntax ofmixinarguments. I think the idea of making them

[Nathan Weizenbaum]

What do you mean by "when the arguments are not interpolated"?

[Chris Eppstein]

Interpolation is the difference between:

:width 200px

which is not interpolated and

:width= 200px

which is.

-chris

[Nathan Weizenbaum]

I'm not sure I want to add another alternate syntax, especially one with
different semantics. I'm worried about syntax bloat, especially when it
doesn't add any power. I am kind of fond of the more CSS-like syntax for
mixins, but I'm not sure it's worth either the syntax bloat if we don't
eval the parameters or the confusing syntax if we do.

[Chris Eppstein]

It sounds like you need to think about it and let us know. I took the
approach I did because of your concerns expressed previously about how
to interpret arguments. I think we all agree that the syntax can be
better, and I would like to see us iterate on the current syntax
before issuing any formal release and taking on a backwards
compatibility burden. If any of my changes help us further that
thinking process then it was time well spent.

chris