Compare current selector to other common selectors

[vhmth]

More of a feature request, but I would like to do the following (and I'm assuming others would probably want to do this at some point as well):

h2, h4 {
    // some shared less

    & {
        // some less specific to h2
    } when (& = h2)

    & {
        // some less specific to h4
    } when (& = h4)
}

So the feature request would be to be able to see if the current selector is another common selector. I'm not sure how the '&' operator works internally. If the functionality does not exist in a month or so, I'll probably return to less and look at its internals to see if I can implement something that allows for this within it (if you give me a green light and think that'd be something people would want). I could attach the commit here. I'm assuming there's some way to get the current selector state as you're building the CSS rules, so the comparison would just make a new selector path if this comparison ever showed up. It would also check if the current selector is a top-level selector and it could just make two "heads" to the selector state. So, in this case:

h2 {
    // shared less code
    // specific h2 less code
}

h4 {
    // shared less code
    // specific h4 less code
}

In other cases where it's not a top-level selector:

// all other normal less rules generated

<previous selectors> h2, h4 {
    // shared less code
}

<previous selectors> h2 {
    // specific h2 less code
}

<previous selectors> h4 {
    // specific h4 less code
}

[lukeapage]

why not write it as

h2, h4 {
}

h2 {
}

h4 {
}

.. e.g.

what advantage do you get with your code?

If we were going to implement this I would want to combine it with the request to have mixin guards on non mixins and then a request to be able to use & as a variable in mixin guards.

[lukeapage]

see #833 and #748

[vhmth]

Yes I agree with combining it with mixin guards on non-mixins. Someone would probably want this when a group of selectors share a ton of similarities but not many differences. For instance (with mixin guards on non-mixins):

h1, h2, h3, h4 {
    // lots of shared less

    & (when & = h1) { // or however you would want to do this syntactically
        color: blue;
    }

    & (when & = h2) {
        color: white;
    }

    & (when & = h3) {
        color: yellow;
    }

    & (when & = h4) {
        color: red;
    }
}

In my opinion, this is much more containerized and readable than writing the shared less and then each additional header selector separately. We just switched over all of our CSS to LESS at the startup I work at (around 7000 - 8000 lines of CSS), and it was a fairly common scenario to see where this feature would be a win. When I'm looking at LESS that extends from a certain class, it eventually turns into somewhat of a class definition, which is awesome because it's super readable. However, it's easy, as the code base grows and whatever else, for this to happen:

.post-card {
    h1, h2, h3, h4 {

    }

    // several lines of LESS

    h1 {
        color: blue;
    }

    // some lines of LESS

    h2 {
        color: white;
    }
}

I suppose it's also the job of the programmer to not fragment their LESS all over the place, but it would also be nice to just know "ok, all/most of the suff pertaining to headers will be compartmentalized into this one block".

[Soviut]

I think the situation you've presented is really just a matter of style and organization on the part of the stylesheet designer. It doesn't reduce the amount of code you need to write and it deviates so far from CSS syntax that it gets confusing to read as you scan down the sheet.

LESS, and even vanilla CSS, give you plenty of ways to organize and comment your styles. I don't see this as bringing any value. Also, with the :extend selector on the horizon, most of what you're trying to do here will be easily accomplished by defining your base styles and extending them. For example, h2 could be an extension of h1.

[matthew-dean]

Agreed with @Soviut & @agatronic. It's an interesting idea, but the use cases are / will be covered with existing and future syntax, and this syntax feels a bit clunky.

[lukeapage]

keep it in the 2 existing issues, have referenced this one