[jQuery] Re: 32-bit PNG, Internet Explorer & jQuery's Animate Opacity
"2. When I try to apply animate-opacity to (particularly, I'm
about a 32-bit PNG with transparency) Internet Explorer (any ver.)
makes its edges ugly."
This is not related to jQuery - unfortunately, it is the way IE7 works
(breaks) when applying Alpha filters to any 32 bit PNG.
For example:
Will have the same end result without the use of any Javascript
library.
For a full explanation read:
http://blogs.msdn.com/ie/archive/2005/04/26/412263.aspx
Particularly the section titled: "There are also a couple of
limitations worth mentioning"
On Jun 19, 9:46 pm, "Y.N.T." wrote:
> Hello!
>
> I discovered two problems in jQuery work with IE 7:
> 1. When I try to apply animate-opacity to element no effect
> comes in IE 7 or 8 (but in 6 version it works!).
> 2. When I try to apply animate-opacity to (particularly, I'm
> about a 32-bit PNG with transparency) Internet Explorer (any ver.)
> makes its edges ugly.
>
> My blueprint:
>
> $('#-div-or-img').hover(function(){
> $(this).animate({'opacity' : 0.5}, 400);},
> function(){
> $(this).animate({'opacity': 1}, 400);
> });
>
> There are no problems with Opera & FF.
>
> As a matter of fact, my question consists in how to get over these
> difficulties...
>
> P.S. Known jQuery's ifixpng.js doesn't help as well as IE's CSS-filter
> hacks.
[jQuery] Re: jQuery source code readability
Hi John,
Thanks for the reply :) I was hesitant posting as I wasn't sure how it
would be perceived but I appreciate the response.
I'm going to spend some more time going through the source and
hopefully between any work done at the developer end and familiarising
myself with the style, there might be a tipping point where it clicks.
I'd like to be able to understand and contribute back to any framework
I adopt, so readability is a priority. I understand though, that there
are differences of opinion about what is a preferred style, so that
may be the case here.
Congrats to the jQuery team on the launch of the UI project.
Cheers,
Ian
On Sep 17, 1:34 am, "John Resig" <[EMAIL PROTECTED]> wrote:
> I've already done some work to improve the readability of variable
> names, you'll see the results of that in jQuery 1.2.1.
>
> But, as far as the second and third points go, we don't plan on making
> changes in that respect, any time soon.
>
> In the future, you should makes posts like this to the jQuery dev
> list:http://groups.google.com/group/jquery-dev
>
> --John
>
> On 9/16/07, kuralj <[EMAIL PROTECTED]> wrote:
>
>
>
> > Hi,
>
> > I really like jQuery's API but find the libraries source code
> > difficult to read.
>
> > For example:
> > - Short var names
> > - Ommission of braces and heavy use of shorthand if(), for() blocks
> > - Nested ternary operators, some of which transcend several lines
>
> > Does anyone know if there are plans to improve the readability of the
> > source code going forward? Am I alone in thinking the source code is
> > difficult to read? (I don't mean it's overall construction, I like
> > the methodology, just the fine grain stuff mentioned above)
>
> > The main problems I have are that the short var names make it hard to
> > follow the code and the shorthand block statements make it tedious to
> > insert logging / debug statements into the core when deconstructing
> > how something works.
>
> > With javascript packers, is it really necessary to have uncompressed
> > source code like this?
>
> > if ( m && (m[1] || !c) ) { ... }
>
> > return ( t.constructor == Array || t.jquery )
> > ? jQuery.inArray( a, t ) < 0
> > : a != t;
>
> > Please don't think that I'm having a dig at jQuery here :) I'm just
> > curious what others think as I find this to be the biggest reason why
> > I haven't utilised the library on any large scale work as yet.
> > Essentially, I'm reluctant to rely on a library that I find hard to
> > read and deconstruct.
>
> > Cheers,
>
> > Ian
[jQuery] jQuery source code readability
Hi,
I really like jQuery's API but find the libraries source code
difficult to read.
For example:
- Short var names
- Ommission of braces and heavy use of shorthand if(), for() blocks
- Nested ternary operators, some of which transcend several lines
Does anyone know if there are plans to improve the readability of the
source code going forward? Am I alone in thinking the source code is
difficult to read? (I don't mean it's overall construction, I like
the methodology, just the fine grain stuff mentioned above)
The main problems I have are that the short var names make it hard to
follow the code and the shorthand block statements make it tedious to
insert logging / debug statements into the core when deconstructing
how something works.
With javascript packers, is it really necessary to have uncompressed
source code like this?
if ( m && (m[1] || !c) ) { ... }
return ( t.constructor == Array || t.jquery )
? jQuery.inArray( a, t ) < 0
: a != t;
Please don't think that I'm having a dig at jQuery here :) I'm just
curious what others think as I find this to be the biggest reason why
I haven't utilised the library on any large scale work as yet.
Essentially, I'm reluctant to rely on a library that I find hard to
read and deconstruct.
Cheers,
Ian
