Is escaping supposed to work with @supports?

[JayPanoz]

Much to my surprise, since @supports is bubbling like @media, it seems that you can’t use any arbitrary string as a variable value for it.

While

@min768: ~"(min-width: 768px)";
.element {
  @media @min768 {
    font-size: 1.2rem;
  }
}

results in

@media (min-width: 768px) {
  .element {
    font-size: 1.2rem;
  }
}

Escaping a string with @supports

@test: ~"(font-variant-caps: small-caps)";

.small-caps {
  @supports @test {
    font-variant-caps: small-caps;
  }
}

results in

@supports @test {
  .small-caps {
    font-variant-caps: small-caps;
  }
}

It failed in any implementation I tried (more or less 20) so I guess this is probably a core issue/feature request?

Is this result to be expected?

Problem is you can have awful feature queries like

@supports ((-ms-font-feature-settings: 'dlig') or (-webkit-font-variant-ligatures: discretionary-ligatures) or (font-variant-ligatures: discretionary-ligatures))

and escaping would be very welcome for such cases, especially as people discover @supports with the grid spec, Open Type features and stuff.

[seven-phases-max]

@min768: ~"(min-width: 768px)";

This is a stone age hack. Use Passing Rulesets to Mixins instead, e.g.:

// usage:
.foo {
    .if-small-caps({
        font-variant-caps: small-caps;
    });
}

// impl:
.if-small-caps(@style) {
    @supports (font-variant-caps: small-caps) {
        @style();
    }
}

I'll add feature-request label to this ticket (this was mentioned earlier I guess, but no dedicated ticket yet) - but personally I'd rather vote for removing this macro-like replacement from @media eventually.

[matthew-dean]

@min768: ~"(min-width: 768px)"; This is a stone age hack.

I would tend to disagree. Wrapping media queries (or support queries in this instance) in mixins is just one additional layer of abstraction. I much prefer something like @media @tablet { } to declare variations of a class for different @media targets.

Since @supports is supposed to bubble like @media, it's intuitive to be able to use the same variable replacement features. So I would label this a bug, just because users won't necessarily know that @media was historically special-cased from other at-rules. Any at-rules that can have rulesets should have the same general features IMO.

[seven-phases-max]

Well, the problem with these "macro-like" variable usage is that it needs a special dedicated support everywhere it's used and inherits all the cons of the vanilla text-replacement macros w/o bringing in any pros of them (at least a consistency of where and how they can be used).
If we need vanilla macros then they should be real macros not some hardcoded "variable-as-a-macro" code spread all over the compiler code-base w/o any consistency.

Someone would also find it useful to have something like:

@var: ~"rgb(128,";
color: @var 255, 0);

with the equal justification ("I don't need any abstraction level bla-bla-bla").

[matthew-dean]

o_O

Er, an un-parseable monstrosity is not an equal example. I'm not sure I agree with the description that it's a macro. It's creating an anonymous node, and it can go where anonymous nodes can go. Between color: and 255, 0); (an un-parseable value fragment) is not one of those.

However, it COULD look like:

@var: ~"rgb(128,";
color: @var ~"255, 0)";

...because it's just output of two simple anonymous nodes. There's nothing wrong with that in Less, so I don't get the argument. Anonymous node output is available pretty much (almost) anyplace in Less. If a variable that evaluates to an anonymous node is not working as expected, it's a bug. It has nothing to do with "macros".

Your argument seems to be just that you don't like the way that code looks, which is fine. Or that alternatives should be promoted, which is also fine. But that's really just a matter of programmer preference. It's still important that the feature is consistent as-is.

[matthew-dean]

Other alternatives as future features might be:

1. Allowing @var: (min-width: 768px) to be parseable, so it looks less "hackish".
2. Requiring at-rules to have something like @media @{var} (like selectors and properties) rather than @media @var, which might also look less hackish, since one is a variable in that declaration, and one is not.

However, those are just alternatives for possible future discussions, and neither is related to the core issue of this thread, which is just at-rule consistency.

[seven-phases-max]

Er, an un-parseable monstrosity is not an equal example.

Absolutely equal. Content of ~"(min-width: 768px)" is never parsed so it's possible only because the @media some-values { pattern is hardcoded right into the parser and the MediaQuery type itself (Not because the variable expands to a valid media features block). Just an easy-n-dirty kludge to quickly bring "what they asked" in - non-maintainable non-generic (that's what we can see right now - if you need something like this elsewhere, e.g. within @support, you need to go and implement this kludge for that elsewhere separately).

[matthew-dean]

so it's possible only because the @media some-values { pattern is hardcoded right into the parser

I think we're both agreeing on the same thing, and just suggesting a different outcome. Those patterns were hard-coded into @media, but then when at-rules support was made more generic, it seems those patterns were then narrowly still tied to @media at the parsing/evaluation stages.

So, I wouldn't suggest special-casing variable support to @supports; I would suggest just removing "special-case" support for @media so that all "wrapping" at-rules have the same variable interpolation features.

Probably the original version of @media @var should have looked like @media @{var} to look less ambiguous. But what the ~"" syntax allows in Less is for developers to essentially "fill-in" whatever parsing / styling feature may not be directly supported in Less, and just output a string as-is (and un-quoted). It's a powerful feature that allows a lot of flexibility, and support for workarounds. So it makes sense to just allow vars in at-rule statements like any other value, especially since it exists in @media already.

[matthew-dean]

So it makes sense to just allow vars in at-rule statements like any other value, especially since it exists in @media already.

Which, 🤔 when I phrase it that way, kind of implicitly DOES make it sound like a feature request. So I withdraw saying it's a bug, as it was designed that way intentionally. I would support it as a natural evolution of that feature though.

[seven-phases-max]

But what the ~"" syntax allows in Less is for developers to essentially "fill-in" whatever parsing / styling feature may not be directly supported in Less, and just output a string as-is

Yes, and this essentially brings us to #1648 (comment). So I'm just asking again maybe it's time to stop abusing variables as macros and bring macros in. The problem is that with allowing a more relaxed "where vars can be used w/o any syntax check" thing we just open the box of "uh-oh, I misprinted some ; - shouldn't compiler give me a error?"...
While with macros (while they don't have to perform any syntax checking at all) we still can validate things where they're supposed to be valid at least:

@min768: pi();

// OK
@media @min768 {
    .element {font-size: 1.2rem}
}

// ...
#define min333 pi() // <- whatever syntax

// error - not valid media query:
@media min333 {
    .element {font-size: 1.2rem}
}

While escaping thing (e.g. @var: ~"some non-parse-able mess";) remains untouched, keeps to do what it does now and is not involved where it should not be involved.

[matthew-dean]

Oh okay, the linked comment illuminates your thinking a little better. I'm only familiar with macros in Microsoft Windows & Office programming, which is recording and replaying a sequence of actions, and not just used for text replacement. (Is that a convention of text-based editors?)

Because I'm not familiar with whatever usage you might be familiar with, I don't really understand what your example is doing. So because I don't understand your example, and the example doesn't use actual media queries (as far as I can tell?), I'm not sure why macros are advantageous as you understand them.

I think one thing we can agree with: we both hate this as typical syntax @tablet: ~"(min-width: 768px)"; I may prefer it to wrapping in mixins, but I don't disagree that it's a hack for media queries.

So I get where you're coming from, basically: "If it's a hack, why expand usage of the hack?"

And my position is essentially, "If this hack is going to continue to be used, it should at the least be consistent."

So, if this hack is going to go away, then it probably needs a proper feature proposal. Otherwise (and maybe even if that feature will happen at some point in the future), it seems reasonable to extend to @supports and other at-rules in the short-term.

[seven-phases-max]

I don't really understand what your example is doing.

In above example (here I'm obviously talking about the simplest 'macro'-variants like those in C or PHP), we define a macro min333 with value of pi() so that the parser (before its later stages - see below) simply replaces any occurrence of min333 with pi() (regardless of context, scope - anything - since nothing actually exists yet). So when the media statement is actually parsed the source code text coming in is already @media pi() { ....

Though it might be a relatively tricky to implement within Less parser since it does not have a separate tokenizer stage - where a macro substitution could be easily injected.

[matthew-dean]

Hmm.... so if I understand correctly, the difference between ~"" and a macro is that a macro replaces the text, but after the replacement, it has to be a valid statement? If so, I get why that would be preferable.

I don't think that's a tricky as you might think, as long as:

1. Macro references had a very distinct signature for the parser (couldn't be interpreted as any thing else)
2. Unlike vars, macro definitions had to appear before they are referenced, and wouldn't follow scoping rules (or were simply required to be a child of the root node).

I don't think the macro reference could be a naked keyword for the Less parser, but if it was a special character that couldn't be mistaken for anything else, then you could easily add to a macro dictionary and quickly swap out values while parsing.

@define tablet "(min-width: 768px)";
@define mobile "(min-width: 640px";   // note missing parentheses
.box {
  @media ~tablet~ { 
    // ...
  }
  // could easily throw immediate parsing error
  @media ~mobile~ {
    // ...
  }
}
@define mobile "(min-width: 440px)";  // this does nothing, since it's not like a variable

Wrapping the macros / text snippets in quotes would allow for things like including semi-colons in your macro, since we already support quote escapes (and don't support semi-colon escapes). And using something like ~ might tie it to the idea of removing the quotes.

Of course, ~ would prevent easy detection and use of macros in selectors. It would be nice if it was language-wide without being over-verbose (like ~~mobile~~).

Thanks for explaining a bit more. Is my understanding of macros basically correct?

[matthew-dean]

I suppose something like this would be not too challenging, parser-wise, if we added a second tilde ~ on only one side:

@define selectors ".title, #main";
.box {
  .other-selector, ~~selectors, .and-one-more  {
    // easy detection of unique characters, and quick exit (lookup) at first non-alpha character
  }