Re: 21 век - век мобильного интернета, а nginx где?

Xasima xasima at gmail.com
Thu Jan 17 11:27:02 UTC 2013


2013/1/17 Alexey V. Karagodov <kav at karagodov.name>

>
> On 17.01.2013, at 12:44, Михаил Монашёв <postmaster at 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 at 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 at softsearch.ru
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
Best regards,
     ~ Xasima ~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130117/8fea665f/attachment.html>


Подробная информация о списке рассылки nginx-ru