Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eliminate duplication when overriding inherited mixin properties #339

Closed
mkoistinen opened this issue Aug 5, 2011 · 3 comments
Closed

Comments

@mkoistinen
Copy link

Hi, I don't know if this is a duplicate request, I tried searching the issues and didn't find anything like this.

Given this less source file:

 // Generic menu structure (many details left out for brevity here...)
.menu() { // UL
  li {
    list-style-type: none;

    &:before {
      content:  "\2022 "; // Unicode for a bullet
    }

    &:first-child {
      &:before {
        content: "";
      }
    }
  }
}


// I would like this to be a menu, but with a different separator...
.my-menu { // UL
  .menu;

  li:before {
    content: "|";
  }
}

The resulting output is this:

.my-menu li {
  list-style-type: none;
}
.my-menu li:before {
  content: "\2022 ";    // <-- THIS IS OVERRIDDEN BY…
}
.my-menu li:first-child:before {
  content: "";
}
.my-menu li:before {
  content: "|";        // <-- THIS.
}

Ideally, the duplicate property(-ies) would be removed since we know them to be overridden.

@dmcass
Copy link
Contributor

dmcass commented Aug 5, 2011

While I still understand your concern, the problem in the example is solved with parametric mixins. You're already using more code in your Less than you need to.

.menu(@sep: "\2022 ") {
  li {
    list-style-type: none;

    &:before {
      content:  @sep;
    }

    &:first-child {
      &:before {
        content: "";
      }
    }
  }
}

.my-menu {
  .menu("|");
}

Result

.my-menu li { list-style-type: none; }
.my-menu li:before { content: "|"; }
.my-menu li:first-child:before { content: ""; }

If possible, can you provide an example where this problem is not solved by parametric mixins?

@mkoistinen
Copy link
Author

You are of course correct, but perhaps this is a poor example. This is a general inheritance issue. Rewriting mixins to add new parameters each time I want to override something else isn't always practical.

@lukeapage
Copy link
Member

The trouble is that people frequently use multiple properties in order to provide a fallback for older browsers.. removing the properties is not something that it would be good to do generically.

In your case I would split your mixin in 2 and put a guard on the one outputting something you don't want - then you can use an argument to switch it on or off.

javisantana pushed a commit to CartoDB/carto that referenced this issue Dec 4, 2014
javisantana pushed a commit to CartoDB/carto that referenced this issue Dec 4, 2014
javisantana pushed a commit to CartoDB/carto that referenced this issue Dec 4, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants