Internet Explorer is a harsh mistress

15 April 2004

So for the past couple of weeks, when I haven’t been out for Pesach, I’ve been working on XSLT scripts for converting an XML description of a workflow, first into HTML, then into SVG images. Unfortunately, I have a bit of a problem now integrating the two results, and perhaps the geeks who read this blog can help me, or can point me at someone else who can help me.

Each workflow has a bunch of tasks. In the HTML file, each task has a nicely formatted box of text describing the various task attributes, with an “id” tag. When one task refers to another, there’s a <a href="http://ropine.com/yesh/article/internet-explorer-is-a-harsh-mistress#TaskName">link</a> that does exactly what you’d expect when I click on it.

Now according to chapter 17 of the SVG spec, any piece of SVG content can be turned into a link. So in the SVG translation of the workflow, every task has a <a xlink:href="otherfile.html#TaskName>link</a> to the corresponding section of the HTML file. Simple, right?

So when I double-click on the SVG file in Windows, IE6, and Adobe’s SVG plugin renders my lovely diagram. When I then click on one of the tasks in the diagram, the browser goes to my HTML page, but doesn’t scroll down to the particular task that I selected.

Yesterday I spent an hour or two applying my Talmudic skills to the SVG spec, the XLink spec, and this crib sheet for embedding SVG in HTML, trying different incantations in my XSLT file, clicking, clicking, clicking, usually with the same disappointing result, sometimes with an even more disappointing result.

Then I tried copying both the SVG and HTML files to somewhere underneath my Web root, opened the SVG file in my browser with http: instead of file:, and clicked through. Voila! Everything works. Curse Microsoft for their not-quite-orthogonal interface. Problem solved, or at least worked around, right?

Of course not.

The fellow who assigned me this project pointed out that my stylesheets, ultimately, will be generating javadoc-like documentation for our clients, and it would be unreasonable to require that in order to read documentation generated from files on their own workstation, they have to run a Web server on that workstation.

The best workaround I’ve found so far is to escape the pound sign in the link, so instead of <a xlink:href="otherfile.html#TaskName>link</a>, the source code says <a xlink:href="otherfile.html%23TaskName>link</a>. This will make the link appropriately follow-able when I double-click on the SVG file in Windows Explorer, but not when I view it as a Web page served from my workstation’s Web server.

I suppose this is good enough for now, but it feels like a standards-violating hack that’s going to stop working as soon as Adobe or Microsoft releases the next version of their software. If I had time to refactor my XSL in a major way, I would probably use the Batik SVG Rasterizer to convert the SVG file into a PNG file, and then use an image map to make the tasks on the graph clickable. However, I have it on good authority that our company is associated with these strange people called “customers”, and extracting money from them is easier when our software is published according to this thing called a “schedule”, so I don’t know if I have time to redo it this way. Does anyone have any easier-to-implement alternatives?

(Well, yes, we could tell our users to get another Web browser, except that Mozilla and Firefox both hang when they try to run the Adobe plugin, the “download SVG-enabled Mozilla” links from the Mozilla SVG Project page appear to be dead, Amaya has a butt-ugly interface and doesn’t render the SVG very well, and Squiggle has a butt-ugly interface and can’t follow links to HTML documents. Give the devil his due: for this purpose, Internet Explorer is the least bad alternative.)

technology