Loading ...
Sorry, an error occurred while loading the content.

Lots of SVG objects in IE (was Re: Inline SVG and CSS in IE)

Expand Messages
  • Domenico Strazzullo
    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
    Message 1 of 14 , Jul 6, 2009
    • 0 Attachment
      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.
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.