Worst. Tag. Ever.

By Evan — — Web

“Rest assured, I was on the Internet within minutes, registering my disgust throughout the world.”

So far, this week has not been a great week, technology-wise.

First, this week’s award for Kookiest Third-Party Documentation goes to JUnit.org, for their rather creative Javadoc description for TestSuite.createTest(). Umm, guys, the traditional we-don’t-give-a-rat’s-ass-about-our-Javadoc Javadoc would have been something like, “TestSuite.createTest(): Creates a test.” Better to be random and pointless than simply pointless, I suppose.

Second, a special shout-out to Dell for designing their hardware such that you can’t buy 3rd-party memory. Let’s see, $210 for two sticks of PC100 RAM.[1] At least now my system can handle amazing feats of computational wizardry… such as running Netscape and FrameMaker at the same time.

But the real winner of this week’s sweepstakes is the <object> tag. The problems with this tag are well-known. Yes, it has terrible support in modern browsers. Yes, it is the only replacement for the <img> tag in XHTML2… still. And no, the situation is not going to improve significantly until about the year 2006. But you’ve heard about all that. I’d like to share with you my particular episode of <object> tag pain.

The trouble started when I decided to play around with SVG. I dutifully downloaded the Adobe SVG plugin, and soon I was off to the races.

So how do you embed SVG in a web page? In theory, you could do it inline… if you served up a pure XHTML page with the right MIME-type, and a carefully constructed DOCTYPE, to the right browser, on every third Sabbath after Simchat Torah. But even the foolhardy don’t bother with this strategy. No, the accepted method uses the <object> tag, like so:

<object type="image/svg+xml" data="/path/to/image.svg"
    width="400" height="400">
  <img src="/path/to/image.gif" width= "400" height="400" 
    alt="description" />
</object>

The <object> tage embeds the SVG image, while the old-fashioned <img> tag provides a fallback GIF image for older browsers. Elegant, right? Only problem is that this markup crashes my copy of Safari every single time.

The problem is with the type attribute, which specifies the MIME-type of the SVG file. If the attribute is present, Safari crashes. If you delete it, Safari works just fine, but IE 5.2 for Mac no longer displays the object. Apparently IE5.2 needs the MIME-type explicitly defined. (This might also be the case for IE/Win, but I haven’t tested this yet.) Note that both browsers have interesting and quirky behavior. Safari is perfectly happy to display the SVG image if there is no type attribute at all or a totally made-up value (such as “foo/bar“. However, a wrong MIME-type (“text/html“) causes Safari to A) not display the image and B) bring a Finder window to the foreground. (?!) IE5.2, on the other hand, refuses to display the object if the attribute is absent or if the MIME-type is totally made up… but it does display the image if you provide any MIME-type that it understands, such as text/html. Meanwhile, Mozilla displays the image in all circumstances.

But don’t fret! You know what works for all three browsers, every single time, with no crashing or quirks whatsoever?

<embed src="/path/to/image.svg" width="400" height="400">

Yeah, I need a drink too.

1. Seriously, who do these Dell guys think they are? Apple?

19 thoughts on “Worst. Tag. Ever.”

  1. Evan, I’m disconsolate.

    Do the SVG figures on my blog crash your copy of Safari too? Have you just been too polite to complain?

    The MIME-type games are not, IMHO, a viable option. And, no, I just got rid or the last <embed> tag from my web site, so we’re not going back there either.

  2. Yeah, your SVG pictures do crash my copy of Safari. It wasn’t a problem earlier because I didn’t have the Adobe SVG plugin downloaded. And I didn’t see any reason to complain to you about it — the problem is on my end, not yours.

    I should note that I searched the web and the Apple Support website for information on Safari SVG crashes, and I didn’t find anything. So perhaps this problem is unique to my system? Either that or the fraction of Safari users with the SVG plugin is vanishingly small.

    Unfortunately I don’t know how to selectively turn off the SVG plugin for Safari alone. I can turn off all Safari plugins, including Java and Flash. Or I can delete the SVG plugin, thus disabling it for Mozilla too. Neither option is all that appealing, so I guess in the short term I’ll be visiting your blog with Mozilla. Good old stable Mozilla…

  3. So in fact, it’s the adobe SVG plugn that crashes Safari? That sounds quite likely – it certianly has a history of problems with Mozilla. Around about Mozilla 0.9, the adobe SVG plugin was working fine. Then suddenly around 0.9.9 or so, it started crashing with symptoms pretty much like those you describe. It turned out that the plugin has been using an unfrozen interface that changed. Adobe pointed out that there were almost no frozen interfaces at the time, and so programming only to frozen interfaces was impossible. A flamewar promptly broke out in bugzilla, and the result was no usable SVG plugin for Mozilla*, for several years. Now, it turns out that the recent beta of the adobe SVG plugin does play nicely in Mozilla and so, in principle, everyone is happy again. All the details are in the bug report, if you like witnessing grown men sling mud at each other: http://bugzilla.mozilla.org/show_bug.cgi?id=133567

    Now I have no idea why this issue should affect Safari (well other than the fact that Safari contains a lot of Mozilla code), but the situation does sound very similar.

    *Actaully, that’s not quite true. A patched version of the plugin did appear – search the netscape.public.mozilla.svg archives for details. I’ve since wondered who is was that did the patching and why it was never given an official release.

  4. Use IFRAME, it’s much more successful, and doesn’t have the object/embed mess – IFRAME is fine for text/html, XHTML 2.0 support is irrelevant as Safari, IE 5.2 etc. are not XHTML 2.0 user agents.

  6. Object has the big advantage over Iframe (and Embed) in that it allows a fallback to a GIF image for those users without SVG support.

    That’s how Evan got by reading my blog before he got all ambitious and installed the Adobe plugin.

    Out of curiousity, (current versions of) NetNewsWire also use the Webcore rendering engine, so I wonder whether it crashes for you too.

  7. Well, James Graham’s claim that “It’s probably the plugin” made me feel a little better… until I read Jacques’s comment. Feh. So maybe it *is* just me.

    Jim — Thanks for the suggestion. I’ve experimented with IFRAME, but I’ve found it to have some truly weird behavior across multiple browsers. As for XHTML2, don’t worry about that — I was just taking the opportunity to take another dig at OBJECT. OBJECT is a perfectly good HTML4.01 tag, and it should be working. Or at least not crashing.

    Webcore — is SVG in Webcore now? As of this summer it wasn’t. It would be interesting to see if Safari also crashes when rendering SVG natively. By the way, I did a little further testing. and it seems Safari crashes whether or not the data is actually present to be loaded. As long as the type “image/svg+xml” is there, that seems to be enough.

  10. Heya Anne! Nope, I haven’t tested NOEMBED yet.

    But with Halloween coming up, you’ve just given me a great idea for a series of scary posts… on non-standard markup! Shiver in fear of BLINK and MARQUEE! Scream in horror at Netscape 4’s Javascript Stylesheets! Ooooooo…. Booooooo!

    I don’t know about you, but I’m already freaked out.

  11. “Feh. So maybe it *is* just me.”

    Just because you’re paranoid, doesn’t mean people aren’t out to get you.

    I did have some problems previewing posts with SVG figures in Kung-Log. Kung-Log uses WebCore for rendering its previews.

    So maybe there is a crasher bug which is hard to trigger. I don’t get it when viewing the posted blog pages, but I did get it when previewing them.

    I’m not going to think too much about this, because a new version of WebCore is coming on Friday (along with a heapload of other goodies).

  12. I still can’t figure out why current-browser non-support of OBJECT is supposed to be an issue with the deliberately-incompatible XHTML 2, which won’t work in any of today’s browsers no matter what.

  13. It is not an issue, it is humor :). Standards are _not_ supported and ‘ugly’ things like embed have total support.

    (Evan, ever thought about the label element? It doesn’t make your browser crash :). It just makes forms easier to use)

  14. Anne, I have indeed. In fact I’ve also been thinking about a great huge laundry list of things, such as:

    * skip nav
    * access keys and tabindex
    * providing site navigation through the link element (someday, somehow, this will pay off, and not just for weirdos who use Mozilla)
    * allowing a valid subset of HTML in comments (very important for journals that discuss markup issues)
    * switching to an individual entry format(without clobbering my old URLs)
    * providing individually-linkable comments (a result of the change above)
    * revamping the CSS layout to ditch my partial NS4 support (right now, the layout looks sorta okay in NS4, at the price of cramping my overall layout options)

    And possibly learning something about graphic design. Honestly, how *can* you people stand to come and visit and stare at all this horrible green? It’s truly beyond me.

    I had also been thinking about switching to XHTML and application/xhtml+xml, but for now that’s off the table. I racked my brain trying to come up with technologies that I could use in this site that would justify my decision. But that’s a pretty backwards form of analysis. Besides, I couldn’t come up with anything. Inline SVG? Client-side XSLT? Err, no.

  15. Oh Evan, you know you want MathML really. I mean, how can you write about professional humour (https://www.goer.org/2003/Sep/index.html#09 ) without mentioning the possibilities of the Mathematical Limerick ( http://euclid.trentu.ca/math/courses/110/2002-2003/MATH110-limericks.html ) and, as that site shows quite nicely, html just doesn’t cut it. Just think of all the oppertunities to provide your readers with rhyming integrals and other such witticisms that you’ll have to pass by.

    (Uh, but seriously, html in comments sounds good. Any chance of the comments box being wider while you’re at it?)

  16. There are two obvious solutions that might work. Did you try:

    <!– KHTML browser –>
    <object data=”/path/to/image.svg” width=”400″ height=”400″>
      <!– Other browsers –>
      <object type=”image/svg+xml” data=”/path/to/image.svg” width=”400″ height=”400″>
        <!– fallback for older browsers –>
        <img src=”/path/to/image.gif” width= “400” height=”400″ alt=”description” />
      </object>
    </object>

    You could also use change the DTD and use embed:

    <!DOCTYPE html
      PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd“
      [
    <!ELEMENT embed EMPTY>
    <!ATTLIST embed src CDATA #REQUIRED width CDATA #REQUIRED height CDATA #REQUIRED>
    ]>

  17. There are two obvious solutions that might work. Did you try:

    <!– KHTML browser –>
    <object data=”/path/to/image.svg” width=”400″ height=”400″>
      <!– Other browsers –>
      <object type=”image/svg+xml” data=”/path/to/image.svg” width=”400″ height=”400″>
        <!– fallback for older browsers –>
        <img src=”/path/to/image.gif” width= “400” height=”400″ alt=”description” />
      </object>
    </object>

    You could also use change the DTD and use embed:

    <!DOCTYPE html
      PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd“
      [
        <!ELEMENT embed EMPTY>
        <!ATTLIST embed src CDATA #REQUIRED width CDATA #REQUIRED height CDATA #REQUIRED>
      ]
    >

  18. Geez. How obvious can you get?!?!

    That’s EXACTLY what I would have done…

    (Well, maybe I should learn more than basic HTML before I make statemenst like that.)

    🙂

Comments are closed.