Better methods for extending classes within @media queries

[blakemann]

I believe similar issues have been brought up in the past, but I have a bit of a different use-case in mind.

I've been setting up some less files to help speed up my workflow.. I have separate files for mixins, as well as for extensions (I created a bunch of special classes for basic styles such as ._block { display: block; }, and then imported that file by reference into my main less stylesheet. I can then extend these classes throughout my styles to help clean up my output css, and reduce the redundancies of style declarations by a great amount.

I'd like to further this advantage by having my mixins also extend these classes. This is currently possible, but begins to fall apart once we get into the use of @media queries. My extension classes which are imported at the top of my file can't be used from within the queries as it currently stands, and any attempts to get this to work (creating special wrappers or files / importing the extension classes multiple times into different scopes) seem to either cause issues, or be overly complicated. Because of this, I also can no longer use any mixins that extend classes inside of the queries, which currently prevents me from using extend from my mixins, and subsequently makes me hesitant to use my own mixins in some cases, in favour of putting the extra effort in to write it myself, using the extends.

Ideally, I'd like to be able to work around this.. there are two possible routes I think this could go:

1. Allowing top-level styles to be extended from within an @media query. Doing so would copy the styles of the extended class into the query, and start constructing a new selector there, in the new scope. Ideally this would be automatic, but if that was not feasible, perhaps we could have a way to easily specify that a new scope for extends was needed... re-importing those classes inside the query would seem acceptable to me as long as I could still use my top-level styles the same way (with the original import and styles right at the top, not inside any queries)

2. Giving functionality to mixins to determine wether to extend the class, or simply use it's styles separately depending on the scope. When calling my mixin from my top-level styles, it would extend the classes, but when calling it from within a media query it would simply add those styles to the calling selector, as usual. This approach does seem to have more issues with implementation than the first though, and would probably be less ideal anyways.

To help clarify my intentions:

Ideal Input

// extensions.less

.block {
    display: block;
}

---

// mixins.less

@import (reference) "extensions";

.mixin() {
    &:extend(.block);
    margin: auto;
}

---

// styles.less

@import "mixins";

.element1 {
    .mixin();
}
.element2 {
    .mixin();
}

@media only screen and (max-width: 768px) {

    .element3 {
        .mixin();
    }
    .element4 {
        .mixin();
    }

}

Ideal Output

// styles.css

.element1, .element2 {
    display: block;
}
.element1 {
    margin: auto;
}
.element2 {
    margin: auto;
}

@media only screen and (max-width: 768px) {

    .element3, .element4 {
        display: block;
    }
    .element3 {
        margin: auto;
    }
    .element4 {
        margin: auto;
    }

}

[matthew-dean]

This was the goal of :extend in regards to @media, but it has not been implemented. (There's a discussion about it at #1165)

[lukeapage]

I cannot remember if it's a bug or on purpose, but if it was on purpose there is a reason for it. i seem to think there was a reason but I cannot remember.
It's either a bug or a feature that needs work. Someone needs to spend real time to determine which it is and implement it

[lukeapage]

I do remember a big question around what should happen if you extend from
within a media query vs extend ing outside on and effecting selectors
inside other ones. I don't think you can just decide it needs to be done.

[lukeapage]

Some people suggest ed it should only match if both are within a matching
media query.

[matthew-dean]

If that's what's most useful, I can see if I can combine this information in a particular feature request, but I think this issue covers it. To clarify, I ran into this issue, and came back to figure out what was happening, since the behavior didn't seem to match the spec (which I didn't by any means decide uniformly) and there was no note present on that issue or reference that said it had been updated.