📌 Друзья, в телеграмме у нас есть отдельный чат, где вы можете задать вопрос по фронтенд-разработке и вам постараются помочь: 💬 t.me/friendlyFrontendChat Если вам это интересно, присоединяйтесь, задавайте вопросы и помогайте другим 🙂
Идеальная подача материала, спасибо автору! Никакой воды, чётко, по делу. В минуту (а то и меньше) рассказывается то, на что у многих уходит по 10-20 минут с водой, и лишней ненужной информацией. Отступления (как проблему решали ранее, и т.д) сделаны в тему, поскольку у многих и правда возникают такие наводящие вопросы. Желаю автору развития в данном деле, и аудитории побольше.
не слушай, круто не знал об этом. А тут как раз в проекте встал вопрос как это все граммотно разместить, а тут такое шикарное видео которое решает мою проблему. Причем случайно наткнулся, фэнкс за инфу
огонь! спасибое! По поводу видео: хорошая дикция, всё кратко и по существу, без лишней болтовни. А еще мне понравилась музыка на заднем фоне, спокойная. Информация под такую музыку воспринимается очень приятно.
Очень хорошая подача материала без воды, чётко и по факту + акцент на возможных проблемах с использованием тех или иных фич (это я вообще считаю главным, т.к. многие опускают этот немаловажный момент). Спасибо за контент!)
Наконец то!! Спасибо за ролик. Сколько боли было пережито с разными версиями айфонов и их нижним баром...ох. Помню делал кастыльную реализацию несколько лет назад с скрытым контейнером который занимал некоторую высоту и при скроле исчезал :D
Добавлено 5 дней назад, ого Как же вовремя выпустил видео! Ты прям читал мои мысли, слушать то, что я искал много времени, балдеж для ушей и глаз) а особенного для мозга, ахахахах Я уже 2 недели пытаюсь решить проблему с адресной строкой в браузере на смартфонах, думал я один такой, кто заметил подобное поведение на этих устройств. Причем, Я самостоятельно искал причину несовпадения размеров, сначала думал что это каким то чудесным образом связано с нижней навигационной панелью смартфонов(что изначально и казалось для меня бредом), но после проверок понял, что оказывается из за адресной строки браузера(не судите, я учусь, поэтому не знаю всего) Я хотел для своего сайта сделать максимум 100vh без скроллов основной страницы вертикально и горизонтально. Я даже уже нашел решение через JavaScript, о котором как раз ты тоже рассказал, но теперь понял в чем минус данного способа. Спасибо тебе большое за такой актуальный, и к тому же качественный контент!
Интересное видео! Спасибо большое. Я правда не особо фанат фронтенда, да и вцелом веба, но тут было интересно, без воды, с хорошими примерами. Жди бума подписчиков - хорошо делаешь!
Очень здорово! Сам недавно посмотрел на эти нововведения и тут в рекомендациях всплыло - решил глянуть, может что упустил. Интересно было бы послушать про динамический размер шрифта, если есть что сказать :0)
Про динамический размер шрифта не так много информации могу дать, буквально одна формула vw через calc и парочка рекомендаций. Скорее это будет часть общего гайда про работу с заголовками :)
Каеф, в свое время такие же костыли с --vh и transition: height делал чтобы фуллскрин модалку открыть в сафари. Мобильные браузеры это отдельный котел в аду, рад что dvh вроде решает все это.
Видео полезное, спасибо! (Музыкальное оформление имхо не соответствует контенту, акцентирует не на единицах измерения в css, а на бренности и временности всего сущего ))
Согласен, можно и без музыки вовсе. Например оставить бодрую музычку только во вступлении и в конце секунд на 10-15, чтобы задать позитивное настроение в начале и послевкусие, что ты узнал что-то новое и жизнь твоя стала совсем другой :)) А в середине без музыки.
Привет! Это запись экрана с реального устройства. Включил live-server в IDE и с телефона, подключенного к той же вайфай сети, подключился к адресу лайв-сервера в локальной сети.
Событие resize не такое уж и страшное как думают или подносят некоторые разработчики - оно так часто срабатывает только из-за того, что сам разработчик дергает эти размеры постоянно и декоратор debounce тут лишний имхо. У обычного пользователя событие срабатывает всего пару раз: 1. при изменении высоты той же панели; 2. при повороте телефона. Браузеры на ПК ещё меньше (при условии, что пользователь намеренно это зачем-то не делает). Такая озабоченность с debounce и частым вызовом более характерна для события scroll т.к. он вызывается даже на стороне обычного пользователя очень часто и там уже можно это дело оптимизировать через debounce или throttle. Вообще радует, что ввели единицы измерения для CSS под это дело. Главное, чтобы браузеры не ввели что-то новое, пока у этих единиц поддержка не стала ~97% и не пришлось придумывать новые костыли.
Интересные мысли, спасибо. Микрооптимизации в виде debounce на resize в большинстве случаев и вправду могут быть излишни. Но у меня всё же был случай, когда банальный ресайз окна на десктопе приводил к падению фпс сайта до 1-2 на несколько секунд, что выглядело очень уж неприятно. Но там были сложнее вычисления, чем window.innerHeight * 0.01 :)
Очень сильно зависит от проекта. Если у тебя, скажем, канавас с 3д сценой на миллион полигонов и юзер решил ресайзнуть окно мышкой, то такая оптимизация будет уместна. Или если несколько графиков или что-то ещё тяжёлое, что рендерится медленнее, чем 30 фпс
@@Disorrder В canvas используются другие оптимизации, которые нужны для вычислений, например, кеширование. Если речь идет про FPS, значит мы про использование requestAnimationFrame, который выполняется ~60 раз в секунду. Смысла оптимизировать его через debounce попросту нет т.к. перед ререндером выполняются вычисления для отрисовки и они подхватят новый размер экрана. Единственный кейс - это разве что остановить анимацию пока не прекратят ресайзить, в других случаях requestAnimationFrame вызывается ещё чаще, чем пользователь вызывал бы событие resize. Опять же, в основном умышленным частым ресайзом занимаются в 99% другие разработчики. Если вы хотите при анализе вашего сайта показать им как у вас оптимизированно все - дело в ваше, но иногда чрезмерная оптимизация для каких-то маловероятных кейсов может вредить обычному пользователю (например, ожидание перерисовки при повороте экрана т.к. debounce использует setTimeout, который ждет очищение стека и он не гарантирует, что функция в нем будет выполнена именно через то время, которое указано в нем).
@@Nomikama а ты точно правильно прочитал мой комментарий? Я же не просто так упомянул 3д графику, ещё и на миллион полигонов. Если ты ресайзишь камеру, то у неё меняется соотношение сторон, меняется разрешение текстур, меняются все шейдеры, всё это может стриггерить множество тяжёлых операций, которые не происходят каждый кадр. Даже 2д графики лагают при ресайзе вьюпорта. Поиграйся с plotly, например, добавь туда пару сабчартов, хотя бы 1000 точек в данные, посмотри как он себя ведёт при ресайзе. Добавь штук 6 таких на страницу и увидишь, как они зависают. И нет, мышкой ресайзят не только разработчики. Есть банальные режимы типа полноэкранный/оконный/ф11. Иногда хочется экран на 2 части разделить, чтобы браузер был с одной стороны, а с другой что-то ещё. В целом, наверное, ничего страшного, если оно лагает при ресайзе, уже все к этому привыкли. Но если есть возможность простым способом это оптимизировать, то почему бы это не сделать? Мы уже текста написали больше, чем нужно кода для реализации
@@Disorrder Я не исключал ресайз полностью. Разделение экрана, полноэкранный - это действие на раз-два, а не тот ресайз из-за которого делают debounce. Как он вообще поможет в этом случае, если только не закликивать эти режимы? При включении режима полного экрана или разделения все равно потребуется перерисовка. Опять же, в основном только разрабы триггерят ресайз очень много раз, как показывали тут на примере. Смотря ютбут ты же не включаешь полноэкранный режим и не выключаешь его каждые 5 мс.
По CSS на канале будет отдельный курс для начинающих. Запущу его после завершения текущего курса по HTML. Это видео, конечно, не для новичков. Мне просто спонтанно пришла идея рассказать о новых фишках CSS, о которых никто (вроде бы) на русскоязычном ютубе пока не рассказывал :)
в первый раз тут, несколько комментов: музыка не нужна, вообще никакая (могут смотреть как на 1х, так и на 2х, а самое главное она не несет никакой полезной нагрузки); аудио дорожку погромче; нет-нет посматривай в камеру, особенно когда что-то объясняешь; height - не хейт/хэйт, а хАйт.
Спасибо за полезную критику! Про музыку обязательно учту. Просто порой кажется, что вообще без музыкального сопровождения будет пресновато. Но на х2 скорости это, наверное, наверняка мешает. Про звук аудиодорожки с голосом - за это отдельное спасибо, разберусь с этим. А вот с камерой - сложнее. Концентрировать мысли глядя на код проще, чем в камеру :) Про хайт - да, из меня тот ещё англичанин, спасибо, запомню произношение.
@@AleksanderLamkov да без проблем, с опытом почувствовать себя увереннее (ваш кэп). Для данного формата образовательной (все же более, чем развлекательной) направленности музыка будет мешать - твоя цель максимально эффективно донести до нас суть с достаточным "мясцом", при этом удерживать фокус, но не перегружать/отвлекать его. Насчет пресности - решай содержательностью, подачей и хронометражем материала :)
Да, возможно это было бы лучше. Спасибо за заметку! Вообще, я руководствовался такой логикой: юзер ресайзит окно и во время ресайза он потенциально готов к тому, что интерфейс может быть поломан, а после окончания ресайза важно, чтобы всё встало на свои места. Поэтому выполнение обновления --vh через debounce, которое произведется только после того, как пройдет последняя итерация события resize, не шибко повлияет на UX, а в конечном итоге результат будет как надо и всё встанет на свои места. С throttle же получается так, что --vh начинает обновляться мгновенно, а затем гарантированно раз в n времени. Получается, что функция через throttle выполняется гораздо чаще, чем через debounce. P. S. если кому-то будут нужны эти функции, вот их реализация на JS: debounce: github.com/aleksanderlamkov/webpack-template/blob/main/src/js/utils/debounce.js throttle: github.com/aleksanderlamkov/webpack-template/blob/main/src/js/utils/throttle.js
@@AleksanderLamkov да, все верно, с тротл интерфейс будет адаптироваться в процессе, хотя бы раз в секунду, а с дебаунс, только когда ты отпустишь окно, до этого момента интерфейс возможно будет поломан. В каждом кейсе свои потребности)
@@NeoCoding мы немного напутали, о svh наверное речь идет, именно эта единица на vh похожа. Small Viewport Height - высота без плашек. Разница между VH и SVH всё же есть. Посмотри эти примеры на мобильном устройстве: 100vh - tppr.me/ue02z (песочница - codepen.io/aleksander-lamkov/pen/dyQmPWd) 100svh - tppr.me/kpHpq (песочница - codepen.io/aleksander-lamkov/pen/yLQKyoY) С svh высота баннера получается адекватной, с vh - нет. Ну и вдогонку lvh и dvh: 100lvh - tppr.me/NIdam 100dvh - tppr.me/hhLeE
Я не думаю что кто-то будет ресайзить окно браузера как мы это делаем в devtools, так что нет смысла писать дебаунс для этого, оно сработает тогда когда пользователь повернет экран и все (я про event 'resize')
Когда использую 34'' монитор, то постоянно перетаскиваю окошки браузера и подгоняю их размеры так, чтобы всё уместилось. Не думаю, что я один такой. Да даже на 16'' ноуте регулярно в сплит-режиме приходится ресайзить окна.
Объясните новичку. Я только только начинаю погружаться в фронтенд. Каким образом происходит использование этих обновлении в css ? Они уже там имеются и не надо не чего нового или как то надо указать в html?
Нужно ориентироваться на браузерную поддержку функциональности на caniuse.com/viewport-unit-variants. Если тебя она устраивает, то можно смело применять. Указывать в HTML ничего не нужно. По моему мнению, если сайт разрабатывается с адекватным ТЗ, где четко указано требование что-то вроде "5 последних версий браузера" и, разумеется, если нет необходимости поддерживать IE, то, например, фичу из этого видео применить можно без особых проблем. Плюс можно подстраховаться, если прописать так называемые "фоллбэки", резервные CSS-свойства: сначала то, что точно работает в большом количестве браузеров, например, 100vh, а затем то, что работает в 89% браузерах, 100dvh, к примеру. А ещё есть "полифиллы", обычно JS-библиотеки, которые автоматически преобразовывают код из нового синтаксиса в старый. Но это всё можно завести, если использовать сборщики проектов.
Все здорово, но в конце видео на сайте caniuse стало понятно, что новых единиц измерения на самом деле в 6 раз больше. А это значит, что все равно придется идти в гугл и этого видео недостаточно :с
Ага, их около 20 штук. Вдобавок к рассмотренным на видео есть ещё все те же единицы, но про ширину (зачем? неужели у мобильных браузеров есть плашки на всю высоту, съедающие часть ширины вьюпорта?), а также единицы из разряда "наибольшее/наименьше среди svh и svw" (как часто требуется задавать размерность исходя из минимальной/максимальной ширины / высоты?) В общем, среди всех новых единиц, лишь svh, lvh и dvh, имхо, заслуживают внимания, т. к. их применение на практике очевидно. С остальными, к сожалению, пока не знаю, что делать, кроме как демонстрировать синтетические абстрактные примеры.
Я занимаюсь айти достаточно давно - администрирование, веб, программирование. И я скажу, что такие нововведения это плохо. Мнение, не поддерживаемое большинством. Но большинство и не имеет хорошего опыта, практики, обучения. Но хватит себе льстить - ближе к делу. Основная проблема нового в айти - это поддержка старого. Внедряется новая фича, технология, способ, метод, фреймворк, паттерн...и не прекращается поддержка старого. Вторая проблема - технологий, способов, приемов для решения одной задачи становится несколько. Пример, близкий вам. На собеседовании вас попросят сверстать страницу. Если вы сверстаете с использовании новых единиц, вам скажут, что не все браузеры их поддерживают. Вы говорите 89% - это хорошо, но это только ваше оценочное суждение. Нет ни рекомендаций, ни спецификаций. Если вы сверстаете с использованием "старых" единиц, вам скажут, что вы не знаете новые фишки, ваша верстка не современная. Это только пример. Если бы были только одни единицы или при выходе новых браузеры прекратили поддержку старых единиц, никто ничего не смог бы вам сказать. Технологии, единицы, методы и подходы множатся в геометрической прогрессии. JS лезет в бекэнд, CSS заменяет костыли JS. Формируются новые требования, подходы, архитектурные решения. Возможно, сейчас вам это мнение кажется надуманным, но это вопрос времени и опыта. Новшество не только влияет на код, но и влияет на индустрию, на отрасль, на людей, на их командную работу, на взаимоотношения, в конце концов на дедлайн проекта (новая фича - работай быстрее). Всё взаимосвязано.
Я согласен со многими вашими тезисами. Если бы браузеры отсекали устаревшие технологии и не боялись "сломать интернет", то нам, как разработчикам, жилось бы проще. Но положение дел, когда W3C и коммьюнити вечно генерирует идеи по решению фундаментальных проблем и "переизобретает" фичи лучше, чем стагнация отрасли.
Не влияла функция вычисления размера вьюпорта на производительность. Какой обычный пользователь, особенно на мобилах, ресайзит окно по 1 пикселю, так, чтобы функция могла нагрузить? Никакой. Однако, такие части вёрстки в js пихать все равно костыль.
Ох. Сложно сказать... Исходники уже удалил (бедный мой ноут на 500 гигов памяти и видосы в 4к). Но вообще, я генерировал плейлист через сервис uppbeat.io/ по ключевым словам 'coding lesson' и мне какой-то эмбиент выдало в результатах.
Как со многими фичами CSS - сложно сказать. Ещё 1.5 года назад в черновике идея этих единиц обсуждалась. На данный момент фича на стадии 'Working Draft'. Уверен, что % поддержки станет ещё выше в ближайшие месяцы.
Ну, не сам ведь resize, а то, что внутри него может происходить :) Вспоминаю, как на одном проекте на ресайзе вычисляли размеры и положение элементов под масонри сетку, и пока через debounce это не прогнали, сайт хряхтел при малейшем ресайзе окна браузера...
Я только одного не могу понять, почему сами мобильные браузеры не делают viewport динамичным, зачем это сайту вычислять. Накостыляли браузеры, а парятся разработчики. Ну это правда тупо выглядит) То есть браузер добавил какую-то область поверх сайта, пусть сожмёть viewport и всё. Зачем сайту парится, что браузер делает хрень xD
Ужасный костыль, пришедший в css из-за мобильных браузеров. Ибо нехрен элементам управления влиять на высоту viewport вообще - вот это устранять надо было.
Как это понимаю я: lvh гарантировано вычислится относительно всей высоты экрана будто бы url-адреса и других панелей не существует vh же более непредсказуем, т. к. на его реальный размер влияет момент применения браузером стилей и наличие в этот момент дополнительных панелей интерфейса Ну, то есть, 100vh может в разные моменты на одном и том же экране выглядеть по-разному, а 100lvh будет всегда одинаковым, т. к. эта единица измерения никогда не учитывает наличие дополнительных панелей браузера.
Ну, vh появился гораздо раньше lvh. Он до сих пор используется многими, т. к. lvh банально не всеми браузерами поддерживается. Через пару лет vh точно будет не нужен и все будут использовать svh, lvh и dvh.
Критика, ибо смотрят те кто потом на собесы ходят и приходится такую дичь выбрасывать. Костыль который показан в начале это п*&^ц, кроме того что есть safe-area-insets, есть ResizeObserver не смейте для таких вещей использовать дебаунсы и еще следующий кто кинет подобный костыль в useEffect будет всю жизнь голый редакс писать, пока пальцы не отсохнут. По этим новым единицам мнение одно это вроде как спасение, но использовать я это бы не стал нигде, ибо дерготня контента, плывущие отступы и прочие прелести больше нервов попортят, уже вроде как все забили на проблему и пользователи привыкли.
Большое спасибо за ценнейшую критику и информацию! Про safe-area-insets не знал, поизучаю. Если разберусь, запишу видео :) Про ResizeObserver вместо debounce - да, имеет место быть. Согласись, ведь каждую задачу можно решить несколькими способами. Дебаунс - лишь один из них. Возможно, не самый оптимальный, но так я делал на одной из предыдущих работ (приложение на ванилле) и это было лучше, чем ничего. Про то, что "пользователи привыкли" - тут как посмотреть. Разрабатывал банковское веб-приложение где в модалке снизу были кнопки а-ля "продолжить оформление кредита", на современных iOS мобилках с плашкой снизу проскроллить до них не получалось. Главная задача модалки фактически не отрабатывалась. Подобное часто вижу в менюшках и модалках. К такому не надо привыкать, надо лечить такой UI.
Спасибо за поправку! Да, в некоторых случаях троттлинг подходит лучше. Но конкретно для этого случая я следовал такой логике: во время ресайза юзер потенциально готов к тому, что интерфейс может выглядеть не идеально и обновлять vh через троттлинг регулярно в n-единицу времени тут кажется не лучшим решением, гораздо «выгоднее» после остановки юзером ресайза окна спустя n-единицу времени один раз произвести ре-калькуляцию нового значения vh. Для этой цели и был использован дебаунс.
@@AleksanderLamkov Да, Вы совершенно правы debounce и правда выгоднее, но так как это CSS анимация, мы можем позволить себе чуть больше динамики при сравнительно небольших технических затратах. throttle сделает анимацию плавнее, а количество вызовов, ну допустим с 1 увеличится до 50. И хоть это и в 50 раз больше работы, я абсолютно уверен что нагрузка изменяется на столько незначительно, что в профейлере это будет даже незаметно.
svh - small viewport height, высота экрана без элементов интерфейса браузера lvh - large viewport height, высота экрана, включающая элементы интерфейса dvh - dynamic viewport height, подстраивающаяся под отсутствие / наличие элементов интерфейса браузера высота вьюпорта
Очень не наглядные примеры. Лучше б с появлением динамической клавиатуры на смарфоне при клацанье на input. Нельзя свойство которое сделаное для смартфона показывать в браузере тестирования...
Я показывал запись экрана с реального мобильного устройства (iPhone 13 mini), это не эмулятор. Про input - да, согласен, было бы нагляднее, но я не встречал в своей практике задачу, когда отталкиваясь от наличия экранной клавиатуры нужно было как-то менять высоту интерфейса.
Возможно. Однако по сontainer queries и их единицы измерения уже много кто на русскоязычном ютубе рассказал. Про вьюпорт-единицы по большей части знает меньше людей, как мне кажется.
![[#2024MAMA] BIGBANG (빅뱅) - 뱅뱅뱅 (BANG BANG BANG) + FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/EQsYfiPR9uM/mqdefault.jpg)
📌 Друзья, в телеграмме у нас есть отдельный чат, где вы можете задать вопрос по фронтенд-разработке и вам постараются помочь:
💬 t.me/friendlyFrontendChat
Если вам это интересно, присоединяйтесь, задавайте вопросы и помогайте другим 🙂
Идеальная подача материала, спасибо автору!
Никакой воды, чётко, по делу.
В минуту (а то и меньше) рассказывается то, на что у многих уходит по 10-20 минут с водой, и лишней ненужной информацией.
Отступления (как проблему решали ранее, и т.д) сделаны в тему, поскольку у многих и правда возникают такие наводящие вопросы.
Желаю автору развития в данном деле, и аудитории побольше.
О, кажется мы стали свидетелями рождения нового классного канала по всегда актуальной теме) буду рад находиться в первой тысяче подписавшихся❤
Мега кайфовый эмбиент на фоне
не слушай, круто не знал об этом. А тут как раз в проекте встал вопрос как это все граммотно разместить, а тут такое шикарное видео которое решает мою проблему. Причем случайно наткнулся, фэнкс за инфу
Классная серия. Фоновая мызыка прямо знатно подобрана под масштаб костылей :) Функция debounce - огонь!!!
ляяя как ютуб узнал о моей проблеме и выдал тебя в рекомендации, спасибо теперь все решено
настолько хорошая подача материала, что я узнал за 8 минут больше, чем за всю пару
Отличная подача, прекрасная дикция, и максимум пользы менее чем за 8 мин. Подписка и лайк! Удачи в развитии канала!
очень круто и понятно, особенно интересно таким как я, кто пока не силен в js..))
Спасибо, бро! Некоторые моменты я не знал.
Идеальная подача без воды. Спасибо.
Хорош 👍
ОЧЕН КРУТО СПАСИБО подписка!
огонь! спасибое!
По поводу видео: хорошая дикция, всё кратко и по существу, без лишней болтовни.
А еще мне понравилась музыка на заднем фоне, спокойная. Информация под такую музыку воспринимается очень приятно.
Коротко. По делу. Спасибо. Самое то, чтобы оставаться вкурсе актуального.
Очень хорошая подача материала без воды, чётко и по факту + акцент на возможных проблемах с использованием тех или иных фич (это я вообще считаю главным, т.к. многие опускают этот немаловажный момент).
Спасибо за контент!)
здорово что вся суть уменьшается в меньше чем 10 мин. все понятно
Классно! Очень понятно пояснил, даже про vmin, vmax напомнил, я о них знал, но как то не использовал и забыл. Лайк 👍
Интересная тема новых фич :)
А вообще удивительно, что apple со своим safari, опять не затянули добавление фичи на годы, заставляя разработчиков страдать 😁
Наконец то!! Спасибо за ролик.
Сколько боли было пережито с разными версиями айфонов и их нижним баром...ох.
Помню делал кастыльную реализацию несколько лет назад с скрытым контейнером который занимал некоторую высоту и при скроле исчезал :D
спасибо, все как оно должно быть, коротко и ясно.
Оо, класс! Вроде и мелочь, а так поможет. Кстати, меня музыка на заднем фоне что-то в тревогу отправила))
Спасибо! Про музыку - учту. Ещё экспериментирую с жанрами. Возможно эмбиент - не лучший выбор для образовательного контента :)
Нормальная музыка 😅
Каждому не угодишь
@@AleksanderLamkov Lofi music норм
Огромное спасибо за видео! Да было, да писали такой же костыль на js, да это очень сильно потрепало когда-то нервы ... Буду тестить новые единицы
Как можно не любить CSS? ❤
Подписка, лайк, респект. Очень хорошая подача и объяснение, очень надеюсь, что и js co временем появится.
Спасибо за видео. Познавательно и интересно.
П.С. - вроде много верстал, а проблем с мобильными устройствами не наблюдал...
Классное объяснение, подписался. И музыка отличная в тревогу не отправляет
Хороший контент, спасибо
Познавательно, спасибо!
Классное видео. Остальные видосы тоже крутые! Подписка однозначно)
В поддержку канала. Красава!
Добавлено 5 дней назад, ого
Как же вовремя выпустил видео! Ты прям читал мои мысли, слушать то, что я искал много времени, балдеж для ушей и глаз) а особенного для мозга, ахахахах
Я уже 2 недели пытаюсь решить проблему с адресной строкой в браузере на смартфонах, думал я один такой, кто заметил подобное поведение на этих устройств. Причем, Я самостоятельно искал причину несовпадения размеров, сначала думал что это каким то чудесным образом связано с нижней навигационной панелью смартфонов(что изначально и казалось для меня бредом), но после проверок понял, что оказывается из за адресной строки браузера(не судите, я учусь, поэтому не знаю всего)
Я хотел для своего сайта сделать максимум 100vh без скроллов основной страницы вертикально и горизонтально.
Я даже уже нашел решение через JavaScript, о котором как раз ты тоже рассказал, но теперь понял в чем минус данного способа.
Спасибо тебе большое за такой актуальный, и к тому же качественный контент!
Прикольно. Не знал. Подписался
Интересное видео! Спасибо большое. Я правда не особо фанат фронтенда, да и вцелом веба, но тут было интересно, без воды, с хорошими примерами. Жди бума подписчиков - хорошо делаешь!
Круто. Продолжай
красавчик!
я так люблю когда в css выходит какое-то крутое нововведение, и людям приходиться ждать несколько лет, что бы браузеры смогли его поддерживать💀
Объективно говоря, CSS в последние годы набрал обороты и многие фичи браузерами обкатываются гораздо быстрее, чем раньше.
@@AleksanderLamkov только раньше у нас был IE который тормозил прогресс, а теперь его место занял Safari на айфонах
@@adeptiworksие не тормозил прогресс. Он просто не сооблюдал никакие стандарты, потому что микрософту было плевать
Отличное видео! Хорошая подача материала
Привет! Отличное видео, только одна маленькая поправка: слово "height" произносится как "хайт", не "хейт".
Круто) Быстро же отреагировали команда W3C на эту проблему и выпустили апдейт.
"хэйт" это ненависть, а "хайт" - это высота.
Спасибо, учту :)
Спасибо ! Подписка )
случайно наткнулся на это видео, жалко не увидел его раньше, через js костыль делал под телефон везде высоту
Очень здорово! Сам недавно посмотрел на эти нововведения и тут в рекомендациях всплыло - решил глянуть, может что упустил.
Интересно было бы послушать про динамический размер шрифта, если есть что сказать :0)
Про динамический размер шрифта не так много информации могу дать, буквально одна формула vw через calc и парочка рекомендаций. Скорее это будет часть общего гайда про работу с заголовками :)
Оч крутой видос и новые фичи)
красота!
Спасибо!
Неплохо. Подписался
топ контент, красавчик.
Каеф, в свое время такие же костыли с --vh и transition: height делал чтобы фуллскрин модалку открыть в сафари. Мобильные браузеры это отдельный котел в аду, рад что dvh вроде решает все это.
Спасибо!
Видео полезное, спасибо!
(Музыкальное оформление имхо не соответствует контенту, акцентирует не на единицах измерения в css, а на бренности и временности всего сущего ))
Согласен, можно и без музыки вовсе. Например оставить бодрую музычку только во вступлении и в конце секунд на 10-15, чтобы задать позитивное настроение в начале и послевкусие, что ты узнал что-то новое и жизнь твоя стала совсем другой :)) А в середине без музыки.
Спасибо за критику касаемо музыки, это безумно полезно! Обязательно учту этот момент.
@@michaelmironenko455 хорошая идея, спасибо!
@@AleksanderLamkov Не за что, а тебе спасибо за полезный контент!
@@AleksanderLamkov а мне понравилась фоновая
Оч полезно, спасибо)
Подскажите пожалуйста что за тулзы вы используете для теста на мобилки, как на 5:10 и дальше
Привет! Это запись экрана с реального устройства. Включил live-server в IDE и с телефона, подключенного к той же вайфай сети, подключился к адресу лайв-сервера в локальной сети.
@@AleksanderLamkov понятно, спасибо, думал какой-то эмулятор прост)
Событие resize не такое уж и страшное как думают или подносят некоторые разработчики - оно так часто срабатывает только из-за того, что сам разработчик дергает эти размеры постоянно и декоратор debounce тут лишний имхо. У обычного пользователя событие срабатывает всего пару раз:
1. при изменении высоты той же панели;
2. при повороте телефона.
Браузеры на ПК ещё меньше (при условии, что пользователь намеренно это зачем-то не делает).
Такая озабоченность с debounce и частым вызовом более характерна для события scroll т.к. он вызывается даже на стороне обычного пользователя очень часто и там уже можно это дело оптимизировать через debounce или throttle.
Вообще радует, что ввели единицы измерения для CSS под это дело. Главное, чтобы браузеры не ввели что-то новое, пока у этих единиц поддержка не стала ~97% и не пришлось придумывать новые костыли.
Интересные мысли, спасибо.
Микрооптимизации в виде debounce на resize в большинстве случаев и вправду могут быть излишни. Но у меня всё же был случай, когда банальный ресайз окна на десктопе приводил к падению фпс сайта до 1-2 на несколько секунд, что выглядело очень уж неприятно. Но там были сложнее вычисления, чем window.innerHeight * 0.01 :)
Очень сильно зависит от проекта. Если у тебя, скажем, канавас с 3д сценой на миллион полигонов и юзер решил ресайзнуть окно мышкой, то такая оптимизация будет уместна. Или если несколько графиков или что-то ещё тяжёлое, что рендерится медленнее, чем 30 фпс
@@Disorrder В canvas используются другие оптимизации, которые нужны для вычислений, например, кеширование. Если речь идет про FPS, значит мы про использование requestAnimationFrame, который выполняется ~60 раз в секунду. Смысла оптимизировать его через debounce попросту нет т.к. перед ререндером выполняются вычисления для отрисовки и они подхватят новый размер экрана. Единственный кейс - это разве что остановить анимацию пока не прекратят ресайзить, в других случаях requestAnimationFrame вызывается ещё чаще, чем пользователь вызывал бы событие resize. Опять же, в основном умышленным частым ресайзом занимаются в 99% другие разработчики. Если вы хотите при анализе вашего сайта показать им как у вас оптимизированно все - дело в ваше, но иногда чрезмерная оптимизация для каких-то маловероятных кейсов может вредить обычному пользователю (например, ожидание перерисовки при повороте экрана т.к. debounce использует setTimeout, который ждет очищение стека и он не гарантирует, что функция в нем будет выполнена именно через то время, которое указано в нем).
@@Nomikama а ты точно правильно прочитал мой комментарий? Я же не просто так упомянул 3д графику, ещё и на миллион полигонов. Если ты ресайзишь камеру, то у неё меняется соотношение сторон, меняется разрешение текстур, меняются все шейдеры, всё это может стриггерить множество тяжёлых операций, которые не происходят каждый кадр.
Даже 2д графики лагают при ресайзе вьюпорта. Поиграйся с plotly, например, добавь туда пару сабчартов, хотя бы 1000 точек в данные, посмотри как он себя ведёт при ресайзе. Добавь штук 6 таких на страницу и увидишь, как они зависают.
И нет, мышкой ресайзят не только разработчики. Есть банальные режимы типа полноэкранный/оконный/ф11. Иногда хочется экран на 2 части разделить, чтобы браузер был с одной стороны, а с другой что-то ещё. В целом, наверное, ничего страшного, если оно лагает при ресайзе, уже все к этому привыкли. Но если есть возможность простым способом это оптимизировать, то почему бы это не сделать? Мы уже текста написали больше, чем нужно кода для реализации
@@Disorrder Я не исключал ресайз полностью. Разделение экрана, полноэкранный - это действие на раз-два, а не тот ресайз из-за которого делают debounce. Как он вообще поможет в этом случае, если только не закликивать эти режимы? При включении режима полного экрана или разделения все равно потребуется перерисовка. Опять же, в основном только разрабы триггерят ресайз очень много раз, как показывали тут на примере. Смотря ютбут ты же не включаешь полноэкранный режим и не выключаешь его каждые 5 мс.
Подписался, жду новых видео с нетерпением)
Неужели я нашел реально что то полезное для работы, а не индусов 😂
аллилуя
Всё супер, фоновая музыка немного сбивает)
Видос топ, но фоновый музон это просто психодел какой-то))))
Хех, сколько людей уже момент про музыку отметили :) В следующих видео решил сделать полностью без неё, посмотрю реакцию зрителей.
CSS свойтва будет ? grid не понял я, обьясните пожалуйста
По CSS на канале будет отдельный курс для начинающих. Запущу его после завершения текущего курса по HTML.
Это видео, конечно, не для новичков. Мне просто спонтанно пришла идея рассказать о новых фишках CSS, о которых никто (вроде бы) на русскоязычном ютубе пока не рассказывал :)
Классное видео, но музыкальный фон бы убрать. У каждого ведь уже играет своя музыка на фоне, когда смотришь туториалы :)
Спасибо! Про музыку - принял к сведению. В следующих подобных роликах учел этот момент :)
в первый раз тут, несколько комментов: музыка не нужна, вообще никакая (могут смотреть как на 1х, так и на 2х, а самое главное она не несет никакой полезной нагрузки); аудио дорожку погромче; нет-нет посматривай в камеру, особенно когда что-то объясняешь; height - не хейт/хэйт, а хАйт.
Спасибо за полезную критику!
Про музыку обязательно учту. Просто порой кажется, что вообще без музыкального сопровождения будет пресновато. Но на х2 скорости это, наверное, наверняка мешает.
Про звук аудиодорожки с голосом - за это отдельное спасибо, разберусь с этим.
А вот с камерой - сложнее. Концентрировать мысли глядя на код проще, чем в камеру :)
Про хайт - да, из меня тот ещё англичанин, спасибо, запомню произношение.
@@AleksanderLamkov да без проблем, с опытом почувствовать себя увереннее (ваш кэп). Для данного формата образовательной (все же более, чем развлекательной) направленности музыка будет мешать - твоя цель максимально эффективно донести до нас суть с достаточным "мясцом", при этом удерживать фокус, но не перегружать/отвлекать его. Насчет пресности - решай содержательностью, подачей и хронометражем материала :)
Вместо debounce лучше использовать throttle, так у тебя функция выполняется сразу и потом не чаще n раз в секунду
Да, возможно это было бы лучше. Спасибо за заметку!
Вообще, я руководствовался такой логикой: юзер ресайзит окно и во время ресайза он потенциально готов к тому, что интерфейс может быть поломан, а после окончания ресайза важно, чтобы всё встало на свои места. Поэтому выполнение обновления --vh через debounce, которое произведется только после того, как пройдет последняя итерация события resize, не шибко повлияет на UX, а в конечном итоге результат будет как надо и всё встанет на свои места. С throttle же получается так, что --vh начинает обновляться мгновенно, а затем гарантированно раз в n времени. Получается, что функция через throttle выполняется гораздо чаще, чем через debounce.
P. S. если кому-то будут нужны эти функции, вот их реализация на JS:
debounce:
github.com/aleksanderlamkov/webpack-template/blob/main/src/js/utils/debounce.js
throttle:
github.com/aleksanderlamkov/webpack-template/blob/main/src/js/utils/throttle.js
@@AleksanderLamkov да, все верно, с тротл интерфейс будет адаптироваться в процессе, хотя бы раз в секунду, а с дебаунс, только когда ты отпустишь окно, до этого момента интерфейс возможно будет поломан. В каждом кейсе свои потребности)
продолжайте все красиво подаете.
не понял нафигв lvh если это то же что vh ?
На мой взгляд, vh - менее стабильная единица, чем lvh. LVH гарантирует высоту без интерфейсных плашек браузера, а VH - нет.
@@AleksanderLamkov ну так без плашек же это и есть vh
@@NeoCoding мы немного напутали, о svh наверное речь идет, именно эта единица на vh похожа. Small Viewport Height - высота без плашек.
Разница между VH и SVH всё же есть. Посмотри эти примеры на мобильном устройстве:
100vh - tppr.me/ue02z (песочница - codepen.io/aleksander-lamkov/pen/dyQmPWd)
100svh - tppr.me/kpHpq (песочница - codepen.io/aleksander-lamkov/pen/yLQKyoY)
С svh высота баннера получается адекватной, с vh - нет.
Ну и вдогонку lvh и dvh:
100lvh - tppr.me/NIdam
100dvh - tppr.me/hhLeE
Я не думаю что кто-то будет ресайзить окно браузера как мы это делаем в devtools, так что нет смысла писать дебаунс для этого, оно сработает тогда когда пользователь повернет экран и все (я про event 'resize')
Когда использую 34'' монитор, то постоянно перетаскиваю окошки браузера и подгоняю их размеры так, чтобы всё уместилось. Не думаю, что я один такой. Да даже на 16'' ноуте регулярно в сплит-режиме приходится ресайзить окна.
Объясните новичку. Я только только начинаю погружаться в фронтенд. Каким образом происходит использование этих обновлении в css ? Они уже там имеются и не надо не чего нового или как то надо указать в html?
Нужно ориентироваться на браузерную поддержку функциональности на caniuse.com/viewport-unit-variants. Если тебя она устраивает, то можно смело применять. Указывать в HTML ничего не нужно.
По моему мнению, если сайт разрабатывается с адекватным ТЗ, где четко указано требование что-то вроде "5 последних версий браузера" и, разумеется, если нет необходимости поддерживать IE, то, например, фичу из этого видео применить можно без особых проблем.
Плюс можно подстраховаться, если прописать так называемые "фоллбэки", резервные CSS-свойства: сначала то, что точно работает в большом количестве браузеров, например, 100vh, а затем то, что работает в 89% браузерах, 100dvh, к примеру.
А ещё есть "полифиллы", обычно JS-библиотеки, которые автоматически преобразовывают код из нового синтаксиса в старый. Но это всё можно завести, если использовать сборщики проектов.
Все здорово, но в конце видео на сайте caniuse стало понятно, что новых единиц измерения на самом деле в 6 раз больше. А это значит, что все равно придется идти в гугл и этого видео недостаточно :с
Ага, их около 20 штук. Вдобавок к рассмотренным на видео есть ещё все те же единицы, но про ширину (зачем? неужели у мобильных браузеров есть плашки на всю высоту, съедающие часть ширины вьюпорта?), а также единицы из разряда "наибольшее/наименьше среди svh и svw" (как часто требуется задавать размерность исходя из минимальной/максимальной ширины / высоты?)
В общем, среди всех новых единиц, лишь svh, lvh и dvh, имхо, заслуживают внимания, т. к. их применение на практике очевидно. С остальными, к сожалению, пока не знаю, что делать, кроме как демонстрировать синтетические абстрактные примеры.
Посмотрел видео и понял, как можно было исправить баг на прошлом проекте.
У вас на канале кроме html, css больше ничего нет? А почему?
Привет! Канал создан относительно недавно, скоро будет и JS и всё остальное :)
@@AleksanderLamkov у вас объясняете тему очень широко. Удачи вам
Музыку не меняйте пожалуйста❤
Я занимаюсь айти достаточно давно - администрирование, веб, программирование. И я скажу, что такие нововведения это плохо. Мнение, не поддерживаемое большинством.
Но большинство и не имеет хорошего опыта, практики, обучения. Но хватит себе льстить - ближе к делу.
Основная проблема нового в айти - это поддержка старого. Внедряется новая фича, технология, способ, метод, фреймворк, паттерн...и не прекращается поддержка старого.
Вторая проблема - технологий, способов, приемов для решения одной задачи становится несколько.
Пример, близкий вам. На собеседовании вас попросят сверстать страницу. Если вы сверстаете с использовании новых единиц, вам скажут, что не все браузеры их поддерживают.
Вы говорите 89% - это хорошо, но это только ваше оценочное суждение. Нет ни рекомендаций, ни спецификаций.
Если вы сверстаете с использованием "старых" единиц, вам скажут, что вы не знаете новые фишки, ваша верстка не современная.
Это только пример. Если бы были только одни единицы или при выходе новых браузеры прекратили поддержку старых единиц, никто ничего не смог бы вам сказать.
Технологии, единицы, методы и подходы множатся в геометрической прогрессии. JS лезет в бекэнд, CSS заменяет костыли JS. Формируются новые требования, подходы, архитектурные решения.
Возможно, сейчас вам это мнение кажется надуманным, но это вопрос времени и опыта. Новшество не только влияет на код, но и влияет на индустрию, на отрасль, на людей, на их командную работу, на взаимоотношения, в конце концов на дедлайн проекта (новая фича - работай быстрее). Всё взаимосвязано.
Я согласен со многими вашими тезисами. Если бы браузеры отсекали устаревшие технологии и не боялись "сломать интернет", то нам, как разработчикам, жилось бы проще. Но положение дел, когда W3C и коммьюнити вечно генерирует идеи по решению фундаментальных проблем и "переизобретает" фичи лучше, чем стагнация отрасли.
Не влияла функция вычисления размера вьюпорта на производительность. Какой обычный пользователь, особенно на мобилах, ресайзит окно по 1 пикселю, так, чтобы функция могла нагрузить? Никакой. Однако, такие части вёрстки в js пихать все равно костыль.
На мобилках не ресайзят, а вот на большом экране десктопа - вполне.
@@AleksanderLamkov это редкость среди большинства пользователей. Частый ресайз окна браузера
Супер подача и контент, но музыка бро как будто я в галокамере сижу и пытаюсь вылечить смертельную болезнь...
Музыки уже нет в последней сотне видео на канале. Давно уже осознал неудачность этой задумки)
@@AleksanderLamkov хорошая работа над ошибками, а так спасибо что спас, не знал об этом баге даже стыдно
А что за музыка на фоне
Ох. Сложно сказать...
Исходники уже удалил (бедный мой ноут на 500 гигов памяти и видосы в 4к).
Но вообще, я генерировал плейлист через сервис uppbeat.io/ по ключевым словам 'coding lesson' и мне какой-то эмбиент выдало в результатах.
Что за трек играет на фоне?
Извини, не подскажу, какой-то эмбиент с uppbeat.io
Скорее всего что-то малоизвестное.
Попробуй через шазам прогнать.
А что за редактор кода?
WebStorm
@@AleksanderLamkov спасибо
а как давно эти штуки вышли?
Как со многими фичами CSS - сложно сказать. Ещё 1.5 года назад в черновике идея этих единиц обсуждалась. На данный момент фича на стадии 'Working Draft'. Уверен, что % поддержки станет ещё выше в ближайшие месяцы.
Улыбнуло с resize, который сильно нагружает браузер )))
Ну, не сам ведь resize, а то, что внутри него может происходить :) Вспоминаю, как на одном проекте на ресайзе вычисляли размеры и положение элементов под масонри сетку, и пока через debounce это не прогнали, сайт хряхтел при малейшем ресайзе окна браузера...
Я только одного не могу понять, почему сами мобильные браузеры не делают viewport динамичным, зачем это сайту вычислять. Накостыляли браузеры, а парятся разработчики. Ну это правда тупо выглядит) То есть браузер добавил какую-то область поверх сайта, пусть сожмёть viewport и всё. Зачем сайту парится, что браузер делает хрень xD
Ужасный костыль, пришедший в css из-за мобильных браузеров. Ибо нехрен элементам управления влиять на высоту viewport вообще - вот это устранять надо было.
И в чем тогда разница между vh и lvh
Как это понимаю я:
lvh гарантировано вычислится относительно всей высоты экрана будто бы url-адреса и других панелей не существует
vh же более непредсказуем, т. к. на его реальный размер влияет момент применения браузером стилей и наличие в этот момент дополнительных панелей интерфейса
Ну, то есть, 100vh может в разные моменты на одном и том же экране выглядеть по-разному, а 100lvh будет всегда одинаковым, т. к. эта единица измерения никогда не учитывает наличие дополнительных панелей браузера.
@@AleksanderLamkov звучит как-будто бы так, что vh бесполезен во всех случаях. А такого не может быть…
Ну, vh появился гораздо раньше lvh. Он до сих пор используется многими, т. к. lvh банально не всеми браузерами поддерживается. Через пару лет vh точно будет не нужен и все будут использовать svh, lvh и dvh.
Маководы опять не учитывают наличие скроллбара(
тупо решил мою проблему отдуши
не уверен что двх работает лучше чем свх особенно это видно на видео в случае с мобильным сафари
ок тупо везде делаем dvh и не знаем проблем. :D
Всё было бы супер, если бы не эта фоновая музыка
Критика, ибо смотрят те кто потом на собесы ходят и приходится такую дичь выбрасывать.
Костыль который показан в начале это п*&^ц, кроме того что есть safe-area-insets, есть ResizeObserver не смейте для таких вещей использовать дебаунсы и еще следующий кто кинет подобный костыль в useEffect будет всю жизнь голый редакс писать, пока пальцы не отсохнут.
По этим новым единицам мнение одно это вроде как спасение, но использовать я это бы не стал нигде, ибо дерготня контента, плывущие отступы и прочие прелести больше нервов попортят, уже вроде как все забили на проблему и пользователи привыкли.
Большое спасибо за ценнейшую критику и информацию!
Про safe-area-insets не знал, поизучаю. Если разберусь, запишу видео :)
Про ResizeObserver вместо debounce - да, имеет место быть. Согласись, ведь каждую задачу можно решить несколькими способами. Дебаунс - лишь один из них. Возможно, не самый оптимальный, но так я делал на одной из предыдущих работ (приложение на ванилле) и это было лучше, чем ничего.
Про то, что "пользователи привыкли" - тут как посмотреть. Разрабатывал банковское веб-приложение где в модалке снизу были кнопки а-ля "продолжить оформление кредита", на современных iOS мобилках с плашкой снизу проскроллить до них не получалось. Главная задача модалки фактически не отрабатывалась. Подобное часто вижу в менюшках и модалках. К такому не надо привыкать, надо лечить такой UI.
Запись микрофона бубнит, тяжело слушать. Хотя-бы эквалайзером настройте, и будет отлично.
Спасибо за замечание, учту!
Все таки не debonce а throttle.
Спасибо за поправку! Да, в некоторых случаях троттлинг подходит лучше. Но конкретно для этого случая я следовал такой логике: во время ресайза юзер потенциально готов к тому, что интерфейс может выглядеть не идеально и обновлять vh через троттлинг регулярно в n-единицу времени тут кажется не лучшим решением, гораздо «выгоднее» после остановки юзером ресайза окна спустя n-единицу времени один раз произвести ре-калькуляцию нового значения vh. Для этой цели и был использован дебаунс.
@@AleksanderLamkov Да, Вы совершенно правы debounce и правда выгоднее, но так как это CSS анимация, мы можем позволить себе чуть больше динамики при сравнительно небольших технических затратах. throttle сделает анимацию плавнее, а количество вызовов, ну допустим с 1 увеличится до 50. И хоть это и в 50 раз больше работы, я абсолютно уверен что нагрузка изменяется на столько незначительно, что в профейлере это будет даже незаметно.
Я так и не поняла в чем разница? Что автор прогнал не известно)
svh - small viewport height, высота экрана без элементов интерфейса браузера
lvh - large viewport height, высота экрана, включающая элементы интерфейса
dvh - dynamic viewport height, подстраивающаяся под отсутствие / наличие элементов интерфейса браузера высота вьюпорта
Он не мог пояиться год назад
да сколько можно этих переменных
1:50
верстальщик
Очень не наглядные примеры. Лучше б с появлением динамической клавиатуры на смарфоне при клацанье на input. Нельзя свойство которое сделаное для смартфона показывать в браузере тестирования...
Я показывал запись экрана с реального мобильного устройства (iPhone 13 mini), это не эмулятор.
Про input - да, согласен, было бы нагляднее, но я не встречал в своей практике задачу, когда отталкиваясь от наличия экранной клавиатуры нужно было как-то менять высоту интерфейса.
Эти единицы старые как моя бабушка.
Нужно писать модные единицы но никак не новые.
Новые единицы это единицы от размера контейнера.
Возможно. Однако по сontainer queries и их единицы измерения уже много кто на русскоязычном ютубе рассказал. Про вьюпорт-единицы по большей части знает меньше людей, как мне кажется.
Это не ви ви, а ви дабл ю
Не видз, а, скорее, виз
Не ви аш, а ви эйч
хорошая подача
Есть совет получше: забейте на динамические элементы в браузерах
Только firefox их пока не поддерживает
Поддерживает ещё с версии 101 (см. caniuse.com/viewport-unit-variants ).