Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Feature Request: Inheritance at the Block Level (e.g. with Fragments) #48

beaniemonk opened this Issue Jul 5, 2013 · 2 comments


None yet
2 participants

Hey Pete,

I've been tinkering with a framework based on CSS-Crush. It's been going well so far, and I've enjoyed working with it. It's led me to really experiment, learn the inner workings, and stretch it where I need to.

No matter how much I rethink my approach or work around it, I keep coming back to the same thing -- how useful it would be to be able to inherit "structures", or multiple rules at once at the block level. For example, if fragments could call other fragments.

In Sass, if you look at the section labeled "Selector Inheritance" on the home page, when a rule is extended it's child rules are extended also. So in the example shown, when .badError extends .error, .badError.intrusion also automatically extends .error.intrusion. I'm not saying I prefer that solution, but it does illustrate what I'm talking about.

This is based on an old message I posted about how I started using fragments. It wasn't an intended use of yours, so it seems odd to request an enhancement to something you never meant to do in the first place. But maybe if I explain it'll make a little sense.

In my framework, I'm trying to create a library of components, but those components are abstract so that they aren't included in the rendered CSS unless something asks for them, so it keeps the rendered CSS as light as possible. And in many places I do that by (mis)using fragments.

For example, in a component that defines a grid layout, I have something like:

@fragment grid {
    &       { /* Do stuff to the container */ }
    .row    { /* Do stuff with rows */ }
    .column { /* Do stuff with columns */ }
@in .grid { @fragment grid(some, args); }

But it would be so cool if I could then do this:

@fragment calendar {
    @fragment grid(some, args);
    /* Additional rules just for calendars */
@in .calendar { @fragment calendar(some, args); }

That way I can re-use chunks of CSS and keep things modular, but at the same time keeping it abstract so none of it ends up in my CSS unless I need it.

I could also pass in selectors dynamically, so that the framework is independent of the HTML structure:

@fragment grid {
    arg(0, &)       { /* I can choose what a container is... */ }
    arg(1, .row)    { /* Or a row (with some sort of default)... */ }
    arg(2, .column) { /* etc... */ }
@in .menu { @fragment grid(default, > ul, > li, some, args);  }
@in .page { @fragment grid(section[role="main"], default, default, different, args); }

I realize this can be prone to bloat if not used responsibly, and also by digging into the code that fragments aren't designed to work like this, so I know it isn't a small request. I just wanted to get your thoughts and see if you think it has value. Or maybe there's a better way to achieve this that I'm overlooking?

Anyway, thanks!


peteboere commented Jul 5, 2013

Seems like a good idea to me, I'll look into extending fragments as you've described soon.

Thanks for the input!


peteboere commented Jul 22, 2013

Support added (in test branch) for fragment calls within fragment definitions.

@peteboere peteboere closed this Jul 22, 2013

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