Why not just put the tag above the script tag? This way you wouldn’t have to worry out the differences between text/html and application/xml.

Is there something obvious I’m missing here?

Thanks for the great informative post/thread btw.

It seems like if the script src is added to the script element AFTER the script element is appended to the div, IE doesn’t crash.
So, the setTimeout first argument should be: “document.getElementById(‘wedje_div_yourcompanyname’).appendChild(s);s.src=’https://mikeindustries.com/blog/scripts/sleepywidget.php’;”.

Don’t forget to remove the original s.src=… before the setTimeout call.

Thank you :)

We are looking to distribute widgets to clients. Not every page view will use our widget, but only when the consumer directly interacts with the widget. Therefore, to limit each trip to our server for the basic widget draw, we want to have the HTML live in the distributed .js file. This way only when a consumer interacts with the widget will AJAX API calls come to our servers; otherwise it is all on our clients servers?

So, deployment is providing the snippet _AND_ the .js file which we ask them to host on their system.

Again, the .js file contains the widget display, defaults, etc and the API calls to our systems.

Is this how other people are doing things? What are some alternatives to think about.

thanks!

Any fix for this?

I tested this and less than 5 minutes in IE5 had crashed twice.

The original version of WEDJE (which is to say, the version we cooked up last night), wrote the container div out as part of the standard HTML, so you could always do that I suppose.

I’m pretty sure you need some sort of tag with a unique id on the target site to reference with the external script — that DOM hook is what allows the browser to go back and deposit the external script’s embedded content after it’s moved on to render the rest of the page.

Here’s one of my test pages that demonstrates WEDJE + an external innerHTML script not working in an XHTML as XML doc with a .xhtml extension

Here’s the exact same code working with a .html extension

Fortunately, the code thats sitting on the end user’s site doesn’t use innerHTML. So if you were concerned about putting your widget on sites created by XHTML as XML claquers, you could use a different (and slower) insertion method in the external script.

I’ll do some more tests to see if I can get WEDJE working on XHTML as XML by not using innerHTML in the remote script. Thankfully I think there are few sites out there that serve up pages with .xml or .xhtml extensions.