Gotta love IE’s little surprises. I’m not sure if this is a known bug, in fact I’m not even sure if this is a bug at all, but I thought I’d write it up for future reference.

One of the challenges of laying out pages in HTML is that there’s no native way to associate a caption with an image so that the caption’s width is constrained to the width of the image.

In order to accomplish this, we wrap both the image and the caption in a div with the width set to be exactly the width of the image. Because both the image and the caption are inline elements, this should force the caption below the image and cause the text to wrap appropriately for the size of the image.

Here’s some test code to demonstrate what I mean. Note: I’ve added the red border in order to make the div easier to see.

<div style="width:100px;border:1px solid red;">
<img src="caption-bug-test-image.gif" width="100" height="100" alt="caption bug test image" /><em>This is the caption for this test image</em>

</div>

Now in Firefox, the code above looks just like we want it to:

However, Internet Explorer interprets the HTML above in a vastly different way:

Because there’s no whitespace between the img tag and the caption (surrounded by em tags), IE chooses to break the line after the first word in the caption rather than before. The best (read: most annoying) part is that if I modify the source above to include a newline in between the image and the caption like so:

<div style="width:100px;border:1px solid red;">
<img src="caption-bug-test-image.gif" width="100" height="100" alt="caption bug test image" />
<em>This is the caption for this test image</em>
</div>

…then IE behaves as expected (or at least closer to expected):

Adding a <br /> tag between the image and the caption also works in both IE and FF without adding an extra line between the image and the caption, but that’s an annoying thing to have to enforce. Might make sense though considering that an image is an inline element.

Of course in this context we’re essentially treating the image like a block level element. So another solution would be to create a class for our image container divs that sets a CSS display:block; rule for any image inside the div. Except sometimes we include multiple images (side by side) inside the div. Oh shucks.

This post first appeared on From the Belly of the Beasts, a weblog from some of the people who build O’Reilly websites.

Powerbook laser-etched with the famous O’Reilly tarsier.

[Via Make]

So cool. Can y’all do my Thinkpad next?

This post first appeared on From the Belly of the Beasts, a weblog from some of the people who build O’Reilly websites.

Keith Casey: I for one am stunned by O’Reilly’s disregard – either through malice or negligence – for their readership.

This post first appeared on From the Belly of the Beasts, a weblog from some of the people who build O’Reilly websites.

From the mailbags this morning, I got the following bug report:

You have two broken links to subscribe to RSS feeds. In both cases, my browser tries to open/save to my desktop rather than open the rss feed in a browser window.

My response, though nothing new, I thought some might find interesting, at least for future reference.

“We return our feeds with the correct MIME type for the syndication format. In the case of RSS 2.0 that would be application/rss+xml, per RFC 3023.

“This is important because it means your browser should able to use this information to determine the file format and launch the appropriate helper program or plugin (e.g. a newsreader) to read the file. We realize in practice this may not be the case. Internet Explorer has not been revised in over 4 years and Firefox requires some additional configuration in order to display application/rss+xml files in the browser (but the latter can be done).

“Some people advocate sending RSS feeds out with a more generic text/xml MIME type, which most browsers natively know how to parse and display. However, doing so would make it impossible for browsers (and more importantly, newsreaders) to know what sort of XML file you’re downloading and what helper application to load.”

This post first appeared on From the Belly of the Beasts, a weblog from some of the people who build O’Reilly websites.

It’s both gratifying and annoying when I get bit by an IE bug (that I’ve previously heard about) for the first time.

A coder innocently places a left float into a container box, and uses a left margin on the float to push it away from the left side of the container. Seems pretty simple, right? Well it is until it’s viewed in [Internet] Explorer for Windows. In that browser the left float margin has mysteriously been doubled in length!

The solution? Put display: inline; on the float.

This post first appeared on From the Belly of the Beasts, a weblog from some of the people who build O’Reilly websites.