Simple enough to fix -- just don't appy a doctype. If you're not using XHTML, it doesn't matter. The bigger question is why use one in the first place? If it's a small amount of content (like a web banner) just dynamically include it. If it's not, it probably shouldn't be in an iframe anyway. Just my .02 of course. :-)

As for doctypes... Adding them can drastically change how a browser views a page, and while the differences occasionally make immediate sense, that isn't often the case. I was doing the GUI prototype for a piece of online banking software and had a lot of problems with certain CSS things, and some stuff with table borders... I dont remember what all it was, but it made no sense, the code did not indicate what it was doing... after much messing with it, I deleted the doctype and it behaved correctly. Since it was going to be translated into xhtml and xslt and all that fun stuff, it had to have a doctype though. It took a good bit of experimentation before I found one that displayed as intended, across all the browsers that were reasonably standardized (ie, it doesnt look so hot in Netscape 4.7, but it's usable, in mozilla/netscape, opera, IE, omniweb, etc it looks fine and works well. [rant]I really wish Netscape/Mozilla would just let the bloody bordercolors work, though. Who is that going to hurt? [/rant])

-Posted by JC on January 2, 2003 05:08 PM

"The bigger question is why use one in the first place?"

Well, mostly to deal with the issues you mentioned. If I use a doctype declaration, I expect that the validating HTML I write will be rendered in expected ways based on the agreed upon standards. No doctype means arbitrary doctype. It's the arbitrariness that I'm attempting to avoid.

As for the iframe, no doctype gave me the results I expected to get, and the content that will live in there should be ok (ie, nothing more that simple html with some light css).

-Posted by Dan on January 2, 2003 07:32 PM

Actually, I meant why use an iframe in the first place.

As for getting the doctype to perform as expected, there are a lot of subtle variations in the basic doctypes that seem to produce different results.

The pages that helped me out were:
http://www.mozilla.org/docs/web-developer/quirks/doctypes.html
and
http://validator.w3.org/detailed.html

-Posted by JC on January 2, 2003 08:03 PM

Oh, gotcha. The iframe is to help increase the density of info on the page without taking up too much real estate. I think you'll like it (hopefully).

Thanks for the doctype URLs.

-Posted by Dan on January 2, 2003 08:27 PM

This isn't flamebait, but I thought iframes were bad (almost as bad as regular frames) from a usability standpoint? I'm writing an app now (a mail client) that uses frames to give the standard 2 or 3 pane mail view, but I'm also writing a version that doesn't use frames because some people seem to freak out over them.

Thoughts?

-Posted by Eric on January 3, 2003 12:52 AM

No worries on flaimbait. I agree, frames are bad. But frames are not 100% bad, and even less bad when they are iframes, but only when used responsibly.

The thing I don't like about normal frames is that getting back to a sub page that lives in a frameset (let's call it a "framelet") is often difficulty or impossible. Sure you can usually open that framelet in a new window, and grab the url, but you are stuck with that page without the UI and content elements that are supposed to surround it. This often reduces the value of the framelet and makes me says "Frames suck!"

I think iframes are much less offensive, and in some cases useful because they can be used a supplemental document that serves that page is included in. In this scheme, the URL of a given resource can be bookmarked, and the iframe included in that resource still appears as normal. iframes and frames attack the same issue, but from opposite ends.

In my case, where I'm using iframes, the material in the iframe will be useful, but not likely to be something you would want to bookmark directly. But, even if you did want to do that, you could, and that content would be able to stand on its own and be a useful resource (and that's the part about using frames, or rather iframes, responsibly).

Now, think about your email app and how it might be more useful/useable if you used iframes instead of frames. Would it be better or more easily developed?

[btw, this is the best thread this site has ever seen. keep it comin']

-Posted by Dan on January 3, 2003 09:31 AM

Hmm. Generally speaking, I've seen iframes used (and used them myself) almost exclusively when it was necessary to include a remote banner ad or some other sort of content window on a static HTML site.
The only other place I've seen them where it was really a good idea is in some message board systems, when you're replying, and it places the post and its comments into an iframe window in reverse order to reduce clutter. That fails gracefully by displaying all the content inline if iframes don't work.

Oh, and some webmail clients use it quite nicely, including AOL's (Dan, if you work with those people, please tell them to stop screwing up a finished product... every time it starts to work reliably they change something and it breaks... and to test it more under omniweb, where it has had many problems with the login after timeout, and doesn't have a log out button)

If you have a dynamic site and the content is locally hosted, it's easiest to just include()(whatever the syntax is for your particular language of choice) it dynamically. If it's remotely hosted, even then it's pretty easy to include (at least, in ColdFusion and PHP which are the languages I know best) although you might have to strip some HTML from it.

As for the Frames Suck issue... most of the people I've experienced who bitch about the entire concept of frames will spout the 'not all browsers support frames' argument, which was valid back when I started learning HTML, but is BS now. If someone's using Netscape 1 or 2, they're bloody well used to nothing working properly and it's not going to be a surprise. I like iframes for what they're useful for, but I'd only use them when they're hte best possible solution to the problem. I don't generally like to use frames for customer/client/etc websites, but there are some intranet and web applications that they're incredibly useful for, like reporting tools that generate very long pages... no need to scroll up to jump to another part of the site, because the navigation isn't up at the top, it's in another frame off to the side (Quest software's Funnel Web Analyzer product is a great example... and a great web log analysis tool, btw)

Oh, and they're fantastic for bumping up the number of pageviews when whether or not your sections of the intranet get to remain linked from the homepage. Our golf league site has 3 frames plus a frameset, so the first time someone clicks it gets 4 pageviews instead of one. Not that that was intentional, the guy who maintains the golf league site uses frontpage and that's just how it interpreted his desires... but it's working to keep him prominent even in the off season.

-Posted by JC on January 3, 2003 12:46 PM

4

-Posted by on February 19, 2003 09:42 PM

Great Thread! Solved my problem w/ the vert scrollbar no prob.

-Posted by Travis Lloyd on March 1, 2003 11:02 AM

Hi There,

I found the horizontal bar problem out when I moved to ie 6.. on http://www.theimpclub.co.uk

all due to the difference IE5.5 and IE 6 interpret the scroll=auto artibute... IE6 does not follow 'auto' setting to scroll=yes behaves like auto if the contect is not wide enough to need a horizontal scrollbar...

oh well, just use NS7

Si

-Posted by si on June 8, 2003 05:00 AM

I've been pulling my hair out over this one for weeks, thanks for your post!

-Posted by appel on June 24, 2003 06:49 AM

Happy to help.

-Posted by Dan on June 24, 2003 09:44 AM

Interesting, a blogger with the same problem has a different solution...

Instead of fooling around with the Doctype stuff, I actually found an easier solution. If I apply a body style that has a width of 95% on the iframe content page, I have no scroll problems!!

-Posted by Dan on October 10, 2003 04:58 PM

Thanks... your suggestion to eliminate the doctype in the iframe content solved the problem. I can still declare a doctype on the page containing the iframe. Cool!

I use iframe more and more in web apps as a way to display resultsets. One thing that helped me feel comfortable using them is that I can have them size to the width of the page.

[inside my stylesheet]
#viewData {
margin-left: 4px;
margin-right: 4px;
text-align: left;
height: 250px;
padding: 0px;
background-color: #FFF;
border: 1px solid #666;
overflow: auto;
}
#viewData iframe {
border: none;
width: 100%;
height: 100%;
}

[inside my html code]
<div id="viewData">

< iframe src="checklist_edit_details_employee.shtml" id="dataTarget" name="dataTarget" marginHeight=0 marginWidth=0></iframe>

</div>

Then inside my iframe I have a table sized to 100%.

Thanks again!

-Posted by Aaron Donsbach on March 17, 2004 12:03 PM

Ah... sense and useful information, and very nicely presented. Thank you very much - I've been wrestling with the scrollbar issue and had independently hit upon

body { width: 95%; }

as my fallback plan. Removing the doctype is not an option for me - I'm writing a WYSIWYG editor with the editable content (which could have any doctype) displayed in an iframe. Don't think there's much argument that this constitutes a valid use of iframes...

-Posted by Tim Down on May 6, 2004 04:16 PM