Feature request: support checking html element in guards

[lunelson]

It would be nice to be able to write a guard function for a mixin, that could check the html element that it is being declared for. It would look something like this:

.set-margins(@font-size) when (element = ul) {margin-left: @font-size * 2;}

This is part of a larger approach I am using to build a suite of typographic sizes and measures in to a kind of master mixin. It could be very powerful if there was a way of checking...

[lunelson]

Although now that I think of it I could add an argument to the mixin to specify the element. It will require more declarations still though

[lukeapage]

I think your suggestion sounds better - otherwise we open ourselves to having to add quite complex tests for the context of the mixin call just to save passing something to pattern match against,,

[lukeapage]

as in #1174 it might be useful to be able to reference the current selectors in guards

[matthew-dean]

I don't get how this would work? How is it applied to that element? What is the keyword element referencing?

[seven-phases-max]

I suppose element is some sort of "expand & as a regular value"... E.g. (pseudo-code):

.set-margins(@font-size) when (& = ul)  {
      margin-left: @font-size * 2;
      me: &;
}

ul {
    .set-margins(33);
}

resulting in:

ul {
    margin-left: 66;
    me: ul;
}

I was pretty sure such FR (with &-based syntax) already exists, but hmm, can't find...

[matthew-dean]

What.... I don't get this at all. & can never "=" ul because & is a collection. It just happens to have a single member. Even if you can resolve that detail, I think this idea has way too many unintended side-effects, where the value of & is not so explicit. And, it has no discernable value over:

ul {
  .set-margins(33, ul);
}

... other than a very minute reduction in length of code, but that's traded for a much clearer explicit call, without unintended results of implementing this as a feature in general. So.... I say no, because the possible downsides are way greater than any possible benefit.

[seven-phases-max]

Mmm... basically it's just regular "parent selector" (well, sort of) but also allowed to be used as property value (not just in selector string as it is now), e.g.:

red {
   color: &; // -> red
}

[matthew-dean]

@seven-phases-max o_O That wasn't the request. It was to guard against the selectors used by the calling block.

[seven-phases-max]

It's basically the same thing, obviously any value in guard is a regular value so if it can be used in guards it also can be used anywhere... We don't have special "guard" values. :)
I guess the op did not mean that but it makes itself automatically :)

[matthew-dean]

@seven-phases-max ...Okay, but then there are even fewer cases where that would have any usefulness.

[seven-phases-max]

Maybe. maybe not. Currently the only use-case I can imagine is something around #1694 (comment).

[matthew-dean]

Btw, this statement isn't true IMO:

It's basically the same thing obviously any value in guard is a regular value so if it can be used in guards it also can be used anywhere

A guard can have a detached ruleset, can it not? But a DR can't be used in place of a property's values, even though it's a value passed to a mixin. There are still rules about where that node type can be used, and & is basically a list of selectors. Selectors can only be used where selectors can be used; they can't be dumped in as a generic value.

[seven-phases-max]

But a DR can't be used in place of a property's values, even though it's a value passed to a mixin.

It's artificially suppressed at the parsing stage. In fact if you assign a DR to a property within a plugin (i.e. bypassing the parsing stage) it will work (expanding to void though).

Edit: parsing stage evaluation stage of course (the error issued is explicitly hardcoded). Though it does not matter. I guess this can be closed due to lack of use-cases and inactivity (until someone comes with similar propose and some useful use-case example).

[matthew-dean]

@seven-phases-max Still, I think you're confusing the issue with your example. That's a whole other deal. Right now the only request is within mixin guards, and referencing & as a property value should be opened as a separate issue, if you think that feature is important.

I went through the thread in #1174, which IMO has a much better explanation / use case for this (that is: an actual use case - it would make sense to have closed this issue and left that one open, but nm). Similarly to my comment on that a while back, and what I noted again here, anything like & = is an awkward semantic construction. If we just want to match a selector from the caller scope, I would avoid treating & as you say as a regular value, and expose a matching function, like match(), as in:

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

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

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

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

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

The reason why I say that is because & represents all of those selectors, but during evaluation, each member of & is being expanded, and so that's what you're really trying to match, not all of & it self.

Although, even match() seems semantically like "contains" which means that all of those blocks should expand for every selector. Basically I think it should be a function that represents theCurrentEvaluatedMemberOf(&), that thaaaat's just a bit too long.

[seven-phases-max]

Closing per discussion above (use-cases are welcome).