А почему вам RTLCSS не кажется качественным? Всё таки WordPress — огромный пользователь. ВКонтакте тоже собирается переходить на RTLCSS.

А почему вам кажется, что нужно будет выключать RTLCSS чаще, чем писать примесь? Может попробуйте на каком-нибудь маленьком тестовом проекте — вы тогда сразу прочувствуете как удобно стало.

Я согласен, что PostCSS не захватил все ниши. Но у вас есть логическая ошибка — вы думаете, что CSS-инструмент = препроцессору.

На самом деле PostCSS стал самый популярным CSS-парсером уже, котрый загружается с npm — графики.

Причина в том, что PostCSS используется в куче новых CSS-инструментов, которые не являются препроцессорами. CSS Modules, css-loader в webpack, Stylelint, Autoprefixer, cssnano, uncss, RTLCSS.

Отключить вам нужно в 1—2 местах. А примесь использовать в сотне.

Практически все люди в Иране, которым я показывал RTLCSS были без ума от него — они явно отлично разбираются с практикой. Так же WordPress использует только RTLCSS и тоже отлично отзывались о её эффективности на CSSConf в Нью-Йорке.

Я понимаю, что часто хочешь взять что-то старое и не учить, но RTLCSS — «абсолютный хищник» в своей нише. Все кто занимается этим вопросов плотно высоко оценивают его полезность.

Для каждой локали не надо — один для обычных языков, второй файл для RTL-языков.

Вообще есть проект, который исправления RTLCSS не в отдельный файл переносит, а дописывает таким «патчем», как в вашем первом комментарии.

Но автор RTLCSS (он из Египта и постоянно занимается вопросом RTL) считает, что отдельный файл — проще. Всё равно сборка автоматизирована. Зато максимальная оптимизация по размеру и кол-ву запросов (но, опять же, если вы другого мнения это легко изменить — гибкость PostCSS позволяет).

Понятно, что на практике иногда думать приходиться. Но, например, в репозитории проекта есть перевёрнутый сайт ГитХаба — весьма неплохо, большинство вещей сделано.

То есть думать придётся, но на порядок меньше.

Для вас есть синтаксис SugarSS. PostCSS позволяет менять парсеры.

Есть специальные управляющие комментарии, которыми можно выключить магию (выключить нужно гораздо реже)

Какой в этом смысл? 99% что я специально написал это правило и специально пренебрег его поддержкой в IE — graceful degradation.

Сейчас лучше всего этот плагин вызывать из Stylelint — там у вас будет спец. комментарий, чтобы явно указать, что вот в этой строчке всё в порядке — вы добавили graceful degradation. С такими явными комментариями и код понятнее (показано что это graceful degradation) и не получиться забыть где-то вставить продумать graceful degradation.

Давай-те объясню чуть точнее, как работает RTLCSS, чтобы было понятно, почему его нельзя сделать на Sass.

Вы пишите обычный код для обычного языка и даже не думаете об арабском:

.menu { left: 10px; text-align: left; }

Потом запускаете RTLCSS и он выдаёт отдельный файл для арабской локали, где будет:

.menu { right: 10px; text-align: right; }

То есть RTLCSS похож на Автопрефиксер — он сам находит нужный свойства в вашем CSS (те, которые специфичны для лево-право) и заменяет их на обратное значение.

В Sass у вас просто нет API для сканирования CSS, только то, что явно указал разработчик в качестве примеси (то есть придётся постоянно думать и легко забыть).

1. Чтобы был универсальный фреймворк для создания CSS-инструментов (PostCSS), так что инструменты будет легче делать
2. Чтобы все CSS-инструменты строились на основе одного фреймворка — переиспользовали больше кода, меньше конфликтовали

Не понял. Можете подробнее описать?

Можно проще — положить куку last_request со временем последнего запроса. Если статика изменилась с последнего запроса — шлём новую версию.

Да, хороший вопрос, как делать CDN на базе HTTP/2. Можно сделать в виде прокси-сервера. Клиент подключается в CDN и запрашивает index.html. CDN проксирует запрос на index.html в главные сервера, а сам в это время начинает отдавать статику (по заранее подготовленной сборщиком таблице зависимостей)

«Замену E-Tag» можно сделать через обычный cookie.

Разносить на разные сервера нужно было в HTTP/1 из-за ограничения кол-ва запросов. В HTTP/2 весь смысл этого пропадает.

Как конкретно делать pre-push — второй вопрос. Можно заранее составить картинку зависимостей. И использовать какой-то аналог E-Tag на клиенте (старый E-Tag не подойдёт)

Исследование в статье неверное, так как строится не неправильном понимании HTTP/2. Просто смена протокола даёт не самое большое ускорение и не позволяет заменить спрайты. Но протокол даёт новые инструменты, с помощью которых как раз можно и добиться существенного ускорения.

Для замены спрайтов есть специальный инструмент pre-push. Это когда сервер может ответить сразу несколькими файлами на один запрос. Например, пользователь запрашивает index.html, а сервер сразу отвечает index.html, app.css, logo.png, img1.png, img2.svg.

Очевидно, что pre-push как раз позволяет сделать такой аналог спрайта (все файлы уходят на один запрос). pre-push даже гораздо лучше спрайтов, так как в одном ответе может быть и HTML, и PNG, и SVG.

Кроме того, pre-push может быть гораздо умнее спрайтов и отвечать только новыми картинками, если только часть из них обновилась.

Соответственно, нужно тестировать не просто HTTP/2, а новый веб-сервер, который поддерживает pre-push. К сожалению, такого сервера (или сборщика) ещё нет. Поэтому все разговоры про то, что HTTP/2 уже здесь — преждевременные.

А вы используете Автопрефиксер или другие плагины для PostCSS?

Ну я и говорю, что цензура — не главная проблема на Кубе. Поэтому интернет в Иране несравнимо лучше и находиться совсем в другой категории (ближе к обычным странами третьего мира).

Не на российском ресурсе об этом говорить — у нас сайты тоже блокируют .

Но в этом абзаце фактическая ошибка. Проблема кубинского интернета не в цензуре, а в его стоимости и недоступности.

В Иране интернет доступен всем, есть ночные безлимитные тарифы, люди, с которым я общался, скачивают сериалы.

То есть интернет в Иране можно сравнить с интернетом на Бали или Пхукете (там тоже блокируют сайты, но он доступен населению). Но не с Кубой.