CSS3 100vh не является постоянным в мобильном браузере
у меня очень странный вопрос. в каждом браузере и мобильной версии я столкнулся с этим поведением:
- все браузер имеет верхнее меню при загрузке страницы (показывая адресную строку, например), которые скользят вверх при запуске прокрутки страницы.
- 100vh рассчитываются только на видимой части окна просмотра, поэтому при скольжении панели браузера вверх 100vh увеличивается (в пикселях)
- весь макет перекрасить и повторно настроить, так как размеры имеют изменено
- bad jumpy эффект для пользовательского опыта
как можно избежать этой проблемы? Когда я впервые услышал о viewport-height, я был взволнован, и я думал, что могу использовать его для фиксированных блоков высоты, но теперь я думаю, что единственный способ сделать это на самом деле javascript с некоторым событием изменения размера.
вы можете увидеть проблему в: пример сайта
может ли кто-нибудь помочь мне с / предложить CSS решение?
простой тестовый код:
8 ответов
к сожалению, это умышленное.
Это хорошо известная проблема (по крайней мере, в safari mobile), которая является преднамеренной, поскольку она предотвращает другие проблемы. Бенджамин Пулен ответил на ошибку webkit:
Это совершенно намеренно. Для достижения этого эффекта потребовалось немало усилий с нашей стороны. 🙂
основная проблема заключается в следующем:видимая область изменяется динамически при прокрутке. Если мы обновим CSS высота окна просмотра соответственно, нам нужно обновить макет во время прокрутки. Мало того, что это выглядит как дерьмо, но делать это при 60 FPS практически невозможно на большинстве страниц (60 FPS-базовая частота кадров на iOS).
трудно показать вам часть «выглядит как дерьмо», но представьте, что при прокрутке содержимое перемещается, и то, что вы хотите на экране, постоянно меняется.
динамическое обновление высоты не работало, у нас было несколько вариантов: drop viewport единиц на iOS, соответствует размеру документа, как до iOS 8, использовать небольшой размер, большой размер.
из данных, которые у нас были, использование большего размера представления было лучшим компромиссом. Большинство веб-сайтов, использующих viewport, большую часть времени выглядели великолепно.
исправление запланировано
на данный момент Вы не можете ничего сделать, кроме как воздержаться от использования высоты видового экрана на мобильных устройствах. Mobile Chrome, кажется, хочет адаптировать это тоже, хотя он не уверен, что они будут следовать через.
для многих сайтов, которые я создаю, клиент попросит баннер 100vh, и так же, как вы нашли, это приводит к плохому «нервному» опыту на мобильном телефоне, когда вы начинаете прокручивать. Вот как я решаю проблему для плавного последовательного опыта на всех устройствах:
сначала я установил свой элемент баннера CSS в height:100vh
затем я использую jQuery, чтобы получить высоту в пикселях моего элемента баннера и применить встроенный стиль, используя эту высоту.
этим решает проблему на мобильных устройствах, как при загрузке страницы, элемент баннера установлен в 100vh с помощью CSS, а затем jQuery переопределяет это, помещая встроенный CSS на мой элемент баннера, который останавливает его от изменения размера, когда пользователь начинает прокручивать.
однако на рабочем столе, если пользователь изменяет размер окна браузера, мой элемент баннера не будет изменяться, потому что теперь он имеет фиксированную высоту, установленную в пикселях из-за вышеуказанного jQuery. Для решения этой проблемы я использую Мобильный Обнаружить добавить класс’ mobile ‘ в тело моего документа. И затем я обертываю вышеуказанный jQuery в Оператор if:
в результате, если пользователь находится на мобильном устройстве, класс «mobile» присутствует в теле моей страницы и выполняется вышеуказанный jQuery. Таким образом, мой элемент баннера получит только встроенный CSS, примененный на мобильных устройствах, а на рабочем столе оригинальное правило 100VH CSS остается на месте.
в моем приложении я делаю это так (typescript и вложенные postcss, поэтому измените код соответственно):
он работает по крайней мере на chrome mobile и ipad. Что не работает, так это когда вы добавляете свое приложение на рабочий стол на iOS и меняете ориентацию несколько раз — каким-то образом уровни масштабирования мешают значению innerHeight, я могу опубликовать обновление, если найду решение для него.
Я только что нашел веб-приложение, которое я разработал, имеет эту проблему с iPhones и iPads и нашел статью, предлагающую решить ее с помощью медиа-запросов, ориентированных на конкретные устройства Apple.
Я не знаю, Могу ли я поделиться кодом из этой статьи здесь, но адрес такой:http://webdesignerwall.com/tutorials/css-fix-for-ios-vh-unit-bug
выход из статьи: «просто сопоставьте высоту элемента с высотой устройства, используя медиа-запросы, которые нацелены более старые версии разрешения iPhone и iPad.»
Они добавили только 6 медиа-запросов для адаптации элементов полной высоты, и он должен работать, поскольку он полностью реализован CSS.
Edit pending: я не могу проверить его прямо сейчас, но я вернусь и сообщу о своих результатах.
Я придумал компонент React -зацените Если вы используете React или просмотр исходного кода Если вы этого не сделаете, то вы можете приспособить его к вашей окружающей среде.
Он устанавливает высоту полноэкранного div в window.innerHeight а затем обновляет его при изменении размера окна.
@nils объяснил это ясно.
Я просто вернулся, чтобы использовать относительную «классику» % (процент) в CSS.
это часто больше усилий, чтобы реализовать то, чем он будет использовать vh , но, по крайней мере, у вас есть довольно стабильное решение, которое работает на разных устройствах и браузерах без странных сбоев пользовательского интерфейса.
Как я новичок, я не могу комментировать другие ответы.
Если кто — то ищет ответ, чтобы сделать эту работу (и может использовать javascript-как кажется, требуется, чтобы сделать эту работу на данный момент), этот подход работал довольно хорошо для меня, и он также учитывает изменение мобильной ориентации. Я использую Jquery для примера кода, но должен быть выполним с vanillaJS.
— во-первых, я использую скрипт, чтобы определить, является ли устройство касанием или наведением. Голый скелет пример:
это добавляет класс к элементу body в соответствии с типом устройства (наведение или касание), который может быть использован позже для сценария высоты.
— затем используйте этот код для установки высоты устройства при загрузке и изменении ориентации:
— тайм-аут установлен так, что прибор высчитал бы новую высоту правильно на изменении ориентации. Если нет тайм-аута, по моему опыту высота будет не правильно. 500ms может быть переусердствовать, но имеет работать на меня.
— 100vh на hover-устройствах является резервным, если браузер переопределяет CSS 100vh.
Источник
CSS исправление для 100vh в мобильных WebKit браузерах
Дата публикации: 2020-06-03
От автора: недавно наблюдался ажиотаж вокруг того, как WebKit обрабатывает CSS 100vh, по существу игнорируя нижний край окна просмотра браузера. Некоторые предложили избегать использования 100vh, другие придумали разные альтернативы для решения проблемы. Фактически, эта проблема уходит еще в давние времена, когда Николас Хойзи подал уведомление об ошибке в WebKit по этому вопросу (кратко: WebKit говорит, что это «намеренно»).
На днях я немного поработал с базовым макетом flexbox — хэдером, основным содержимым и липким футером — мы все видели и использовали это много раз раньше:
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3
Я начал выполнять некоторые тесты браузера на своем iPhone, и тогда я заметил, что мой липкий футер не выглядел таким уж липким:
Футер скрывался под строкой меню Safari. Это ошибка 100vh, которую Николас первоначально обнаружил и сообщил о ней. Я немного потрудился — надеясь, что, возможно, к настоящему моменту найдены нехакерские исправления — и вот тогда я нашел свое собственное решение (кстати, это 100% хак):
Использование -webkit-fill-available
Идея, лежащая в основе -webkit-fill-available, по крайней мере, в части ее, заключалась в том, чтобы позволить элементу встраиваться в конкретный макет, т. е. заполнять доступное пространство. В настоящее время внутренние значения, подобные этому, не полностью поддерживаются CSSWG.
Тем не менее, описанная выше проблема касается именно WebKit, который поддерживает -webkit-fill-available. Имея это в виду, я добавил это свойство в свой набор правил для 100vh в качестве запасного варианта для всех других браузеров.
Этот код был изменен с включением элемента html после того, как мне сказали, что Chrome обновляет поведение, чтобы соответствовать реализации Firefox. И теперь липкий футер располагается в мобильном Safari там, где я хочу!
Это действительно работает?
Кажется, да. У меня не было проблем ни с одним из проведенных тестов, и я сейчас использую этот метод в производстве. Но я получил несколько ответов на мой твит, указывающих на другие возможные проблемы с использованием этого (эффекты вращающихся устройств, Chrome не полностью игнорирует свойство и т. д.).
Будет ли -webkit-fill-available работать в каждом сценарии? Наверное, нет, потому что давайте будем честными: это веб, и для него чертовски сложно создать что-то универсальное. Но если у вас проблемы с 100vh в WebKit, и вы ищете альтернативу CSS, вы можете попробовать это.
Редакция: Команда webformyself.
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3
Источник
CSS3 100vh не постоянный в мобильном браузере
У меня очень странная проблема . в каждом браузере и мобильной версии я сталкивался с таким поведением:
- у всех браузеров есть верхнее меню при загрузке страницы (например, с адресной строкой), которое сдвигается вверх, когда вы начинаете прокручивать страницу.
- 100vh иногда рассчитывается только для видимой части области просмотра, поэтому при увеличении полосы браузера 100vh увеличивается (в пикселях)
- все макеты перекрасить и заново отрегулировать, так как размеры изменились
- плохой эффект для пользователя
Как можно избежать этой проблемы? Когда я впервые услышал о viewport-height, я был взволнован и подумал, что смогу использовать его для блоков с фиксированной высотой вместо javascript, но теперь я думаю, что единственный способ сделать это — фактически javascript с некоторым событием resize .
Вы можете увидеть проблему по адресу: образец сайта
Может кто-нибудь помочь мне / предложить решение CSS?
простой тестовый код:
К сожалению, это намеренно .
Это хорошо известная проблема (по крайней мере, в Safari Mobile), которая является намеренной, поскольку предотвращает другие проблемы. Бенджамин Пулен ответил на ошибку веб-набора :
Это совершенно намеренно. С нашей стороны потребовалось немало усилий для достижения этого эффекта. 🙂
Основная проблема заключается в следующем: видимая область динамически изменяется при прокрутке. Если мы соответствующим образом обновим высоту области просмотра CSS, нам нужно обновить макет во время прокрутки. Мало того, что это выглядит как дерьмо, но сделать это при 60 FPS практически невозможно на большинстве страниц (60 FPS — базовая частота кадров на iOS).
Сложно показать вам часть «выглядит как дерьмо», но представьте, что во время прокрутки содержимое перемещается, а то, что вы хотите на экране, постоянно смещается.
Динамическое обновление высоты не работало, у нас было несколько вариантов: отбросить единицы просмотра в iOS, соответствовать размеру документа, как до iOS 8, использовать маленький размер представления, использовать большой размер представления.
Из данных, которые мы имели, использование большего размера представления было лучшим компромиссом. Большинство сайтов, использующих блоки просмотра, выглядели великолепно большую часть времени.
Исправление не запланировано
На данный момент вы ничего не можете сделать, кроме как отказаться от использования высоты области просмотра на мобильных устройствах. Chrome изменился и в 2016 году:
Вы можете попробовать min-height: -webkit-fill-available; в своем CSS вместо 100vh . Должно быть решено
в моем приложении я делаю это так (машинопись и вложенный postcss, поэтому измените код соответствующим образом):
это работает по крайней мере на Chrome Mobile и Ipad. Что не работает, так это когда вы добавляете свое приложение на домашний экран на iOS и меняете ориентацию несколько раз — каким-то образом уровни масштабирования портятся со значением innerHeight, я могу опубликовать обновление, если найду решение для него.
Для многих сайтов, которые я создаю, клиент будет запрашивать 100-вольтовый баннер, и, как вы уже нашли, это приводит к плохому «нервному» впечатлению на мобильном телефоне, когда вы начинаете прокручивать. Вот как я решаю проблему для бесперебойного согласованного взаимодействия на всех устройствах:
Сначала я установил свой элемент баннера CSS на height:100vh
Затем я использую jQuery для получения высоты в пикселях элемента баннера и применяю встроенный стиль, используя эту высоту.
Это решает проблему на мобильных устройствах, так как при загрузке страницы элемент баннера устанавливается на 100vh с использованием CSS, а затем jQuery переопределяет это, помещая встроенный CSS в мой элемент баннера, который останавливает его изменение размера, когда пользователь начинает прокручивать.
Однако на рабочем столе, если пользователь изменяет размер своего окна браузера, размер элемента баннера не изменится, потому что теперь он имеет фиксированную высоту, заданную в пикселях из-за вышеупомянутого jQuery. Для решения этой проблемы я использую Mobile Detect, чтобы добавить «мобильный» класс в тело моего документа. А затем я оборачиваю вышеупомянутый jQuery в оператор if:
В результате, если пользователь находится на мобильном устройстве, класс «mobile» присутствует в теле моей страницы, и выполняется вышеуказанный jQuery. Таким образом, мой баннерный элемент будет применять только встроенный CSS на мобильных устройствах, в то время как на рабочем столе оригинальное правило CSS 100vh остается в силе.
Источник