Мобильные устройства, position: fixed; и во что это выливается

Почему бы просто тот самый absolute; на мобильных устройствах не привязывать к нижней границе по координатам, минус размер самого элемента? На браузерах поддерживающих fixed; делать его а на остальных делать так выше сказано в чем же разница в мобильных (на моей практике ее не замечено). Как по мне так отсутствие zoom + доп. ratio скорее минус.

Столько «костылей» ради полоски «scroll to the top»,
А польза от этого довольна сомнительна — я на своём HTC MyTouch 4G только с третьего раза попал пальцем в эту полоску, то есть проще было отмотать вверх.

В своём проекте я использовал JavaScript, который стырил отсюда, но это работает только для мобильников.

Костыли, костыли, вокруг одни костыли…

В Сафари на iOS тап по верхней, статусной панели выполняет функцию «Scroll to top».

Осталось добавить полоски «Scroll to bottom», «Scroll to the topmost comment», «Scroll to my first comment», «Scroll to my last comment» и, главное, «Take me out of here now!».

А что с формой поиска? Размер уехал куда-то влево и далеко.

Только позавчера боролся с этой же проблемой.
У вас, видимо, ее нет (т.к. кнопка не показывается, если страница в самом верху). А у меня дело вот в чем: меню вверху, задано position: fixed. При клике на пункты меню страница прокручивается влево-вправо. Проблема в том, что при прокрутке страницы JS-ом все fixed-ы фактически едут вместе со страницей (хотя рисуются правильно), и чтобы их вернуть на место надо чуть-чуть подвигать страницу пальцем. Так вот и получается, что я 1 раз жму — страница крутится, и больше меню не нажимается, т.к. фактически оно тоже уехало. Надо подвигать страницу пальцем, тчобы меню снвоа заработало.
Может вы знаете как решить эту проблемку?
Для меня решение очевидно — вынести меню из скроллящейся области, но верстка не моя и она крайне убога и вся завязана на таблицах, что влечет за собой переверстку пол-сайта(

Проверка регулярным выражением на наличие подстроки «android» может выйти боком, когда Android станут ставить не только на мобильники да планшетки, но и на более компьютероподобные устройства — ASUSовские ноутбуки, например.

$(window).scroll( function() {
   if ( $(this).scrollTop() > $(window).height() ) { // Если длинна прокрутки страницы больше высоты экрана, то...
      $('.scroll-to-top-mobile').fadeIn(); // Показать кнопку
   }   else   { // Если нет, то...
      $('.scroll-to-top-mobile').fadeOut(); // Скрыть кнопку
   }
});

Это сколько же фейдИнов накидается в queue, пока будут происходить onscroll.
может хотя бы .stop().fadeIn() и .stop().fadeOut()

Спасибо за решение!

var mobile = (/iphone|ipad|ipod|android|blackberry|mini|windows\sce|palm/i.test(navigator.userAgent.toLowerCase()));

Тут не нужен toLowerCase(), т.к. в регулярке уже стоит параметр «i», который указывает на нечувствительность к регистру.

Помню, была такая же беда с fixed элементом. Но использовать

<meta name=”viewport” content=”user-scalable=no” />

было нельзя.
В итоге пришлось пересчитывать его позицию с помощью

window.addEventListener(«orientationchange»
window.addEventListener(«scroll»

Единственное, мобильная опера вообще не поддавалась лечению, так что пришлось ампутировать:

if( clientBrowser.isOpera ) {
	$('.box').hide()
}