Almost

[Aljoša]

Great work xCSS team. I like it a lot but I prefer the way of mixins
in sass and what you can do with them over expands which
unfortunatelly ain't so flexible or intuitive :(

[Anton Pawlik]

Hey thank you for your compliment. But in my opinion mixins are very
wrong (that's basically the only reason I've developed xCSS).

please look at this:

http://pastie.org/788648

http://pastie.org/788670

I don't really understand why this other approach appeals more to you.

[Aljoša]

Ok, you got me convinced :) Good work!

[Martin Klepsch]

Haha, that was kinda easy.

In fact thats one of the reasons why i originally preferred xCSS over lessCSS.

martin

2010/1/21 Aljoša <aljosa....@gmail.com>

[Nathan Weizenbaum]

Hi there, lead Sass developer here. I wanted to chime in with Sass's
mixin philosophy.

We agree that when it comes to saying "this rule extends that rule",
Less's behavior of literally including the contents of the extended
rule is wrong. We really like xCSS's behavior, and in fact that's what
I'll be using when I implement rule-extension for the next Sass
version (I will certainly be giving proper credit to xCSS for
pioneering the idea).

We also think that literal-inclusion mixins have their place, though.
Not as a way of doing OOCSS, necessarily -- xCSS-style extension is
better for that -- but as a way of abstracting non-semantic
functionality. By "non-semantic" I mean presentational stuff that
doesn't belong in a class, like clearfixes and so forth. These also
typically want to be more customizable, by way of arguments and so
forth.

Now, there remains the annoying problem of potential code duplication
when using literal-inclusion mixins. That's why I'm planning on adding
an optimization step to the Sass compilation that will do what it can
do eliminate duplication.

Also, incidentally, xCSS is the Sass developers' (second-) favorite
CSS preprocessor. Keep up the good work.

- Nathan

[tony]

@Nathan Weizenbaum: I appreciate your response.

I like both syntaxes. Each of them has its pros and cons and I think
that it's
largely a matter of taste and performance. On the contrary to real
programming
languages and their purposes, in the end it doesn't matter if a style
cascade is
constructed by using "extends" or by mixin multiple definitions. To
repeat myself,
In the end counts the performance overhead.

To be accurate, even in the domain of object-oriented programming both
patterns
(class-based vs. mixins/composition) have their place and where to
prefer one
over the other depends on the project and its architecture. In my
opinion the same
applies to xCSS/SASS.

What I'd like to see is a comparison chart with 1on1 performance
tests. Maybe you
(SASS/xCSS developers) could work out a chart. I'm sure that your
communities
would be greatly interested.

So far...

[Anton Pawlik]

@Nathan hello, thanks for your response. I was a little bit harsh,
mixins can provide handy shortcuts for inconsistent things like
rounded-corners (lets hope webkit and others will stop this non-sens).
I'm really exited about the upcoming sass version (I've also read that
you can use { } based syntax in sass, that's pretty awesome too!). If
you have any questions, about this "extend" thing, don't hesitate to
ask.

@tony I'm not really sure what performance you're talking about.
Because the performance of the compiler actually doesn't matter, after
the development you link to the compiled css files, and that's it, no
fancy compiler needed. I'm sure sass does the same thing. The
performance of the compiled css files, was already described and
discussed in this thread.

[tony]

Oh, right. I ought to have had considered this before I wrote my post.
But wouldn't make it more sense to keep xCSS on the developer's client-
side (for example as a Textmate/Eclipse plugin)? When xCSS doesn't use
a caching system and a on-demand-compiler behind it?

[Anton Pawlik]

you can use xCSS the way that best fits you. i like to keep my xcss
class on the ftp for faster changes, but the api is very flexible and
you could even use this "--watch" thing like less does it. the other
thing is that I just can't develop ide plugins :(