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

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

Это всё хорошо и классно до тех пока дизайнер вам не выкатил требования к элементам для каждого экрана.
Все верно, но как минимум останется преимущество в виде адаптивности для больших мониторов и телевизоров. Вместо узкой (по отношению к огромным экранам) полосы контейнера и пустого места по бокам, мы получим верстку с сохраненными пропорциями.
Сохранение пропорций да, но вы думаете что люди с экранами 30 дюймов видят всё в уменьшенном варианте, что при ваших сохранённых пропорциях это будет удобно? Для телевизоров да, но я думаю если думать так, то для этого есть в css есть указатель на тип устройства для которого будут данные стили применяться. Там есть в том числе и tv устройства.
Конечно не в уменьшеном варианте, просто появляется нереализованное пространство.
Можно сообщить тип устройства конечно, но суть способа использованного в статье как раз в уменьшении медиа запрсов и привязок к определенным размерам.
Просто как альтернативное решение, которое не обязательно должно использоваться повсеместно.
Если бы в вашем способе можно было полностью отказаться от media запросов, то да, а так это ещё одно место, где может пойти что-то не так, собственно от чего пытались уйти, «улучшили» и получили тоже самое x2.
Мест где что то может пойти не так, за время использования замечено было не так много, но за счет меньшей разбросанности сss кода вносить правки стало гораздо легче. Поэтому «получили тоже самое x2» не совсем верное замечание.
В любом деле всегда приятно иметь альтернативные пути решения задач, трудно спрогнозировать когда они смогут пригодиться.
А каким образом Вы боритесь с тем, что единица vh ведет себя по разному на Android и IOS устройствах? А если еще точнее, с «особым» пониманием от Apple того ЧТО должна давать эта единица на мобильном Сафари?
Она ведет себя по разному от браузера к браузеру.
В медиа запросах отвечающих за мобильную версию вестки, я использую только абсолютные единицы измерения и проценты.

А как же mobile first? Ведь если есть макеты мобильной версии, то проще верстать как раз с неё.

Если мы начинаем верстку с мобильной версии то можем использовать метод описанный выше реверсивно. Постепенно переходя от абсолютных к относительным единицам измерения.

Видимо, мне просто привычнее «думать» от меньшего к большему, т.е. использовать min-width вместо max-width.

Могут быть проблемы у пользователей оперы мини, поэтому если вы ориентируетесь на поддержку этого браузера то лучше использовать иной подход.
Все идет к тому, что составлять css будут не верстальщики, а программисты…

Ну, fullstack никто не отменял) К тому же давно уже существуют препроцессоры LESS, SASS, Stylus. Уже забыл, когда использовал чистый CSS последний раз.

К миксинам и функциям в sass лучше пишите сразу комментарии. Потому что вам очевидно, другим нет.

vh, vmin, vmax — неадекватные единицы, лучше их избегать.

При вёрстке, удобно быть главным над дизайнером) Обычно говорю ему — мне два макета пожалуйста — минимальный 320px*550px, и максимальный 1366px*650px. Остальное додумаю сам. Если сомневаюсь над визуальным видом какого-то компонента при какой-то определённой ширине/высоте, зову дизайнера и вместе думаем как лучше. В итоге удобно обоим. Ему не нужно рисовать 100500 макетов, мне не нужно думать как реализовать избыточную креативность), которая зачастую ломает «очередность потока блоков» в документе.
Иногда, если известно что заказчик смотрит результат на каком-то конкретном айпаде, и есть ресурсы — прошу отрисовать и вылизать макет по всем правилам конкретно под данное устройство.
чем не адекватные?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории