Комментарии 27
Вот вроде бы и статья написана с неплохим знанием матчасти, но только вот обсуждаемое положение дел несколько разнится с жестокой реальностью.
Можно много рассуждать об "отзывчивом дизайне", уходе от "мышления контрольными точками", но всё это моментально разбивается о тот факт, что большинство современных дизайн-макетов подразумевают использование растровой графики в качестве оформления.
И на этом все разговоры про отзывчивость заканчиваются. Потому что большинство дизайнеров, я так понял, считают что в мире существуют устройства просмотра с шириной только в диапазоне от 360 (кстати, частенько даже не 320!) до 1920px. И что вся использованная дизайнером растровая графика, каким-то волшебным образом, без потери качества, сама собой экстраполируется под девайсы 8К.
И когда такой вопрос ставится перед дизайнером ребром - вопрос о необходимости "полного адаптива" как-то вдруг резко становится неактуальным... Ну иногда правда приходится напомнить старую кавказскую притчу о шитье семи шапок из одного куска шкуры.
Современные css-фичи это, конечно, очень хорошо. Но тут у нас фундаментальное ограничение в виде самой сути растровой графики. Вот какие проблемы нужно решать...
веб-среда отзывчива по умолчанию, пока мы не начинаем применять к нашим макетам креативность
Вот это надо высечь на камне!
Если честно, статья очень слабая, автор практически не знает матчасть. container-fluid в бутстрапе с первой версии, только им мало кто пользуется. Почему? Все тупые? Нет, в европейских языках есть ограничение на длину строки, порядка 60-80 символов. Если строка длиннее, глаз срывается, и читать такую колбасу становится неудобно. При стандартном размере шрифта 16px (это рекомендация ВОЗ для слабовидящих) мы и получаем где-то 1100-1200 пикселей. Именно поэтому стандартный бутстраповский контейнер имеет полезную ширину 1140 пикселей.
Ну и главное. Все эти клампы, минимаксы и размеры шрифтов, заданный в единицах vw, это всё годится только для строчки в резюме, "смотрите как я умею". На телефон должен приезжать стиль, рассчитанный на ширину от 360 до 428 пикселей. Это не такая большая разница на самом деле, здесь совершенно не нужны никакие особые вычисления лэйаута и различные правила для десктопа на несколько мб.
Вот тут, позвольте добавить один нюанс - так же стандартная ширина 1140 очень бедненько смотрится на мониторах с большим разрешением, и не "кадратным" соотношением сторон. Отдельная боль - широкоформатные мониторы с соотношением сторон 21:9 - и когда вот по середине такая жиденькая колонка, а вокруг одно пустое место
А что, если у меня монитор 32", то текст в нем должен быть от края до края? Те самые 1000 пикселей(+/-) и есть комфортная длина строки для чтения. Пустое пространство, которое образуется вокруг, должно заполняться или другими колонками или, если сайт построен так, что там нет информации для других колонок, просто не нужно открывать браузер на весь экран.
Ну уж точно не нужно растягивать текстовое содержимое на все 2000-3000 пикселей ширины монитора.
Не текст от края до края, а хотелось бы заполнение другими элементами коли место есть. А не после куча блоков, или еще узкий сайдбар с кучей инфы. То что контент должен быть ограничен, вопросов нет. Но и нормальная утилизация пространства тоже должна быть, имхо
... и вот здесь таки должен пострадать хотя бы один дизайнер, а не освоивший 5% бутстрапа формошлёп. Когда у вас контент - карточки, товаров там или статей, ещё понятно что делать. А вот с текстом хороших решений в общем случае нет.
Мысль я вашу понимаю и в целом поддерживаю, но, как человек, прочувствовавший на собственной шкуре масштаб работы, которую нужно проделать, чтобы красиво презентовать руководству компании, например страницу каталога более-менее серьёзного е-коммерса с насыщенной параметрами товарной группой, не говоря уже о маркетплейсах типа условных Озонов/Амазонов, могу вам сказать, что текст — меньшая из проблем, учитывая то, что он достаточно «текучий». Я, естественно, про «резиновый от уха до уха» дизайн с перестройкой всего лейаута и его вложенных частей. Тут нужно быть верстаком, который занимается вёрсткой для души и во славу бога адаптивного дизайна, а не за ради себе поесть и жене сапоги купить.
Ну хз, не говорю что это прям просто, но таблицы гриды творят чудеса. Тут главное чтобы дизайнер понимал в вёрстку таблицами гридами и мог нарисовать, чего он хочет.
Дык и на флексах-то можно ого-го. Вон, Penpot уже научили flex-wrap'у. В Фигму тоже, думаю, завезут. Вообще, конечно, плохо, что именно толковым дизайнерам, которые всей душой за облегчение жизни фронтам, нужно, как вы выразились «пострадать». На своём веку я разных лентяев на фронтенде повидал — обколются фреймворками до зависимостей, а потом им MUI не кастомайзи (и это под задачу-то), а то бедненькие боятся лишний оверрайд написать... А вот балбесов-дизайнеров, которые грязь в макетах развозят с неймингом типа "Frame 407", например, нужно кошмарить, да.
Не, на флексах как раз плохо получается, если мы говорим именно о десктопах против больших десктопов. Т.е. где надо не просто в кишку вытянуться, а именно разное число колонок с контентом. Вот гриды огонь, вообще думать не надо, если дизайнер нарисовал табличку под каждую ширину. Обозвал ячейки и просто перечислил где какая для каждого разрешения. Ну, людям, которые до сих пор на ХР, конечно печаль.
Ну, если мыслить категориями «если дизайнер нарисовал табличку под каждую ширину», то мы вернёмся опять, к тому, что фронты будут синить на дизайнеров при разборе полётов. И тут победят софт-иху-мать-скиллы и прочие уровни интеграции с заказчиком. Как говорил мой коллега, бывший прапорщик: «Нужно, ***ть, сначала определиться с понятиями». Короче, это куча внутренних разборок. Я про то, что дизайнер хорошего уровня может ткнуть фронта носом в гайд, где написаны относительные величины для брейкпоинтов. Причём написаны с предельными значениями в абсолютных величинах для определённых «молекул». И будет прав. Но фронты чаще всего начинают качать права, мол, обижают программистов... За такое в нормальном рабочем коллективе, например, строителей — просто дадут **зды. И поделом, в принципе. Ну, как-то так.
Для решения, точнее недопущения, этой проблемы, должен быть проджект менеджер, который сразу распедалит, что дизайнер отвечает за то и за это, а фронт - за третье и четвёртое. И ежели у них непонятки, то они садятся рядышком у монитора, ресайзят окно браузера и решают вопрос до устраивающего всех результата.
Конечно, если проджект — про красивые отчёты и лизинг вышестоящего руководства, тогда ой.
Целую ваши мысли :) Видимо я постоянно вписывался в какой-то колхоз, где материализовывалось именно последнее ваше предложение. Что, собственно, подтверждает расхожее утверждение «Быт определяет сознание».
P.S.: может с «постоянно» я переборщил, и, дабы не обидеть нормальных пацанов, скажу «в большинстве случаев».
А какими другими? вот возьмите хабр, даже на фуллхд - пустые поля по бокам
и так делают 99% сайтов
ну и делать еще 1,2,3,4 сайдбара по разные разрешения, да как-то туда полезную инфу выводить - это надо придумывать. Ну и опять таки, получится, что люди с более узким окном браузера будут получать какую-то другую информацию
Почему другую? Всю туже, только по другому расположенную. Возможно, не все сайты могут в "полный адаптив", но большинство сможет, там где есть что выводить
в смысле по-другому? типа как в газетах - 10 узких колонок? вместо одной области под текст?
Вот пример у Ведомостей
https://www.evkova.org/evkovaupload/job/80366/4.jpg
2 сайдбара, а центральная область поделена на 3 колонки
То есть в случае хабра, левого сайдбара не будет, будет4 колонки под тектстовую область и имеющийся правый сайдбар
Ближе наверно вот такая газета
https://kartinkin.net/uploads/posts/2021-01/1611330095_51-p-fon-sovetskie-gazeti-58.jpg
Знаю один сайт, который для главной раскидывал блоки в ширину
https://old.elementy.ru/
но это ток для главной, для контентных у них уже там все "хреновато"
При стандартном размере шрифта 16px (это рекомендация ВОЗ для слабовидящих) мы и получаем где-то 1100-1200 пикселей.
А может быть ВОЗ, прежде чем давать рекомендации, перестанет набирать людей с улицы? 16px - это сколько попугаев? Вы же понимаете, что пиксель - это не физическая единица измерения? Что рассматривать её в отрыве от dpi нет смысла? И даже в связке с dpi - у нас всё ещё недостаточно вводных для выводов о "комфортном кегле". Нужно ещё расстояние просмотра, ну или хотя бы опосредованно, через физические размеры дисплея.
Да, все кругом идиоты, вы один тут в белом плаще:)
На самом деле там довольно длинные лонгриды от ВОЗ, W3C и их адаптация в наших посконных ГОСТах. И покрывают они целую кучу параметров, от размеров мониторов и расстояния от глаз по горизонтали и вертикали и до яркости и контрастности. Ну вот для типичной офисной техники с разрешением 72-96 dpi рекомендуется размер шрифта не менее 16px. И именно это требование веб-мастерам выполнить проще всего, потому как на расстояние до монитора они влиять не могут, а высококонтрастная цветовая схема как правило не дружит с брендбуком заказчика, да и здоровому человеку неудобна.
Если вам действительно интересно, можете начать с ознакомления с документами WCAG 2.0 и ГОСТ Р 52.872−2012
Добрый вечер, сейчас как раз изучаю CSS, и смотря по комментариям вижу что не все согласны что это хороший способ делать отзывчивый дизайн, поэтому очень прошу написать какие способы наиболее актуальны в работе; Спаибо заранее.
На старте просишь дизайнера отрисовать только в двух разрешениях - 320px и 1920px.
Всё что между - делаешь на своё усмотрение (!). Без глобальных брейкпоинтов, а индивидуально по каждому компоненту.
Т.е. делаешь, например, хедер - смотришь в отрыве от всего остального контекста как он себя ведёт на разных разрешениях. Нужно чтоб не ломался и небыл кривым. Этого достаточно. Сам принимаешь решение когда именно спрятать\показать гамбургер меню и т.д.. Условно, ты должен мочь копипастнуть компонент в другой проект без проблем. И такой подход по каждому компоненту (Container Queries сейчас по идее очень облегчают жизнь в этом).
Таким образом ты секономишь кучу времени, энергии и нервов и у себя и у дизайнера.
Сдаёшь работу. Вдруг если где-то на каком-то китайском планшете, на каком-то портретном режиме кому-то что-то не нравится.. просто фиксишь конкретно только этот момент и в рамках новой задачи, и то потом когда-то, когда приоритет этой задаче дадут.
И не программируешь в стилях! Никаких много этажных миксинов. Везде используй px (!) по максимуму, а еm - только в местах где явно понятно, что расстояние зависит от соседнего текста и это очевидно, и прописывается в одном блоке правил рядом (паддинги у кнопок, иконок, марджины между параграфами)
Инедайбог использовать rem - как говорят "лучшие практики" - чтобы удовлетворить юзеров, которые вдруг могут менять размер шрифта в браузере. Не знаю ни однорго, кто знает где эта настройка находится. Все используют или pinch-zoom, или ctrl+, или ctrl+mause-whell-up
сейчас вы просмотрели советы из разряда "как не надо делать"))
самый простой способ "прокинуть" адаптив между 320 и 1920 - это как раз использовать rem и привязывать его к vw. грубо говоря:
html{
font-size: calc(100vw / 1920);
}как видите, дефолтный размер шрифта в браузере элементарно меняется при помощи css))
В конечном счете все зависит от дизайнера, с которым приходится работать. Любой программист хочет писать меньше кода с наилучшим результатом, но если твой дизайнер весь такой «вдохновленный», и от разрешения к разрешению его блоки летают из одного края макета в другой и деформируются весьма непредсказуемым образом - ничего ты с этим не сделаешь. Не всегда получается переубедить руководство в своей праведной точке зрения, приходится подстраиваться под требования работодателя.
Очень полезная как по мне статья. Поскольку затрагивает самые последние достижения в вёрстке. По мне так слишком большой выбор методов вёрстки, надо бы стандартизировать всё, оставить методологию лучшую и всё лишнее убрать. То есть например, если как говорит автор можно делать без медиаквери - то их нужно depricated официально сделать, как и другие отжившие штуки.
Руководство по реализации отзывчивого дизайна в 2023 году