Большая ошибка CSS Media Query
Опубликовано: 2017-05-15Вы когда-нибудь чувствовали себя странно, когда все вокруг вас делали что-то, что вы обычно считали бы неправильным (или, по крайней мере, не совсем идеальным), но почему-то кажется, что никто не хочет ничего говорить по той или иной причине? Это очень странное чувство — видеть, как все стараются изобразить несчастного наблюдателя как можно лучше. Это чем-то напоминает мне ту старую басню «Новое платье императора».
Я всегда так думал о медиа-запросах CSS. Почему все так принимают технологию, которая, кажется, не выполняет свою работу? Почему мы, как сообщество, не объединились и не улучшили его реальным и значимым образом? Почему мы не придумали что-то лучше?
Сегодня медиа-запросы CSS являются функциональным краеугольным камнем адаптивного веб-дизайна. Но он никогда не был разработан для того, что все используют его сегодня, и доказательство тому — практика. Я все еще часто натыкаюсь на веб-сайты при использовании планшетного устройства, которые на первый взгляд кажутся хорошо спроектированными, но просто выглядят и чувствуют себя совершенно неуверенно, когда вы проверяете их темпы.
В этом подходе к отзывчивому веб-дизайну есть что-то принципиально неправильное, что мы просто еще должным образом не рассмотрели, и я хотел бы быть одним из немногих голосов, которые призывают императора за его наготу в этом вопросе. К счастью, в наши дни я рад, что шанс быть сожженным на костре за такую альтернативную точку зрения практически нулевой.
Что не так с медиазапросами CSS
Медиа-запросы CSS были разработаны для чего-то, но это не адаптивный веб-дизайн. Исходя из моего опыта, вот семь (7) серьезных проблем, с которыми я столкнулся при попытке использовать их для работы с веб-сайтами:
1. Не интуитивно понятно:
«Медиа-запросы CSS интуитивно понятны», — никогда не говорил ни один веб-дизайнер. То, как вы определяете медиа-запрос, довольно простое, но не всегда точно ясно, как все будет работать в реальных браузерах, на реальных устройствах и во множестве сценариев.
Только экран @media и (минимальная ширина: 320 пикселей) и (максимальная ширина: 480 пикселей) {
/** Здесь находятся правила CSS **/
}
Приведенный выше код применяется к области просмотра, когда она находится между 320 и 480 пикселями. Тем не менее, это не совсем окончательный [или интуитивно понятный], когда вы хотите сделать что-то более конкретное, например применить правило стиля, когда устройство представляет собой планшет в горизонтальной ориентации. Не исключено [своего рода] настроить медиа-запрос для этого, но это определенно не интуитивно понятно — или окончательно.
2. Ограниченная обусловленность:
Медиа-запросы CSS являются динамическими и позволяют вам определять условные операторы в вашем CSS. Например, если вьюпорт находится между этим и этим, то сделайте другое. Однако в основном вы ограничены соображениями области просмотра, и есть много других условных сценариев, которые имели бы смысл в современном веб-дизайне.
Допустим, вы создаете прогрессивное веб-приложение. Бывают случаи, когда было бы полезно по-разному стилизовать определенные элементы пользовательского интерфейса в зависимости от ОС. Например, для устройств iOS принято располагать панель вкладок внизу, а для Android — наоборот. Итак, как именно вы можете заставить это работать с медиа-запросами CSS?
Вы не можете, потому что мультимедийные запросы CSS не содержат никаких функций, которые позволили бы вам. Помимо этого, существует множество других настроек, которые вам, возможно, потребуется выполнить с помощью CSS, но медиа-запросы не подходят, когда вам нужны различные степени от простых до сложных условий.
3. Не расширяемый по умолчанию:
Медиа-запросы CSS — это функциональность, встроенная в браузер. Это означает, что он изначально не является расширяемым. Другими словами, вы не можете добавлять дополнительные и расширенные возможности к медиа-запросам CSS изначально через интерфейс CSS.
Даже если новые функции медиазапросов CSS будут одобрены [многострадальным] процессом веб-стандартизации, все равно потребуется время, прежде чем эти функции станут пригодными для использования из-за повсеместного распространения. Кроме того, не каждая добавленная функция может оказаться для вас полезной, поэтому вам остается найти какой-то другой способ решить вашу конкретную задачу, если вы не получите то, что хотите.
Конечно, есть способ расширить CSS, но вы должны очень хорошо знать JavaScript, а это не тот процесс, который подходит большинству веб-дизайнеров.
4. Не подходит для дооснащения:
Некоторым может быть трудно в это поверить, но до того, как появились мобильные устройства, на самом деле было много веб-сайтов, и ни один из них не был оптимизирован для мобильных устройств. В результате эти веб-сайты эпохи настольных компьютеров нуждались в обновлении.
К сожалению, медиа-запросы CSS не очень подходят для этой задачи. Поскольку эти веб-сайты были созданы до того, как мобильные устройства стали актуальными, многие из них имеют элементы дизайна, которые не поддаются адаптивному веб-дизайну, например, боковые панели, макеты на основе таблиц, содержимое с вкладками и т. д. Кроме того, значительная часть этих веб-сайтов построенный на системе управления контентом (CMS), такой как WordPress, Drupal, Magento и т. д., и эффективной интеграции медиа-запросов CSS [внешняя часть] из внутренней части чрезвычайно сложно или почти невозможно координировать.
Мне приходилось модифицировать веб-сайты на базе Magento Enterprise, WordPress и тот, который использовал пользовательскую CMS на основе Coldfusion, и все проекты были бы совершенно невозможны с использованием медиа-запросов CSS [это то, что пробовали все мои клиенты, прежде чем использовать нашу альтернативу подход].
5. Неэффективный код:
Использование медиа-запросов CSS для создания адаптивной веб-страницы требует масштабного умножения кода. Из-за того, как эти директивы работают [с вашими точками останова], вы должны определить индивидуальные правила стиля в каждом блоке медиа-запроса.
раздел {ширина: 960 пикселей;}
/* Портрет */
Только экран @media и (минимальная ширина устройства: 320 пикселей) и (максимальная ширина устройства: 480 пикселей) и (-webkit-min-device-pixel-ratio: 2) и (ориентация: книжная) {
раздел {ширина: 100%}
}
/* Пейзаж */
Только экран @media и (минимальная ширина устройства: 320 пикселей) и (максимальная ширина устройства: 480 пикселей) и (-webkit-min-device-pixel-ratio: 2) и (ориентация: альбомная) {
раздел {ширина: 100%;}
} При написании вышеприведенного кода моей первоначальной целью было сделать элементы <section> на моей странице плавными [ширина 100%] на всех мобильных устройствах. Однако, поскольку у меня нет встроенной возможности обнаружения устройств, мне приходится идти на компромисс и определять правило стиля в каждом блоке мультимедийного запроса CSS, ориентированном на мобильные устройства, чтобы убедиться, что новое свойство будет применяться во всех соответствующих сценариях.
Это означает, что функциональная эффективность каскада таблиц стилей и хорошие принципы разработки Do-not-Repeat-Yourself должны отойти на второй план.
6. Увеличивает сложность рабочего процесса:
Медиа-запросы CSS обрабатывают только очень специфический аспект адаптивного веб-дизайна, который почти полностью сосредоточен на изменении размера макета. Следовательно, чтобы сделать что-то большее, вы должны полагаться на JavaScript, чтобы компенсировать разницу. Это вводит дополнительные требования к обучению коду и инструментам.
Кроме того, неопределенный способ обработки точек останова [медиазапросами] означает, что вам придется тратить больше времени [и денег] на тестирование веб-страниц на многочисленных виртуальных и/или физических устройствах, чтобы убедиться, что все работает так, как вы изначально планировали. . И вам нужно снова все тестировать, когда вы вносите какие-либо существенные изменения в свой макет.
Простым и целенаправленным действием по использованию медиазапросов CSS вы значительно увеличиваете количество шагов, необходимых для создания современной веб-страницы.
7. Ухудшает работоспособность:
Из-за того, как работают медиа-запросы CSS, вам в конечном итоге потребуется гораздо больше кода CSS, чем в противном случае, чтобы сделать ваш сайт адаптивным/удобным для мобильных устройств. Согласно данным HTTPArchive.org, за последние пять лет размеры файлов CSS увеличились на 114%. Максимальное увеличение размеров HTML-файлов за тот же период составило около 53%.
Эта специфическая ситуация влияет на производительность вашего веб-сайта, поскольку после реализации медиа-запросов CSS [в контексте адаптивного веб-дизайна] он будет работать медленнее, чем когда-либо прежде, особенно для мобильных устройств, использующих далеко не идеальные мобильные широкополосные сети.
И, помимо проблемы увеличения размера файлов, в медиа-запросах CSS нет внутреннего механизма, который фактически улучшал бы производительность вашей веб-страницы. Для этого вам придется использовать передовые методы JavaScript, чтобы включить эти улучшения.
Почему мы все еще используем это?
Если бы я спросил вас, какой процент веб-сайтов использует медиа-запросы CSS, каким был бы ваш ответ? Со всем стрессом, который веб-дизайнерам приходилось терпеть на протяжении многих лет, вы могли бы подумать, что мы, вероятно, уже преодолели горб принятия, но вы были бы очень неправы.
Процент веб-сайтов, использующих медиа-запросы CSS во всей сети, составляет около 0,2%. Сравните это с процентом веб-сайтов, использующих jQuery, на уровне 18%. Это означает, что у вас в 90 раз больше шансов встретить веб-сайт, работающий на jQuery, чем адаптивный веб-сайт [не считая тех, которые являются обоими].
Почему инструментарий, основанный на базовой технологии [JavaScript], которую некоторые люди считают сложной и ненужной, настолько опережает, казалось бы, менее сложный [CSS] и предназначен для решения, возможно, более важной проблемы [удобство для мобильных устройств] ? Очевидно, что здесь есть что-то серьезное, что мешает внедрению, и это необходимо исправить.
Медиа-запросы CSS нашли свой путь в веб-браузерах для решения конкретной задачи, но затем они были разработаны так, чтобы нести на своих плечах всю тяжесть адаптивного веб-дизайна. Это похоже на репетицию перед концертом магнитофона в 3-м классе, только чтобы волшебным образом переместиться в Королевский Альберт-Холл, чтобы исполнить соло на тромбоне из «Мессии» Генделя; Нечестно!
При всех проблемах современного веб-дизайна крайне удивительно, что мы все еще занимаемся медиа-запросами. Этого недостаточно, чтобы решить некоторые важные унаследованные проблемы, в дополнение к некоторым новым в новых областях, таких как прогрессивный дизайн веб-приложений. Таким образом, я думаю, пришло время предложить альтернативу. Но что бы это было именно?
Каково решение?
Решение всего этого действительно очень простое: JavaScript. Теперь, прежде чем ты возьмешь вилы, дай мне шанс объяснить.
JavaScript — единственный компонент тройки HTML5, где расширяемость не является ругательством. Вы не можете расширить HTML-разметку, используя больше HTML, и вы, черт возьми, не можете расширить CSS изначально с помощью CSS. Однако вы можете расширить JavaScript с помощью JavaScript, и вы даже можете сделать то же самое для CSS.
Манипулирование CSS с помощью JavaScript широко обсуждается в учебной программе W3C по веб-стандартам. Интерфейс DOM document.stylesheets позволяет нам получить доступ к таблицам стилей, примененным к веб-странице, включая все внешние таблицы стилей, на которые ссылается HTML- <link> . Это не просто сделать, но возможно.
Поэтому я должен расширить первоначальный ответ: это не просто JavaScript, это CSS с поддержкой JavaScript . JavaScript — потрясающая платформа с функциональностью, в которую вы не поверите, но CSS — это то, где работает большинство веб-дизайнеров. Если бы мы могли каким-то образом создать своего рода функциональный мост между этими двумя понятиями, где веб-дизайнер мог бы написать набор правил CSS, чтобы использовать функциональность JavaScript, это в некотором роде изменило бы правила игры для веб-дизайна.
Покажи мне код
Последние два года или около того я работал над новым набором инструментов CSS с поддержкой JavaScript под названием rKit. Вся идея заключалась в том, чтобы создать удобный для дизайнера инструмент, который не только заменит медиа-запросы CSS для адаптивного веб-дизайна, но и решит некоторые из известных [и неизвестных] проблем, с которыми сталкиваются веб-дизайнеры/разработчики при создании современных веб-сайтов и веб-приложений.
Концепции много, но вот краткий фрагмент кода CSS для объяснения:
#my-element[rk="if @viewport.width между 320 и 480"]{цвет фона: #0000ff;}
В rKit правила CSS выглядят как модифицированные селекторы значений атрибутов. Затем вы можете определить выражение в разделе значений. Синтаксис этого выражения разработан таким образом, чтобы быть простым и интуитивно понятным.
Примечание : rk — постоянный идентификатор атрибута.
Приведенный выше код функционально эквивалентен приведенному ниже медиа-запросу CSS:
Только экран @media и (минимальная ширина устройства: 320 пикселей) и (максимальная ширина устройства: 480 пикселей) {
#мой-элемент {фоновый цвет:#0000ff;}
}Однако с rKit вы можете делать гораздо больше. Вот еще один быстрый пример:
#my-element[rk="if @self.width между 320 и 480"]{цвет фона: #00ff00;} Просто изменив ссылку на объект с @viewport на @self , мы, по сути, настроили то, что обычно называют запросом элемента. Итак, теперь происходит то, что когда ширина #my-element составляет от 320 до 480 пикселей, применяется данное объявление [ background-color: #00ff00 ].
Вы также можете использовать классы вместо чистых объявлений:
#my-element[rk="если @self.width между 320 и 480, то addClass(c_mobile_320)"]{}
.c_mobile_320 {цвет фона: #00ff00;}Хотя это только верхушка айсберга. С помощью rKit вы можете делать довольно крутые вещи, такие как управление событиями, наблюдение за мутациями, количественные запросы, маршрутизация, привязка данных [до 7 способов] и множество других интересных вещей, и все это с использованием чистого кода CSS и без написания кода. одна строка JavaScript.
rKit будет бесплатным и с открытым исходным кодом, когда он будет запущен. И он также будет иметь специальный пакет производительности, который вы можете установить таким образом, чтобы гарантировать нулевую блокировку рендеринга, поэтому веб-страница загружается как ракета на рельсах.
Потребовалось довольно много времени, чтобы собрать это воедино, но скоро оно будет здесь [определенно до Годо], и мне очень интересно посмотреть, что веб-дизайнеры [и разработчики] смогут с ним сделать.
Заключение
Я надеюсь, что вы не уйдете с этого поста, думая, что я критикую медиа-запросы CSS просто так. Я не. Это все равно, что бить помидор за то, что он оказался во фруктовом салате. Как я уже говорил ранее, медиа-запросы CSS никогда не предназначались для адаптивного веб-дизайна. Он был кооптирован из соображений целесообразности, и мы все допустили ошибку, пытаясь использовать его для решения всех проблем.
К сожалению, мы, как веб-сообщество, так и не удосужились исправить эту первоначальную ошибку, значительно улучшив ее или предложив лучшую альтернативу. Но, увы, шоу должно продолжаться, веб-сайты должны создаваться, а прогресс должен восторжествовать. Пришло время перемен.
rKit — это всего лишь один вариант и один ответ. Это не первое и точно не последнее. Но, по крайней мере, это правильный шаг в правильном направлении. Возможность исправить некоторые проблемы в прошлом, а затем итерировать, чтобы исправить те, что есть сейчас и в будущем. Было бы интересно посмотреть, как это соотносится со статус-кво.
Как ни крути, ошибка не является самоцелью; это должен быть опыт обучения. Если повезет, в следующий раз мы научимся использовать правильный инструмент для правильной работы. Я имею в виду, что если вы можете ездить на велосипеде по асфальтированной дороге, это не значит, что вы должны взять его на Нюрбургринг. Возьми Порше!