Website development
CSS
HTML
Comments 19
UFO landed and left these words here
+2
Мы, вероятно, сильно не правы, т.к. очень далеки от вёрстки.
Но у нас есть смутное чувство, что история повторяется. Сначала были таблицы, все от них плевались. Потом стали дивы, и половина статей была на тему как на них реализовать то, что делалось на таблицах без проблем, но таблицы назывались греховными. Потом появились флексбоксы, в них содержалось много табличного по идеологии и вот — дошли до гридов. И гриды как-то по нашим ощущениям являются по сути более ¿улучшенной? версией таблиц.
+2
гриды как-то по нашим ощущениям являются по сути более ¿улучшенной? версией таблиц

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

Таблица обладает семантикой и предназначена для вывода табличных данных. Гриды и флексы не обладают семантикой и предназначены исключительно для раскладки.

А если начать вдаваться в детали, то получится что гриды и таблицы похожи только на первый взгляд.
-1
Про разную семантику — это всё как бы верно, но если откровенно, то рядовому веб-разработчику на это плевать (и я его понимаю). Намного важнее то, что гриды позволяют очень гибко управлять размерами и поведением своих ячеек, а таблицы в этом смысле тупые и малопредсказуемые.
+2

Гриды — это таблицы на максималках. Табличные раскладки имели довольно громоздкий код в html (особенно вложенные друг в друга) и часто имели непредсказуемое поведение (до сих пор мало кто знает про table-layout: fixed).


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


Главный недостаток (кроме поддержки разных версий браузеров¹) — «плоская» структура, все элементы должны быть строго потомками первого уровня относительно корневого элемента раскладки. Это собираются исправить во второй версии гридов с помощью сабгридов.


¹ Однако, базовая версия есть даже в IE11, и без некоторых фич может работать даже в нём с помощью Автопрефиксера (из-за неполной поддержки надо включать отдельно).

0
Это собираются исправить во второй версии гридов с помощью сабгридов.

Боюсь, там «флексбокс вс. грид» окончательно станет холиварной темой, особенно если по производительности будет плюс-минус однинаково.
+1

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


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


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

0
Но в общем случае у них разные области применения. Сделать сетку на флексах можно сделать только с помощью лишних обёрток и, возможно, хаков в запущенных случаях.

Ну на самом деле это всё не так сложно, и эта задача вообще не сложнее создания чего-то типа модального окна в html (т.е. такой вещи, у которой нет адекватного built-in функционала, но который тривиально эмулируется кодом и некоторой дополнительной версткой).
То есть с одной стороны да, сетку на флексе сделать — нужны будут дополнительные блоки и дополнительный код, с другой стороны это будут очень даже очевидные дополнительные блоки и очевидный дополнительный код.
0

table-layout: fixed, кстати, отвратительно работает в ситуациях, когда первая строка таблицы имеет объединённые ячейки при ненулевой толщине границы.

0

Насколько я помню, там получается проблема с границами, которые то учитываются, то нет. А в colgroup нельзя использовать calc, из-за чего таблица вечно вылезает на пару (десятков) пикселей за пределы контейнера.

+1

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

+1

При table-layout: fixed не должна, там нет рекурсивной обработки всех ячеек.

0
Это было бы по сути так, пока ты вдруг н понимаешь для чего все-таки существуе тgrid-template-areas.

Я при беглом осмотре grid-ов вообще не понял в чем преимущество перед таблицами, а когда понял что надписи имен профайлов в grid-template-areas это и есть блоки, и как ты их напишешь, просто напишешь их имена в тексте, так они и выстроятся на странице — это реально магия, вот только тогда я понял для чего сделали Grid.

Это реально cool, напиши 3 слова в строку — получи 3 столбца в итоге, напиши 2 слова в строке и 2 во второй строке — получи 4 ячейки 2x2.

При чём, размеры в fr, сами подгоняют соотношения в любой ширине (для меня это кстати было большим плюсом, ибо я уже 20 лет пишу неизменно размер столбцов для ListView в обычных языках именно в соотношениях относительно друг к дургу, а не в каких то других единицах).
0
Таким образом, в примере выше содержимое первого блока настолько большое, что создаёт проблему, потому что, как flex-элемент, по умолчанию он стремится сжаться, чтобы вместить содержимое

Иногда такое подходит:
.flex-container {
  min-width: max-content;
  <...>
}
-3
«Таким образом, в примере выше содержимое первого блока настолько большое, что создаёт проблему, потому что, как flex-элемент, по умолчанию он стремится сжаться, чтобы вместить содержимое. В этом примере данный элемент имеет много содержимого, так что…

«Я задал ширину одному элементу флекс-контейнера, и не задал другому».

У меня объяснение короче вышло. Если очень волнует вопрос, как элемент с шириной в 50% может оказаться меньше 50%, у меня есть второе короткое объяснение:

«flex-shrink по умолчанию выставлен в 1».

Эти сопли про неочевидность флексбокса хороши только для того, чтоб под ними написать статью про «а давайте не флексбокс». Но сами по себе они очень слабенькие. Точно так же можно накатать слезливую статью о том, что html плохой и неочевидный, потому что <body> имеет какие-то дефолтные margin, хотя никто об этом его не просил.
0

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


Картинка


Это может оказаться нежелательным выравниванием. Например, если имя окажется слишком длинным и не влезет в одну строку — то либо фотография "уедет" вниз, либо кнопки оторвутся от неё.


Так что без выделения двух колонок тут не обойтись.

+1

Я сейчас заканчиваю сайт, полностью на grid, сделал его. Это просто кайф.

Only those users with full accounts are able to leave comments.  , please.