Question about new features... #30

Closed
beaniemonk opened this Issue May 22, 2012 · 3 comments

Projects

None yet

2 participants

@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
Owner

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!

@beaniemonk beaniemonk closed this May 22, 2012
@peteboere
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment