Nesting with @in?

[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]

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.