WordPress Core использует препроцессор Sass CSS

Почти год назад Крис Уоллес предложил, чтобы ядро ​​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 принесет новый яркий день для фронтенд-разработчиков, которые вносят свой вклад в ядро.