@Dave
> If this problem has a good fix, it should be fixed. There are several
> cases that will break differently in IE when this proposed fix is
> applied. It's not achieving consistent cross-browser behavior. There
> may be a solution out there still, and if someone has one they should
> post it.
I haven't tested it, but did suggest an 'extra check' for opacity in
the sample I gave. Assuming jQuery reports the curCSS correctly, this
would seems to address the 'snap' issue you described...
if ($E.css('filter') && $E.css('opacity')==1)
FYI, I ran across another example of this issue today. I created a
test page with both a static and popup ui.datepicker. When seen side-
by-side in IE7, the popup (animated) datepicker text is obviously not
anti-aliased as the static version is...
http://layout.jquery-dev.net/demos/datepicker.html
All UI Widgets using animation look poorer than necessary when used in
*the most common browser in the world*. So if this won't be addressed
in the jQuery core, then every UI widget using animated elements
should be patched to address it. Such a simple, common problem should
not be allowed to affect UI Widgets IMO.
/Kevin
On Sep 30, 2:46 pm, Dave Methvin <dave.meth...@gmail.com> wrote:
> > I'm not sure why this 'fix' should be added to fadeOut? It seems most
> > applicable to fadeIn and fadeTo.
>
> Whoops, right. So the problem would be that in IE only, .fadeTo
> ("slow", 1) makes the element completely visible and then pops to 50%
> opacity based on the stylesheet when the element's filter property is
> removed.
>
> > There is no way to fix anti-aliasing if the user *chooses* to use
> > opacity since this is a browser issue,
>
> If the user chooses to set a 50% opacity in the stylesheet that should
> work properly in IE as well, right? A fix for antialiasing shouldn't
> break something that currently works properly across browsers.
>
> > Calling it an IE-bug doesn't make it go away. This is a cross
> > browser issue, pure and simple.
>
> If this problem has a good fix, it should be fixed. There are several
> cases that will break differently in IE when this proposed fix is
> applied. It's not achieving consistent cross-browser behavior. There
> may be a solution out there still, and if someone has one they should
> post it.
