Question about new features...

[beaniemonk]

Looks like you have been busy. :) New features look really cool.

Not so much an "issue" per say (just don't know where else to ask this). I've been trying them out.

I think I have inheritance figured out (abstract and non abstract):

.not-abstract: { color: red; background: white; }
@abstract something { font-size: 14px; font-weight: bold; }
.something { extends: .not-abstract; extends: something; }

I almost have mixins sorted, but I can't figure out how to pass arguments. I've tried all kinds of different syntax.

@mixin something /* tried everything here */ { padding: /* here too */; }
.something { mixin: something(20px); /* works when i don't try to pass arguments */ }

I can't get nested blocks to work no matter what I try. I've tried LESS/SCSS syntax, the CSS working group syntax, etc.

p {
    strong { /* doesn't work */  }
    & strong { /* nor this */ }
    &this strong { /*nor this */ }
}

Fragments I'm a little foggier on -- not sure what they are.

Do you have a rough idea when some documentation might be available on these? Are there any quick pointers you could pass along in the meantime?

Thanks!

[peteboere]

Yes documentation for the new features is in the works, but here is the short version:

Your rule inhertitance example is right, though it's a bit cleaner to pass comma seperated arguments to the extends property:

.not-abstract { color: red; background: white; }
@abstract something { font-size: 14px; font-weight: bold; }
.something { extends: .not-abstract, something; }

Mixins take positional arguments with an 'arg' function, the second param is the optional default value:

@mixin test {
     padding: arg( 0, 10px );
     color: arg( 1 );
}

p {
    mixin: test( default, green );
}

Fragments work in the same way except they work at block level:

@fragment placeholders {
    ::-webkit-input-placeholder { color: arg( 0 ); }
    :-moz-placeholder { color: arg( 0 ); }
}

/* invocation */
@fragment placeholders( red );

Block nesting is via an @-rule:

@in .homepage {
    &.theme-one {
        ...
    }
    .content {
        ...
    }

    /* Drill down another level */
    @in .sidebar {
        ...
    }
}

[beaniemonk]

Awesome, thanks! That clears everything up, actually.

And perfect timing -- I've been working on refactoring our CSS "framework" so these come in handy.

One of things I like about Crush more than the usual suspects is syntax. They all tend to start to look sloppy and ugly to me after a while. But the Crush syntax just looks clean and intuitive for some reason.

I think you've done a great job incorporating these new features without compromising this. In all cases I prefer the syntax you've chosen over the others out there.

One thing I noticed (and yes, I can wait for the documentation if it's answered there)...

Your example for fragments would output those 2 blocks as-is. So if I want to add them to other selectors, I should combine them with block nesting, a-la:

@fragment links {
    &:any(:link, :visited) {
        text-decoration: none;
    }
    &:pocus {
        text-decoration: underline;
    }
}

@in a {
    @fragment links;
}

Is that the intended usage? I like it -- just want to make sure...

Thanks again!

[peteboere]

That's quite cool, though it wasn't my intention to combine them in that way :)

I guess there's no reason it wouldn't work since fragments are resolved before nested blocks are.