Just as an FYI, in 1.3.2 (haven't looked at what is done in 1.2.6),
this is happening at lines 808-811:
var computedStyle = defaultView.getComputedStyle( elem, null );
if ( computedStyle )
ret = computedStyle.getPropertyValue( name );
Note that in IE, getting the display at this point returns 'undefined'
as IE doesn't use getComputedStyle.
The span created by jQuery returns block for display since it is using
the W3C DOM 2 method above (as does a span created through normal DOM
methods):
console.log(document.defaultView.getComputedStyle
( document.createElement('span'), null ));
Obviously after appending the created element to the document the
display returns 'inline'. If this is a bug in jQuery, then it's a bug
in the W3C DOM Level 2 DocumentView interface as well. Perhaps someone
else can provide more explanation about why the interface returns the
values it does?
On Mar 2, 5:40 am, sliver <sliver2...@gmail.com> wrote:
> Bump...
>
> Is this an intended change in 1.3.2? I don't see anything about it in
> the release notes...
>
> On Mar 1, 1:59 pm, sliver <sliver2...@gmail.com> wrote:
>
> > Is this a bug in 1.3.2 then?
>
> > On Mar 1, 1:16 pm, Frederik Ring <frederik.r...@gmail.com> wrote:
>
> > > Looks like this is a 1.3.2 issue I think. Just tried it with 1.2.6 and
> > > it returned inline in both cases.
>
> > > On Mar 1, 6:31 pm, sliver <sliver2...@gmail.com> wrote:
>
> > > > Im not sure if this is intended, but it leads to some unexpected
> > > > results:
>
> > > > console.log($('<span/>').css('display')); --> 'block'
>
> > > > According to W3, span's default display value is inline. Any reason
> > > > for the switch?
>
> > > > Also, say you have a class definition in a style sheet:
> > > > .inline {
> > > > display: inline;
>
> > > > }
>
> > > > console.log($('<div/>').addClass('inline').css('display')); -->
> > > > 'block'
>
> > > > I would expect it to report 'inline'...
