Владислав Лысков, а как у вас элементы будут точно занимать 100, 50 и 33 процента? Вы же не знаете, сколько контента содержит каждый дочерний элемент. С учётом стандартного flex: 1, какой-то из этих элементов может быть больше других, если в них всех разный контент. И в любом случае это не особо решает проблему адаптивности, всё равно придётся использовать медиа-запрос.
Если вы в одном контейнере задали дочерними элементам flex: 0 0 100%, во втором — 0 0 50%, а в третьем — 0 0 33%?
Вам всё равно будет нужно адаптировать. Если хотите использовать flex-grow и -shrink, то это будет равносильно непредсказуемому поведению в плане расширения и сужения габаритов, которое будет зависеть от контента внутри дочернего блока.
Коля Шоря, как я писал выше, надо смотреть настройки сервера, а не данные Pingdom, если вы хотите узнать, работает ли GZIP. Меньше запросов — ясное дело, ведь нет запросов к Facebook.
Коля Шоря, Facebook не может блокировать GZIP на вашем сервере, потому как это технология вашего сервера. Iframe с Facebook не может влиять на настройки вашего сервера никоим образом.
ProgerSoft, у меня CSSNano обрабатывает calc(), сжимает названия анимаций до одной и более букв и убирает все пробелы в конструкциях по типу «rgba(1, 1, 1, . 2)». Да и селекторы с одинаковыми свойствами объединяет через запятую.
PinocioCORP, нет экранов меньше 320 пикселей. Косяк в JS тоже может быть.
Активируйте USB-отладку на телефоне, откройте проблемный браузер и попробуйте через Chrome на ПК сделать отладку через режим разработчика. Если там, конечно, этот браузер вообще отобразится. Стандартный браузер иногда можно отладить через Chrome, иногда нет. Видимо, должна быть совместимость с ним, если разработчики отдельной прошивки что-то меняют и делают какой-то отдельный браузер, хоть и основанный на Chromium.
ProgerSoft, у меня CleanCSS иногда ломал вложенные media-запросы. Но, возможно, дело исключительно в конфигурации.
CSSNano использую в стандартной конфигурации, если говорить не о Gulp-версии. Вполне возможно, у Gulp-версии CSSNano другая конфигурация, более агрессивная, поэтому сжимает она лучше.
Спасибо за результаты и тестирование, сегодня посмотрю!
ProgerSoft, уверенность — понятие относительное, всегда рад ошибиться касательно технологии, иначе нет развития. Касательно NanoCSS был уверен не в плане скорости, а именно в результатах на выходе (сжатие, объединение и т. п.).
NanoCSS пока ничего ни разу не сломал, что случилось, к примеру, с CleanCSS, но вполне возможно, что это мои косые руки.
Вообще, вы весьма интересную тему подняли.
Сейчас товарищ sim3x прислал ссылку (первую) на сводную таблицу результатов, есть повод задуматься. Надо тестировать.
ProgerSoft, да, пробовал как раз с level 2 (последний, как помню), ещё комбинировал другие параметры, но остановился на NanoCSS, результаты получались лучше в плане уровня сжатия кода. В любом случае, нахожусь сейчас в поисках инструментов лучше, чем NanoCSS.
Единственная проблема, которую заметил у NanoCSS, это ошибка пирсинга свойства calc(80px + env(safe-area-inset-bottom)). Решилось обособлением env() скобками: calc(80px + (env(safe-area-inset-bottom)));
sim3x, в этом вы можете быть правы. Но вы бы могли тоже привести аналоги, иначе не понятно, с чем сравнить. С технологиями не рождаются и живут всю жизнь. Я с удовольствием сменю NanoCSS на что-то более эффективное.
sim3x, но вы не учитывает великий и могучий фактор пользователей, которые заходят на сайт даже с IE11, Safari 10 и т. п.
Исходники всякого разного могут быть и 30 МБ. Вот у меня лежат исходники стилей целого веб-приложения с кучей всего — около 8 Мб. Обычные сайты — это около 500 Кб CSS, так что вполне нормальный инструмент.
sim3x, наверное, для лучшей поддержки браузеров? К примеру, perspective без префикса на iOS 10.X вызывает проблемы с z-index в ряде случаев, ну и тому подобное. В США, по статистике компании, где я работаю, нашими веб-сервисами с устройств на iOS 10 пользуются ~9% людей.
Autoprefixer надо, конечно, не тупо прогонять «last 20 versions», а настраивать его (+ оставлять функциональные комментарии для него в CSS-разметке). Transition'ы, конечно, префиксить не нужно, если нет цели поддержки древних браузеров.
NanoCSS работает быстро, если говорить на примере одного общего CSS размером как 100 Кб, так и 800+ Кб. Если куча мелких CSS (~90–100 штук) — примерно так же, как один.
Сборка из ~100 файлов LESS в один CSS + Autoprefixer + NanoCSS = 4–5 секунд на Macbook Pro 15 (2017). Общий размер CSS после этого — около 400 Кб. LESS-логика не особо сложная.
Но опять же скорость зависит от многих условий. Бывает и быстрее сборка, бывает медленнее.
