Очень интересный подход. До этого видео единственным способом который я знал для создания резиновой вёрстки был писать все размеры не в пикселях, а в vw. Твой подход с rem по сути работает так же(поскольку в обоих способах используется ширина вьюпорта), но rem предоставляет больше гибкости, за счёт того что для текста в теге html можно писать медиазапросы для брейкпоинтов, и rem размеры любого элемента будут пересчитываться исходя из этого размера шрифта. А вообще да, заказчики иногда бесят с их приколами про масштабирование. Распишу более конкретно: - Если брать браузер, то мало того что в нём есть своё масштабирование, так ещё и окно браузера может быть не полностю развёрнуто. Особенно такое любят заказчики(и не только) с макбуками, коих походу большинство. И отсюда вытекает потребность в том, чтобы сайт отображался хорошо на любом разрешении, даже на нестандартных разрешениях(браузера, а не всего экрана). Но минус в том, что если тестировщик посмотрит сайт на разрешении, отличным от разрешения макета, то размеры элементов не будут соответствовать размерам в макте(фигме как правило). Зато сайт пропорционально скейлится. И начнётся холивар о том, какой же подход выбрать. - А если брать масштабирование системы, то тут вообще ничего не сделать
Такие вопросы просто нужно документировать и описывать в задачах. - Если на свое усмотрение то какие вопросы могут быть от QA? Только после демо клиенту он уже сам может сказать как бы хотелось поменять или что добавить, что либо уже делает дизайнер, а ты согласно дизайну переносишь, либо просто указывается в таске. - Если есть дизайны условно для мобилки, планшета и десктопа то то что между этими запросами либо пакуется в контейнер, либо на свое усмотрение. А если на свое усмотрение то смотри предыдущий пункт. Если тестировщик смотрит сайт не по макетным размерам, с маштабированием - максимум что он может предъявить это то, что разметка ломается.
блин, ну вроде пока круто работает, если прям все зайдет и не будет крэшится, я просто буду в шоке, это реально максимально полезный лайф хак, вы даже не представляете на сколько я благодарен)))) это просто потрясение)))))невероятниший вам респект, очень надеюсь, что сработает эта темка)))
спасибо, пользуйтесь на здоровье!) но главное помните, что это тоже решение не на все случаи жизни. хочу как-то выделить время и сверстать лендинг на канале с применением данного подхода
@@Простоверстка-версткапросто Сейчас проблема появилась, когда в браузере сжимаешь до телефона экран то все хорошо уменшяеться, а когда на реальном телефоне открываешь, то оно просто маштабируеться при версии как на пк, все нужные мета теги стоят, что делать я не знаю
попробовал и подумал, что кроме текста мне ничего разинить и не надо. На десктопе в финальном брейкпоинте я хочу, чтобы размер текста перестал меняться
При данном подходе и контейнер также автоматически уменьшается + не будут работать flex-wrap и grid, т.к. элементы пропорционально уменьшаются, правильно? Получается, что вёрстка абсолютно резиновая, но блоки не будут перемещаться ?
ага, я как правило при таком подходе сетки строю на гридах и просто когда мне нужно перестраиваю на необходимое количество колонок (причем лучше 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)
@@Простоверстка-версткапросто Интересный подход, насколько я понял весь контент по брейк поинтам перестраивается. я делаю иначе, у меня есть миксин в который я подставляю значения например ( 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 в коде..
@@ПавелКоробко-г4л и тот и другой подход имеет право на жизнь. при моем подходе настоящая магия происходит с зумом в браузере, что тоже не всегда гуд. Я бы сказал он хорошо подходит для каких-то лендингов. Кстати auto-fit в связке minmax() классная штука тоже, хорошая практика
@@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 тысяч).
попробовал сверстать макет по гайду, что-то не получается с блоками при наложении друг на друга, они начинают разъезжаться при медиазапросах, если в них указана ширина не такая, как в функции.
@@Простоверстка-версткапросто проблема оказалась в ограничении размеров контейнера. Картинка с позицией relative масштабировалась в рамках контейнера, а картинка с позицией absolute масштабировалась относительно body
У вас в корне неверный подход к адаптивности. Вы думаете, что при изменении размеров дизайн не должен меняться, а это неверно ))) Кто вам это сказал? Как может не меняться дизайн, если вы смотрите с портретного смартфона и с десктопа? Принцип адаптивности в том, чтобы пользователю было комфортно пользоваться сайтом при любом разрешении. А главное в удобстве - это шрифт (потому что сайт в первую очередь рассказывает а во вторую только - показывает). Шрифт должен быть комфортный для чтения. А представьте, какой будет шрифт у вас на ноутах и планшетах? Малюсенький! Зато "все смотрится одинаково" )))
хахаха, интересно почему все переходят на данный метод? просто изначально делаешь дизайн на full hd с увеличенным размером текста (20-24 пикселя) вместо 16, что уже не удобно. А на телефонах делаешь перестроение
Ставь лайк, если хочешь, чтобы я сверстал макет с применением данного подхода!)
а вот и час настал таки)) ruclips.net/video/gRJ87CWK4tE/видео.html
Очень интересный подход. До этого видео единственным способом который я знал для создания резиновой вёрстки был писать все размеры не в пикселях, а в vw. Твой подход с rem по сути работает так же(поскольку в обоих способах используется ширина вьюпорта), но rem предоставляет больше гибкости, за счёт того что для текста в теге html можно писать медиазапросы для брейкпоинтов, и rem размеры любого элемента будут пересчитываться исходя из этого размера шрифта.
А вообще да, заказчики иногда бесят с их приколами про масштабирование. Распишу более конкретно:
- Если брать браузер, то мало того что в нём есть своё масштабирование, так ещё и окно браузера может быть не полностю развёрнуто. Особенно такое любят заказчики(и не только) с макбуками, коих походу большинство. И отсюда вытекает потребность в том, чтобы сайт отображался хорошо на любом разрешении, даже на нестандартных разрешениях(браузера, а не всего экрана). Но минус в том, что если тестировщик посмотрит сайт на разрешении, отличным от разрешения макета, то размеры элементов не будут соответствовать размерам в макте(фигме как правило). Зато сайт пропорционально скейлится. И начнётся холивар о том, какой же подход выбрать.
- А если брать масштабирование системы, то тут вообще ничего не сделать
Такие вопросы просто нужно документировать и описывать в задачах.
- Если на свое усмотрение то какие вопросы могут быть от QA? Только после демо клиенту он уже сам может сказать как бы хотелось поменять или что добавить, что либо уже делает дизайнер, а ты согласно дизайну переносишь, либо просто указывается в таске.
- Если есть дизайны условно для мобилки, планшета и десктопа то то что между этими запросами либо пакуется в контейнер, либо на свое усмотрение. А если на свое усмотрение то смотри предыдущий пункт.
Если тестировщик смотрит сайт не по макетным размерам, с маштабированием - максимум что он может предъявить это то, что разметка ломается.
как же вы мне жизнь упростили, спасибо огромное
да, адаптив становится в кайф)
@@Простоверстка-версткапросто давайте видео теперь с wh,wv
есть плагин, который переводит пиксели в rem по нажатию alt+z, и не нужно самому считать. называется - px to rem
спасибо! именно то, что искал)
блин, ну вроде пока круто работает, если прям все зайдет и не будет крэшится, я просто буду в шоке, это реально максимально полезный лайф хак, вы даже не представляете на сколько я благодарен)))) это просто потрясение)))))невероятниший вам респект, очень надеюсь, что сработает эта темка)))
Ничего не понятно, но очень интересно 😁
Решение огонь, очень пригодилось🔥
спасибо, пользуйтесь на здоровье!) но главное помните, что это тоже решение не на все случаи жизни. хочу как-то выделить время и сверстать лендинг на канале с применением данного подхода
Классно используешь сокращения, лайк
очень классный подход, спасибо!
Спасибо за уникальный материал
А можно ка каждому видео добавлять ссылку на содержание файлов index.html и style.css ?? Было бы намного нагляднее и удобнее и вообще цены бы не было.
Не проще использовать clamp(20px, 17vw, 300px) ?
Я в шоке просто вы бог
спасибо, главное чтобы приносило свои плоды)
@@Простоверстка-версткапросто Сейчас проблема появилась, когда в браузере сжимаешь до телефона экран то все хорошо уменшяеться, а когда на реальном телефоне открываешь, то оно просто маштабируеться при версии как на пк, все нужные мета теги стоят, что делать я не знаю
@@vladrudni3059 спробуйте dvw
Спасибо тебе добрый человек!!!)))
Действительно хорошо сделано
попробовал и подумал, что кроме текста мне ничего разинить и не надо. На десктопе в финальном брейкпоинте я хочу, чтобы размер текста перестал меняться
а как масштабировать шрифты таким образом
Красавчик! Хороший лайфхак!
спасибо, юзайте!)
Лучший! Спасибо
спасибо, мужик!)
нельзя увеличивать масштабом, капец, тогда сразу надо делать на сайте кнопку "для пользователей с плохим зрением" и все подстраивать для них...
А можно умножить не на 10, а на сто, чтобы не делить потом опять на 10?
а попробуйте!) по идее логика верная с одной стороны, но просто тогда у нас что пиксели, что ремы будут одинаковым числом, и различать не очень удобно
@@Простоверстка-версткапросто эта самая функция идентична *font-size: 62.5%*, но я подозреваю, что по производительности там будет все то же самое
Как и обещал пример верстки макета с применением данного подхода - ruclips.net/video/gRJ87CWK4tE/видео.html
При данном подходе и контейнер также автоматически уменьшается + не будут работать flex-wrap и grid, т.к. элементы пропорционально уменьшаются, правильно? Получается, что вёрстка абсолютно резиновая, но блоки не будут перемещаться ?
ага, я как правило при таком подходе сетки строю на гридах и просто когда мне нужно перестраиваю на необходимое количество колонок (причем лучше 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)
@@Простоверстка-версткапросто Интересный подход, насколько я понял весь контент по брейк поинтам перестраивается. я делаю иначе, у меня есть миксин в который я подставляю значения например ( 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 в коде..
@@ПавелКоробко-г4л и тот и другой подход имеет право на жизнь. при моем подходе настоящая магия происходит с зумом в браузере, что тоже не всегда гуд. Я бы сказал он хорошо подходит для каких-то лендингов. Кстати auto-fit в связке minmax() классная штука тоже, хорошая практика
@@ПавелКоробко-г4л как думаете, насколько сильно calc будет грузить сайт?)) я вот не думаю, что ето прям сильно повлияет на скорость загрузки
круто, спасибо)
пользуйтесь)
Граница указывается в Макс(1px, 1rem) мин().
Калькулятор использовать нельзя ,он грузит сайт. Вычисления нужно делать через sass
в идеале может быть, согласен
Ты угараешь? Насколько сложно браузеру сделать такое вычисление? Это же банальные умножения / деления. Даже миллисекунды не займет
@@mifaress офигенно сложно потому что ему нужно преобразовать строку в число провести операцию и потом обратно.
Т.е. ты тупо пишешь лишний js скрипт
@@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 тысяч).
попробовал сверстать макет по гайду, что-то не получается с блоками при наложении друг на друга, они начинают разъезжаться при медиазапросах, если в них указана ширина не такая, как в функции.
может конфликтуют медиа-запросы (например используете min-width: 768px и max-width: 768px вместо max-width: 767px) ?
@@Простоверстка-версткапросто проблема оказалась в ограничении размеров контейнера. Картинка с позицией relative масштабировалась в рамках контейнера, а картинка с позицией absolute масштабировалась относительно body
А почему бы просто не написать html {
font-size:10px;
}
И так же все можно будет делить на 10
Понял
пасиба
Чуть не уснул.
У вас в корне неверный подход к адаптивности. Вы думаете, что при изменении размеров дизайн не должен меняться, а это неверно ))) Кто вам это сказал? Как может не меняться дизайн, если вы смотрите с портретного смартфона и с десктопа? Принцип адаптивности в том, чтобы пользователю было комфортно пользоваться сайтом при любом разрешении. А главное в удобстве - это шрифт (потому что сайт в первую очередь рассказывает а во вторую только - показывает). Шрифт должен быть комфортный для чтения. А представьте, какой будет шрифт у вас на ноутах и планшетах? Малюсенький! Зато "все смотрится одинаково" )))
хахаха, интересно почему все переходят на данный метод? просто изначально делаешь дизайн на full hd с увеличенным размером текста (20-24 пикселя) вместо 16, что уже не удобно. А на телефонах делаешь перестроение
а если просто html{ font-size:62.5%};??
это получается 10, удобно считать rem
да, такой подход тоже распространенный и верный для обычных rem-ов, но тут несколько иной подход, а именно в связке с vw