I also do UA sniffing. So does GWT.
GWT also uses tables. We aren't supposed to use those either. Somehow
it's supposed to be "just better". More-zen like to have fully-W3C
conformant DIVs and CSS and to and furrow your eyebrows and express
your displeasure at a developer that's still the dark ages--I mean the
'90s.
But I don't like feature detection because a) when people tell you you
should do things "just because", as the web development community at
large has been doing since Ajax got big, think twice about it; and b)
you can't do things like serve content that is tailored to their
browser.
Performance-wise, I simply can't swallow that dropping a bunch of
if(browser.featureExists){} logic branches is more efficient, either
for the developer or the JavaScript engine, than a regex match on the
UA string that serves browser-specific code. GWT itself is empirical
data on which method is more performant.
I'm in the process now of writing some server-side templating in
Django that is basically like an #IFDEF for CSS and JavaScript. Since
I'm not using GWT for this (and GWT doesn't do CSS anyway), I'm using
Djangos templates to generate browser-specific code. Writing reusable
regexs that withstand software updates is much easier than keeping up
with features that may or may not be available. It's been my
experience that feature detection has unintended consequences if you
pick the wrong feature. It also doesn't tell you *how well* that
feature is implemented. Best not to guess. You'll be disappointed.
</SOAP:BOX>
Consider UA sniffing because a) it works brilliantly in both server
and client and you get the same results; b) server-side browser
detection should involve using *all* the information you have in
there. They went to a lot of trouble to be real specific, I don't know
why we can't use that information. I get the impression that a lot of
people aren't successful with UA sniffing because they don't spend
enough time getting it right and then don't understand why it doesn't
work like they expect (no, /MSIE/ isn't a reliable-enough test unless
you want to exclude them :). Writing a solid chain of browser-sniffing
regexs is not very intuitive. But it's a modular component and, unlike
in feature detection, when things change, I only change the switch at
the power panel rather in every switch in the house.
If a feature-detection "configure" script could be sent down on the
first access and all the important dependent functionality was tested
for then, that would be a greater help even than UI sniffing. Then the
zealots on the other side would be happy and I'd be tickled that I
could go on and argue about more important things. :)
Thanks!
Jon Brisibn
http://jbrisbin.com
On Aug 18, 2008, at 6:19 PM, waynepan wrote:
>
> I do some User Agent sniffing so I know if it's specifically an
> iPhone2
>
> var iPhone2 = RegExp("OS 2_[^ ]* .*
> AppleWebKit/").test(navigator.userAgent);
>
> Ahrjay's method is much faster though if you know your page is being
> served to an iPhone only.
>
>
> On Aug 18, 4:12 am, Ahrjay <[EMAIL PROTECTED]> wrote:
>> Just do a test with something you know 1.x doesn't support in
>> javascript like
>> if(document.ontouchstart)
>> {
>> 2.x stuff here
>>
>> } else {
>> 1.x stuff here
>> }
>>
>> On Aug 15, 12:17 am, shamus <[EMAIL PROTECTED]> wrote:
>>
>>> Hi,
>>
>>> How would you go about detecting 1.x versions of the iPhone OS vs.
>>> 2.x
>>> versions of the os using JavaScript? Is it possible to see which
>>> version of the OS a visitor has running?
>>
>>> Thanks.
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"iPhoneWebDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/iphonewebdev?hl=en
-~----------~----~----~----~------~----~------~--~---
