2013/1/17 Alexey V. Karagodov <kav@karagodov.name>
>
> On 17.01.2013, at 12:44, Михаил Монашёв <postmaster@softsearch.ru> wrote:
>
> > И ещё важный вопрос: чем именно Ваша мобильная версия отличается от
> > обычной, кроме размера страничек?
> ну как бы разница есть, но это дорого стоит в плане дизайна просто
> либо отдавать клиентосу с монитором 1600х1200 кучу хлама либо отдавать
> мобильнику 320х240
> разница вроде есть
> это ещё если не учитывать кол-во точек на дюйм, 800х600 можно впихнуть и
> на 11 дюймов и на 9 и т.д.
> все клиенты любят индивидуальный подход
>
> и поголовно все забивают (мне так кажется) на персональный размер шрифта
> пользователя. вдруг он к примеру плохо видит
>
Если текстовое содержимое страниц более-менее одинаковое, то через
CSS3 media-queries можно подключить совершенно разные файлы стилей, каждый
из которых будет срабатывать на своем наборе параметров: width and height
of the browser window, device width and height, orientation (landscape
/portrait), resolution. Таким же образом можно подтягивать разные
разрешения картинок. И, да, использование em-юнитов вместо px в CSS вроде
как раз и учитывает персональный размер шрифта, в том числе под мобильными
устройствами.
Если текстовое содержимое для мобильной и полной версии сильно отличаются
(а "прятать" блок текста нельзя), при этом часть текстов заполняются на
странице с помощью ajax, тогда и на уровне js можно зацепиться за те же
media-queries параметры и отдавать разные наборы текстов в зависимости от
параметров устройства (и/или настройках пользователя).
Остается, конечно, вариант, когда для мобильного и обычного пользователя -
разные наборы "тяжелого" js приложения (аналог "разных" вариантов gmail).
Но, в таком случае js уж точно включен и лишнее определение на клиенте
вряд ли сыграет определяющую роль.
Выгрыш "правильного nginx модуля определения мобильности" в
1) скорости (media-queries требует времени исполнения на клиенте и часто
дополнительных запросов к серверу)
2) надежной поддержки старых браузеров (вместо нативного CSS3 в таких
случаях нужно использовать обходные маневры типа js-эмуляции) или браузеров
с отключенными возможностями (запрещен js)
3) легкости использования слишком специфического для конкретного браузера
кода (например, какие-нибудь "большие блоки" HTML5-возможностей,
неодинаково реализуемые на разных движках и, соответственно, требующие
совершенно разных наборов js кода, может быть трудоемко поддерживать и
"менять" на клиентской стороне).
2013/1/17 Михаил Монашёв <postmaster@softsearch.ru>
> то, что нормально поддерживается - вагон regexp под php. А хочется-то
модуль!
> А что мешает скопировать этот регэксп в nginx. Регэкспы одинаковые и
> там и там.
>
Скопировать (прямо в конфиг или специализированный файл) в любом случае
придется. С другой стороны, если кто-то станет писать модуль, то, вероятно,
лучше вместо "цикла" проверок (что, вроде бы (?) и делается в
serbanghita/Mobile_detect), использовать что-то другое поверх этих
регэкспов (
http://bytes.com/topic/python/answers/390189-speeding-up-multiple-regex-matches),
если оно будет хорошо вести себя под нагрузкой с т.з. потребляемых
ресурсов.
> Здравствуйте, Anton.
>
>> Я по прежнему не вижу способа на нжинксе с 99% определить мобильного
>> посетителя. А хочется-то вообще 4 или 5 девяток, а не две... :(
Мне кажется, что вопрос скорее смещен в сторону (конечной) скорости
определения, чем точности.
>
> А зачем нужна такая точность?
>
> >
> > --
> > С уважением,
> > Михаил mailto:postmaster@softsearch.ru
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
--
Best regards,
~ Xasima ~
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
