Less.js: Недопустимое слияние вложенного медиа-запроса с условием «или», когда переменная используется для суб-медиа-запроса.

Это скорее запрос функции, чем ошибка. Предполагается, что Less не понимает, что находится внутри этих ~"" ( где угодно , а не только для медиа-запросов). Поэтому ожидается, что Less никогда не узнает ни о каких запятых или других специальных символах.

Технически, приведенный выше код («список медиа-запросов в экранированной строке») больше похож на старый обходной путь / синтаксис, чем когда-либо считался правильным кодом (опять же из-за самого ~"" ). В сегодняшнем Less правильным шаблоном для достижения того же самого было бы использование анонимных / отдельных наборов правил / миксинов вместо «переменной магического значения», например:

.highdpi(@rules) {
    <strong i="10">@media</strong> (-webkit-min-device-pixel-ratio: 1.25), 
           (min-device-pixel-ratio: 1.25), 
           (min-resolution: 1.25dppx) {
        @rules();
    }
}

.bg {
    <strong i="11">@media</strong> (max-width: 1000px) {
        background: url(bg-small.png);

        .highdpi({
            background: url([email protected]);
        });
    }
}

или аналогичные методы.

Относится к № 1421 и аналогичным вопросам / запросам.

Обратите внимание, что даже в качестве запроса функции (если предлагается) эта функция в любом случае должна будет использовать другой синтаксис вместо ~"" , т.е. пример никогда не должен работать так, как ожидалось выше, поэтому я не отмечаю это как " запрос функции "(поскольку FR потребует немного больше понимания).

Может быть, слияние с №1421?

@ seven-phase-max спасибо, что прояснили это. Я собираюсь изменить свой миксин, чтобы использовать другой миксин ".highdpi" вместо переменной с экранированной строкой.

@ seven-phase-max Я думаю, что здесь есть две отдельные проблемы / запросы функций, поэтому не уверен, следует ли нам объединиться с # 1421 без их указания.

1. Разрешите синтаксическому анализатору Less быть более слабым с выражениями и списками. Например, разрешить создание списков из значений или селекторов медиа-запросов. Таким образом, экранирование строки не должно быть обязательным требованием при преобразовании медиа-запроса в переменную. (Это обычная потребность.) Это # 1421, и пример @media может быть чем-то еще добавленным к этой проблеме.
2. Списки слияния вложенных значений медиа-запросов (зависит от #1 , но должен иметь отдельный проход / отказ от #1 . Хотя после этого #1 , #2 следующий логический шаг. Итак, я думаю, мы можем отследить это здесь, в # 2964.

Ссылка на # 3059 здесь, поскольку по сути это почти та же проблема. Т.е. в основном вопрос: «Можем ли мы позволить себе полнофункциональный повторный анализ запросов @media @supports и т. Д. И т. Д. После того, как переменные заменены их значениями?» (Это требует либо серьезного рефакторинга самого синтаксического анализатора, чтобы его можно было использовать в произвольной строке в любой момент, либо дублирования кода синтаксического анализа на каждом конкретном узле и его функциях eval / css-gen).

Эта проблема была автоматически помечена как устаревшая, поскольку в последнее время не было активности. Он будет закрыт, если больше не будет активности. Спасибо за ваш вклад.