Grid что это: Подробное руководство по CSS Grid

Понимание CSS Grid (2 часть): Grid-линии / Хабр

Перевод Understanding CSS Grid: Grid Lines» Rachel Andrew

В первой статье из серии «Понимание CSS Grid» мы рассмотрели, как создавать родительский grid-контейнер и различные свойства, применяемые к данному элементу. Когда сетка создана, в нашем распоряжении оказывается набор grid-линий. В этой статье вы узнаете, как располагать элементы вдоль данных линий путём добавления свойств к дочерним элементам grid-контейнера.

Мы охватим следующие моменты:

1. Свойства размещения элементов grid-column-start, grid-column-end, grid-row-start, grid-row-end и их краткие формы записи grid-column and grid-row
2. Как использовать grid-area для размещения элементов по номерам grid-линий
3. Как располагать элементы с помощью именованных линий
4. Отличие в размещении элементов в явной и неявной сетке
5. Использование ключевого слова span с небольшим бонусом subgrid
6. Чего следует остерегаться при одновременном использовании ручного и автоматического размещения элементов

Статьи из данной серии:

Примечание от переводчика

В интернете очень много как статей, так и руководств о технологии CSS Grid. Но порой в материалах Rachel Andrew доступно освещаются те моменты, которым в других руководствах уделяется недостаточно внимания.

Следовательно, данную статью стоит воспринимать лишь как ещё одну точку зрения на уже хорошо известную технологию

Концепции позиционирования элементов по линиям

Чтобы разместить элемент на сетке, нужно задать линию, на которой он должен начинаться, и линию, на которой заканчиваться. Следовательно, если я хочу, чтобы на сетке, имеющей по 5 строк и колонок, элемент занимал вторую и третью колонки, а также с первой по третью строки, мне нужно использовать следующий CSS. Помните, что мы указываем не номер трека (колонки или строки), а номер линии, которые их разделают.

.item {
  grid-column-start: 2;
  grid-column-end: 4;
  grid-row-start: 1;
  grid-row-end: 4;
}

То же самое можно было указать в сокращённом виде: число перед слешем – номер линии, с которой начинается элемент, после слеша – номер линии на которой элемент заканчивается.

.item {
  grid-column: 2 / 4;
  grid-row: 1 / 4;
}

В следующем CodePen вы можете увидеть пример и попробовать изменить линии, которые охватывает элемент.

Обратите внимание, что наш элемент растягивается на всю определённую линиями область, потому что изначальные значения свойств выравнивания для элемента align-self и justify-self равны stretch.

Если достаточно, чтобы элемент занимал только один трек (одну колонку или строку), номер линии завершения можно не указывать, поскольку по умолчанию браузер и так растянет элемент до следующей линии, заняв один трек. Мы видим такое поведение, когда автоматически располагаем элементы (как в первой статье из этой серии) – каждый элемент помещается в ячейку, которая по ширине равна одной колонке, а по высоте – одной строке. Таким образом, чтобы заставить элемент занять место между 2 и 3 линией, следует указать:

.item {
  grid-column: 2 / 3;
}

Но также вполне корректной будет запись, не содержащая линию, на которой элемент заканчивается:

.item {
  grid-column: 2;
}

Сокращённое свойство "grid-area"

Располагать элементы можно и с помощью свойства grid-area. Указав в свойстве номера четырёх линий, можно тем самым определить область, занимаемую данным элементом. Более подробно мы разбёрем это свойство в следующей статье.

.item {
  grid-area: 1 / 2 / 4 / 4;
}

Последовательность номеров линий в данном свойстве определяет значения для следующих свойств: grid-row-start, grid-column-start, grid-row-end, grid-column-end. Для языков с горизонтальным направлением текста, записываемых слева направо (таких, как английский), это будет верх, лево, низ, право. Возможно, вы обратили внимание, что стороны указываются в обратном порядке по сравнению с тем, как мы привыкли записывать в CSS сокращения для таких свойств, как, например, margin.

Причина этого заключается в том, что Grid работает одинаково, независимо от того, какой установлен режим письма, и мы ещё вернёмся к этому чуть ниже. Следовательно, установка сначала двух линий начала, а затем двух линий конца имеет больше смысла, чем сопоставление значений с физическими сторонам экрана. Я не склонна использовать это свойство при размещении элементов по линиям, так как считаю, что свойства с двумя значениями grid-column и grid-row более удобочитаемы при беглом просмотре файла стилей.

Линии явной сетки

В первой части упоминались явная и неявная grid-сетки. Явная – это сетка, которую вы создаёте с помощью свойств grid-template-columns и grid-template-rows. При объявлении колоночных и строковых треков вы также определяете и линии между этими треками.

Линии пронумерованы. Нумерация начинается с 1 для начального края как блочного, так и строчного направления. В горизонтальном режиме записи слева направо, линия 1 в блочном направлении будет вверху сетки, а линия 1 в строчном направлении – слева.

При работе с языком, имеющим горизонтальный режим записи справа налево (например, арабским), линия 1 в блочном направлении всё еще будет вверху, но линия 1 в строчном направлении уже будет справа, а не слева.

Если вы работаете с вертикальным режимом записи (на изображении ниже установлено свойство writing-mode: vertical-rl), линия 1 блочного направления будет справа. Линия 1 строчного направления – вверху.

Таким образом, grid-линии связаны с режимом и направлением записи, используемым в документе или компоненте.

Последняя линия явной сетки всегда имеет номер -1, а нумерация линий идёт в обратном порядке, задавая следующей с конца линии номер -2 и так далее. Это значит, что если вы хотите, чтобы элемент охватил все колонки явной сетки, достаточно задать:

.item {
  grid-column: 1 / -1;
}

Линии неявной сетки

Если вы создали треки неявной сетки, они также отсчитываются от 1. В примере ниже я создала явную сетку для колонок, однако, строковые треки были созданы в неявной сетке, которой я задаю высоту 5em с помощью свойства grid-auto-rows.

Элементу с классом placed задано свойство grid-row: 1 / -1, при котором он должен занять всё доступное место по вертикали, начиная с первой строковой линии 1 до последней строковой линии -1. Если бы для двух образовавшихся строк была задана явная сетка, то элемент и занимал обе строки. Но так как данные строковые треки были созданы в рамках неявной сетки, последней линией (которую мы обозначаем номером -1) стала линия 2, а не линия 3.

В настоящее время нет возможности указать последнюю строку неявной сетки, не зная заранее, сколько в этой сетке строк.

Размещение элементов по именованным линиям

В первой статье из этой серии упоминалось о том, что в дополнение к номерам, линиям сетки также можно задавать названия. Обёрнутые в квадратные скобки имена линий указываются между размерами треков.

.grid {
  display: grid;
  grid-template-columns: [full-start] 1fr [main-start] 2fr 2fr [main-end full-end];
}

Имена линий можно использовать вместо номеров при размещении элементов на сетке.

.item {
  grid-column: main-start / main-end;
}

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

Примечание: Именование линий сопровождается некоторыми примечательными моментами. Более подробно это описано в статье «Именование в CSS Grid»

Одинаковые имена у разных линий

Вы получите весьма интересное поведение, если дадите нескольким линиям одинаковые имена. Данная ситуация может произойти, если линии именуются с помощью функции repeat(). В приведённом ниже примере дана сетка с 8 колонками, созданными путём 4-кратного повторения шаблна 1fr 2fr. Начальную линию маленького трека я назвала sm, а для большого трека – lg. Это значит, что у меня есть по 4 линии с каждым именем.

В этой ситуации мы можем использовать имя линии в качестве её порядкового номера. Таким образом, чтобы разместить элемент, начиная со второй линии с именем sm и растянуть до третьей линии с именем lg, я задаю свойство grid-column: sm 2 / lg 3. Если указать имя без порядкового номера, это всегда будет восприниматься как первая линия с таким именем.

Использование ключевого слова "span"

Бывает, нужно, чтобы элемент занимал определённое количество треков (столбцов или строк), но при этом точно неизвестно или не важно, где именно он будет располагаться на сетке. Например, в ситуации, когда элементы располагаются на сетке автоматически, но вы хотите, чтобы они занимали несколько треков вместо одного, как предусмотрено по умолчанию. В этом случае вы можете использовать ключевое слово span. В приведённом ниже примере элемент начинается с линии auto (это линия, на которую элемент будет помещён в результате автоматического размещения) и занимает 3 колонки.

.item {
  grid-column: auto / span 3;
}

Эта техника станет очень полезной, когда мы получим широкую поддержку технологии subgrid в виде соответствующего значения для свойств grid-template-columns и grid-template-rows. Например, в макете, состоящем из набора карточек, у каждой из которых есть область заголовка и область основного содержимого, может возникнуть потребность сделать эти области у всех карточек одинаковыми. Каждая отдельная карточка будет использовать subgrid для своих строк (то есть, получать по две строки каждая). Результат можно увидеть в CodePen-примере ниже, если используете браузер Firefox или на изображении под ним.

Наслаивание элементов при размещении по линиям

При автоматическом позиционировании, CSS Grid помещает элементы сетки в пустые ячейки, а не в одну и ту же. Однако, вы всё же можете сделать это с помощью их размещения с указанием конкретных линий. В следующем примере изображение занимает два строковых трека, а подпись расположена во втором строковом треке и имеет полупрозрачный фон.

Элементы будут накладываться друг на друга в порядке, в котором они появляются в разметке документа. Таким образом, в примере выше подпись идёт после изображения и поэтому показывается над изображением. Если бы подпись шла первой, то находилась под изображениям и не была видна. Вы можете управлять наложением с помощью свойства z-index. Если для подписи важно идти первой в исходном коде, то можно использоватьz-index с бо́льшим значением, чем у изображения. Это заставит подпись отобразиться над картинкой, чтобы её можно было прочитать.

Смешивание автоматического и «линейного» позиционирования

Следует соблюдать осторожность, если вы одновременно используете автоматическое позиционирование элементов и их размещение по линиям сетки. Если используется только автоматическое размещение, это происходит последовательно – каждый элемент находит следующее доступное пустое пространство, в которое может поместиться.

Поведение по умолчанию всегда предусматривает продвижение вперёд, оставляя ячейку свободной, если элемент не помещается на сетке. Вы можете менять это поведение с помощью свойства grid-auto-flow со значением dense. В этом случае, если присутствует элемент, который равен оставшемуся в сетке свободному месту, он будет помещён туда вне очереди, чтобы заполнить свободное пространство. В приведённом ниже примере используется «плотное» размещение, элемент 3 теперь размещается перед элементом 2.

Обратите внимание, что это поведение может вызвать проблемы у пользователей, которые переключаются между элементами вдоль документа с помощью кнопки Tab, так как визуальный порядок элементов будет отличаться от их последовательности в исходном коде.

Также, работа автоматического позиционирования немного меняется, если какие-то из элементов уже были размещены разработчиком. Сначала будут размещены «вручную» спозиционированные элементы, а остальные будут последовательно занимать оставшееся свободное место.

Чтобы продемонстрировать это, я разместила элементы 1 и 2 с помощью линий сетки, оставив верхний ряд пустым. Последующие элементы оказались вверху, чтобы заполнить свободное пространство.

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

В заключение

Это почти всё, что вам нужно знать о линиях сетки. Помните, что вам всегда доступны пронумерованные линии. Независимо от того, как вы используете сетку, всегда можно переместить элемент с одной линии на другую. Методы, которые мы рассмотрим в следующих статьях, будут представлять альтернативные способы задания макета, но всё равно будут основаны на сетке, созданной с помощью пронумерованных линий.

Как CSS Grid меняет представление о структурировании контента / Хабр

Каждый, кто хотя бы немного занимался созданием веб-сайтов, знает, что теги <div> — являются важным строительным блоком для контроля над макетом.

HTML5 представил новые семантические элементы, чтобы помочь в этом. И хотя они являются фантастическим дополнением к языку, они немного похожи на украшение к нашему супу из <div> элементов.

С приходом CSS Grid, нам больше не нужно полагаться на элементы <div> для создания структуры страницы или даже более сложного компонента. Структура буквально определяется родительским элементом, а не тем, как расположено содержимое внутри него.

Это значит, что мы можем получить хороший простой макет, который структурирует содержимое, не обращая внимание на то, как оно изначально организовано с помощью элементов <div>.

CSS Grid может быть сложным, но и Flexbox тоже

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

Технология CSS Grid действительно вводит множество новых свойств и значений, так что да, есть кривая обучения. Но и Flexbox также довольно сложен.

Можете ли вы рассказать о преимуществах использования свойства flex-basis вместо width? Или как Flexbox рассчитывает ширину flex-элементов, если мы её явно не задали?

Например, если вы покажете приведённый ниже пример тому, кто никогда не использовал Flexbox, как вы объясните тот факт, что в нём заданы одинаковая разметка и одинаковые стили для обоих наборов столбцов? Что ещё хуже, второй столбец в обоих случаях имеет ширину 50%. Очевидно, что ширина со значением 50% на самом деле не устанавливает размер элемента в 50%.

«Что ж, всё начинается с того, что элементы сжимаются, если в контейнере недостаточно места, поэтому, даже если мы установили элементу ширину = 50%, места ему не хватает, поэтому он начинает сжиматься, чтобы втиснуться в контейнер, так как другой <div> требует больше места. 50% — это скорее идеальный размер для блока, а не размер фактический.»

«Таким образом, в примере выше содержимое первого блока настолько большое, что создаёт проблему, потому что, как flex-элемент, по умолчанию он стремится сжаться, чтобы вместить содержимое. В этом примере данный элемент имеет много содержимого, так что…

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

Grid сложен тем, что влечёт за собой много новых свойств и значений, но они дают нам гораздо больше контроля, чем flexbox.

В этой статье мне бы хотелось рассмотреть, как этот дополнительный уровень контроля помогает упростить нашу разметку и позволяет писать меньше кода, и всё это даже без необходимости изучения того, как использовать целый ряд его причудливых функций.

Ограничения Flexbox

Даже если мы возьмём простой компонент и создадим его с помощью flexbox, из-за того, что он действует только в 1 измерении (flex-элементы являются либо строками, либо столбцами, они не могут быть и тем и другим), у нас оказывается большое количеством элементов, используемых для создания строк, которые потом можно будет разбить на столбцы.

Например, если мы работает над карточкой, как эта:

Это не сложный макет, но нам всё ещё нужно организовать наш контент довольно специфичным образом, чтобы заставить работать.

Желтый и оранжевый блоки в этой ситуации нужны, чтобы при добавлении свойства display: flex для элемента .card (красный блок), создались две колонки. Таким образом, чтобы структурировать всё содержимое, мы получаем разметку, которая выглядит примерно так:

<div>  
    <div>
        <!-- Изображение профиля и список иконок соцсетей --> 
    </div>
    <div>
        <!-- Имя, должность, описание -->
    </div>
</div>

Как только вы поймёте, как работает Flexbox, понять такую структуру станет просто.

Когда мы добавим свойство display: flex для элемента .card, получим две колонки, после чего нужно будет стилизовать каждую из них отдельно.

Вот рабочий пример со всеми стилями:

Дело в том, что при создании столбцов содержимого, мы получаем немного более сложную разметку, и мы также ограничиваем себя, так как вынуждаем разные части содержимого группироваться вместе.

Упрощение всего с помощью CSS Grid

Поскольку CSS Grid двухмерный, он позволяет нам одновременно создавать строки и столбцы, а это значит, что grid-контейнер (которому мы задали свойство display: grid) имеет полный контроль над макетом внутри себя.

Раньше для этого требовались дополнительные элементы, как в приведенном выше примере с Flexbox. Используя Grid, мы можем полностью избавиться от них.

<div> <img src="https://i.pravatar.cc/125?image=3" alt="">
  <ul> ... </ul>
  <h3>Ramsey Harper</h3>
  <p>Graphic Designer</p>
  <p>Lorem ipsum ...</p>
</div>

С точки зрения разметки, разве не имеет ли это больше смысла?

Есть элемент с классом .card, в который мы помещаем его непосредственное содержимое. Нам не нужно переживать о структуре и компоновке элементов, мы просто помещаем контент, который нам нужен, и идём дальше.

Структурирование макета

Так же, как при использовании Flexbox, нам все еще нужно структурировать макет, хотя из-за особенностей работы Grid, это выглядит немного иначе.

Это одна из ситуаций, в которой люди могу утверждать, что Grid сложнее, но на самом деле, я просто рисую блоки вокруг каждой части содержимого.

Используя Flexbox, мы создали два блока, которые выступали столбцами. При использовании Grid, вместо этого мы настраиваем всю сетку для родительского элемента, после чего указываем дочерним элементам, где расположиться на этой сетке.

Чтобы настроить сетку, мы можем сделать что-то вроде этого:

.card {  
    display: grid;
    grid-template-columns: 1fr 3fr;
}

Единица измерения fr уникальная для Grid, и обозначает долю доступного пространства. Такое использование очень похоже на установку двух колонок во Flexbox и определение им ширин 25% и 75% соответственно.

Размещение элементов на сетке

Возможно, из-за того, что в течение многих лет для создания разметки я использовал float, теперь ситуации, в которых элементы просто располагаются именно там, где это нужно, кажутся похожими на небольшую магию.

Можно было использовать grid-row и grid-column для каждого элемента, чтобы разместить их именно там, где мы хотим, но чем больше я использую Grid, тем больше я влюбляюсь в свойство grid-template-areas и размещаю элементы с помощью определения областей.

Такой подход занимает немного больше времени, но оно стоит того, особенно когда мы создаём адаптивный дизайн (скоро мы дойдём до этого).

Сперва мы должны определить grid-template-areas для элемента .card, после чего мы можем назначить все дочерние элементы в эти области:

.card {
  ...
  display: grid;
  grid-template-columns: 1fr 3fr;
  grid-column-gap: 2em;
  grid-template-areas:
      "image name"
      "image position"
      "social description";
}


.profile-name     { grid-area: name; }
.profile-position { grid-area: position; }
.profile-info     { grid-area: description; }
.profile-img      { grid-area: image; }
.social-list      { grid-area: social; }

В примере ниже можно увидеть это всё в действии:

Это так просто

Одна из причин, по которой я люблю использовать grid-template-areas, заключается в том, что если кто-то еще посмотрит на код, он сразу поймёт, что происходит…

Если кто-то показывает вам код, в котором заданы grid-row и grid-column с использованием чисел и span, высчитать и понять, где и как они будут расположены элементы, достаточно просто. Для простых макетов или для использования span в некоторых местах, их использование считаю уместным, но гораздо приятнее, просто посмотрев только на код родительского элемента, сразу понять, как будет выглядеть весь макет.

При использовании Grid легче узнать фактический размер элемента

В самом первом нашем примере, где мы установили ширину одного из flex-элементов = 50%, на самом деле она не была равна 50%. Если вы понимаете, почему так произошло, отлично, но порой это всё равно может раздражать. Это достаточно просто обойти, но когда используется Grid, это становится гораздо меньшей проблемой.

Поскольку мы определяем целый макет, мы также точно задаём, сколько места должны занимать элементы.

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

Ограниченные изменения

Если рассмотреть пример с Flexbox, мы не можем сделать его похожим на макет ниже без изменения HTML-разметки:

Мы ограничили сами себя тем, как группировали элементы вместе с помощью <div>. Нам пришлось использовать эти <div>, чтобы заставить макет работать, но теперь это стало для нас преградой.

С дочерними элементами нашего grid-контейнера, расположенными на одном уровне, можно делать всё. И в качестве дополнительного бонуса, поскольку мы настроили всё используя grid-template-areas, вносить эти изменения очень легко.

.card {
  /* Старая разметка 
  grid-template-areas:
      "image name"
      "image position"
      "social description"; */
   
  /* Новая разметка */
  grid-template-areas:
      "image name"
      "image position"
      "image social"
      ". description";
}

Играя с grid-template-areas подобным образом, быстро и легко можно сместить иконки социальных сетей туда, где мы хотим их видеть (точка в последней части указывает на пустую ячейку).

Это облегчает жизнь при работе с медиа-запросами

Как я упоминал несколько раз, это тот случай, когда оправдано использование grid-template-areas. Мы можем полностью контролировать наш макет только с помощью свойств родителя:

.card {
  /* настройки для небольших экранов */
  display: grid;
  grid-template-columns: 1fr 3fr;
  grid-column-gap: 2em;
  grid-template-areas: 
      "name" 
      "image" 
      "social" 
      "position" 
      "description";
}
.profile-name     {  grid-area: name;}
.profile-position {  grid-area: position; }
.profile-info     {  grid-area: description; }
.profile-img      {  grid-area: image; }
.social-list      {  grid-area: social; } 


/* Перестраивание макета для больших экранов */

@media (min-width: 600px) {
  .card {
    text-align: left;
    grid-template-columns: 1fr 3fr;
    grid-template-areas: 
        "image name" 
        "image position" 
        "social description";
  }
  .profile-name::after {
    margin-left: 0;
  }
}

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

Flexbox всё еще имеет свою область применения

Я всё чаще и чаще использую Grid, но думаю, что Flexbox всё еще имеет свою область применения. Если у меня есть логотип и навигация, расположенные рядом друг с другом, хорошо бы иметь простой способ сделать что-то подобное и знать, что они окажутся там, где я хочу чтобы они были:

.header {
  display: flex;
  justify-content: space-between;
}

То же касается и <ul>, который мы используем для навигации, чтобы просто получить элементы, следующие друг за другом, или, как вы могли заметить в примере с карточкой, который мы рассматривали, он идеально подходит для .social-list.

Для простых компонентов, где нам не нужен сложный макет, это действительно хорошо работает. Но всё больше и больше я замечаю за собой движение в сторону Grid, иногда из-за явной потребности в них, иногда потому что хочу использовать функцию minmax() или единицы измерения fr.

Но в конце концов, я думаю, что самое лучшее в Grid — это возможность существенно упростить нашу разметку.

Мы всё ещё вынуждены использовать <div>, но благодаря Grid, мы всё меньше можем их использовать.

В завершение

Как бы ни был хорош Flexbox, он не проще, чем Grid. Он действительно отлично подходит в определенных ситуациях, но при работе с более сложными макетами, Grid позволяет нам иметь намного больше контроля. Этот контроль усиливается во время работы с адаптивным дизайном при внесении изменений в медиа-запросы.

При использовании Flexbox, наибольшее, что мы можем изменить, это направление flex-direction. Используя Grid, мы можем быстро и просто полностью изменить дизайн компонента.

И Flexbox и Grid имеют гораздо больше возможностей. Каждый имеет своё предназначение, но если вы чувствуете, что не знаете, какой подход выбрать, или застряли при попытке понять адаптивный дизайн в общем, недавно на Scrimba я анонсировал курс, который углубляется в вопросы адаптивного дизайна, который называется The Responsive Web Design Bootcamp.

Grid Layout как основа современной раскладки

В темные века верстальщики строили сайты на таблицах. Потом они освоили float и flexbox, и тьма отступила. В 2017-м наступила эпоха Просвещения с приходом CSS Grid Layout.

Grid учитывает горизонтальное и вертикальное пространство, с ним можно менять раскладку, не трогая разметку, и все это без медиазапросов. С Grid можно забыть про магические числа, хаки, обходные пути и CSS-фреймворки.

Несмотря на всю мощь, есть маленький нюанс, который портит картину — его все еще редко используют верстальщики. Спецификация Grid есть, браузеры поддерживают, а реальных проектов мало.

Об этом расшифровка доклада Сергея Попова на Frontend Conf: про спецификацию, про то, почему верстальщики боятся Grid и как решиться применять сетку в своих проектах, чтобы «Make your website great again!».

О спикере: Сергей Попов (popovsergey) — Генеральный директор аутсорса по фронтенд-разработке Лига А. от HTML Академии, фронтенд-разработчик, организатор сообщества moscowcss, соорганизатор WSD и pitercss_conf. Пока не стал руководителем в компании, много лет занимался версткой.

За последний год появилось много курсов и докладов про Grid, про то, как их использовать и писать. Если технические доклады вам надоели, то добавлю еще один в ваш список. Шутка — поговорим про комиксы. Или нет?

Примечание: вместо длинного «CSS Grid Layout» дальше будет просто «Grid».

Что сейчас с CSS Grid Layout?

Технически, Grid — это простая двухмерная сетка.

Нарисовать и использовать Grid достаточно просто, но разработчики все еще его сторонятся. Я вижу две причины для этого.

• Многие просто не понимают, что происходит с Grid. Большое количество мифов про этот инструмент мешают разобраться в нем.
• Мы, как верстальщики и фронтендеры, не понимаем, как и где применять Grid в повседневных задачах.

Начнем разбор с первого пункта.

Спецификация

Первая версия спецификации вышла в 2012 году, много менялась, переписывалась, и, спустя пять лет, начала активно внедряться. В 2017 случился тот самый бум, когда за полгода Grid из состояния первого опубликованного черновика пришел к тому, что сначала Chrome внедрил его без флага, а потом и все остальные браузеры. Из-за того, что внедрение происходило в спешке, спецификация не утряслась и некоторые спорные моменты пришлось оставить, чтобы браузерам не пришлось переписывать половину движка.

Спецификация стабильна, хотя до сих пор в статусе Candidate Recommendation. Если бы я мог, то давно бы уже зарелизил, но разработчики спецификации пока не спешат, а дополняют и меняют формулировки.

Давайте применять нерекомендованную спецификацию Grid Layout — в этом нет противоречия, потому что Grid сначала была реализован, а потом описан.

Второе неверное утверждение — это то, что Grid не имеет смысла без второго уровня.

Второй уровень спецификации

Когда писали спецификацию, она оказалась слишком большой, поэтому какую-то часть выделили во второй уровень. На 2018 год спецификация второго уровня в состоянии First Public Working Draft — первая публикация рабочего черновика.

Над спецификацией активно работают и в ближайшее время она перейдет в состояние Working Draft — рабочий черновик. Разработчики ждут, пока зарелизят Grid, но это долгий процесс, который может затянуться лет на 5.

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

display: subgrid;

Не успели мы понять, что такое grid, как появился subgrid. Давайте разбираться, что это такое.

Представим такую разметку.

Все довольно просто: у нас есть сетка, в нее вложено три несемантических и один семантический элемент. Grid работает как flexbox: когда вы применяете display: grid; к обертке, он применяется только к элементам на первом уровне вложенности.

В примере 1, 2 и 3 <div> займут место в сетке, а все, что находится внутри списка, — схлопнется. Вы потеряете все эти элементы, потому что так работает Grid.

Если хотите, чтобы эти элементы остались частью вашей сетки, то есть два варианта:

• Первый вариант — избавиться от обертки. Удалим <ul>, а <li> заменим на <div>. Мы убьем семантику, но оставим сетку.

• Второй вариант — использовать display: subgrid;.

Если применить display: subgrid; к списку, то элементы <li> станут частью этой сетки, <ul>, как обертка, будет игнорироваться. Вы получите полноценную сетку и останется полноценная семантика — и HTML хорошо, и CSS хорошо.

Одна проблема — subgrid не поддерживается, он где-то там за флагами, а релиза можно ждать еще долго.

display: contents;

Вообще ждать не обязательно, потому что есть display: contents;  — замечательное свойство, которое работает так же, как display: subgrid;. Если для элементов списка применить display: contents;, то элементы <li> станут частью сетки.

Есть нюанс — display: contents; поддерживается не во всех браузерах.

CSS Subgrid Emulation

Пока у display: contents; решают проблему поддержки, верстальщики придумали выход — сделали эмуляцию subgrid.

На слайде пример Паши Ловцевича.

В примере выше есть поведение subgrid, но его поведение эмулируется не посредством display: subgrid; или display: contents;, а за счёт кастомных выражений, которые пересчитываются в переменные.

Свойства с дефисом — это кастомные свойства в CSS.

Второй уровень не нужен

Если кто-нибудь скажет не использовать Grid, пока не выйдет второй уровень — не слушайте его. Второй уровень решает определенные проблемы, которые уже решены другими способами.

Не везде нужны subgrid. Grid в связке с Flexbox иногда получается куда круче, чем с subgrid.

Поэтому не надо ждать второй уровень, смело занимайтесь первым. Тем более, что он уже есть.

Поддержка Grid в браузерах

Эту картинку можно показывать, если кто-то скажет вам, что Grid не поддерживается.

Глобально поддерживается 87% браузеров, кроме Opera Mini — она ничего не поддерживает. Я писал в CanIuse, просил убрать ее из колонки, чтобы не портить картину, но пока безрезультатно 😉

Если добавить @supports, то работает вообще все, даже Opera Mini. Я не знаю, поддерживает ли Opera Mini flexbox, но там можно сделать fallback.

Остается проблема с IE. Как всегда, он здесь, с нами, и никуда не делся.

IE и Grid

Если ваше приложение поддерживает IE, вы возможно скажете, что не можете использовать Grid. Это не так — Grid работает в IE, так как спецификация была рождена в Microsoft, и впервые появилась именно в IE. Просто ее никто не использовал, пока не пришли нормальные люди и не переписали спецификацию.

IE справляется с Grid, но ему нужно объяснить, как это делать. IE поддерживает Grid в старой версии спецификации, в которой не все свойства поддерживаются, а часть называется по-другому.

Версию спецификаций для IE учить не нужно, потому что большую часть работы за вас сделает Autoprefixer — плагин, который переводит новую версию спецификации в старую. Поэтому, чтобы обеспечить поддержку Grid в IE, достаточно использовать Autoprefixer.

Остальное надо просто знать и помнить. Достаточно открыть статью «Supporting CSS Grid in Internet Explorer», прочитать какие свойства поддерживаются в IE, а какие нет, и решить, что из них вы будете использовать.

Помните про «graceful degradation», когда в старых версиях браузера пропадают элементы из новых. Например, в браузерах, в которых не поддерживается border-radius, у форм будут квадратные уголки. Верстальщиков заставляли вырезать картинки форм, вместо CSS, и в некоторых ситуациях это считалось нормальным.

Почему бы в старых версиях браузеров не переводить Grid в обычные колонки? Если вы разрабатываете под старый браузер, либо не используйте современные технологии, либо смиритесь с тем, что контент в них будет выглядеть по-другому.

Internet Explorer вместе с Grid работает неплохо, просто надо немного практики. Если вы не используете Grid, потому что боитесь IE, то я вынужден вас удивить — это не прокатит.

Баги и Grid

Вы можете сказать, что в Grid много багов, но это не так. Rachel Andrew нашла все ошибки в CSS Grid — всего их 14, и это все что есть. Никто не занимается Grid Layout CSS больше, чем Рейчел, поэтому ей можно доверять.

Баги довольно специфические. Мы помним, когда пришли flexbox, в них тоже были баги, но нас это не остановило. Баги в Grid нас тоже не останавливают, тем более, такие.

«Некоторые HTML элементы не могут быть Grid-контейнером». Сразу идет уточнение, что кнопка не может быть Grid-контейнером, но мы и не хотели этого.

«Textarea, когда она является элементом Grid, схлопывается». Проблема легко решается, если поставить ширину и высоту в процентах.

Эти баги довольно специфические и проявляются не во всех браузерах. Если ты знаешь, что баг может проявиться, то просто берешь и исправляешь — это несложно.

Технических причин не использовать Grid не так уж много. Браузеры поддерживают, а в старых браузерах применяйте «graceful degradation». Теоретических причин тоже мало, потому что материалов больше, чем по flexbox.

Теория, или маленький ликбез

• Выжимка спецификации — «A complete guide to Grid» от СSS-Tricks настолько же хороша, как и  по flexbox.
• Курс Learn CSS Grid или видеокурсы, например, от Wes Bos, записанные и спонсированные Mozilla.
• Полное погружение на сайте Gridbvexample.com: сам сайт написан на Grid, там есть информация по всем спецификациям, примеры, сниппеты кода.
• Игра с морковками — полная геймификация, даже дети разберутся.
• Интерактивный курс HTML Academy. Академия внедрила Grid в учебный процесс.

Grid уже здесь! Мы можем долго говорить почему не используем Grid, но пока вы читаете статью, Grid уже задеплоили в продакшен.

Сайты уже используют Grid. Например, я зашел на сайт Russian Internet Week, и это последнее место, где я ожидал увидеть Grid. Обычно сайты бизнес-конференций собираются на Тильде.

Причем они более-менее правильно используют сетку. RIW попробовали, и у них получилось, причем без fallbacks. Они явно ориентируются на пользователей современных браузеров.

Конференции, которые рассказывают про CSS, в любом случае, пытаются применять новые инструменты. Мы на сайте pitercss_conf сделали бейджики, а у ребят из Минска половина сайта на Grid.

Russian Internet Week — это довольно узкая аудитория посетителей. New York Times читает больше людей.

Я уверен, что среди читателей есть владельцы устройств даже с IE 9, 10, 11, но половина сайта на Grid.

Я был удивлен, когда увидел, что такие крупные проекты используют Grid.

Почему Grid не используют повсеместно?

Мы поняли, что спецификация есть, ее можно использовать и никакие отговорки не сработают. Так в чем же дело?

Есть определенные причины не применять сетки:

• Дизайнеры не ставят перед верстальщиками неразрешимых задач.
• Верстальщики не понимают, как приложить Grid к реальным проектам. Скорее всего ваш дизайнер не нарисовал сложную сетку, и вы не понимаете, как приложить Grid к макету.

С точки зрения дизайна

Сейчас я буду защищать дизайнеров.

Дизайн развивается медленно, по своим трендам, никак не связанным с развитием веб-технологий. Скорее наоборот — веб-технологам приходится подстраиваться под тренды дизайна. Маловероятно, чтобы верстальщики сказали: «Дизайнеры, а у нас есть Grid, можно с ним работать», а они бы ответили: «О, да!» и начали рисовать под них макеты.

Поэтому большинство сайтов выглядит так.

Абстрактный пример с простой сеткой и колонками, ничего необычного. Сайт легко собирается без flexbox, на float, даже можно обойтись табличной версткой.

Дизайнеры перестали ставить перед верстальщиками сложные задачи, потому что когда-то мы сами загнали их в угол тем, что перестали делать то, что они хотят.

Приходит к нам дизайнер и говорит:

— Я хочу сложную сетку!

— Я не могу. Она сложная.

— Нет, делай.

— Я не могу!

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

Все, дизайнер больше не рисует сложные сетки. Раньше мы действительно не могли строить сложные интерфейсы, а сейчас можем — у нас полно инструментов. Теперь дизайнер не хочет, он перестал просить сложные макеты. Дизайнер рисует интерфейс, чтобы верстальщик смог его реализовать, и часто максимально примитивно.

Блог

Приведу распространенный пример из нашего аутсорса. Дизайнер получил задачу нарисовать блог и дает волю всем своим сеточным порывам. Рисует большой блок, широкий, 3 маленьких, средний, фантазирует. Выглядит круто и современно.

Верстальщик видит макет, пишет на flexbox одну обертку, вторую, третью и получает вот такую картинку.

Верстка идет в бэкенд.Бэкендер говорит верстальщику, что у него есть вывод из базы данных, а там карточки идут друг за другом, разложить их не получится.

На этом счастливая история заканчивается и мы возвращаемся к дизайнеру.

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

Здесь есть разные варианты выхода:

• Дизайнера отправляют в дальний угол и говорят: «У нас будет все просто друг за другом, обойдемся без твоих выпендрежей, сделай — то, что можно реализовать на flexbox». Дизайнер будет страдать, но выложит на Behance портфолио с красивой сеткой. В макете будет ссылка на продакшен, а там просто квадратики.
• Верстальщик навешивает jQuery-плагин, который автоматом расставляет элементы по сетке с абсолютным позиционированием — все прекрасно! Кроме того, что плагин будет дополнительно нагружать страницу и безбожно лагать в IE. Однако, дизайнер и бэкендер будут довольны.
• Дизайнер и верстальщик договорятся и реализуют невероятную историю и приведут к компромиссу дизайн, бэкенд и верстку.

Реальный кейс

На главной странице журнала «The Village» сложная сетка. Она выполнена намеренно для разных типов материалов. Я знаю про это, так как работал в издании.

«The Village» написали огромный алгоритм, который на бэкенде генерирует сетку. Это смесь float, абсолютного позиционирования и других страшных вещей, но она работает!

Иногда ломается, но, когда это происходит, блоки просто переставляются местами и снова все работает.

Не представляю, сколько часов ушло на то, чтобы спроектировать эту систему, отладить и добиться, чтобы она работала практически без ошибок. Сколько времени бы ушло на реализацию этой же сетки, если использовать display: grid; или grid-auto-flow: dense;? Внутри Grid есть отдельная спецификация, которая автоматом расставляет элементы по странице, сама забивает свободные места и реализует подобную сетку. Не надо десяти тысяч строк кода бэкенда — все работает только одним свойством.

На момент создания алгоритма этой технологии еще не было, но когда речь пошла о редизайне, я предложил сразу использовать Grid.

В «The Village» заморочились, чтобы сделать как хотят, но большинство этого не делает. Поэтому мы видим заурядный веб, стандартизацию, все сводится к одному Layout. Раньше у нас был Bootstrap, который описывает большую часть кода. Сейчас уже у дизайнеров есть свои инструменты, наподобие Bootstrap, которыми они собирают сайты. Что за ерунда — где креатив?!

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

Я мечтаю выступить на конференции дизайна и сказать: «Привет! Мы стали лучше! Мы теперь снова умные», но верстальщика не пускают на дизайнерские конференции. Рассказать дизайнерам, что мы стали лучше — это не так уж сложно. Вам пришла простая сетка, вы спрашиваете: «Почему она простая, а не сложная? Я могу сделать любую!»

С точки зрения реализации

Кажется, что Grid сложно найти. Когда мне говорят: «У меня 3 колонки и я могу сделать это на flexbox. Зачем мне Grid?», то я отвечаю: «Действительно, не надо». Поэтому возникают сложности с тем, где вообще прикладывать Grid.

Grid — это не только сложная сетка

Это и простая раскладка, которую можно сделать на Grid, причем проще, чем на flexbox, потому что не нужна дополнительная обертка. Ниже есть один пример на Grid, его тоже можно сделать на flexbox, но надо много дополнительных оберток или flow, и получится настоящая мешанина.

Grid — не для мелких элементов: либо для очень сложных мелких, либо для крупных.

Grid для раскладки

Я не знаю ни одного сайта, у которого нельзя переписать раскладку на Grid и сэкономить на этом кучу бесполезных дополнительных оберток.

• Grid можно применить к глобальной раскладке.
• Grid можно применить к элементам интерфейса

Это бейджик pitercss_conf-2, он сделан на сетке.

Самое сложное в Grid Layout — это начертить сетку, которая вам подходит. В данном случае это не просто 6*6, а 5*8, но у каждого блока разная высота и ширина.

Мы видим задачу и компонуем контент, очень похоже на направляющие в Photoshop. Дизайнер отрисовал, а мы перевели макет на сетку. Здесь нет ни одной дополнительной обертки — только семантические элементы, которые выстраиваются в сетку с помощью Grid.

Посадочный талон можно сделать на flexbox.

А можно на Grid, и в мобильной версии талон выглядит по-другому.

Grid для структуры

Вторая важная вещь, которую нужно запомнить: с помощью Grid просто менять структуру.

Есть order во flexbox, который позволяет поменять порядок всех элементов. Это сложная технология, и как с Z-индексами можно выстрелить себе в ногу, если не знать, как ей пользоваться.

С Grid все просто. В этом примере, если бы не было сетки, нам бы пришлось правую часть с QR-кодом вынести в абсолютное позиционирование. А на Grid это 13 строк кода в мобильной версии.

Чтобы начать использовать Grid, надо начать использовать Grid. Попробуйте сверстать на сетке некоторые элементы вашего интерфейса. Можно начать с маленьких, можно — с глобальных, чтобы понять, насколько это упрощает жизнь.

Никто не скажет вам: «Вот здесь используй Grid, а здесь — нет!» Вы должны сами понять и научиться, но для этого нужно набивать шишки. Если реализация задачи на Grid заняла в два раза больше времени, чем на flexbox, значит, такие задачи не надо решать на Grid.

Вот для комиксов Grid идеален.

Рассмотрим нетривиальную задачу.

Если покопаться в коде, становится понятно, как все устроено. Ребята программируют на CSS и выстраивают Grid Areas. В зависимости того амплуа игрока, он автоматически встает в нужную Area. Вертикальное и горизонтальное выравнивание создает построение. Это целое программирование на CSS. Задача решается 50 строчками CSS-кода, что гораздо проще, чем через бэкенд или JS.

Я хочу, чтобы дизайны и раскладки были прикольными, такие как эта.

Это слишком сложная верстка на Grid, потому что задача была сложная. Верстальщик не мог отрисовать раскладку на простых flexbox, только Grid. Можно было сделать меньше ячеек, но учитывая, что ячейки строит repeat, на это много времени не ушло. Главное, что они сделали это.

Сверстано замудренно, но интерфейс очень круто перестраивается в дальнейшем.

Что дальше?

Давайте перестанем говорить себе: «Я не могу» в плане Grid. Вы можете — просто не хотите. Нет ни одной объективной причины не использовать сетку, кроме лени и нежелания попробовать.

Grid — это настолько универсальная система, что для нее даже невозможно сделать фреймворк. Если вы видите, что какой-то фреймворк использует Grid Layout — это бред, потому что Grid сам по себе фреймворк для построения сеток. Bootstrap вряд ли перейдет на Grid. Представьте, что там будет 20 миллионов классов — извращение!

Поэтому у вас никогда не будет готового решения. Возможно, будут шаблоны, но правил, где применять Grid, а где нет — не будет.

Учитесь, смотрите примеры, развивайтесь. Нет ничего плохого в том, чтобы смотреть на примеры других людей. Я, например, так и делаю.

Несите знания в команду. Говорите, что знаете Grid, предлагайте его использовать.

Подойдите к дизайнеру и скажите: «Давай ты будешь рисовать интереснее, а я буду твои задумки реализовывать!»

Скажите менеджеру: «Мы теперь можем больше с Grid!»

Делитесь знаниями внутри команды и двигайте веб вперед. В конечном счете у нас простая цель — делать веб лучше и круче!

Если в какой-то момент у нас все уходило в упрощение, то сейчас есть новые технологии. Не только Grid — это SVG-маски, анимации, трансформации. Проблема не в технологиях, а в том, что большинство до сих пор не использует на полную и половины из них. Мы не знаем всего или не хотим использовать, а дизайнеры не догадываются, что мы можем.

Контакты Сергея Попова: e-mail, Fb, twitter

Это доклад — один из лучших на Frontend Conf. Понравилось, и хотите больше — подпишитесь на рассылку, в которой мы собираем новые материалы и даем доступ к видео, и приходите на Frontend Conf РИТ++ в мае.

Знаете больше и готовы делиться опытом — отлично! Присылайте тезисы, прием докладов уже открыт и будет продолжаться до 27 февраля.

стоит ли использовать сетку для построения макета

От автора: вы стремитесь перейти на CSS Grid Layout, но не можете убедить остальных членов команды (ваших коллег или менеджеров)? Кто-то недавно спросил меня, что я могу посоветовать скептически настроенной команде, чтобы они приняли CSS Grid в свой рабочий процесс. Хотя я сам не сталкивался с какими-либо серьезными препятствиями, эту историю я слышу слишком часто.

Несмотря на то, что разочаровывает, подобные настроения имеют под собой некоторую рациональную основу. Давайте разберемся, стоит ли использовать CSS Grid на самом деле.

В качестве примечания, эти соображения продиктованы моим опытом работы в веб-агентстве. Я не претендую на то, что этот опыт подойдет для каждого, и в других средах могут потребоваться другие подходы. Тем не менее, я думаю, что есть некоторые предложения, которые являются универсальными.

Почему их нужно убеждать?

Поддержка браузерами

Наиболее распространенной причиной не принятия Grid является поддержка браузерами. В то время как Grid имеет около 85% поддержки браузерами, оставшиеся 15% — это значительный разрыв. Большая часть этих пользователей работает в IE, который на самом деле поддерживает более старый синтаксис CSS Grid, начиная с IE10. Этим пользователям нужен макет, который, по крайней мере, будет годным для использования. Это подводит меня ко второй проблеме …

Время

Если не все браузеры поддерживают свойство CSS, необходимо предоставить подходящий запасной вариант. В случае использования отдельных свойств (например mix-blend-mode) может быть довольно просто написать дополнительную строку или две, которые позволят пользователям по-прежнему воспринимать ваш контент полезным (если не оптимальным) способом. Это прогрессивное улучшение.

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

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

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

В случае целой спецификации, такой как Grid, если вы примете ее в качестве основной стратегии компоновки, это повлияет не только на один или два элемента, но и на всю веб-страницу. Так что это немного другая история. Вы должны убедиться, что предоставляете подходящие запасные варианты, какую бы стратегию вы не использовали для поддержки старых браузеров. Я не собираюсь отрицать, что это иногда занимает немного времени.

Если остальная часть вашей команды еще не знакома с Grid, то есть также фактор времени, который необходимо учитывать, когда речь идет о том, чтобы научить всех работать с новой стратегией макета. Они могут нервничать по поводу инвестиций в обучение и отвлечения всех от существующих проектов на день или около того.

Поддержка

Некоторые команды могут быть обеспокоены тем, что, когда кто-то в вашей команде выберет ваш проект для работы, им будет сложнее поддерживать его, потому что вы используете незнакомый CSS, а не среду X. В сочетании с этим существует множество различных способов создания макета с помощью Grid. Например, grid-template-areas. Если один человек использует именованные линии сетки, в то время как другой использует его, это может привести к противоречиям в базе кода и, возможно, стать головной болью для всех, кому нужно подойти к этому проекту заново.

Все эти причины сводятся к времени и деньгам. Нам нужно убедить вашу команду, что Grid может помочь в обоих случаях.

Чем может помочь Grid?

Теперь давайте посмотрим, как использование Grid может помочь с вышеуказанными проблемами и не только:

Экономия времени на сложных макетах

Grid значительно упрощает процесс построения макетов, которые ранее требовали много хаков и полифилов. Если вам нужно разобраться со сложным дизайном, используя более старые методы верстки, то вы будете тратить драгоценное время. Конечно, вам также нужно обеспечить доступный резервный вариант для старых браузеров, но часто это не требует значительного времени.

Если ваша команда пишет свою собственную сеточную структуру, используя более старые методы компоновки, это тоже требует времени и усилий.

Творчество

Если дизайнеры, разработчики и команды хотят выйти за рамки и создать действительно креативные, современные макеты, которые выделяются из общей массы и охватывают новую эру мышления веб-дизайна, то Grid является неотъемлемой частью этого. Grid позволяет нам создавать макеты, которые раньше были недоступны в CSS.

Лучшая производительность

Многие проекты импортируют большие, громоздкие CSS-фреймворки для системы сеток. Даже минималистичные фреймворки могут добавить много дополнительных классов, которые увеличивают объем CSS-файла. Для сложных макетов, которые отличаются от «стандартных» столбцов и строк, вам может потребоваться обратиться к библиотекам Javascript. По моему мнению, в 2019 году нам почти наверняка не нужно будет отправлять дополнительные JS только для обработки макета (за очень немногими исключениями). CSS Grid может обрабатывать много сложных случаев с помощью очень небольшого количества кода.

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

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

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

Есть также некоторые признаки того, что создание 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.

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

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

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

PSD to HTML

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

Смотреть

Правда ли уже пора использовать CSS Grid Layout? / Хабр

Я учусь пилотировать легкие самолеты. Это отвлекает меня от компьютеров. Недавно мне никак не удавалось удержать Сессну-150 на малой высоте, когда мы приближались к аэропорту Бристоля. Меня буквально засосало в облако восходящим потоком. Мой летный инструктор сказал: «Это не ваша вина, но ваша проблема». Он имел в виду, что я обязана была удерживать высоту, пусть даже что-то работало против меня. Мне нужно было узнать, что бывает такая ситуация, и научиться справляться с ней при пилотировании.

Уже после приземления я подумала, что фраза «это не ваша вина, но ваша проблема» отлично подходит практически к любым ситуациям. В этой статье я раскрываю тему поддержки старых браузеров при использовании новых технологий наподобие CSS Grid Layout. Мы, разработчики, часто робеем при обсуждении браузерной поддержки с заказчиками и коллегами, как будто это мы виноваты в том, что сайты не выглядят в IE9 в точности так же, как в новейших Firefox или Chrome. Пора нам уже принять, что это не наша вина. Но обязанность справиться с этим как следует, с пользой для каждого — во многом наша проблема.

Гриды совсем новые! У них наверняка ужасная поддержка в браузерах?

CSS Grid Layout уже работает в Chrome, Firefox, Opera и Safari с марта этого года. Microsoft Edge недавно выпустил предварительную сборку с гридами за флагом. На момент выхода статьи Can I Use показывает, что глобальная поддержка CSS Grid Layout составляет 65.64%, или 70.75%, если добавить версию с префиксом из IE10-11 и теперешнего Edge. До сих пор мы не видали, чтобы настолько грандиозная новинка внедрялась так быстро. Неудивительно, что люди не осознают, у какого множества посетителей поддержка будет.

Не стоило об этом и упоминать, но я всё равно скажу, что у вас цифры могут быть больше или меньше в зависимости от аудитории вашего сайта. Но если вы прямо сейчас делаете новый сайт, есть хорошая возможность воспользоваться преимуществами CSS Grid Layout.

Зачем мне использовать гриды?

Как я объясняла в предыдущей статье, CSS Grid Layout дает возможность делать двумерную раскладку без дополнительной разметки для оборачивания рядов. Поскольку раскладка двумерная, элементы в ней могут охватывать несколько рядов, надежным и предсказуемым образом.

Можно добиться некоторых приятных дизайнерских эффектов. Например, чтобы элементы в дизайне были как минимум определенной высоты, но растягивались при более высоком контенте — как в этом примере.

Можно легко чередовать элементы фиксированной ширины с гибкими элементами, с помощью единицы fr в гриде. Благодаря этому проще иметь дело с элементами макета, которые должны сохранять фиксированный размер.

Можно переопределять раскладку на уровне контейнера, что делает отзывчивый дизайн элементарной задачей, и настраивать дизайн индивидуально при различных размерах окна.

Можно накладывать элементы друг на друга, они подчиняются свойству z-index, так что разные элементы можно помещать в одни и те же грид-ячейки, что дает массу простора для творчества.

А как же неподдерживающие браузеры?

В CSS есть для вас решение. Во-первых, в спецификациях гридов и флексбоксов уже точно определено, как эти спецификации переопределяют старые методы раскладки.

Таким образом, если вы хотите использовать флоаты, инлайн-блоки, многоколоночную раскладку, флексбоксы или даже display: table в качестве фолбэка для своей раскладки на гридах, в спецификации уже всё предусмотрено. Можете переопределять эти методы надежным и предсказуемым способом. Я сделала шпаргалку с пояснением фолбэков. О некоторых из них говорится в моем докладе, записанном на конференции Render ранее в этом году.

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

1. CSS для фолбэка
2. CSS для гридов

Все браузеры поймут стили для фолбэка. Те, что не поддерживают гриды, на этом и остановятся. А те, что поддерживают, будут использовать стили для гридов, и благодаря правилам, которые описаны в спецификации и поясняются в моей шпаргалке, многое в фолбэчном поведении обнулится.

Как правило, в стилях фолбэка у вас останется что-то, что «просочится» в раскладку на гридах. Часто это бывает ширина элементов, поскольку в старых раскладках приходится задавать им ширину, чтобы имитировать что-то похожее на грид. Поэтому мы используем простую директиву supports, проверяем поддержку гридов, и в ней, может быть, возвращаем ширине значение auto. Вообще там можно делать для грид-версии что угодно, не опасаясь, что это увидят старые браузеры.

Мы пишем CSS с помощью CSS. Никаких полифилов, никаких хаков. Всё строго по спецификации.

Но фолбэки означают, что я пишу раскладку дважды!

Это верно лишь если вы в своей работе исходите из того, что сайты должны одинаково выглядеть во всех браузерах. И знаете что? Это ни к чему.

Вот статья, которую я написала в 2002 г. В 2002-м люди боялись изучать верстку на CSS, потому что это значило бы, что их сайты не будут «одинаково отображаться» во всех браузерах. Но я верстала сайты с помощью CSS, стараясь выяснить, как это можно сделать наилучшим образом, и учила других людей тому, что узнавала сама. С самого открытия собственной фирмы, делая сайты для клиентов, требующих, чтоб всё работало в Netscape 4. Я занимаюсь этим на протяжении всей своей карьеры. Я разбираюсь с проблемами совместимости уже 20 лет. Сейчас я делаю продукт с интерфейсом, который должен работать вплоть до IE9. Не моя вина, что эти старые браузеры существовали, но моя проблема и моя работа все эти годы как раз в том и состояла, чтобы справляться с ними.

Если ваш сайт действительно должен выглядеть одинаково во всех браузерах (что бы это для вас ни значило), вы не сможете использовать ничего, что можно сделать только гридами. В таком случае не используйте гриды! Используйте Grid Layout, если хотите добиться чего-то, чего никак не сделать нормально старыми технологиями. Затем делайте фолбэк, которым можно будет пользоваться в менее продвинутых браузерах, и не беспокойтесь о том, чтобы сделать в точности так же. Мощь гридов в том, что с ними можно делать такое, что раньше было невозможным. Используйте их для этого, а не для воссоздания своих старых дизайнов.

Хочу волшебный полифил!

Если глобально подпереть полифилом весь макет, для пользователей это будет кошмаром. Если реализовать то, что делают гриды, средствами JS, это всё будет жутко тормозить. Загрузка страницы в итоге будет выглядеть ужасно «дерганой». Гораздо лучше дать этим старым браузерам вариант попроще, адаптированный к их возможностям, чем пытаться насильно впихнуть в них грид-раскладку скриптами.

Попытки сделать полифил могут существенно затянуть вам сроки разработки и тестирования, причем для меньшей группы пользователей. Опять же, если одинаковый вид для всех — идеал для вашего сайта, я бы не советовала использовать гриды прямо сейчас. Вам придется принять, что все те пользователи, которые могли бы насладиться грид-раскладкой, будут ее лишены из-за наличия в мире старых браузеров.

Вот что значит разрабатывать для веба

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

Ваша работа состоит в том, чтобы изучать новое и советовать своему клиенту или руководству, как наилучшим способом реализовать их бизнес-цели при помощи всех доступных технологий. А для этого вы должны сначала сами изучить эти новинки. Тогда вы сможете советовать им, на какие именно компромиссы пойти стоит. Гарантировать единообразный дизайн ценой добавочной разметки, лишнего времени на разработку или вынужденного ограничения удобства для всех браузеров? Или упрощенный макет для IE9, что позволит сократить время разработки, и более быстрый сайт благодаря новым технологиям в итоге? Если вы понимаете плюсы и минусы каждого варианта, вы сможете отстоять свои аргументы.

Если использование новой технологии не дает абсолютно никаких преимуществ, то и не используйте ее. Но если ваш клиент хочет чего-то такого, что есть смысл делать только на новых технологиях типа гридов, или что на гридах можно сделать быстро, а без них придется долго мучиться, у вас есть куча способов объяснить возможные компромиссы, их выгоду и цену.

Объясняйте их тем, сколько времени на разработку, сейчас и в будущем, можно будет сэкономить благодаря меньшей сложности.

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

Объясняйте их быстродействием, во многих случаях этот аргумент сработает, потому что можно будет избавиться от громоздкого фреймворка, без которого иначе было бы не обойтись.

Всё это мы получим в обмен на требование отдавать упрощенный макет старым браузерам. Но это не значит «никакого макета». Будьте готовы объяснить и то, что внедрение гридов в браузеры не похоже на внедрение чего бы то ни было в CSS, что мы видели прежде. Реализации уже совместимы как никогда. Edge уже обновил гриды за флагом в предварительной сборке. Браузеры без поддержки исчезают намного быстрее, чем можно было бы ожидать по прошлому опыту.

Когда вы вооружены всей нужной информацией о цене вопроса, дискуссия становится очень простой. То, что старые браузеры существуют — не ваша вина. Не начинайте этих дискуссий так, как будто это вы провалили задание добиться, чтобы сайт выглядел одинаково во всех браузерах, выпущенных за последние 10 лет, используя при этом технологию, которой нет и года. Это не ваша вина, но ваша проблема. Ваша проблема, ваша обязанность как веб-профессионала, поставить себя в такие условия, в которых вы сможете выбирать правильный курс действий для каждого проекта.

Вот к чему мы идем

Переход от табличной верстки к CSS изменил облик веба. Он увел нас от попиксельно нарезанных картинок к чему-то более гибкому, с текстом в основе, менее похожему на печатный дизайн. Последние 15 лет облик веба диктовался техническими ограничениями CSS. Думаю, что наши новые раскладочные методы — гриды, флексбоксы и штуки вроде веб-фигур — изменят его облик снова. Но мы должны дать этому случиться, нам надо позволить себе экспериментировать, учиться и творить новое.

Мы сможем сделать это, только если готовы показывать преимущества этих методов тем людям, для которых мы делаем сайты и приложения. Мы можем сделать это, только если отбросим наши предрассудки о вебе, браузерах и темпах внедрения хотя бы до тех пор, пока не изучим все эти штуки. Только тогда мы сможем принимать правильное решение для каждого проекта. Никогда не будет четкого «или — или», всегда будут компромиссы. Наша работа — справляться с этим, как и всегда.

Что такое грид-вычисления? (с изображением)

Грид-вычисления — это совместное использование задач на нескольких компьютерах. Задачи могут варьироваться от хранения данных до сложных вычислений и могут распространяться на большие географические расстояния. В некоторых случаях компьютеры в сети используются как обычно и действуют как часть сети только тогда, когда они не используются. Эти сетки очищают неиспользуемые циклы на любом компьютере, к которому они имеют доступ, для завершения заданных проектов. SETI @ home, пожалуй, один из самых известных проектов в области грид-вычислений, и ряд других организаций полагаются на добровольцев, предлагающих добавить свои компьютеры в грид.

Во время грид-вычислений несколько систем выполняют задачу в определенном месте.

Эти компьютеры объединяются в виртуальный суперкомпьютер. Сетевые компьютеры могут работать над теми же проблемами, которые традиционно предназначены для суперкомпьютеров, и все же эта сеть компьютеров более мощная, чем суперкомпьютеры, построенные в семидесятых и восьмидесятых годах.Современные суперкомпьютеры построены на принципах грид-вычислений, объединяя множество меньших компьютеров в большее целое.

Идея грид-вычислений возникла у Яна Фостера, Карла Кессельмана и Стива Туеке. Они собрались вместе, чтобы разработать набор инструментов для управления вычислениями, перемещением данных, управлением хранилищем и другой инфраструктурой, которая могла бы обрабатывать большие сети, не ограничивая себя конкретным оборудованием и требованиями.Техника также исключительно гибкая.

Методы

грид-вычислений могут использоваться для создания грид-сетей самого разного типа, добавляя гибкости, а также мощности за счет использования ресурсов нескольких машин. Сетка оборудования будет использовать сетку для управления частью оборудования, например телескопом, а также для анализа данных, которые собирает оборудование.Однако сетка данных будет в первую очередь управлять большими объемами информации, позволяя пользователям совместно использовать доступ.

Грид-вычисления похожи на кластерные вычисления, но имеют ряд отличий. В сетке нет централизованного управления; Компьютеры в сети управляются независимо и могут выполнять задачи, не связанные с сетью, по усмотрению оператора.Компьютеры в сетке не обязательно должны иметь одинаковую операционную систему или оборудование. Сети также обычно слабо связаны, часто в децентрализованной сети, а не содержатся в одном месте, как это часто бывает с компьютерами в кластере.

.

PPT — сетка доступа Что это такое и для чего она нужна? Презентация PowerPoint

.