Ответ 1
Во-первых, я бы сильно отговаривал делать такие вещи. Вместо этого попробуйте использовать мощь CSS и создать свой HTML, например, например, правила загрузки. В любом случае, поскольку вы просили об этом, вот решение.
Проблема заключается не в сложности селектора, либо в дочернем правиле, а в роли селектора имен тегов (например, li
). Итак, что мы должны исправить, это парсинг mixin, соответствующий только классам и идентификаторам. Думаю, нам не хотелось бы вмешиваться в первый класс или тест id, , поскольку это, вероятно, необходимо для того, чтобы отличать миксины от обычных правил CSS (хотя тесты выполняются нормально, и эта проверка прокомментирована). (На самом деле в действии есть предпочтение синтаксического анализатора, и единственное, что было пробовано после того, как mixins - это комментарии и директивы, поэтому мы также можем безопасно удалить эту проверку), Однако мы можем легко разрешить имена тегов в более поздних частях селектора mixin, добавив знак вопроса после [#.]
в соответствующее регулярное выражение. Так
while (e = $(/^[#.](?:[\w-]|\\(?:[A-Fa-f0-9]{1,6} ?|[^A-Fa-f0-9]))+/)) {
- i. е. строка 825 - становится
while (e = $(/^[#.]?(?:[\w-]|\\(?:[A-Fa-f0-9]{1,6} ?|[^A-Fa-f0-9]))+/)) {
Тесты все еще проходят через мелкие, потом, но тонкие поломки, которые я встречаю, поэтому будьте осторожны.
Изменить: Для этой же проблемы существует проблема GitHub. По-видимому, тем меньше людей предпочитает, чтобы функция mixin была более узкой и функциональной, а не позволяла более гибко... хорошо... смешивать правила. Что касается вывода CSS, это, вероятно, разумно.