Через пару месяцев пройдет 2 года с тех пор, как я начал использовать Sass. Почти каждый день. На работе. Дома. На сторонних проектах. В тот момент, когда люди обращаются за моей помощью, когда дело касается Sass, и верят мне, я очень рад помочь, когда смогу.
Некоторые запросы справедливы. Некоторые очень просты, но эй, мы все начали где-то. А некоторые просто безумны. Смотри, я не судья; в какой-то момент каждый человек, использующий Sass (или любой другой препроцессор в этом отношении), испытывал искушение чрезмерно спроектировать что-то, чтобы упростить ситуацию . Меня включали и не раз.
Давайте оптимизировать!
На днях меня спросили, как это сделать:
.class {
width: 20px;
}
.other-class {
width: em(.class:width);
} По сути, преобразуйте .classem.other-class Подумайте об этом на секунду. Мало того, что pxem Нет.
Даже Стилус, который хорошо известен как достаточно продвинутый, не может этого сделать. В лучшем случае он может ссылаться на значение свойства в том же блоке кода (известный как поиск свойства ). Очевидно, Сасс, будучи гораздо более консервативным, тоже не может этого сделать.
Но проблема не в том, чтобы иметь возможность делать что-то подобное. Проблема в том, чтобы хотеть сделать что-то подобное . Этого не должно быть. Когда-либо. Если вы столкнетесь с ситуацией, когда вам это нужно, вы, очевидно, делаете что-то не так.
Примечание: если вы когда-нибудь хотели сделать что-то подобное, не стыдитесь и не обижайтесь. Это только один пример из многих .
Потому что мы можем
Хорошо, давайте согласимся с тем фактом, что приведенный выше запрос действительно является неправильным способом использования Sass. Хотите более спорный пример? Список изменений Sass 3.4 недавно появился повсюду, продвигая функции входящего селектора. Эти функции предназначены для управления селекторами, такими как списки, такими функциями, как selector-nest()selector-replace()
Как бы я ни старался, мне еще не удалось найти ни одного законного варианта использования функций селектора. Некоторые люди в Твиттере пытались убедить меня такими примерами:
@mixin context($old-context, $new-context) {
@at-root #{selector-replace(&, $old-context, $new-context)} {
@content;
}
}
li {
float: left;
ul {
display: none;
@include context('li', 'li:hover') {
display: block;
}
}
}
Хотя я согласен, что это делает работу умным способом, я не думаю, что это проще. Я думаю, что это усложняет ситуацию. Я думаю, что это добавляет сложности кода там, где их не должно быть.
Почему бы не написать это так?
li {
float: left;
ul {
display: none;
}
&:hover ul {
display: block
}
}
Теперь это просто. Это понятно. Я чувствую, что иногда мы используем вещи только потому, что они существуют, а не потому, что мы должны их использовать. Также известен как синдром « потому что мы можем» .
Как ты сюда попал?
В некотором смысле, я чувствую себя немного виноватым по этому поводу. Я сделал несколько сумасшедших вещей с Sass (например, здесь и здесь ) и показал их, вероятно, без предупреждения о том, что эти методы в основном экспериментальные.
Я думал, что это было достаточно очевидно. Когда вам нужно написать десятки строк Sass для вывода пары строк CSS, вы должны быть подозрительны. В восторге и заинтересованности, да, но все еще с подозрением использовать его в производстве.
Кажется, если вы дадите людям слишком много власти, в конечном итоге они будут злоупотреблять ею. Хуже того, они, вероятно, захотят еще больше власти. Вот как мы с CSS препроцессорами. Переменных было недостаточно, поэтому мы получили миксины. И функции. И массивы. И все больше и больше. И мы не переставали думать о том, что мы делаем и почему мы это делаем.
Я не остановился, пока не начал делиться базой кода с разработчиками, которые практически не имели опыта работы с CSS. Излишняя инженерия и сумасшедшие вещи больше не были выбором. И я рад.
Должны ли мы отказаться от Sass в целом?
Суть этой статьи не в этом, тем более что в Sass нет ничего плохого. Вы знаете поговорку:
Препроцессоры не выводят плохой код. Плохие разработчики делают.
Sass — замечательный инструмент, когда вы знаете, как его использовать и как его не использовать. Вопреки тому, что думают некоторые, нет ничего плохого в миксинах или функциях — даже сложных — если они не слишком сложны. Сложный не сложный.
Нет ничего плохого и во вложении, если вы держите его под контролем. Насколько я понимаю, я склонен избегать вложения, потому что это делает код намного сложнее для чтения.
Хотя я люблю это, когда речь идет о псевдоклассах и псевдоэлементах, я думаю, что это может быстро запутаться, когда вложенные селекторы внутри друг друга, как в следующем примере, взятом из этого поста :
.tabs {
.tab {
background: red;
&:hover {
background: white;
.tab-link {
color: red;
}
}
.tab-link {
color: white;
}
}
}
Нет. Слишком много для меня. Я бы лучше написал:
.tabs .tab {
background: red;
&:hover {
background: white;
}
}
.tab-link {
color: white;
.tabs .tab:hover & {
color: red;
}
}
И знаешь, что? Первый пример длиной 176 символов, а второй длиной всего 152 символа. Так что глубокая вложенность не обязательно спасет вас персонажей.
Но это весело!
Да, это так. Я знаю, это. Я парень, который написал JSON-парсер из Sass и реализовал побитовые операторы только с SCSS . Конечно это весело!
Избыточное проектирование не только весело, но и полезно! Я нашел несколько небольших ошибок в Sass ( # 1090 , # 1265 ), когда делал неожиданные вещи. Я также стал лучше в Sass, делая неожиданные вещи. Вы не поправляетесь, определяя 3 переменные для каждого проекта. Вы поправляетесь, раздвигая границы.
Но вам нужно знать, где остановиться. Вам нужно знать, когда все зашло слишком далеко, и вы больше не полностью контролируете свой код. Мне потребовалось почти 2 года и в основном крупномасштабный проект, чтобы понять это. Все не предназначено для использования везде. Эксперименты не относятся к производственной среде. Мало того, что это неправильно, но на самом деле это может быть довольно опасно.
Рассмотрим этот хак, который я придумал, чтобы обойти ограничения, касающиеся директив перекрестного медиа-запроса @extend Он использовался в DoCSSa как — я цитирую — СУХОЙ подход. Это действительно так. За исключением того, что это нарушает каскад . Поскольку заполнители создаются и расширяются на лету, ваш CSS перемещается тут и там, что может привести к неожиданному поведению.
Эта техника была экспериментом. Он не предназначен для использования в огромной среде Sass, которая должна решать все проблемы. Это не должно было использоваться в производстве, по крайней мере, без полного понимания последствий. Тем не менее, он используется таким образом.
Последние мысли
Продолжайте экспериментировать! Не прекращайте взламывать Sass, потому что это круто. Просто будьте осторожны с тем, что вы делаете в реальных проектах. Прежде всего, будьте проще. Меньше — больше.