Комментарии 4
прикольно продумано!
А я не знал, что на майл.ру можно туда суда-двигать прямо в браузере, довольно модно получилось.
Сейчас верстка - как минное поле, слишком всё друг на друге завязано, то очень вас понимаю - внедрять что-то новое в такой крупный проект - ещё та задачка!
Божественное имя у поста.
Честно, не понимаю, зачем надо было городить обсерверы, если у вас всего пара "ручек", за которые можно тянуть.
Брейкпоинты и фиксированные раскладки под них -- да, логично. А ваш подход выглядит каким-то переусложненным. Не сделайте, пожалуйста, из Мэйла подобие Фейсбука по внутреннему устройству.
Я как раз и старался в статье описать, почему применили именно такой подход :)
По сути, это и есть "брейкпойнты и фиксированные раскладки". Но брейкпойнты в рамках компонента, а не в рамках приложения. Подобные технологии часто применяют в других платформах, где компонент - что-то более фундаментальное, чем в вебе (тут слишком принято через css дотягиваться "куда угодно" в архитектуре). В качестве яркого примера - flutter, где виджет явно адаптируется под "выделенное" ему место.
Если мы попробуем сделать это на каком-то другом уровне (например, когда колонка размера X, применяем стиль Y к кнопке "написать письмо"), то получим плохо поддерживаемые селекторы в css на родительский класс + компонент, и кнопку, которую очень дорого будет просто передвинуть на другое место в интерфейсе. Да что там, даже для того чтобы добавить ей отступы - может понадобиться менять брейкпойнты.
Плюс, когда Container Queries таки выпустят - переход на них с такого подхода будет организовать очень даже просто. Они реализуют такую же возможность. Правда, когда писался этот код (статью выпускали не сразу), они были только в состоянии intent-to-prototype. А вот сейчас, даже когда реализации ещё нет ни в одном браузере, уже постепенно появляются полифиллы.
Адаптивный layout — как переверстать весь проект, не перевёрстывая его