От автора: вы стремитесь перейти на CSS Grid Layout, но не можете убедить остальных членов команды (ваших коллег или менеджеров)? Кто-то недавно спросил меня, что я могу посоветовать скептически настроенной команде, чтобы они приняли CSS Grid в свой рабочий процесс. Хотя я сам не сталкивался с какими-либо серьезными препятствиями, эту историю я слышу слишком часто.
Несмотря на то, что разочаровывает, подобные настроения имеют под собой некоторую рациональную основу. Давайте разберемся, стоит ли использовать CSS Grid на самом деле.
В качестве примечания, эти соображения продиктованы моим опытом работы в веб-агентстве. Я не претендую на то, что этот опыт подойдет для каждого, и в других средах могут потребоваться другие подходы. Тем не менее, я думаю, что есть некоторые предложения, которые являются универсальными.
Почему их нужно убеждать?
Поддержка браузерами
Наиболее распространенной причиной не принятия Grid является поддержка браузерами. В то время как Grid имеет около 85% поддержки браузерами, оставшиеся 15% — это значительный разрыв. Большая часть этих пользователей работает в IE, который на самом деле поддерживает более старый синтаксис CSS Grid, начиная с IE10. Этим пользователям нужен макет, который, по крайней мере, будет годным для использования. Это подводит меня ко второй проблеме …
Время
Если не все браузеры поддерживают свойство CSS, необходимо предоставить подходящий запасной вариант. В случае использования отдельных свойств (например mix-blend-mode) может быть довольно просто написать дополнительную строку или две, которые позволят пользователям по-прежнему воспринимать ваш контент полезным (если не оптимальным) способом. Это прогрессивное улучшение.
В случае целой спецификации, такой как Grid, если вы примете ее в качестве основной стратегии компоновки, это повлияет не только на один или два элемента, но и на всю веб-страницу. Так что это немного другая история. Вы должны убедиться, что предоставляете подходящие запасные варианты, какую бы стратегию вы не использовали для поддержки старых браузеров. Я не собираюсь отрицать, что это иногда занимает немного времени.
Если остальная часть вашей команды еще не знакома с Grid, то есть также фактор времени, который необходимо учитывать, когда речь идет о том, чтобы научить всех работать с новой стратегией макета. Они могут нервничать по поводу инвестиций в обучение и отвлечения всех от существующих проектов на день или около того.
Поддержка
Некоторые команды могут быть обеспокоены тем, что, когда кто-то в вашей команде выберет ваш проект для работы, им будет сложнее поддерживать его, потому что вы используете незнакомый CSS, а не среду X. В сочетании с этим существует множество различных способов создания макета с помощью Grid. Например, grid-template-areas. Если один человек использует именованные линии сетки, в то время как другой использует его, это может привести к противоречиям в базе кода и, возможно, стать головной болью для всех, кому нужно подойти к этому проекту заново.
Все эти причины сводятся к времени и деньгам. Нам нужно убедить вашу команду, что Grid может помочь в обоих случаях.
Чем может помочь Grid?
Теперь давайте посмотрим, как использование Grid может помочь с вышеуказанными проблемами и не только:
Экономия времени на сложных макетах
Grid значительно упрощает процесс построения макетов, которые ранее требовали много хаков и полифилов. Если вам нужно разобраться со сложным дизайном, используя более старые методы верстки, то вы будете тратить драгоценное время. Конечно, вам также нужно обеспечить доступный резервный вариант для старых браузеров, но часто это не требует значительного времени.
Если ваша команда пишет свою собственную сеточную структуру, используя более старые методы компоновки, это тоже требует времени и усилий.
Творчество
Если дизайнеры, разработчики и команды хотят выйти за рамки и создать действительно креативные, современные макеты, которые выделяются из общей массы и охватывают новую эру мышления веб-дизайна, то Grid является неотъемлемой частью этого. Grid позволяет нам создавать макеты, которые раньше были недоступны в CSS.
Лучшая производительность
Многие проекты импортируют большие, громоздкие CSS-фреймворки для системы сеток. Даже минималистичные фреймворки могут добавить много дополнительных классов, которые увеличивают объем CSS-файла. Для сложных макетов, которые отличаются от «стандартных» столбцов и строк, вам может потребоваться обратиться к библиотекам Javascript. По моему мнению, в 2019 году нам почти наверняка не нужно будет отправлять дополнительные JS только для обработки макета (за очень немногими исключениями). CSS Grid может обрабатывать много сложных случаев с помощью очень небольшого количества кода.
Есть также некоторые признаки того, что создание Grid-макетов с помощью flexbox менее производительно, хотя я не смог найти дополнительные ресурсы по этому вопросу с тем же уровнем детализации.
Лучшая поддерживаемость
Поскольку Grid — это просто нативный CSS, нет никакого риска, что он сломается, и вам придется реорганизовать свой проект через год. Это изначально стабильно. Поддержка браузерами будет только улучшаться. С другой стороны, зависимости делают проекты менее стабильными. Они нуждаются в поддержке. Возможно, вам придется пересмотреть проект через год или два, только чтобы обнаружить, что он использует старую систему сетки, которая больше не поддерживается, или используемая версия устарела, и вы не можете найти документацию. Известные фреймворки, такие как Bootstrap, возможно, с меньшей вероятностью будут связаны с этой проблемой, но они связаны с компромиссами производительности.
Кроме того, инвестиции в обучение вашей команды Grid — это надежное вложение в будущее. Это не фреймворк, который через несколько лет устареет, это фундаментальный CSS, который останется. Эти навыки будут полезны в течение многих лет.
Так как же убедить команду?
Веб-сайты не должны выглядеть одинаково во всех браузерах
Я считаю, что самым большим препятствием для широкого принятия Grid является распространенное заблуждение, что веб-сайты должны выглядеть одинаково во всех браузерах. К сожалению, может быть так, что менеджеры либо считают, что это так, либо не сообщают клиенту об ином. Никто не хочет оказаться в ситуации, когда ваш клиент откроет ваш красивый, блестящий новый веб-сайт на своей древней скрипучей машине под управлением IE9 и сразу же будет поражен тем, что он не соответствует замыслам.
Это означает, что вам нужно выдвигать аргументы в пользу прогрессивного улучшения и способствовать общению на более высоких уровнях. Сделайте так, чтобы менеджеры и дизайнеры знали об ограничениях старых браузеров и о том, что затраты на реализацию проектов должны быть одинаковыми везде. Это должно быть справедливым не для каждого отдельного проекта, а для всей организации.
Я знаю, как трудно изменить мышление всей организации, и вряд ли это произойдет в одночасье. Одна из идей, с которой я встречался, заключается в том, что дизайнеры на самом деле разрабатывают версию сайта с упрощенной версткой, чтобы представить ее клиенту в качестве запасного варианта, наряду с полностью поддерживаемой версией, точно так же, как они представляют мобильные и планшетные версии дизайна. Таким образом, клиент осознает, что некоторые браузеры получат более простую компоновку, и в этом нет ничего удивительного. Кроме того, дизайнер может разработать его так, чтобы он выглядел хорошо, а не полагаться на интерпретацию разработчика. Хотя неизбежно потребуется немного больше времени для разработки, значительная экономия может быть достигнута при разработке. Я хотел бы, чтобы этот подход стал более распространенным.
Попробуйте Grid
Вам не нужно использовать Grid для всего — это не должен быть подход «все или ничего». Один из лучших способов представить Grid — начать с модулей UI меньшего размера. Таким образом, у вас будет возможность наглядно продемонстрировать преимущества и, надеюсь, обучить — или, по крайней мере, вызвать любопытство — других членов вашей команды. Часто лучше показать, чем рассказать.
Нет ничего плохого в использовании Grid вместе с существующей системой макетов, если людям это удобно. Это дает вам время для следующей части …
Планирование стратегии
Как я упоминал ранее, есть много способов создать макет в Grid. Вам необходимо продумать, как вы и ваша команда будете это реализовывать, чтобы обеспечить согласованность и поддерживаемость. Вы можете решить, что как только все изучат основы, они смогут использовать любой подход, который им нравится, для выполнения работы, или вы можете, например, решить использовать только номера строк для размещения и не прибегать к grid-template-areas, чтобы избежать путаницы. Вы можете создать несколько служебных классов для наиболее распространенных потребностей компоновки, или вы можете решить, что ваш код сетки должен быть тесно связан с компонентами.
Вам также нужно подумать о своей стратегии поддержки браузеров. Должны ли вы использовать @supports и оборачивать в него весь Grid-код или только там, где это строго требуется? Проведите собственные исследования и придумайте план. Вероятно, ваш подход со временем будет развиваться, но вам нужно продемонстрировать, что вы об этом подумали, чтобы обеспечить наиболее плавный переход для команды.
Представьте предложение
Дайте команде и / или менеджеру возможность представить свое предложение. Если вы сможете заставить других чувствовать, что они являются частью дискуссии, они с большей вероятностью вступят в игру. Плюс могут быть некоторые другие подводные камни, о которых вы не задумывались, на которые они могут указать, и вы можете преодолеть их вместе.
Часто бывает трудно добиться изменений в организации. Чтобы выделить полезные вещи, убедитесь, что вы учитываете все недостатки, старайтесь избегать конфликтов. Наконец, найдите союзников! Гораздо проще продвигать изменения вместе!
Источник: https://css-irl.info
Редакция: Команда webformyself.
