Почти год назад Крис Уоллес предложил, чтобы ядро WordPress внедрило препроцессор CSS, чтобы помочь перенести CSS пользовательского интерфейса администратора в будущее. Включение препроцессора CSS позволяет разработчикам ускорить выполнение задач с использованием переменных в таблицах стилей. Переменные упростят такие задачи, как изменение внешнего вида администратора WordPress. Уоллес решительно выступал за Sass в своем билете из-за его относительно низкого барьера для входа из-за того, что он в своей основе следует соглашениям CSS.
С включением MP6, наконец, блокировки для WordPress 3.8, Хелен Хоу-Санди возобновила дискуссию о препроцессорах CSS, выделив оригинальный билет Уоллеса в основном блоге разработчиков make.wordpress.org. После эпических дебатов о Sass и LESS кажется, что Sass победил и будет принят в качестве препроцессора CSS для WordPress в будущем.
Почему Sass?
Сторонники Sass приводили множество причин, по которым он лучше подходит для WordPress, чем другие препроцессоры CSS. Чтобы быстро подвести итоги обсуждения, я изложил лишь несколько важных аргументов в пользу препроцессора CSS в целом и Sass в частности:
- Позволяет использовать переменные для расчета ширины макета, создания цветовых схем, размеров шрифта и т. д.
- Уменьшает HTTP-запросы при объединении таблиц стилей в одну.
- Легко минимизируйте сгенерированные файлы CSS в связанных версиях WordPress, чтобы ускорить время загрузки.
- Sass совместим с GPL, под лицензией MIT.
- Sass обратно совместим со всеми версиями CSS.
- Sass поддерживает более продвинутую логику — возможность включать операторы if/then/else и for/while/each.
Основная проблема с Sass заключается в том, что он зависит от Ruby и драгоценного камня Sass Ruby. Усилия по устранению зависимости от Ruby привели к использованию grunt-sass , что позволяет компилировать файлы .scss без Ruby.
Включение возможностей Sass в WordPress 3.8 принесет новый яркий день для фронтенд-разработчиков, которые вносят свой вклад в ядро.
