Yet another appeal for browser sniffing

Discussion in 'Javascript' started by David Mark, Nov 1, 2011.

  1. David Mark

    David Mark Guest

    This one was posted as a response to a Twitter conversation.

    http://webreflection.blogspot.com/2011/10/on-user-agent-sniffing.html

    I would have commented there, but moderation is turned on (meaning
    criticism will likely be deleted) and I don't want to sign in to a
    blog site anyway.

    "Oh well, who was following me on twitter today is already bored about
    this topic (I guess) but probably other developers would like to read
    this too so ..."

    Here's hoping that other developers do not read this latest defense of
    UA sniffing.

    "What Is UA Sniffing

    UserAgent sniffing means that a generic software is relying into a
    generic string representation of the underlying system. The User Agent
    is basically considered a unique identifier of "the current software
    or hardware that is running the app".
    In native applications world UA could be simply the platform name ...
    where if it's "Darwin" it means we are in a Mac platform, while if
    it's Win32 or any other "/^Win.*$/" environment, the app reacts,
    compile, execute, as if it is in a Windows machine ... and so on with
    Linux and relative distributions."

    I really prefer the description in Richard's article:-

    http://jibbering.com/faq/faq_notes/not_browser_detect.html.

    "The Modern Web Behavior

    Recently things changed quite a lot on web side and only few companies
    are redirecting via server side User Agent sniffing. We have now
    something called runtime features detections, something that supposes
    to test indeed runtime browser capabilities and understand, still
    runtime, if the browser should be redirected or not into a hopefully
    meaningful fallback or degraded service."

    Redirecting by server side UA sniff? That's hardly the opposite of
    feature detection/testing. I sense this is heading off into the
    weeds...

    "Features Detections Good Because

    Well, specially because the browsers fragmentation is massive, FD can
    tell us what we need from the current one, without penalizing in
    advance anybody.
    The potential redirection or message only if necessary, informing the
    user his/her browser is not capable of features required to grant a
    decent experience in the current online application/service.
    FDs are also widely suggested for future compatibility with new
    browsers we may not be able to test, or recognize, with any sort of
    list present in our server side logic, the one that is not directly
    able to understand if the current browser may run the application/
    service or not.
    Of course to be automatically compatible with newer browsers is both
    business value, as "there before we know", and simplified maintenance
    of the application/logic itself, since if it was working accordingly
    with certain features, of course it's going to work accordingly with
    newer or improved features we need.
    As summary, runtime features detections can be extremely valuable for
    our business ... but

    Features Detections Bad Because

    Not sure I have to tell you that the first browser with disabled
    JavaScript support will fail all detections even if theoretically
    capable ... but lets ignore these cases for now, right?
    Well, it's kinda right, 'cause we may have detected browsers with JS
    disabled already in the server side thanks to user headers or specific
    agent ... should I mention Lynx browser ? Try to detect that one via
    JavaScript ... "

    I had a feeling. :)

    "Back to "real world cases", all techniques used today for runtime
    features detections are kinda weak ... or better, extremely weak!
    I give you an example:"

    // the "shimmable"
    if (!("forEach" in []) || !Array.prototype.forEach) {
    // you wish this gonna fix everything, uh? ...
    Array.prototype.forEach = function () { ... };
    }

    That's a pretty lousy example.

    // the unshimmable
    if (!document.createElement("canvas").getContext("2d")) {
    // no canvas support ... you wish to know here ...
    }

    What does that mean?

    "Not because I want to disappoint you but you gonna be potentially
    wrong in both cases ... why that?"

    No, he is going to be potentially wrong. It is, after all, his code.

    "Even if Array.prototype.forEach is exposed and this is the only Array
    extra you need, things may go wrong. As example, the first shim will
    never be executed in a case where "forEach" in [] is true, even if
    that shim would have solved our problem."

    Hard to understand why he included that - in - test at all (or how it
    will lead to his perceived downfall).

    "That bug I have filed few days ago demonstrated that we cannot really
    trust the fact a method is somewhere since we should write a whole
    test suite for a single method in order to be sure everything will
    work as expected OR we gonna write unit, acceptance, integration, and
    functional tests to be sure that a bloody browser works as expected in
    our application."

    What bug? And don't test *everything*; test what you need for your
    app. ;)

    "Same is valid for classic canvas capability ... once we have that, do
    we really test that every method works as expected?"

    No.

    "And if we need only a single method out of the canvas, how can we
    understand that method is there and is working as expected without
    involving, for the single test, part of the API that may not work but
    even though we don't care since we need only the very first one?"

    If it doesn't work as needed, proper feature testing should detect
    that and avoid disaster.

    "I am talking about drawImage, as example, in old Symbian browsers,
    where canvas is exposed but drawImage does not visually draw anything
    on the element ... nice, isn't it?"

    If you can't test whether it drew anything, attempt to draw two
    identical images at the outset and let the user choose which one looks
    best. Then you can rightfully blame the user if they end up with empty
    images. ;)

    "You Cannot Detect Everything Runtime

    .... or better, if you do, most likely any user has to wait few minutes
    before the whole test suite becomes green, specially in mobile
    browsers where any of these tests take ages burning battery life, CPU
    clocks, RAM, and everything else before the page can be even
    visualized since we would like to redirect the user before he can see
    the experience is already broken, isn't it?"

    The whole test suite for what?

    "IT Is Not Black Or White"

    No, it's feature testing, feature detection, object inferences in that
    order of proficiency. Notice that UA sniffing does not appear in the
    list.

    "... you think so? I think IT is more about "what's the most
    convenient solution for this problem", assuming there is, generally
    speaking, no best solution to a specific problem, since every problem
    can be solved differently and in a better way, accordingly with the
    surrounding environment.
    So how do we brainstorm all these possible edge cases that cannot
    obviously be solved runtime in a meaningful, reliable way?"

    I suppose we can try.

    "I want provide same experience to as many users as possible but
    thanks to my tests I have already found user X, Y, and Z, that cannot
    possibly be compatible with the application/service I am trying to
    offer."

    Now that is a shame.

    "If I detect runtime everything I need for my app, assuming this is
    possible, every browser I already know has no problems there will be
    penalized for non updated, low market share, problematic
    alternatives."

    It's an imperfect Web. This is one of the reasons why context is so
    important to the design. You test only what needs to be tested and
    nothing more.

    "If I sniff the User Agent with a list of browsers I already know I
    cannot possibly support due lack of unshimmable features, how faster
    will be on startup time every other browser I am interested on?"

    Who cares how fast you can shoot yourself in the foot? You don't know
    when those bugs might be fixed or what other agents have them and you
    sure as hell can't determine anything from the UA string.

    "Just think about it "

    I thought about it in the late 90's and I haven't changed my mind.

    You think about it as you are just confusing the "issue" (and there's
    more than enough confusion out there already).
     
    David Mark, Nov 1, 2011
    #1
    1. Advertising

  2. David Mark

    Eric Bednarz Guest

    David Mark <> writes:

    > http://webreflection.blogspot.com/2011/10/on-user-agent-sniffing.html


    | At the very beginning

    … was the command line?

    | there was only a major and supported browser, Internet Explorer, and
    | this had something like 80% or more of market share.

    … and that’s why its user agent string starts with ‘Mozilla’.

    Citing the article and voicing an opinion on it, however, seems to
    indicate that you didn’t find it incomprehensible. Congratulations on
    that.
     
    Eric Bednarz, Nov 1, 2011
    #2
    1. Advertising

  3. David Mark

    S.T. Guest

    On 11/1/2011 4:42 AM, David Mark wrote:
    >
    > "I am talking about drawImage, as example, in old Symbian browsers,
    > where canvas is exposed but drawImage does not visually draw anything
    > on the element ... nice, isn't it?"
    >
    > If you can't test whether it drew anything, attempt to draw two
    > identical images at the outset and let the user choose which one looks
    > best. Then you can rightfully blame the user if they end up with empty
    > images.


    lol
     
    S.T., Nov 1, 2011
    #3
  4. David Mark

    Eric Bednarz Guest

    Andrew Poulos <> writes:

    > On 2/11/2011 8:10 AM, Eric Bednarz wrote:
    >> David Mark<> writes:
    >>
    >>> http://webreflection.blogspot.com/2011/10/on-user-agent-sniffing.html


    >> Citing the article and voicing an opinion on it, however, seems to
    >> indicate that you didn’t find it incomprehensible. Congratulations on
    >> that.

    >
    > Why the sarcasm?


    As Chico said, “why a no chicken�

    > Browser sniffing has been advised against for years
    > and your comment seems to imply that DM "supports" the idea.


    How did you get *that* idea? But discussing bad ideas based on some
    incoherent ramblings in Pidgin English published somewhere on the web is
    like discussing emotional intimacy or good taste in fashion based on a
    Jersey Shore episode (I’d warmly recommend to just stop watching in
    those cases; it builds character :).

    --
    λ
     
    Eric Bednarz, Nov 2, 2011
    #4
  5. David Mark

    Bwig Zomberi Guest

    David Mark wrote:
    > Here's hoping that other developers do not read this latest defense of
    > UA sniffing.


    I use Naviscope to hide my useragent. Some websites will not allow me to
    post comments because the spam-control logic thinks that an empty
    useragent string is an indicator of a spam bot.

    Browser sniffing is not easy and the code can be very voluminous.
    http://www.vsubhash.com/article.asp?id=108&info=Really_Ultimate_Client_Sniffer_JavaScript


    --
    Bwig Zomberi
     
    Bwig Zomberi, Nov 3, 2011
    #5
  6. David Mark

    David Mark Guest

    On Nov 3, 12:44 am, Bwig Zomberi <>
    wrote:
    > David Mark wrote:
    > > Here's hoping that other developers do not read this latest defense of
    > > UA sniffing.

    >
    > I use Naviscope to hide my useragent. Some websites will not allow me to
    > post comments because the spam-control logic thinks that an empty
    > useragent string is an indicator of a spam bot.
    >
    > Browser sniffing is not easy and the code can be very voluminous.http://www.vsubhash.com/article.asp?id=108&info=Really_Ultimate_Clien...
    >


    Not to mention a complete waste of time.
     
    David Mark, Nov 3, 2011
    #6
  7. David Mark

    David Mark Guest

    On Nov 1, 7:28 pm, "S.T." <> wrote:
    > On 11/1/2011 4:42 AM, David Mark wrote:
    >
    >
    >
    > > "I am talking about drawImage, as example, in old Symbian browsers,
    > > where canvas is exposed but drawImage does not visually draw anything
    > > on the element ... nice, isn't it?"

    >
    > > If you can't test whether it drew anything, attempt to draw two
    > > identical images at the outset and let the user choose which one looks
    > > best. Then you can rightfully blame the user if they end up with empty
    > > images.

    >
    > lol


    Assuming feature detection/testing is impossible for this problem
    (which I doubt), this is the best you can do. Based on prior idiocy
    from your account, I assume you would prefer to sniff their UA string
    and wrongfully blame the user, browser vendor, etc. if they end up on
    the wrong page.

    Again, much better to show two maps (or whatever) at the outset and
    let the user choose which displays best for them. One click/tap is
    hardly an inconvenience, is it? Now, incompetently redirecting them
    to some other page...
     
    David Mark, Nov 3, 2011
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Lauchlan M
    Replies:
    2
    Views:
    444
    John Saunders
    Aug 17, 2003
  2. Berehem
    Replies:
    4
    Views:
    592
    Lawrence Kirby
    Apr 28, 2005
  3. James

    Browser Sniffing

    James, May 20, 2004, in forum: Javascript
    Replies:
    10
    Views:
    220
    Matt Kruse
    May 21, 2004
  4. Replies:
    16
    Views:
    272
    Richard Cornford
    Sep 7, 2006
  5. RobG

    Browser sniffing - all the rage.

    RobG, Sep 11, 2007, in forum: Javascript
    Replies:
    1
    Views:
    106
    Stevo
    Sep 11, 2007
Loading...

Share This Page