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.
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.
At first glance, everything seemed to work (in Firefox at least) but today I discovered the first chink in the wall, which isn’t so much a bug in the technique as a problem in Firefox (I think), and one that I’ve seen crop up in different incarnations.
The problem being that when Firefox hides content that’s overflowed, it doesn’t completely obliterate it. Depending on what sort of focus the clipped block has, a scroll wheel can actually expose the hidden content as if the block had overflow set to auto or scroll.
The bug became abundantly clear when I used a link that linked down to a target anchor in the same div. This is how it looks before you click the link:
And this is how it looks after:
You can see that all three columns (all of which are just left floated divs, which may be part of the problem) have scrolled up in tandem to the level of the header.
In Internet Explorer I’ve got a completely different problem. It appears that IE is hiding the overflowed content, but it’s using the bottom of the viewport to determine where to stop displaying content. So no scrollbar shows up, but the footer div gets overlayed by the “extremely tall but clipped columns.”
Argh!
Anyways, here’s the source code for the examples above: equal-height-columns.html. Comments are always welcome.
This post first appeared on From the Belly of the Beasts, a weblog from some of the people who build O’Reilly websites.
Got bit by the IE id="tags" printing bug on Java.net today. Eric Meyer (of CSS fame) describes the bug on his blog here: Reserved ID Values?
Basically if a page has an html tag with with id="tags" as an attribute, when you try to print in IE you’ll get a fun error message:
And you can’t print the webpage.
Of course one of articles on Java.net had just that, so I removed the unnecessary id="tags" and lo and behold…the problem did not go away. So it took me some time to discover that name="tags" is also persona non grata in IE, something that hadn’t previously been described in Eric’s post.
So the moral of the story is, avoid using tags as the id or name of any HTML tag.
This post first appeared on From the Belly of the Beasts, a weblog from some of the people who build O’Reilly websites.
