On 11/29/06, Peter Michaux <[EMAIL PROTECTED]> wrote:
> If you say "Aside from . . ." then it seems that you also think that
> this code needs some attention.

Sure, the lack of a version check might be a problem if the WebKit
team changes the behavior in a future version. On the other hand,
putting a known version number will definitely cause it to break if
the WebKit team doesn't fix it in the next Safari update, so I can
understand why it's done. I'll admit that I'm not familiar enough with
this issue to tell whether the changes I mentioned are necessary or
not, hence the qualification before the suggestions.

It's my personal preference to check rendering engines for gecko and
webkit to account for alternate browsers based on those platforms, but
I don't consider code "poor quality" if the author doesn't feel the
same way. One of these days, I'll get a test environment set up like
Alex Russell's [1] so I can definitively fix issues like this. Until
then, I'll just have to live with the code written by people who did
test and fix the issues and trust the community built around the
framework for bug reports.

[1] http://alex.dojotoolkit.org/?p=588

> navigator.userAgent should be avoided like the plague.

I figured this was your gripe. It is wrong. You should most certainly
do object/feature detection when deciding whether a browser is able to
perform a specific task. The article you linked describes exactly the
reasons why and MochiKit certainly does this .

The code you pasted above does not do this. It corrects a known error
in a particular pair of user agents. There is only one way to fix
errors that you know occur in a particular user agent and that is...
checking the user agent string. You can't do this with object/feature
detecting because the browser is lying to you.

In theory someone could change their correct user agent to a specific
older version of a non-working useragent and incorrectly get the fix,
but in this day and age, I don't believe UA switching is widely done.
In any event, UA switchers get what they deserve. If you think this
solution is unnecessarily ugly, you haven't been doing web development
long enough.

Regards.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups 
"Ruby on Rails: Spinoffs" 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/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to