On Aug 19, 5:13 am, Jon Brisbin <[EMAIL PROTECTED]> wrote:
> On Aug 19, 2008, at 4:40 AM, RobG wrote:
>
>
>
> > The logic here is completely at odds with your statement above.
>
> It's really not. I don't have time to digress into a pointless
> argument over semantics and point out why this, and the arguments
> later about me somehow suggesting that you should use UA sniffing
> because I said so are just simplistic and designed to undercut and
> redirect attention away for the purposes of proving a point.
>
> In the end, it doesn't matter. Do whatever you want. For whatever
> reason or no reason. JUST BUILD APPS. Good apps that provide good
> functionality to users. How you go about doing that really doesn't
> matter. They're not gonna care whether you used feature detection or
> UA sniffing. Only other developers will care.
>
That is true because poor internal quality means the code is harder to
change and modify.
In the case with browser detection, the code is not the only thing
that is being changed. The browser changes, too.
>
> Feature detection doesn't help you send down CSS or images that are
> specific to that browser.
So content negotiation and media queries are completely useless?
> Period. Why include three or four different
> stylesheets when you can include one? The structure of my pages is
> different for iPhone than for desktop browsers. How, exactly, would I
> use feature detection (other than using it to set a cookie or other
> variable announcing that I'm version "iPhone OS 2_0_1") to make
> template-time decisions about what gets included in the page and
> where? How would I use feature detection to send a different image for
> iPhone because the gradients don't look good on a white background?
> How do I feature-detect "-moz-border-radius" on the server?
>
> I used GWT as an example of empirical evidence of targeting specific
> browsers using code tailored to that browser. Empirical means judge
> for yourself. Not because I said so, but because you actually
> investigated it and can make up your own mind.
>
> Because I like UA sniffing for *some* things, I somehow support
> detecting 78,000 unique UA strings? Again, hyperbole in the interest
> of proving a point. I think it's fairly obvious to most people that UA
> strings contain enough reusable information to make them useful.
>
This might seem obvious to an amateur, and I'll admit, I've used
browser detection in the past.
However, I've come to realize that relying on UA strings, even in the
most careful ways, is spurious and leads to code that will be harder
to maintain.
> I don't understand why this topic has to become religious every time
Who's being religious?
> the subject is touched upon. We're talking about the iPhone here.
The subject is "How to identify 1.x vs 2.x", and the topic is about
browser detection, even though it begs the question: "Why? What are
you trying to do?"
> A
> known quantity. Feature detection is a perfectly legitimate way to
> write JavaScript to target that. If you're wanting to extend the
> customization of your app beyond just JavaScript, then you've either
> got to use feature detection to build a configure-like set of
> variables that tell your server what the UA can do, or you sniff the
> UA string. It's a decision that no one's life depends on and can be
> made wrongly and flippantly.
>
Doing the job correctly only when "someone's life depends on it,"
seems haphazard, doesn't it?
I think that quality and implementation really do matter. I take pride
in producing professional quality code.
I agree with satisfying the user with something of high *external*
quality. However, I cannot agree with your argument that
implementation doesn't matter. How does external quality negate the
need for internal quality?
> Whatever you feel comfortable with, do. All things in moderation...
>
> Thanks!
>
> Jon Brisbinhttp://jbrisbin.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
