Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Nesting with @in? #58

Closed
dubcanada opened this Issue · 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
@peteboere peteboere referenced this issue from a commit
@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.