Comments 29
Мне кажется, что это можно сделать с помощью банальных скучных классов css, более банально скучно и понятно.
1) Как предлагаете полностью "спрятать" странное поведение overflow-y: auto в классе?
2) Промежуточное решение как раз и было основано на атрибутах css, которые близки классам, но компактнее в использовании. Если кому лучше подходят классы - не вопрос. Речь про то, что пока не попадалось элегантных решений.
Я думаю что предыдущий комментарий был отсылкой к тому, что в HTML часто для разметки стилей используют просто классы, а не атрибуты, как у вас. Исторически было так что стили на атрибутах работают медленее чем на классах, но как сейчас обстоят дела с производительностью стилей на атрибутах я не знаю. К теме странного поведения overflow-y: auto это не имеет никакого отношения.
Grid как раз и был создан для того чтобы решать подобные проблемы и отлично решает их. Flex - это как бы 1D (либо по горизонтали/либо по вертикали), а Grid - это как бы 2D (и по горизонтали и по вертикали).
Попробуйте решение: https://latis.cc/comment/300. Это grid, и в нем нет никаких костылей.
Спасибо за идею. Ответил дополнением в конце статьи.
Тот лайоут, что Вы повторили с помощью grid, можно упростить до использования одного единственного <div style="display: grid; и не "городить" ещё один вложенный grid.
<div style="display: grid; grid-template-columns: auto 1fr auto; grid-template-rows: min-content auto min-content; overflow-y: auto; height: 100%;">
<div style="background-color: lightblue; grid-column: 1 / span 3">Header</div>
<div style="background-color: bisque;">Left panel</div>
<div style="overflow-y: auto;">
Grid<br/>Grid<br/>Grid<br/>Grid<br/>Grid<br/>Grid<br/>Grid<br/>
Grid<br/>Grid<br/>Grid<br/>Grid<br/>Grid<br/>Grid<br/>Grid<br/>
</div>
<div style="background-color: bisque;">Right panel</div>
<div style="background-color: lightblue; grid-column: 1 / span 3">Footer</div>
</div>Заметьте, вы сводите решение к частному случаю, в котором возможно "упростить grid", но беда частных случаев в том, что их нужно помнить. В статье же, я пытался показать универсальный способ построения разметки. В котором для достижения результата делается одно и то же, независимо от уровня вложенности блоков и т.д.
Т.е. например Карандаш - он всегда рисует, независимо от того круг или квадрат. А когда нужно нарисовать треугольник, вы смело берете карандаш и рисуете, не вспоминая, в каком окружении его нужно нарисовать и т.д.
Мой пример использования grid был сделан намеренно общим, без "оптимизаций для частного случая", так как они сложнее в запоминании и т.д.
Но, разумеется, удобнее использовать фасад (вроде показанного Box), который "сделает все красиво" и будет столь же простым, как и оптимизированная частная реализация, вроде показанной вами.
И первая строка слегка выбивается из понятия "просто" :)
Ваша "универсальность" сводится к слишком узкому пониманию того, как реализованы и работают очень богатые возможности grid и flexbox. По сути вы свели не "нет" всё то, что вам предлагает такая богатая технология.
А по поводу карандаша ... У нас в команде таких "художников" рисовать карандашом столько, что голова кругом идет. Постоянно приходиться бить по рукам. На форме от силы 5 - 6 элементов ввода, а её layout содержит столько же, а иногда даже больше div контейнеров с о стилем display:grid; вложенных друг в друга чуть линао 4-ре уровня в глубину (!) Это же тихий ужас!
p.s. Если для Вас первая строка в приведённом мной примере вызывает сложность, я бы советовал подучить сначала мат. часть :-) Там вообще-то базовые вещи. Без них Вам будет в дальнейшем сложно.
Боюсь вы не прочитали статью полностью, либо мне не удалось донести свою мысль правильно. Если даже для простых ситуаций, необходимо "богатство синтаксиса", то это считаю недостатком.
Непонятен тезис про количество div+grid. Думаю, привязываться нужно не к количеству элементов ввода, а к количеству функциональных зон. При этом не вижу никакого криминала в том, чтобы обернуть каждую зону одним div (если мы говорим о чистом html\css). В рамка одной функциональной зоны, лишних div не будет.
Также, вы слишком буквально понимаете слово "сложность". Речь о избыточном синтаксисе и т.д. Проблем осознать приведенные синтаксические конструкции нет.
Вам для блока (4) нужно тоже добавить overflow-y: auto и всё у Вас заработает. Общий концепт таких разметок в том, что если Вам нужно некая прокручиваемая область, то overflow нужно "прослеживать" вплоть до родительского элемента на несколько "поколений" вверх по иерархии child-parent. Если в этой цепочке у некоего div где-то отсутствует overflow, то всё "рвётся", т.к. высота такого блока расчитывается по сумме высот всех блоков в него входящих и сколлируемость как бы переходит на уровень вверх по иерархии.
p.s. для Left и Right тоже нужно добавить overflow.
Спасибо за пояснение логики, которая от ясности не становится простой.
Мне как пользователю не понятно, почему просто указания "сделай это прокручиваемой областью" недостаточно.
Еще раз: об этом как раз и статья: простое должно быть простым. Если нужно, для достижения этого можно и нужно реализовать единожды некий фасад над "магией" или "ясной но избыточной логикой".
Логика "проста". Overflow параметр всего лишь необходимое условие, но никак недостаточное. Вы поймите, что если Вы в некий блок натолкали каких-элементов и не зафиксировали явно или неявно размер этого блока, то его результирующий размер - это сумма всех размеров его елементов (children).
Если у блока с overflow его родитель сам не имеет overflow, то результирующий размер родителя - это опять же сумма всех размеров его елементов (children). Естественно ваш блок не получит скроллбар, т.к. в родителе он получил достаточное пространство для отображения всего своего контента. Поэтому скроллбар возможно появится у другого parent или grand parent вверх по иерархии, пока для этого не появятся соответствующие уловия.
И так будет всегда, пока всё это дело не "упрётся" в body, который конечно же физически ограничен размерами клиентской области окна и как результат - вы видите скроллбар у всего докуметна.
Один из читателей предложил Grid вместо Flex.
Но ни тот, не другой как высокоуровневое средство разметки мне не кажется удобным.
Принципиальной разницы в случае "упаковки" в некий компонент\набор css классов не вижу.
Если мы рассматриваем только css-стиль overflow, то Grid и Flex в этом контексте совершенно "одинаковы".
Спасибо автору от труженников back-end-а, которым раз в год надо что-нибудь на фронте замастрячить! ?
Судя по постскриптуму, вы плохо понимаете, как нужно использовать вариант @kotan-11, но поспешили отвергнуть его. Его сила как раз в уходе от порочного принципа "взаимоположение блока определяется самим блоком и его контейнером" в пользу правильного - "компонент знает только своё собственное устройство и ничего не знает о родителе и соседях".
Взаимное расположение блоков определяется централизованно, той самой "картой". Особенно удобно делать отзывчивость: по медиа-запросу меняются несколько свойств grid-template-* у лейаута - и все компоненты-потомки перестраиваются. Ничего не зная друг о друге. В произвольное количество рядов и столбцов, потому что промежуточные обертки не путаются под ногами. Нативно, без лишних перерендеров DOM-а.
Вариант @kotan-11 понят мной именно так, как вы его описываете. Только как раз ваша интерпретация предложенного мной подхода неверна (возможно из-за моих недостаточных литературных способностей).
Я предлагаю централизованную карту разметки распределить по функциональным блокам, расположенным по месту. Компоненты, размещаемые в этих блоках действительно не знают о соседях. Но блоки - знают. И только они определяют положение дочерних компонентов. В примерах из статьи, "компоненты" вырождены в простой текст и стиль блока. Также, при необходимости, можно в одном блоке на любом уровне вложенности разместить любое количество любых компонентов\блоков, которые не будут знать о своем местоположении ничего, но тем не менее выстроятся нужным образом. И, меняя свойства контейнера, можно перестраивать расположение дочерних компонентов, которые ничего по прежнему не знают друг о друге.
Во пример "компонентов" не знающих о соседях и не определяющих своего положения, но выстраивающихся так, как это задает их контейнер. Здесь, меняя свойства контейнера (col, gap, xAlign), можно изменять положение дочерних блоков.
<Box col gap expand>
<Box gap hAlign = {Align.Start}>
<div className = 'bar'>Component</div>
<div className = 'bar'>Component</div>
<div className = 'bar'>Component</div>
</Box>
<Box gap>
<div className = 'action'>Component</div>
<div className = 'action'>Component</div>
<div className = 'action'>Component</div>
<div className = 'action'>Component</div>
</Box>
<Box gap hAlign = {Align.End}>
<div className = 'panel'>Component</div>
<div className = 'panel'>Component</div>
</Box>
</Box>Вот пример динамически перестраиваемой разметки с компонентом Box (попробуйте изменять ширину окна браузера) :
А вообще мы, как это обычно бывает, "соскользнули" с главной темы.
Суть вообще не в противостоянии Grid vs Flex или "карта" vs "по месту". Речь про короткий внятный элегантный синтаксис разметки, логику которого не нужно вспоминать. Причем, что важно, именно во взаимодействии нескольких аспектов (flex\вложенность + overflow) или любых других.
И, меняя свойства контейнера, можно перестраивать расположение дочерних компонентов, которые ничего по прежнему не знают друг о друге.
Как будто бы да, но нет. Ваша абстракция протекает.
Дочерние блоки может и "не знают" о соседях, но косвенно их "чувствуют" при делёжке доступного места. Может возникать неявная взаимозависимость размеров. В гридах такое тоже возможно, если нужно. А если не нужно — легко реализуются действительно независимые ячейки.
Кроме того, ваша система не умеет нормальный адаптив. Даже тривальный случай (2 в ряд -> 2 в столбик) требует JS, а что-то нетривальное просто невозможно.
Гриды по своим возможностям и гибкости выше на порядок, потому что их придумали с учетом накопленных за пару десятилетий боли и опыта. Сложного там тоже ничего нет. Поначалу немного непривычно — может быть, но разобраться нетрудно. А разобравшись, можно использовать стандартный общепринятый механизм, с которым по умолчанию знаком любой фронтендер с улицы.
Вижу два посыла в вашем ответе:
Grid мощнее: Я не против грида в принципе. При необходимости можно использовать его. Что считаю неудобным - централизованная "карта" сразу всей разметки в нем. Но это холиварный вопрос, понимаю.
Grid привычнее: А вот здесь очень интересно. В свое время Grid был "непривычной новинкой" и т.д. Попробуйте отнестись к этой статье, не как к руководству к действию, а как обозначению проблемы и некоторым идеям, которые можно использовать как угодно.
Вообще проблема избыточной сложности глобальна. Сейчас накоплен такой багаж знаний, технологий и инструментов, что дальнейшее развитие требует подходов к "укрощению" этого джина сложности. На разных уровнях.
Странно, но пока за Grid голосов нет. Вообще.
Спор в комментариях был ради спора?
Простое должно быть простым: Палки в разметку