Почему макет CSS Grid не заменяет сетку фреймворка

Почему макет CSS Grid не заменяет сетку фреймворка

От автора: я встречал много статей и комментариев, в которых говорилось, что пришло время заменить сетку фреймворка на CSS Grid. Я не могу полностью согласиться с этим.

Сетка фреймворка — это «пакет» служебных классов, который можно использовать в любом проекте для распределения элементов по (адаптивным) столбцам и строкам. Он может включать сотни строк кода или всего несколько правил. Это может быть сетка that-framework-name или ваша пользовательская сетка.

Вот пример из сеточной системы CodyFrame:

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

Узнать подробнее

CSS Grid — это подмножество свойств CSS, используемых для распределения элементов по (адаптивным) колонкам и рядам. Например:

Любая структура — это абстракция, использующая CSS; она не заменяет его. Следовательно, мы не можем сравнивать сетку фреймворка с CSS Grid. Первая может использовать вторую (т. е. систему сеток фреймворка на основе CSS Grid). Вопрос «Что лучше?» в этом случае не имеет смысла.

Однако мы можем обсудить, имеет ли смысл включать пакет служебных классов сейчас, когда у нас есть такие мощные свойства макета CSS.

Короткий ответ: и да, и нет, если вы работаете над небольшим проектом. Это имеет смысл в тот момент, когда ваш проект становится все сложнее.

Хватит теории! Позвольте мне показать вам пример.

Запуск проекта с использованием только CSS Grid

Представим, что мы начинаем проект, в котором в какой-то момент нам нужно создать сетку.

По мере развития проекта, скорее всего, нам понадобится создать больше сеток:

Все идет нормально! Если наш проект в основном выполнен, зачем вообще думать об импорте системы сеток? CSS Grid легко справляется со своей задачей.

Проект усложняется

Представьте, что нам нужно применить одну и ту же сетку к двум компонентам. Что нам делать?

Вариант 1) Использовать тот же класс.

Такой подход может не сработать по многим причинам. Во-первых, придирчивый разработчик, любящий семантику, немного изменит все изнутри. Что наиболее важно, мы создадим невидимую связь между двумя компонентами: изменение CSS первого из них повлияет на второй. Вы создаете ловушку для себя в будущем.

Вариант 2) Создать новую сетку.

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

Узнать подробнее

Создание новой сетки для нового компонента и группировка классов были бы самым безопасным подходом. Кроме того, это не повлияет на размер CSS.

Теперь представьте, что мы подошли к моменту, когда проекту требуется несколько (похожих) сеток. Следует ли нам продолжать создавать новую сетку для каждого компонента?

Вот самые слабые места описанного выше подхода:

Несмотря на то, что классы сетки находятся в одном файле SCSS (что очень необычно – как правило, они оказываются в разных файлах SCSS / компонентов), а количество сеток относительно невелико, работа с сеткой уже становится более сложной.

Каждая сетка требует отдельного имени класса, и слишком много имен может раздражать.

Поскольку классы взаимосвязаны, изменение или создание новых сеток требует высокого уровня концентрации. Риск ошибок велик.

Рано или поздно мы делаем единственное, что имеет смысл: мы создаем абстракции.

Наши классы экосистемы генерируются по необходимости!

Вот основные преимущества абстрагирования служебных классов сетки:

Все классы сетки находятся в одном файле SCSS и легко читаются.

Вы можете быстро расширить систему, если этого требует проект.

Больше никаких проблем с именами.

Если вы используете одну и ту же сетку в нескольких проектах, вам вообще не нужно проверять CSS.

Использование более простого CSS означает снижение риска ошибки.

Заключение

Основная цель при работе с CSS – поддерживаемость: делать то, что упрощает сопровождение кода.

При работе с сетками это означает использование служебных классов, если проект становится более сложным. Это также подразумевает создание сеток в HTML, а не в CSS. «Разделение задач» не является темой данной статьи. Если вам интересно, вот видео, котором я объясняю, как мы используем служебные классы в CodyHouse.

«Вы предлагаете, чтобы мы импортировали пакет из сотен строк CSS в каждый проект только для управления сеткой?» Нет. Системы сеток фреймворка обычно огромны, потому что они включают в себя все параметры, некоторые из которых вы никогда не будете использовать: адаптивные модификаторы для всех контрольных точек, смещение, параметры пробелов и так далее. Однако современные инструменты, такие как PurgeCSS, предотвращают раздувание CSS и включают в CSS только те классы, которые вы действительно используете.

Вы ищете отличную сетку? Посмотрите CodyFrame.

Автор: Sebastiano Guerriero

Источник: https://codyhouse.co

Редакция: Команда webformyself.

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

Узнать подробнее

PSD to HTML

Практика верстки сайта на CSS Grid с нуля

Смотреть

Метки:

Похожие статьи:

Комментарии Вконтакте:

Комментарии Facebook:

Комментирование закрыто.