Занимательная вёрстка с единицами измерения области просмотра

[@bro-dev]

Для меня как пользователя это неприятное и неожиданное поведение когда зум в браузере не работает. Имхо нужно абсолютно все размеры давать в пикселях, а пользователь уже сам если хочет крупнее то увеличит как ему удобно. Контейнеры само собой резиново и адаптивно.

[@dom1n1k]

В статье не хватает одного «нюанса», с которого нужно начинать любой разговор о единицах вьюпорта и выделять красным цветом — единицы vw/vh отсчитываются от размеров вьюпорта включая ширину полос прокрутки.
Это обстоятельство для многих (как и для меня в своё время) становится большим сюрпризом и рушит много логичных идей использования таких многообещающих единиц. Нужно понимать, что 100vw != 100%. На самом деле в большинстве случаев 100vw > 100% и причем соотношение между ними не постоянно, а зависит от ОС и её настроек!

Так написано в спецификации. Конечно, авторы спецификации тоже не дураки, и у них были на то свои причины. Но рядовому верстальщику от этого не легче — эта неприятная особенность изрядно девальвирует ценность единиц вьюпорта.

Ну и идея завязывать на vw интерлиньяж — мягко говоря, сомнительна.

[@nullc0de]

Они зато просчитываются быстрее и шаблон быстрее рендерится чем со 100%, они нельзя называются единицами видимой области. Процентные единицы требует просчет родителя контейнера, что на сложных шаблонах с большим dom деревом замедляет отрисовку, по это же причине верстка флоатами с процентами медленее flex. На крупных ресурсах % могут замедлить довольно значительно отрисовку, особенно если это SPA и при взаоимодействии пользователя с интерфейсом могут возникнуть тормоза.
Мой плагин например все необходимые расчеты с calc делает автоматически, и дизайн адаптивный, засчет использования языка макросов

[@gprokofyeva]

Спасибо. Поправлено.

[@jankovsky]

Старо как мир. И не хочу Вас огорчать, но давно известно, что ни vw, ни vh, ни flexbox и все остальное перечисленное в статье в будущую спецификацию не войдет.

[@pepelsbey]

Что это вообще значит в будущую спецификацию не войдет? Они уже в спецификациях и широко поддерживаются браузерами.

[@gprokofyeva]

Можно ссылку на источник, откуда взята такая инфа?
По ссылке рабочий черновик будущей спецификации https://drafts.csswg.org/css-values-3/#viewport-relative-lengths
Пока содержит viewport-единицы.

[@SelenIT3]

Возможно, в n-ном пересказе так причудливо исказилась информация, что CSS как язык ушел от понятия версий и не будет «CSS4», «CSS5» и т.д. (хотя отдельные модули, составляющие один большой язык CSS, бывают и 4-го, а с недавних пор и 5-го уровня). А что касается модуля значений и единиц, то он не просто есть, но уже дошел до статуса кандидата в рекомендации (т.е. полностью готов теоретически и реализован независимо и единообразно как минимум в двух браузерах — в переводе с W3C-шного на человеческий:) и входит в официальное определение CSS 2017-го года.

[@pepelsbey]

Не бойтесь слова вьюпорт. Представьте, что вы кричите коллеге в другом конце комнаты:

Какой размер шрифта ставить: полторы единицы изменения области просмотра или больше?

Нет конечно, скажете полтора вьюпорта и всё. Так зачем в статье усложнять?

[@gprokofyeva]

Все верно, в устной речи, да и в любом обсуждении, я не стала бы использовать такие длинные термины.
Но в переводе все-таки предпочитаю использовать именно переводы терминов, как «поля», а не «маргины», «отступы», а не «паддинги» и т.д. Мне трудно представить книгу, в которой бы было написано что-то вроде «Что такое единицы вьюпорта?»

[@lipton_ice_tea]

Статья понравилась:) Заинтересовал последний пример с индикатором прокрутки, но он оказался не рабочим на практике, т.к. он перекрывается контентом. Т.е. любая картинка, background в блоке и т.д. перекроет индикатор:(