Skip to content

Nesting with @in? #58

Closed
dubcanada opened this Issue Feb 27, 2014 · 1 comment

2 participants

@dubcanada

Hello,

I know in your documentation you have the following...

@in .homepage {
  @in .content {
    p {
      font-size: 110%;
    }
  }
  &.blue {
    color: powderblue;
  }
  .no-js & {
    max-width: 1024px;
  }
}

While this works it feels really redundant to have @in there. If you look at the syntax there is already a opening and closing bracket for the main class (.homepage) and a internal class (.content) which also have an opening and closing bracket.

I don't see any reason why you need to have @in, why it could not just be

.homepage {
  .content {
    p {
      font-size: 110%;
    }
  }
  &.blue {
    color: powderblue;
  }
  .no-js & {
    max-width: 1024px;
  }
}

Which is both cleaner, required less typing, and similar to other css preprocessors to give a easier transition.

Thoughts?

@peteboere
Owner

Nesting is not a 'first-class citizen' in Crush partly as a design decision. I can see the benefits of nesting and use it myself, but also find it to be quite unreadable when nesting more than 2 levels deep.

Technically, from a library developer point of view, the @in makes things a lot simpler and faster to parse, less edge cases, and more freedom for later adding features.

You are right though, making the syntax similar to other preprocessors for a short learning curve would be an advantage.

@peteboere peteboere closed this Mar 3, 2014
@peteboere peteboere added a commit that referenced this issue May 3, 2014
@peteboere Made rule nesting work without `@in` directives (turns out it wasn't …
…too hard #58).

`@in` directives are still supported for backwards compatability until at-least next major release (3.x).
c070be3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.