Как стать автором
Обновить

Комментарии 19

НЛО прилетело и опубликовало эту надпись здесь
Мы, вероятно, сильно не правы, т.к. очень далеки от вёрстки.
Но у нас есть смутное чувство, что история повторяется. Сначала были таблицы, все от них плевались. Потом стали дивы, и половина статей была на тему как на них реализовать то, что делалось на таблицах без проблем, но таблицы назывались греховными. Потом появились флексбоксы, в них содержалось много табличного по идеологии и вот — дошли до гридов. И гриды как-то по нашим ощущениям являются по сути более ¿улучшенной? версией таблиц.
гриды как-то по нашим ощущениям являются по сути более ¿улучшенной? версией таблиц

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

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

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

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

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

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

Можете уточнить, в чем проблема при таких условиях?

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

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

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

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

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

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

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

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

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

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

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

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


Картинка


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


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

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации