Какие могут быть подводные камни при верстке в REM c шрифтом HTML в VW?

Question

[Вячеслав Яшников]

Подскажите какие могут быть подводные камни при верстке адаптивного сайта с применением величины REM вместо px.

Например:
Я задаю размер шрифта html

html {font-size: 0.6944vw} /* 1rem = 10px на ширине экрана 1440px */

Далее всем шрифтам и элементам я указываю размеры в rem исходя из формулы 1rem = 10px соответсвенно если ширина блока 200px я ему ставлю 20rem.

Это удобно так как можно скейлить пропорционально интерфейс от большого экрана к малому, но я заметил, что например сайты банков сверстаны в px, это сделано, чтобы размер шрифта был всегда один на любом разрешении экрана, но зачем?

Вот пример сайта сверстанного мной по технологии, что я пишу выше:
https://bittraffic.webflow.io/

Интересуют минусы этого подхода и проблемы с которыми можно каким либо образом столкнуться

Comments

[Lynn «Кофеман»]

Подслеповатые пользователи (вроде меня) будут вас нелюбить потому что невозможно увеличить размер шрифта стандартным масштабированием страницы.

Answer 1

[Ivan Bogachev]

Классическая реализация этого подхода предполагает, что есть CSS шлюз, ограничивающий минимальный/максимальный размер шрифта для минимального/максимального размера экрана, и логика дизайна явно завязана на размер шрифта. Как в мире, где люди печатают разные штуки на бумаге. Плюс альтернативные единицы измерения - vw, vmax, проценты - если нужно. Это помогает сохранить в верстке логику дизайна в явном виде. Используя искусственную логику 1rem = 10px, и rem не в значении "базовый размер шрифта", а просто как костыль для адаптивности, вы упрощаете изначальные подсчеты, но в верстке получается гора рандомных дробных значений, которые не пойми что обозначают. Тут нужно либо подгонять все под 10px сетку, что не всегда уместно, либо по мере усложнения интерфейса это все превратится в такую кашу, что врагу не пожелаешь. Собственно это возвращает нас к изначальной проблеме верстки в пикселях. Куча магических значений и никакой логики в коде. Это главный недостаток вашего способа приготовления rem.

Вторая проблема, более общая - округление значений. При изменении размера экрана будут появляться дробные размеры всего. Они будут округляться до целого количества пикселей. При этом у нас есть много ситуаций, когда разные браузеры будут округлять по-разному, или просто не туда, куда мы ожидаем. Появляются разные артефакты. В модных сайтах, где в дизайне много негативного пространства, мы можем этого не заметить, но в тесных интерфейсах кроваво-энтерпрайзных приложений это быстро станет проблемой. Там пиксели = надежность и предсказуемость.

Comments

[Вячеслав Яшников]

это как пример, можно использовать и не дробные значение привязав 1rem = 1px на разрешении 1440, тогда 200px = 200rem, но вот с округлением да, я согласен, я часто наблюдал когда ты ставишь например размер элемента в 1px в rem то на разных браузерах он округляется либо до .5px либо до 1 и соответственно выглядит не пропорционально, но это наблюдается только в старых браузерах. Актуальные версии браузеров работают адекватно с округлением до десятых пикселя

[Ivan Bogachev]

это как пример, можно использовать и не дробные значение привязав 1rem = 1px

Это не поможет получить логику дизайна в коде. Логика - в явных взаимосвязях между сущностями в дизайне, а не в пикселях. Если элемент по логике должен быть в два раза больше базового размера шрифта, то это должно быть явное 2rem в коде, а не какие-нибудь 266rem, потому что пойди пойми почему. В этом смысл.

Актуальные версии браузеров работают адекватно с округлением до десятых пикселя

Если бы. Добавьте в свою верстку больше трансформаций, анимаций, фильтров, SVG-картинок, и "актуальные" версии браузеров заиграют новыми красками. Да даже на вашем сайте в актуальном chrome я вижу, что декоративные линии, которые приходятся строго в углы элементов, местами съехали на 1-2px вверх/вниз относительно не менее актуального firefox.