Discussion on Interpolation

[matthew-dean]

Related to #12. Moved from that issue:

For interpolators, I could see us doing one of two things:

1. just use variable interpolation syntax for both:

.class@{#ns[@var]} { }

.class@{#ns[prop]} { }

...but that leaves a redundant @ in the first example:
2. Use a more generic interpolation syntax, such as borrowing from mustache: {{ }} (but could be another pair of something, if the language starts to look too curly-bracy. But used here just to demo concept)

.class{{#ns[@var]}} { }
.class{{#ns[prop]}} { }
// or for local
.class{{@var}} { }
.class{{$prop}} { }

Existing interpolation syntax (1) could be deprecated but still supported throughout 3.x.

For single property accessing, syntax doesn't need to change.

color: red;
border-color: $color;

One possible benefit of adopting a new interpolation syntax is that it doesn't need to just contain identifiers but could, like mustache, contain expressions:

.icon_{{ @startNum + @i + 1 }} { }

That's just a possible benefit, not a necessity.

Response from @seven-phases-max (which I agreed with):

As for the selector interpolation stuff, I would not take it so far yet. It's a big story on its own.
After all, the @{} syntax initially was invented for strings only, then when (~"@{var}") (almost accidentally) was found to also be usable in selectors, it was decided to be reduced to just @{var}.
The biggest problem with those curly braces in selectors is that they really make things harder to read because of the same symbol used for CSS {} block itself. So while @{} found its way to selector interpolation for some historical reasons, if we are about inventing a new syntax (especially if it's targeting for an arbitrary Less statements to appear there), the {{ }} is the last thing I'd vote for (ref.).

[calvinjuarez]

For this discussion, it might be useful to note the following:

• ., #, |, ,, *, :, ,>,+,~,[, and] already have specific meaning in CSS Selectors.
• { and } are ambiguous because CSS uses them to delimit the block, as was noted above.
• $, ^, ~, |, and * are used in attribute selectors (the first 3 exclusively so in CSS).
  • $ is gonna be used for property reference.
  • ~ is also meaningful in Less at the moment.
• " and ' are string delimiters in Less and CSS, and are allowed in attribute selectors.
• @ is used for CSS At Rules and Less variables.
• % is a Less function.
• & has specific meaning in selectors for Less.
• ! has (or will likely have) a specific function in CSS Selectors (not to mention strong connotations).
• ` doesn't seem to have any specific meaning in either language, afaik.
• / is for paths and the CSS Reference Combinator, \ is for escaping.

[calvinjuarez]

Note: The following is meant primarily as food for thought; I'm just spitballing.

>

Honestly, if a new syntax is required, it seems fairly safe to use <, since CSS probably won't be using it. > is the child selector, but because of how a selector's subject is determined, < won't likely be the parent selector. Instead, it's likely to be something like E! > F (or something similar; see http://www.w3.org/TR/selectors4/#subject).

The preferred use of < would be as a delimiter along with >, though, I imagine. And that starts to get ugly with the child selector:

.class< @var > > li,

Proper code coloring would probably make that conflict a non-issue, but you can't really guarantee proper coloring. Although, in that case, is it really much better than {}?

Examples

.class<@var>,
.class<$prop>,
.class<#ns[@var]>,
.class<#ns[$prop]>,
.class<.ns[ident]>,
.class<@ns[ident]>, {
  // ...
}

^

^ also seems fairly safe, though since it's not a delimiter-type character, it'd require more of a no-spaces syntax.

Examples

.class^@var,
.class^$prop,
.class^#ns[@var],
.class^#ns[$prop],
.class^.ns[ident],
.class^@ns[ident], {
  // ...
}

%

I personally like the idea of deprecating the format function %() (since it's a special, very short function name for what seems an uncommon function).

Doing so would allow using % as an interpolation signifier (and since there's technically no conflict, you could still leave the function functional). Since Less uses a modulo function rather than using % as the modulo operator, there's no conflict there.

I don't know if it would be best to use it just at the beginning, or at the beginning and end, though. Or whether even <%...%> might make sense.

Examples

.class%@var,
.class%$prop,
.class%#ns[@var],
.class%#ns[$prop],
.class%.ns[ident],
.class%@ns[ident], {
  // ...
}

[seven-phases-max]

.class<@var> looks fine for me - but (I guess) only because my eyes use to use C++ templates (#<@a>>.<@b>? :-/). Aside of that the more I think of the feature the more I doubt if the use-case is actually to appear often enough to deserve to pollute the language with a new operator(s). After all we also do not let functions, arithmetic expressions etc. and so on to be used directly within selector interpolation.
So if this important should not we instead invent a generic construction for all of these? i.e. "start any arbitrary expression here, end it here" instead of searching for (always artificial) marker/symbol for each specific feature. I.e. (intentionally using weird pseudo-syntax):

div.:expr(replace(extract(foo bar baz, #ns[offset] - 2), a, lu)) {
    // ...
}

After all, a minimal verbosity was never a goal of Less, and unconscious hunt for it would rather lead to a thing... like hmm... Perl.
(so leaving things as they are:

@name: replace(extract(foo bar baz, #ns[offset] - 2), a, lu);
div.@{name} {
    // ...
}

also does not look like a major fault).

[matthew-dean]

Aside of that the more I think of the feature the more I doubt if the use-case is actually to appear often enough to deserve to pollute the language with a new operator(s)

I don't disagree with that. Or, at the least, the feature seems less of a priority to me than other 3.0 features, so that may already indicate that it doesn't have enough value to be added at this time. After all, it's not a requirement for namespacing. It's just that we addressed interpolation in the previous namespacing discussion, and the newer proposed syntax doesn't really gel with interpolation syntax. So, it's a little bit of a conflict, unless we simply require the author to assign a namespaced var to a local var, and use that with interpolation. Which is really not bad as an interim solution.

Just to prioritize other features, we could possibly shelve this for now and re-consider in the context of a future release? Or should we close entirely? What do you think?

[seven-phases-max]

I think it's OK to leave it open, just to demonstrate that the feature is/was considered but w/o any solid outcome yet.

[matthew-dean]

Old thread, but what about just bringing in Sass's syntax for interpolation, where it can hold an expression? Basically, any place that can old an interpolated var can hold the interpolated expression. As in:

.class-@{var} { }
// and
.class-#{@var + 1} { }

In terms of parsing and evaluation, this would have very little overhead, as a single Less variable today can itself point to an operation. I would even suggest deprecating ${prop} and @{var} for #{prop} (or #{$prop}) and #{@var}, but allowing both to co-exist for 4.0.

There's no reason to re-invent the wheel here, and I see nothing inherently wrong / incompatible / problematic with Sass's interpolation syntax.