Comments 22
А flex контейнер не может сам рассчитать девятку если правильно задать правило распределения элементов и число колонок?
Мне более читаемым/явным показался grid.
По этому использую его для сложных шаблонов, а для простого выравнивания по центру, сторонам - flex.
В остальном - флекс без проблем, но нужно объединять в контейнеры будет каждую строку, либо проставлять на детях flex-grow 1/2. А через grid можно всё в одном месте задать.
Стиль именования переменных правильный, но классы то зачем с заглавной писать ?)
Весной 2021 года Microsoft объявила, что с 15 июня 2022 года прекращается поддержка IE11 (да, не для всех версий Win 10, но всё же), а значит, к выходу статьи уже останется менее полугода до знаменательного события, когда не придётся верстать под IEНу то, что поддержку прекратят — еще не означает, что браузер тут же исчезнет со всех компьютеров)
1. Браузеры давно и прекрасно работают с дробными размерами. Нет никакой проблемы сделать стандартный межколонник 8px, а лишний пиксель раскидать половинками в колонки.
2. Величина 343px — это ширина стандартного айфона (375) минус два стандартных марджина по 16. То есть это ширина контентного контейнера, а не экрана — нельзя эту величину использовать в медиа-запросе.
3. Но 375 это лишь один из популярных экранов, а есть и другие — и к слову сказать, большинство четные. А главное, множество телефонов на Андроиде имеет экран 360, в который ваша верстка просто не влезет. (Кстати, именно поэтому лично я предпочитаю рисовать мобильные макеты под 360, а не 375).
4. Зачем в коде конкретная ширина экрана и колонок?! Там вообще не должно быть переменных типа $columnWidth — там нужно работать либо свойством flex, либо единицей 1fr в гридах.
5. Дискретные ширины экрана — это дичь уже несколько лет как. Это получается устаревшая адаптивная (несколько фиксиарованных размеров), а не отзывчивая (тянется непрерывно) верстка.
По первым 3м пунктам думаю нет смысла отвечать. Они никак не противоречат статье. Странно, что вам показалось, что я спорю хоть с чем-то из этого.
А по поводу последних двух.
Это шикарно, если можно сделать всё динамично - это ещё лучше передаст мысли заказчика.
Во второй части статьи я привёл свой пример, где нужно было сделать только для определённых телефонов дизайн, но вкорне отличным.
Если вы можете сделать не так, а записать другим способом, например используя медиа квери с ориентации девайса или ещё чего - это намного лучше, чем не используя их или хард кодя.
Идея статьи описана в первом предложении отражена. Поясните пожалуйста, где вы увидели в корне не правильные выводы.
По первым 3м пунктам думаю нет смысла отвечать. Они никак не противоречат статье.А код им противоречит. Код ведь является частью статьи?
Желание отразить в коде логику дизайнера — несомненно благое. Посыл правильный, а вот его реализация — нет. Потому что в итоговом коде неправильно примерно всё. Где-то посередине рассуждения пошли не в ту сторону.
Почему не в ту? Код никак не противоречит. В коде нет проблем с четностью и нечетностью. То, что вы написали дальше про колонки в статье и используется. Там абзац про инвертирование логики.
Возможно вы предложили вариант отразить лучше. Статья об этом. Я предложил один вариант, вы ещё более понятный по вашему мнению.
Великолепно, значит мы вместе охватывает сразу кучу вариантов написания.
Главное, чтобы логика заказчика была отображена в коде максимально близко к логике его рассуждения.
Если он мыслит в brakepoint, то нельзя делать по другому. Тк именно так думает заказчик. Даже если кому-то кажется, что так логичнее.
Иначе получится классика, что одни сделали по гайдам фейсбука, вторые поддерживают по гайдам майкрософта, третьи тестируют по гайдам гугла. А бедный заказчик бегает и не знает, почему его код ужасен. Нужно делать по гайдам заказчика.
З. Ы. Я не говорю про сохранение логики дизайна, я говорю про сохранение логики заказчика. Это разное. Дизайн - лишь очередной инструмент в переводе мыслей заказчика в код. Просто более наглядный, чем слова заказчика.
12 месяцев пытался руководство убедить что верстать в рем(про ем и зависимости размера шрифта от ширины окна), использовать сетки - упрощает и главное ускоряет связку проектировщик-дизайнер - верстальщик. А так же если применять бэм упростит дальнейшую поддержку...
Но в итоге руководитель (он верстал на таблицах раньше, про флекс не в курсе даже) решил что препроцессоры и jade нам как верстальщикам не нужно, нам надо в один файл на чистом CSS заполнять и все. (Типо мы кучу времени тратим на придумывание структуры и.т. д). А я еще про Tailwindcss заикался, а меня отправили блоки в layout на floatах делать, рассмеявшись на совещании .... Был уволен)
За статью однозначно плюс. Лет пять назад был бы благодарен вам)
Ничего плохого во float нет, многие элементы до сих пор на них делаются. Tailwindcss - вообще редкостный отстой. Я бы за него тоже уволил. Вообще странная ситуация. На выходе вы можете отдавать в деплой что угодно. Один файл css или один сжатый. Это настраивается в таск менеджере или сборщике. Как вы верстаете сами это ваше личное дело, на выходе этого не втдно и странно в это посвящать руководство на совещании.
Без БЭМ не кошерно как то выглядит
Обнаружил здесь те мысли, над которыми одно время размышлял сам, а затем идея куда-то испарилась и внимание переключилось на другие задачи. Благодарю за приятную статью и за возможность освежить в памяти некотореы концепции!
Это точно 22? Похоже на 17 или ранее ?
Я думал будет про вебпак/ролап/модули
И ещё в рамках статьи препроцессор излишне... для всех примеров выше Достаточно somevalue:var(--)
современные дизайнеры используют авто лайут в фигме (аналог цсс флекбокса) и пишут цифры :) Я уже давно не двигаю элементы по сетке, только в каких то особых случаях, все задаю цифровыми значениями.
"Вёрстка в 2022". Код вставляется картинками, которые на экранах с высокой плотностью пикселей почти невозможно разглядеть.
У меня вся верстка на работе сводится к ant design + styled components)
Видеть отступы не через gap очень пугает. Залоголовок статьи вводит в заблуждение
Вёрстка в 2022. Часть 1: Теория