Results from http://smithies.org/cpks/test/

IE = v:8.0.6001.18783
IE64 = v:8.0.6001.18783 64-bit Edition

Testing both versions on a 64-bit system.


IE64 With no plugin (ASV doesn't run on 64-bit): I count 21 raster images and
the browser is stable;


IE with plugin: I get this error message:
________________________________________
Message: HTML Parsing Error: Unable to modify the parent container element
before the child element is closed (KB927917)
Line: 0
Char: 0
Code: 0
URI: http://smithies.org/cpks/test/
________________________________________
Then the page breaks and the loading hangs. No svg images displayed, 3 png. At
that particular point these images are present in a previously empty cache, in
the order:
cpkslogo.svg
shriek_y.png
head-yel.gif
hourglas.svg
hourglas.png
question.svg
question_grey.png
redx0000.svg
redx0000.png


IE With no plugin: I count 21 raster images and the browser is stable.


I took the liberty of using your svg and png images I found in the cache to
build another test, where I also added three more svg/raster sets for a total of
23 images.

http://www.dotuscomus.com/svg/object_tag_test/object-tag.html

In ALL cases and configurations IE renders all the raster images.

The svg images are rendered only in local mode by IE and never by IE64.

Reults show that IE always loaded and displayed all rasters except with your
test page.

At a glance your test file seems to have three relevant differences with test
file "object-tag.html":
1) The <param name="href" value="#"/> of the first <object> tag (the logo)
2) The style sheet
3) corners0.js

I reproduced as a test the first point in test file "object-tag.html". That
causes the logo (svg, local) not to render but doesn't prevent the others from
rendering, and there is no Parsing Error warning like the one above. If I may
suggest, I would try taking out corners0.js and take it from there.

In any case what I make of it is that the fallback raster content is rendered,
but given that replacing the <object> tag by <embed> programmatically fails,
given that svg's in <object> do not render except if in local mode, the MS team
didn't quite make it yet with the <object> tag. But there is progress.


To go back briefly to jQuery,

> Well, I hereby surprise you. They do. And yes, the ability of javascript
> frameworks to break the expected behaviour of native types IS scary.

If you are really, really sure that you encountered a situation where you
couldn't use the 'for-in' loop on an array, like for example:

var fruits = ['banana','cherry','pear'];
...
for (var f in fruits) {
alert(fruits[f] + ' is a fruit');
}

without having invoked in the meantime an extension method like fruits.toJSON(),
if one of those alerts prints "whathever-toJSON-returns is a fruit", that can
only be called a malfunction and you should file a bug report 'cause it's
breaking away from the specification.

Domenico


--- In svg-developers@yahoogroups.com, "CPK Smithies" <c.1@...> wrote:
>
> > The script shouldn't work anyway because you can't append fallback
> content elements to <embed>. HTML 5 doesn't allow that either, if I read
> well. <
>
> Let us agree that the script would not work (or even exist) in an ideal
> world. However, in the actual world, we are working with browsers which
> violate all sorts of important metaphysical principles (e.g. that
> "ought" implies "can"). From the practical point of view, then, and
> without passing any value judgments, it does appear that IE executes (or
> not) its fallback logic on the object elements. If the decision is to
> fall back, then it seems the object elements are ignored; otherwise, the
> child elements (except param elements) are eliminated. So when the
> script runs and the object elements are converted to embeds, all is in
> fact well, except for the erratic loading of the object/fallback data.
>
> > Jquery, Ext.js and others all add methods to the Array prototype, but
> I'd be surprised if they added elements to arrays. If using jQuery one
> cannot loop through array elements using 'for in' then that's really
> scary! Maybe you mean objects, as class instances, where you get all
> (almost) the enumerable properties... <
>
> Well, I hereby surprise you. They do. And yes, the ability of javascript
> frameworks to break the expected behaviour of native types IS scary.
>
> > I just tried 8 <object> tags with SVGs (+ scripts and SMIL) and IE8
> runs all of them fine for like 5 secs and then crashes. With no plugin
> it loads the fallback png's fast. <
>
> That's interesting. Try the example on my site, with 21 SVG objects:
>
> http://smithies.org/cpks/test/
>
> What was your score? I'll bet it wasn't 21! (This example does not use
> the script at all. The sole purpose of the script was to get IE to
> render the SVG backgrounds transparent.)
>
> Regards,
>
> Christopher S.
>