Discussion:
browser detection middleware
omat
2007-05-22 08:38:22 UTC
Permalink
Hi all,

Is it a good idea to use a middleware class to detect the browser
client looking at the HTTP_USER_AGENT so as to serve presentation
logic accordingly, for mobile devices or older browsers, etc...?

I know this is mostly done by <!--[if IE 6]>, etc... tags in the html
document but I am not very familiar with this style.

One pitfall I can think of is the bots. Googlebot for example can
detect I am serving different content for different clients and judge
that I am index spamming.

oMat


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
Atilla
2007-05-22 09:11:51 UTC
Permalink
Post by omat
Hi all,
Is it a good idea to use a middleware class to detect the browser
client looking at the HTTP_USER_AGENT so as to serve presentation
logic accordingly, for mobile devices or older browsers, etc...?
I know this is mostly done by <!--[if IE 6]>, etc... tags in the html
document but I am not very familiar with this style.
One pitfall I can think of is the bots. Googlebot for example can
detect I am serving different content for different clients and judge
that I am index spamming.
oMat
In an ideal world you wouldn't have to do that, but if you find it
absolutely necessary, you could trigger different output templates for
different systems.

But as a first - try making everything as clear as possible, so you
wouldn't need to do such things in your code and complicate it
further. Serve validated output, so you won't trigger the different
quirks in different browsers when they encounter a "broken" section.
Focus on structure, and lay out with CSS. Define CSS for different
media - screen, print, mobile - and almost every sensible browser will
handle your output as you want it to be.

If you primary concern is mobile browsers, it would make sense to
define two different sets of outputs, but try not to do this for every
browser. People are trying to avoid such things as much as possible -
it does make a big mess.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
omat
2007-05-22 11:06:42 UTC
Permalink
I agree your comments. My primary concern is to have a reasonably
similar presentation in most popular browsers. I would prefer a one-
css-fits-all solution, but...

In most cases this just doesn't seem possible. The source of wikipedia
discouraged me. Even in their relatively simple layout, they are using
6 additional css s and an additional javascript to fix IE bugs.

Anyway, this is going a little off topic, so I would not discuss css
problems here.
Post by Atilla
Post by omat
Hi all,
Is it a good idea to use a middleware class to detect the browser
client looking at the HTTP_USER_AGENT so as to serve presentation
logic accordingly, for mobile devices or older browsers, etc...?
I know this is mostly done by <!--[if IE 6]>, etc... tags in the html
document but I am not very familiar with this style.
One pitfall I can think of is the bots. Googlebot for example can
detect I am serving different content for different clients and judge
that I am index spamming.
oMat
In an ideal world you wouldn't have to do that, but if you find it
absolutely necessary, you could trigger different output templates for
different systems.
But as a first - try making everything as clear as possible, so you
wouldn't need to do such things in your code and complicate it
further. Serve validated output, so you won't trigger the different
quirks in different browsers when they encounter a "broken" section.
Focus on structure, and lay out with CSS. Define CSS for different
media - screen, print, mobile - and almost every sensible browser will
handle your output as you want it to be.
If you primary concern is mobile browsers, it would make sense to
define two different sets of outputs, but try not to do this for every
browser. People are trying to avoid such things as much as possible -
it does make a big mess.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
Simon Willison
2007-05-22 12:07:53 UTC
Permalink
Post by omat
Is it a good idea to use a middleware class to detect the browser
client looking at the HTTP_USER_AGENT so as to serve presentation
logic accordingly, for mobile devices or older browsers, etc...?
I would advise against this because it won't play well with caching
proxies in between you and the client. If an intermediate proxy caches
your page for Internet Explorer and serves it up to a client running
Firefox stuff will break in very mysterious ways.

You can work around this with the HTTP Vary header, but many proxies
are notoriously badly written so I'm not sure that I'd trust it. Much
better to serve up a standards compliant site for Firefox/Safari/Opera
and have a single stylsheet included using conditional comments for
any specific IE fixes.

Cheers,

Simon


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Loading...