Even though there is only few purely visual issues, there is some
(such as the VML ones pointed above), and there is no point giving the
developer indications about the browser and its version if a browser
can run an alternate rendering engine...

On Mar 29, 8:45 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Mar 29, 2:27 pm, "Jeffrey Kretz" <jeffkr...@hotmail.com> wrote:
>
> > While I am completely behind feature detection as a solution and am using it
> > wherever possible, it is important to realize that feature detection doesn't
> > always identify the ability of the browser to render the VISUAL layout of a
> > page correctly.
>
> And if there is no way other than visually inspecting the results to
> see if they worked, then that is a case where feature detection will
> not work. There are fewer of these cases than most people think.
>
> > As an example, take the broken implementation of PNG alpha in IE6.
>
> This is one of the few cases mentioned above. Two typical approaches
> are:
> 1) Refactor out the dependency on PNG alpha. Design to the lowest
> common denominator using GIFs.
> 2) Use IE's cc mode to include an additional style sheet that targets
> the specific browser with issues.
>
> In these cases, it is often more problematic for a user to see a
> broken PNG than to see an ugly GIF, which is why many users opt for
> #1. But doing #2 is simple and doesn't depend on user-agent sniffing.
>
> > Another example is for "zones" in my CMS.  I am using the min-width and
> > min-height CSS property while in design mode.  These CSS attributes are not
> > supported by IE6, so when I detect that client, I use alternate means to
> > render the design mode.
>
> Same solutions apply. Still no need for sniffing the user-agent.
>
> > A few months ago there was a jquery user having troubles animating
> > relatively positioned elements with percentages. {left:"-=25%"} and
> > {left:"+=25%"}, etc.  It wasn't working the same in all browsers.  The
> > FUNCTION worked, but the rendering on the screen was broken.  Would it not
> > be correct to detect the browser and provide an alternate animation to
> > ensure the correct rendering?
>
> I don't know of the exact situation, but I would suspect that the real
> issue may be fixable, and probably would not need browser sniffing to
> figure it out. Especially if something is measurable, you can usually
> do a test for it. The guys over at comp.lang.javascript are especially
> good at detecting and correcting for quirky behavior in browsers
> without the need for sniffing at all.
>
> Matt Kruse
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to 
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to