This has been brought up a couple of times before, and my feeling has
mostly been that using more CSS classes is better. But I'm gradually
being convinced that at least the issue isn't clear-cut enough to make
it worth forbidding rule inheritance (really mixins, in this case). So
I'll accept the patch, but it does need a little cleaning up first.
First of all, the documentation should be moved from the commit message
to files where the user can get at it. You should give an in-depth
discussion in the Sass reference in lib/sass.rb, and I think this is
useful enough to give an overview in the README.
"git am" doesn't seem to like the patch. "git format-patch
origin/master" with the latest git versions should work for that.
It looks like you've got a few debug outputs still in there.
In general, I think a better way to go about this would be to avoid
adding new Node types entirely. An include definition is really just an
array of Nodes; all you need to do when you encounter the include (in
build_tree; you'd probably want to return the include name as a string
from parse_tree) is to add all its children into an array and put that
in a hash (@includes or something) keyed by the include name. Then when
you see an include directive, just insert all the associated children as
children of the current node. This way you can avoid all sorts of
string-munging, since you're just dealing with tree nodes. It also makes
stuff like the following work:
-redlink
a
:color red
You should also have some error checking and tests for that in
SassEngineTest::EXCEPTION_MAP.
Thanks for the patch! Judging by the number of requests we've had for
this in the past, I imagine it'll be a pretty popular feature.
- Nathan
Garry Hill wrote:
> Hi,
>
> I don't know if anyone's had this idea before but I've always thought
> that the one thing CSS needs to make it truly useful is some form of
> OO style extension mechanism, i.e. ".rule extends .other-rule"
>
> Since Sass is such a lovely CSS templating language, instead of
> writing my own I've just quickly hacked in a demo of this feature into
> the Sass source. Here's the patch on pastie.org:
>
> http://pastie.org/173146
>
> Just to summarise the checkin message in that git patch, the idea is
> to create a way of defining includes inside Sass, much like ruby
> Modules. From the above pastie this is the syntax i've used:
>
> Any rule starting with a '-' is considered to be a declaration
> of an include (and generates no css on the render call).
>
> Then inside rules you start a line with the '+' character to include
> all the previously defined css declarations into the current context.
>
> E.g. '-blueoutline' starts an include block:
>
> -blueoutline
> :border
> :colour #000099
> :width 3px
> :style dotted
>
> then '+blueoutline' will include that into your current selector:
>
> .freebie
> +blueoutline
> :font
> size 10px
> :padding 4px
>
> this should generate the following css:
>
> .freebie {
> border-color: #000099;
> border-width: 3px;
> border-style: dotted;
> font-size: 10px;
> padding: 4px;
> }
>
> Note that the 'blueoutline' code isn't output, though it optionally
> could be which might be useful.
>
> Anyway. The code I've used to get this feature working isn't
> particularly pretty, but it works. I would be willing to do more work
> to get it accepted as part of Sass, but I'm obviously not going to be
> able to do that alone.
>
> Would anyone be interested in this as a feature for Sass? I think it
> could be really powerful. Having variables is alright, but sometimes
> you want to include blocks of css into a selector. At the moment the
> only way to do this is to have multiple css classes on an element, but
> to me that's exposing too much of how your css is structured to the
> html. I have always wanted to be able to use single class names where
> ever possible and use some kind of inheritance in the css code itself
> to sort out repetitive styles.
>
> Thoughts welcome.
>
> Garry
>
>
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Haml" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---
