Пиксели больше НЕ нужны?! СУПЕР подход с REM в css

Друзья, в этом видео поведаю вам о замечательном и удобном, гибком и резиновом подходе с заданием всех css размеров в rem-ах. Данный подход имеет как свои плюсы, так и минусы. Подробнее о них можно узнать посмотрев видео целиком. Ну а использовать данный подход при верстке или нет - дело каждого, но рекомендую попробовать)
#frontend #верстка #css #rem #простоверсткаверсткапросто

[@user-by6rl6pn6o]

Ничего не понятно, но очень интересно 😁

[@user-cj3zo5py4q]

Ставь лайк, если хочешь, чтобы я сверстал макет с применением данного подхода!)

[@user-cj3zo5py4q]

а вот и час настал таки)) kzbin.info/www/bejne/nYOtaWp5jLBnqqc

[@Cookie-by5ml]

как же вы мне жизнь упростили, спасибо огромное

[@user-cj3zo5py4q]

да, адаптив становится в кайф)

[@bake5448]

@@user-cj3zo5py4q давайте видео теперь с wh,wv

[@dinkerk]

есть плагин, который переводит пиксели в rem по нажатию alt+z, и не нужно самому считать. называется - px to rem

[@user-qu9tg8fd3y]

Спасибо за уникальный материал

[@user-fh4ss8ce1n]

очень классный подход, спасибо!

[@entropulechka]

Решение огонь, очень пригодилось🔥

[@user-cj3zo5py4q]

спасибо, пользуйтесь на здоровье!) но главное помните, что это тоже решение не на все случаи жизни. хочу как-то выделить время и сверстать лендинг на канале с применением данного подхода

[@user-br5zk6fb2m]

Действительно хорошо сделано

[@ByEfimov]

Классно используешь сокращения, лайк

[@core2077]

Красавчик! Хороший лайфхак!

[@user-cj3zo5py4q]

спасибо, юзайте!)

[@njsaab9722]

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

[@mihademid5000]

Спасибо тебе добрый человек!!!)))

[@RainbowJet1]

Очень интересный подход. До этого видео единственным способом который я знал для создания резиновой вёрстки был писать все размеры не в пикселях, а в vw. Твой подход с rem по сути работает так же(поскольку в обоих способах используется ширина вьюпорта), но rem предоставляет больше гибкости, за счёт того что для текста в теге html можно писать медиазапросы для брейкпоинтов, и rem размеры любого элемента будут пересчитываться исходя из этого размера шрифта. А вообще да, заказчики иногда бесят с их приколами про масштабирование. Распишу более конкретно: - Если брать браузер, то мало того что в нём есть своё масштабирование, так ещё и окно браузера может быть не полностю развёрнуто. Особенно такое любят заказчики(и не только) с макбуками, коих походу большинство. И отсюда вытекает потребность в том, чтобы сайт отображался хорошо на любом разрешении, даже на нестандартных разрешениях(браузера, а не всего экрана). Но минус в том, что если тестировщик посмотрит сайт на разрешении, отличным от разрешения макета, то размеры элементов не будут соответствовать размерам в макте(фигме как правило). Зато сайт пропорционально скейлится. И начнётся холивар о том, какой же подход выбрать. - А если брать масштабирование системы, то тут вообще ничего не сделать

[@romatokar3516]

Такие вопросы просто нужно документировать и описывать в задачах. - Если на свое усмотрение то какие вопросы могут быть от QA? Только после демо клиенту он уже сам может сказать как бы хотелось поменять или что добавить, что либо уже делает дизайнер, а ты согласно дизайну переносишь, либо просто указывается в таске. - Если есть дизайны условно для мобилки, планшета и десктопа то то что между этими запросами либо пакуется в контейнер, либо на свое усмотрение. А если на свое усмотрение то смотри предыдущий пункт. Если тестировщик смотрит сайт не по макетным размерам, с маштабированием - максимум что он может предъявить это то, что разметка ломается.

[@DreamMaster_ru]

А можно ка каждому видео добавлять ссылку на содержание файлов index.html и style.css ?? Было бы намного нагляднее и удобнее и вообще цены бы не было.

[@arh_arh]

круто, спасибо)

[@user-cj3zo5py4q]

пользуйтесь)

[@_alexovn]

Лучший! Спасибо

[@user-cj3zo5py4q]

спасибо, мужик!)

[@biLLie_wiLLie]

попробовал и подумал, что кроме текста мне ничего разинить и не надо. На десктопе в финальном брейкпоинте я хочу, чтобы размер текста перестал меняться

[@vladrudni3059]

Я в шоке просто вы бог

[@user-cj3zo5py4q]

спасибо, главное чтобы приносило свои плоды)

[@vladrudni3059]

@@user-cj3zo5py4q Сейчас проблема появилась, когда в браузере сжимаешь до телефона экран то все хорошо уменшяеться, а когда на реальном телефоне открываешь, то оно просто маштабируеться при версии как на пк, все нужные мета теги стоят, что делать я не знаю

[@ArtyomStouch]

@@vladrudni3059 спробуйте dvw

[@_denysd9683]

нельзя увеличивать масштабом, капец, тогда сразу надо делать на сайте кнопку "для пользователей с плохим зрением" и все подстраивать для них...

[@user-cj3zo5py4q]

Как и обещал пример верстки макета с применением данного подхода - kzbin.info/www/bejne/nYOtaWp5jLBnqqc

[@BALERA304]

пасиба

[@user-fb7vk5ch9p]

При данном подходе и контейнер также автоматически уменьшается + не будут работать flex-wrap и grid, т.к. элементы пропорционально уменьшаются, правильно? Получается, что вёрстка абсолютно резиновая, но блоки не будут перемещаться ?

[@user-cj3zo5py4q]

ага, я как правило при таком подходе сетки строю на гридах и просто когда мне нужно перестраиваю на необходимое количество колонок (причем лучше mobile-first: на мобилках одна колонка - то есть grid-template-columns нам задавать не нужно, на планшетах например 2 колонки, то есть пишу на min-width: 768px grid-template-columns: repeat(2, 1fr), все что больше например 4 колонки - на min-width: 1025px пишу grid-template-columns: repeat(4, 1fr)

[@user-fb7vk5ch9p]

@@user-cj3zo5py4q Интересный подход, насколько я понял весь контент по брейк поинтам перестраивается. я делаю иначе, у меня есть миксин в который я подставляю значения например ( padding-top: adaptiv(120, 185, 600, 320) ) и на выходе получаю это ( padding-top: calc( 7.5rem + (185 - 120) * ((100vw - 320px) / (600 - 320))); ) И использую flex-wrap или grid-template-columns: repeat(auto-fit, minmax()), по итогу проект абсолютно адаптивен и подстраивается под любое разрешение экрана и красиво выглядит на каждом экране при любой ширине хоть - 1280, хоть - 1111, хоть - 325. Но намного больше времени тратится на мобильную разработку + медиа запросы почти к каждому значению которое должно уменьшаться или увеличиваться . Вот не могу понять какой подход лучше? В моём подходе я могу контролировать каждый пиксель и быть уверенным за любое разрешение экрана, с другой стороны слишком много calc в коде..

[@user-cj3zo5py4q]

@@user-fb7vk5ch9p и тот и другой подход имеет право на жизнь. при моем подходе настоящая магия происходит с зумом в браузере, что тоже не всегда гуд. Я бы сказал он хорошо подходит для каких-то лендингов. Кстати auto-fit в связке minmax() классная штука тоже, хорошая практика

[@andriy-kos]

@@user-fb7vk5ch9p как думаете, насколько сильно calc будет грузить сайт?)) я вот не думаю, что ето прям сильно повлияет на скорость загрузки

[@WERWOLION]

Граница указывается в Макс(1px, 1rem) мин(). Калькулятор использовать нельзя ,он грузит сайт. Вычисления нужно делать через sass

[@user-cj3zo5py4q]

в идеале может быть, согласен

[@mifaress]

Ты угараешь? Насколько сложно браузеру сделать такое вычисление? Это же банальные умножения / деления. Даже миллисекунды не займет

[@WERWOLION]

@@mifaress офигенно сложно потому что ему нужно преобразовать строку в число провести операцию и потом обратно. Т.е. ты тупо пишешь лишний js скрипт

[@WERWOLION]

@@mifaress гуглим to me it says that version with calc has about 1500 more operations per second than the margin auto (usually around 40 vs 41.5 thousands). для меня это говорит о том, что версия с calc имеет примерно на 1500 операций больше в секунду, чем margin auto (обычно около 40 против 41,5 тысяч).

[@dinkerk]

попробовал сверстать макет по гайду, что-то не получается с блоками при наложении друг на друга, они начинают разъезжаться при медиазапросах, если в них указана ширина не такая, как в функции.

[@user-cj3zo5py4q]

может конфликтуют медиа-запросы (например используете min-width: 768px и max-width: 768px вместо max-width: 767px) ?

[@dinkerk]

@@user-cj3zo5py4q проблема оказалась в ограничении размеров контейнера. Картинка с позицией relative масштабировалась в рамках контейнера, а картинка с позицией absolute масштабировалась относительно body

[@reutoffreutoff4549]

А можно умножить не на 10, а на сто, чтобы не делить потом опять на 10?

[@user-cj3zo5py4q]

а попробуйте!) по идее логика верная с одной стороны, но просто тогда у нас что пиксели, что ремы будут одинаковым числом, и различать не очень удобно

[@reutoffreutoff4549]

@@user-cj3zo5py4q эта самая функция идентична *font-size: 62.5%*, но я подозреваю, что по производительности там будет все то же самое

[@deanwichester6412]

А почему бы просто не написать html { font-size:10px; } И так же все можно будет делить на 10

[@deanwichester6412]

Понял

[@iloginu]

Чуть не уснул.

[@IgorBobyrev]

У вас в корне неверный подход к адаптивности. Вы думаете, что при изменении размеров дизайн не должен меняться, а это неверно ))) Кто вам это сказал? Как может не меняться дизайн, если вы смотрите с портретного смартфона и с десктопа? Принцип адаптивности в том, чтобы пользователю было комфортно пользоваться сайтом при любом разрешении. А главное в удобстве - это шрифт (потому что сайт в первую очередь рассказывает а во вторую только - показывает). Шрифт должен быть комфортный для чтения. А представьте, какой будет шрифт у вас на ноутах и планшетах? Малюсенький! Зато "все смотрится одинаково" )))

[@user-fr4fi5fb4v]

хахаха, интересно почему все переходят на данный метод? просто изначально делаешь дизайн на full hd с увеличенным размером текста (20-24 пикселя) вместо 16, что уже не удобно. А на телефонах делаешь перестроение

[@beebee-sn9sb]

а если просто html{ font-size:62.5%};?? это получается 10, удобно считать rem

[@user-cj3zo5py4q]

да, такой подход тоже распространенный и верный для обычных rem-ов, но тут несколько иной подход, а именно в связке с vw