Using Inline Frames (iframe Elements) To Embed Documents Into Html

Using inline frames (iframe elements) to embed documents into HTML documents

Page 1 of 13

IT and communication - Web authoring and surfing:

Using inline frames (iframe elements) to embed documents into HTML documents An inline frame ("floating frame") is a construct which embeds a document into an HTML document so that embedded data is displayed inside a subwindow of the browser's window. This does not mean full inclusion; the two documents are independent, and both them are treated as complete documents, instead of treating one as part of the other. Support to inline frames is not universal, but with a properly designed "graceful degradation", they can be used in authoring for the World Wide Web. However, there are serious problems with printing documents containing them. This document also discusses the legal side of the matter as well as the details of the iframe element as defined in the HTML specifications, on one hand, and as implemented on IE, on the other. Content: The basics | Content matters | Browser support | Inline frames vs. normal frames | Inline frames vs. object | Simulating scrollable tables | Targets | Legal issues | Attributes | Styling | Embedding different media | JavaScript | Problems | References

The basics Basically, an iframe element is of the form <iframe src="URL" more attributes> alternative content for browsers which do not support iframe Browsers which support iframe display the document referred to by the URL in a subwindow, typically with vertical and/or horizontal scroll bars; such browsers ignore the content of the iframe element (i.e. everything between the start tag <iframe...> and the end tag ). Browsers which do not support iframe (or have such support disabled) do the opposite: process the content as if the <iframe...> and tags were not there. Thus, the content matters, despite being ignored by some browsers. See below for notes on designing that content. As a simple example, consider the following situation. We have a site which contains a separately updated newsflashes page, say news.html. We would like to embed that page into some other page(s) so that the first few lines of its content are directly visible and the rest of it can be viewed by vertical scrolling. This could be written in HTML as follows:

News from Nowhere 2000-01-03 Film at 11. 2000-01-01 Still going strong. Contrary to widespread

<iframe src="news.html" width="40%" height="80" align="right">

See our newsflashes.

Inline frames do not mean an "include feature", although it might sometimes serve similar purposes. The issue of including a document into another is discussed in question How do I include one file in another? in WDG's Web Authoring FAQ. Note that when inline frames are used, the browser (if it supports them) sends a request to the

http://www.cs.tut.fi/~jkorpela/html/iframe.html

10/31/2009

Using inline frames (iframe elements) to embed documents into HTML documents

Page 2 of 13

server referred to by the URL in the iframe element, and after getting the requested document displays it inside an inline frame. In this sense inline frames are a joint browser-server issue, but only the browser needs to be specifically iframe-aware; from the server's point of view, there's just a normal HTTP request for a document, and it sends the document without having (or needing) any idea on what the browser is going to do with it. (This answers the question "Can I prevent others from inline framing my documents?". There is no effective technical method; but see notes on legality below.) Technically, an iframe element is a text-level element, or "inline element" (as opposite to block-level elements). Syntactically an iframe element may occur inside a paragraph, even between two words of text, though that's not particularly useful. It may also occur e.g. inside a table cell (though with some complications). Being text level, iframe does not imply line break before or after. Therefore, consider puting an iframe element inside a paragraph of its own (

<iframe...>...

) or at least use
before and after it.

Content matters Although browsers supporting inline frames ignore the content of the element, an iframe element needs some content and the closing tag. (If you omit the end tag, everything up to the end of the document will be taken as the content of iframe, i.e. ignored by browsers supporting iframe!) The content can be empty, though, but only if such content really is an adequate replacement for the inline frame (in situations where the inline frame is not displayed). This is the case if the text of the document otherwise provides a surrogate for it, e.g. when a link to the embedded document appears in an introductory paragraph. Typically the content should be either a link to the embedded document or a copy of the content of its body. In the latter case, the copy must not include the head part (title etc.) or body tags, just the part that is inside the body element in the full document. Some suitable authoring tools or server side mechanisms could be used to make the copying automatic. It might be useful to apply an approach that I call augmentative authoring: Design the page first using simple and robust constructs, like very basic HTML elements that are universally supported. Then consider "augmenting" it by offering some enhancements as alternatives which replace a simpler construct in some browsing situations. For example, write first a simple link to a document; later consider augmenting it e.g. by slapping suitable iframe markup around it, so that iframe-enabled browsers will show that document an inline frame instead of displaying the link. As a special case, you might consider using the Netscape-specific ilayer element as the content. Note that although that element has some resemblance to iframe, it is fundamentally different. In particular, the entire document (referred to by the src attribute of the ilayer element) is displayed as a whole, not within any scrollable box. Thus, this approach is probably suitable for small documents only. You still need to take into account that there are browsers which do not support either iframe or ilayer, so you need a content for ilayer, as the ultimate fallback. (Such browsers include Netscape 3 as well as most other browsers than Netscape and IE.) Example (with the rendering on your current browser below it): <iframe src="news.html" width="70%" height="80">

See our newsflashes.

http://www.cs.tut.fi/~jkorpela/html/iframe.html

10/31/2009

Using inline frames (iframe elements) to embed documents into HTML documents

Page 3 of 13

News from Nowhere 2000-01-03 Film at 11. 2000-01-01 Still going strong. Contrary to widespread expectations, the world still exists. The content of an iframe element can be just text, or it can contain text-level (inline) markup, or even blocklevel markup (such as the p markup for a paragraph above). The iframe element itself is technically an "inline" element. You might find this somewhat confusing but it means that you can put both text-level and block-level markup around an iframe. On the other hand, Nick Theodorakis has reported, in a Usenet article and a followup to it, that Mac IE5 shows both the inline frame and the alternate content, if you have p markup both inside the iframe element and outside it:

<iframe src="foobar"...>

yada yada...

and that the problem is removed if you change the outer p markup to div markup. Nick recommends that if authors use div markup rather than p as a block-level container for iframe, if they don't want the alternate content to be displayed by Mac IE5. Netscape's documentation of layer and ilayer is partly obscure and does not say very explicitly what the effect of a src attribute really is, but it seems that if it is present, the content of the element is ignored, i.e. only the content of the external file is displayed. And this is quite nice since it gives you the opportunity to provide a "graceful degradation". It's an interesting question is what happens if and when Netscape drops layer support. This may well mean that future versions support iframe but not ilayer. In fact, it has been announced that Netscape 6 will not support layer or ilayer. This should not be a problem if you have nested iframe and ilayer (either way) but it would be problem if you have them in succession.

Browser support Browser to the iframe element is not very wide yet, but increasing: • Internet Explorer has supported iframe since version 3. However, IE as well other browsers have problems in the support, as discussed later in this document. • Netscape 6 supports iframe. It has been reported that Netscape 4.7 on Mac has iframe support, but all Netscape 4.x versions on Windows probably lack support. And it has been reported that Mozilla M12 supports iframe. • iCab supports it, with a user option to disable the support. • WebTV Plus has iframe support, but the "small bugs" include failure to comply with the fundamental idea of using the content of the element only if the inline frame itself is not displayed. • Lynx 2.8.2 handles iframe in a manner similar to its treatment of normal frames: it provides a link (preceded by the text IFRAME:) to the document specified in the src attribute of the iframe tag and then renders the content of the iframe element. As the link text, it uses the name attribute if present, otherwise the URL (the src attribute value). • Opera 4.0 beta supports iframe, with the option to turn the support off (as independently of normal frame support), and the default setting seems to be to have the support disabled. Browsers which do not support iframe are expected to ignore the start and end tags of the element and render its content instead. This is a special case of the general idea of ignoring unknown tags. This could fail if a browser does recognize iframe but has a fundamentally incorrect implementation for it. Luckily there don't seem to be such cases.

http://www.cs.tut.fi/~jkorpela/html/iframe.html

10/31/2009

Using inline frames (iframe elements) to embed documents into HTML documents

Page 4 of 13

Inline frames vs. normal frames Normal frames are used to divide the entire browser window (or a frame) to subwindows. Inline frames appear inside the presentation of a document much the same way as images are: the browser allocates some space for an inline frame and takes this into account when rendering the document. This means, in particular, that an inline frame as a whole scrolls along with the rest of the document, so it might be scrolled away. Whether this is positive or negative depends on the aims and nature of the page. (An inline frame usually has its own internal scroll bar too, for scrolling its own content.) These features make inline frames an interesting possibility especially for embedding relatively small documents onto pages. On the other hand, as explained above, browser support to iframe is limited, more limited than for normal frames. On the other hand, normal frames are usually resizable by the user, though the author might manage to prevent this (using the noresize attribute). Inline frames are not resizable any more than e.g. a table is, except in the sense that if the width or height is specified as a percentage, the actual width or height may change when the entire window is resized. For information about normal frames, see • section on frames in Mikodocs Guide to HTML (excellent tutorial, which discusses advanced issues too) • Guide to frames usage by Galactus (excellent discussion, but partly dated) • section Frames in the HTML 4.01 Specification (official reference) • section on frames in the Web Authoring FAQ (answers the most common questions about frames).

Inline frames vs. object The description of iframe in WDG's HTML 4.0 Reference says: IFRAME provides a subset of the functionality of OBJECT; the only advantage to IFRAME is that an inline frame can act as a target for other links. OBJECT is more widely supported than IFRAME, and, unlike IFRAME, OBJECT is included in HTML 4.0 Strict. Structurally, this is quite true. But in practical terms, as the WDG's reference says in its description of object, referring to Antti Näyhä's survey of object implementation problems, and as the section on objects in Stephanos Piperoglou's HTML 4.0 in Netscape and Explorer also explains, the object element is seldom a good choice at present. There are too many risks involved. On the other hand, for simple embedding of e.g. HTML or plain text documents, iframe does not seem to suffer from such problems. With minor exceptions, either a browser supports it, or it correctly uses the content instead, as planned. See however notes on different treatment of unreachable documents.

Simulating scrollable tables As an example of using inline frames, let us see how one could try to simulate "scrollable tables". One of the ideas behind the thead element (and the associated tbody element) is that an author could specify that some row(s) of table be taken as containing header information, suggesting to browsers that they could, especially for large tables, present the body in a scrollable window much smaller than the entire table would take. Unfortunately there does not seem to be any browser support yet. But let us see how it could be simulated using inline frames:

http://www.cs.tut.fi/~jkorpela/html/iframe.html

10/31/2009

Using inline frames (iframe elements) to embed documents into HTML documents

dec

oct

hex

160

240

A0

161

241

A1

Page 5 of 13

glyph official ISO 8859-1 (and Unicode) name NO-BREAK SPACE ¡

INVERTED EXCLAMATION MARK

This inline frame will act as the target of links from the table body frame. It is not part of the basic design of a simulation of a scrollable table but shown here for convenience. See notes on targets later in the main document. The basic design is relatively simple: • The original table is divided into two parts, table header and table body, written to separate files (separate HTML documents) They can technically be written as table elements, the first one containing a thead element and the second one containing a tbody. • Suitable width attributes are added to the cells of the first rows of each part so that they match. In our case, the first four columns all have width="40"; this is normally enough for the data we have here, though it's of course a guess. • The main document contains iframe elements for embedding the parts: <iframe src="latin1head.html" width="100%" height="30" style="height:1.8em" scrolling="no" marginwidth="0" marginheight="0">
<iframe src="latin1body.html" width="100%" height="60" style="height:4em" marginwidth="0" marginheight="0"> If we wrote the header part simply into the main document before the inline frame containing the document, the columns wouldn't probably match. Inline frames are displayed differently from normal content e.g. with respect to margins etc. Instead of trying to fine tune such things, which would be browser version dependent anyway, we use iframe for the header too. There is still the risk of having different formatting, especially since width attributes are recommendations only. You may notice that if you view the page with a large font, there will be mismatch since the width of cell contents makes the browser use cells wider than the recommended 40 pixels and the widths, depending on the amount of content in the cells, become different in the frames. But this is usually a tolerable risk. The use of scrolling="no" is more risky. It is used here to suppress the vertical scroll bar, since we expect that the height requirement might be a pixel or two larger than the space available, and a scroll bar would thus just confuse. But there is the risk that when the page is viewed with a large font, a considerable portion of the text in the header gets lost. When scrolling="no" is specified, the content outside the visible are is not accessible at all. The tfoot element could be simulated in a similar manner, using a "footer" frame after the body frame.

Before using this technique, consider using normal frames so that the material for which you would use inline frames is on a separate frameset page and you just link to it elsewhere. Naturally you would need to write a noframes alternative for it too, as usual, but in good design that's not a big problem, since you anyway write the simple noframes design first.

http://www.cs.tut.fi/~jkorpela/html/iframe.html

10/31/2009

Using inline frames (iframe elements) to embed documents into HTML documents

Page 6 of 13

Targets Inline frames can be used as targets for links. An inline frame can be named using the name attribute. This implies that when a link with a target attribute with that name as value is followed, the linked resource is opened in the inline frame. (Note that target names should be case-insensitive, but browsers are known to get this wrong, so be careful with the spelling.) In particular, the href attribute of a link can contain, after a URL proper, a fragment identifier (like #foo), referring to a particular location in a document. There is an example of this above. (Try following the links in the "table body" frame.) However, specifying a location with a fragment identifier seems to fail on printing. If the browser does not support inline frames and there is no frame or window with the specified name, such a link will cause a new window to be opened, with that name (or the linked resource to be opened in the current window, depending on the browser). So using target attributes referring to inline frames is "safe". If a link in a document displayed in an inline frame is followed, normal rules apply so that the default target (where the linked document is shown) is that inline frame. This can be overridden using the target attribute; in particular, target="_top" means that the linked document is to be opened in the full window. Note that the default target for links in a document can be set using the base element, e.g. which generally acts as partial "protection against framing". Since documents in inline frames are treated as separate documents, the destination (href) of each link in a document is interpreted independently of the situation that the document appears inside an inline frame. For example, a reference like href="#foo" refers to location named foo in that document, not in the embedding document. So the example discussed above uses, when providing a link from inside an inline to a location named target in this main document, not only target="_top" but also href="iframe.html#target" instead of href="#target". (It can use the relative URL iframe.html though, since in this case the embedded document resides in the same directory, therefore with the same path part in its URL, as the embedding document.)

Legal issues Since iframe embeds a document into another document, it is comparable to copying as opposite to linking (in the strict sense of the word). Thus, you normally need a permission from the copyright holders of the "inline framed" document, and you should provide adequate authorship information if that document is not yours. "Inline framing" is in this respect similar to normal framing. And the more you hide, intentionally or unintentionally, the fact that you're framing someone else's document, the more probable it is that someone will consider a legal action. (For example, the suppression of borders could mean such hiding.) Example: Here I "inline frame" my own document Copyright basics for Web authors and users: IT and communication - Legal issues in IT:

Copyright basics for Web authors and users Every Web author, and even every Web user, should know the very basics of copyright. This document discusses them very briefly and gives links to more detailed resources.

http://www.cs.tut.fi/~jkorpela/html/iframe.html

10/31/2009

Using inline frames (iframe elements) to embed documents into HTML documents

Page 7 of 13

When used that way, inline framing looks rather harmless and comparable to linking. But quite a large number of controversies have arisen from cases where it is less obvious to readers what's going on. In particular, removing borders and surrounding the inline frame with different logos and advertisements could be seriously misleading. To avoid problems, ask before "inline framing" (except when the material being framed is in the public domain, or a permission can otherwise be implied, and you give adequate credits). In a very strict interpretation of copyright rules, someone might even say that my inline frame above is questionable, since it contains some normal links to external documents, so that if the user follows those links, the documents may appear inside an inline frame. Thus you might consider adding into a document of yours if you intend to display it inside an inline frame.

If you view this document on a browser which supports inline frames, you might see the current paragraph as a seamless part of the document. But in reality, in such a case the paragraph is actually a separate document displayed inside a borderless iframe. Consider how misleading this could be if that separate document is actually someone else's document. For more information, see • Tim Berners-Lee: Links and Law • Oppedahl & Larson: Web Law FAQ, especially item May I freely link to the Web sites of others? • Stefan Bechtold: The Link controversy Page (a link (!) list) • Mark Sableman: Link Law, which contains detailed analyses of several cases; a valuable resource for understanding what's really going on.

Attributes According to the HTML 4.01 Specification, the following attributes can be used in an iframe element: name

value

meaning

src

"URL"

the address of the initial content for the inline frame

name

"string"

assigns a name to the inline frame, for use in target attribute

longdesc

"URL"

refers to a document containing a description (not supported yet)

number of pixels or percentage (e.g. "20%")

width of the inline frame; see notes below

width height

align

height of the inline frame; see notes below

"top"

aligns the inline frame vertically on the top of the surrounding content on its left and right

"bottom"

aligns the inline frame vertically on the bottom of the surrounding content on its left and right

"middle"

aligns the center of the inline frame vertically with the current baseline

"left"

places the inline frame at the left margin so that subsequent page content flows on the right of it

"right"

places the inline frame at the right margin so that subsequent page content flows on the left of it

"1"

specifies that a border is to appear around the frame; this is the default

"0"

suppresses the border

frameborder

marginwidth number of pixels

size of the top and bottom margin inside the inline frame; see notes below

http://www.cs.tut.fi/~jkorpela/html/iframe.html

10/31/2009

Using inline frames (iframe elements) to embed documents into HTML documents

size of the left and right margin inside the inline frame; see notes below

marginheight

scrolling

Page 8 of 13

"auto"

scrollbars appear if and only if they are needed to see all the content; this is the default

"yes"

scrollbars appear in any case

"no"

scrollbars do not appear, which may cause part of the content to be inaccessible; see example on simulating scrollable tables

In addition, the core attributes can be used. Note: Internet Explorer uses fairly large default values for marginheight and marginwidth. For some odd reason, if you set one of them, the other is set to zero by IE, so it is best to set both of them.

Using a style sheet to affect the appearance of an inline frame Style sheets (CSS) can be used to affect the appearance of inline frames, too. Note that among the browsers which currently support iframe, IE 3 has horrendous CSS support, which is little else than a careless experiment; people who use IE 3 should be advised to turn off the stylesheet support on it. On IE 4+ however there are several useful CSS features supported, but you still need to be careful and test things.

The embedded document is displayed autonomously Setting font, background, etc. properties for an iframe element should not be expected to have an effect on the presentation. Instead, the style sheet specified or referred to in the document displayed in the inline frame has normal effect. This is quite natural, since the inline frame is for displaying a document in a rather autonomous way. It need not be an HTML document at all, and the browser could even launch a separate program (such as Acrobat Reader for PDF documents) to display it in the subwindow. The embedded document is displayed according to what's applicable to it, not what's applicable to the embedding document; thus, markup inside the embedded document matters, and so do any style sheet rules specified for it. (For example, a style element in a document applies only to the document where it appears, not to any embedded document.) Basically, to affect the appearance of data inside an inline frame, attach a style sheet to the document to be displayed there. If there are style sheet rules which should be applied both to the embedding document and to the embedded document, it is best to write them into an external style sheet and use a link element to refer to it in both documents. And, on the other hand, it is natural that the dimensions of the inline frame can be affected by a style sheet for the embedding document. Similarly, the border around an inline frame is a matter of the embedding document. Thus, for example, to make an inline frame appear so that the News from Nowhere background of the text in it is light green and the border around it is 2000-01-03 Film at 11. pure green and 0.2em thick, you would use e.g. in the 2000-01-01 Still going strong. Contrary to widespread embedded document and <iframe frameborder="0" style="border:solid #0f0 0.2em"...> in the embedding document. Note that the CSS border property won't really affect the frame border in the IE implementation but adds a border around the frame border; so to get a border of our preferred color, we turn off the frame border and add a separate border of our own. (But beware of the potential legal problems.)

Margins In particular, specifying the margins to be used inside an inline frame in HTML is rather inflexible: the marginwidth and marginheight attribute values are interpreted as numbers of pixels. It is generally best to use units which are relative to the font size when suggesting dimensions in Web authoring; in practice this means using "the amazing em unit".

http://www.cs.tut.fi/~jkorpela/html/iframe.html

10/31/2009

Using inline frames (iframe elements) to embed documents into HTML documents

Page 9 of 13

Assume, for example, that you would prefer, for an inline frame, a left margin which is rather narrow but still prevents the text from being glued to the frame border; 0.5em might be suitable - it means half of the size of the current font; and assume that you would like to have an even narrower top margin, say 0.2em. For the HTML markup, you would have to guess a reasonable average font size, say 20 pixels. But luckily you can use style sheets too, to give more rational dimensions. The style sheet rules would need to apply to the embedded document, as explained above; the simplest approach would then be to set the marginwidth and marginheight attributes of iframe in the embedding document to zero. The reason is that Internet Explorer, somewhat oddly, seems to use those attributes as default values for the margins of the body of the embedded document. Those values can then be overridden by using proprietary attributes for the body element or, more logically and more flexibly, by using style sheets.

It seems best to set both marginwidth and marginheight to zero and use a style sheet for the embedded document to specify suitable margins. However, if you cannot affect the margins of the embedded document, use some reasonable values like marginwidth="4" marginheight="0". Below you can see, on browsers supporting the iframe element, our simple "news frame" first as affected by the marginwidth="10" and marginheight="4" attributes, then with marginwidth="0" and marginheight="0" and style sheet rules body { margin-left: 0.4em; margin-top: 0.2em; } in the embedded document:

News from Nowhere

News from Nowhere

2000-01-03 Film at 11.

2000-01-03 Film at 11.

2000-01-01 Still going strong. Contrary to 2000-01-01 Still going strong. widespread expectations, the world still exists. Contrary to widespread expectations, the 1999-12-31 Great expectations. Yeltsin world still exists. They resemble each other quite a lot for "normal" font sizes, but the latter is more flexible. It's not really a big issue, since the font size would need to be rather exceptional to make a big difference. However, turning now to the dimensions of an inline frame we'll see more important differences. Naturally, style sheets are applicable to HTML documents only. Thus, to apply this method to plain text data (to be presented as such), you need to write an HTML "container" for it: simple markup around the textual data, most importantly pre markup and markup for associating a style sheet (e.g. a style element). Below you can see a simple plain text document (four lines) embedded in two ways corresponding to those used for the sample HTML document above: This is a very simple textual document. This is a very simple textual document There is very little content in it, really. There is very little content in it, re In total, it contains four lines only. Jukka KorpelaIn total, it contains four lines only. Jukka Korpela

To display two inline frames side by side, I have just written two iframe elements in succession and used width="47%". This seems to work mostly; using width="50%" might mess things up since the browser may think they don't fit. Naturally you could also use a simple two-cell table, too. However it seems that IE does not display an inline frame at all, if the iframe widths are specified as percentages and the table tag has no width attribute! Assumably it thinks it cannot determine the widths for the inline frames. This can be fixed by using e.g. . If an inline frame is inside a table, a percentage width for it will be interpreted as relative to the cell width, so to get the maximum width available, you would use width="100%" for the iframe element too (not width="50%", which would mean just half of the width available for the cell, not half of the window width.)

http://www.cs.tut.fi/~jkorpela/html/iframe.html

10/31/2009

Using inline frames (iframe elements) to embed documents into HTML documents

Page 10 of 13

Dimensions The dimensions of an inline frame, if specified in HTML, must be given either as pixels or as a percentage; the latter refers is relative to "currently available" space. Although percentages work well for the width in many cases, the height is more problematic. Typically we have an idea of how much from the beginning of the embedded document should be initially visible, or, for small documents, how much space the entire document will occupy vertically. And our idea is probably something like "a heading and the first paragraph" or "four lines". These don't translate to pixels, still less to percentages, unless we make wild assumptions about the presentation.

Although suggesting dimensions in a style sheet is the logical alternative and works reasonably on screen, it seems to cause serious problems when printing the document. Thus, in addition to or instead of using the width and height attributes, we could use style sheets, normally using with em units. This won't be exact science either, since e.g. the spacing between lines is unknown. But roughly speaking, for normal text, one line is about 1.2em when line spacing is taken into account. A horizontal scroll bar, if present, will roughly correspond to one line. Thus to get room for a particular amount of lines, you could suggest a height value of 1.2×lines+1 em units. The examples above, inline frames with plain text content, use a guessed width of "100". This is how the latter of them looks with a style sheet suggesting height:5.8em: This is a very simple tex There is very little cont In total, it contains fou Jukka Korpela

The example additionally uses width:30ex which effectively forces a horizontal scroll bar, just to get such an appearance for illustration. The ex unit can be used as a very rough measure for an (average) character width; though its real meaning is the height of the letter x, this may reasonably approximate the average width, at least for monospace fonts. Thus, for plain text data, remembering to allow for some margins and inexactness, one could use a width value of characters+3 ex units, where characters is the number of characters at the longest line. This should suppress a horizontal scroll bar, and so we would use a smaller height value (of 1.2×lines em units): This is a very simple textual document. There is very little content in it, rea In total, it contains four lines only.

One drawback is that if the inline frame is wide, it may force a horizontal scroll bar for the entire document window.

Embedding different media As the example above illustrates, the embedded document need not be an HTML document; it could be a plain text document, or something else. The specifications do not list any particular list of Internet media types (MIME types) that can be used; it depends on the browser and the environment, such as installed program repertoire, which media types are supported in this context. A browser should investigate the HTTP headers sent by a server to determine the media type of the data it gets, in order to select a suitable method of processing for it. And there is no reason why this should not apply to documents embedded via iframe too. (When a browser which supports iframe encounters an iframe element, it sends an HTTP request to a server to get the document to be embedded, unless it has already got it in its cache.) But IE seriously violates the protocols, making it essential what filename suffix is used. As I explain in section Media types of Learning HTML 3.2 by Examples:

http://www.cs.tut.fi/~jkorpela/html/iframe.html

10/31/2009

Using inline frames (iframe elements) to embed documents into HTML documents

Page 11 of 13

There is an additional complication caused by the fact that Internet Explorer does not work according to the protocols in this area. It often ignores the media type announced in the Content-Type and uses the last few characters of the URL instead to determine the method to be used. (IE may also apply some "heuristics" based on the actual content of the data!) This means that in addition to making sure that the server sends the correct media type information one should try to name the file so that things might work on IE, too. Thus, one should try to stick to commonly used conventional file name suffixes like .DOC for MS Word documents, .XLS for MS Excel documents, .TXT for plain text documents, etc. Note that above I use a technique for quoting a document in a manner which displays the original document in an inline frame, on browsers supporting iframe. Using a "fragment identifier" in the URL I position that document suitably, so that the user sees the part I am referring to but can scroll vertically to see the context.

So, for practical purposes at present, if you wish to embed e.g. a PDF document using iframe, you need to use the suffix .pdf for it. IE is capable of handling it on screen if there is a PDF viewer, such as Acrobat Reader installed on the system. It is questionable whether it is useful to embed PDF documents, partly because viewing them requires so much screen space that it does not work well in a subwindow, partly because there are serious problems with printing the embedding document. For demonstration purposes, however, I have written a separate document illustrating a PDF document in an inline frame. For PostScript documents as well as for images (in widely supported formats like GIF and JPEG), using inline frames could make more sense in some cases. By using an inline frame, we can create a subwindow which displays an image either as a whole (when the actual dimensions permit) or in a scrollable box. Such a technique might sometimes work nicely for images (or other material) where the most essential part, or the part to start with, is on the left, or in the upper left corner, depending on the dimensions. For a "timescale" like image, with time running from left to right, you might use an inline frame with a height attribute equal to the actual height of the image and the width set to some reasonable value. But use your judgment and test it in various browsing situations. And if the image is essential, provide, as the content of the iframe element, a link to it or the image itself via the normal img element.

JavaScript JavaScript can be used in various ways in conjunction with inline frames. See JavaScript Frames FAQ. Note that it calls inline frames "floating frames". Technically, the term floating frame would best be reserved for such inline frames which have the attribute align="right" or align="left", causing subsequent text to flow on the left or right of the inline frame, respectively. See section Floating objects in the HTML 4.01 Specification. See also section Floats in the CSS2 specification.

The JavaScript Frames FAQ addresses in particular the following questions: • Is it possible to detect from outside a floating frame that the contents have loaded? • How can I skip an IFRAME when tabbing through the elements? • How can you dynamically write content to a floating frame (IFRAME)?

Problems The discussion above has mentioned several problems with inline frames, such as limited browser support, legal issues, links inside inline frames and the inflexibility in which margins and dimensions are to be specified in HTML. Some partial solutions to them were also mentioned. Here we briefly discuss some additional problems.

http://www.cs.tut.fi/~jkorpela/html/iframe.html

10/31/2009

Using inline frames (iframe elements) to embed documents into HTML documents

Page 12 of 13

Separate access to the inlined document When a document is displayed in an inline frame, the user cannot access directly that document in other ways, such as to view it in a larger window, or to save it locally. A normal link would allow all these. One might say that a browser should allow them for documents embedded via inline frames, too. The iCab browser allows the user (through a contextual menu) to load an iframe's content (or any frame, image, or whatever object) into either a new window or into the current browser window. But IE 4+ does not do anything like that. (It lets the user view the HTML source of an inline frame or print its content, when the right mouse button is used for clicking.) Therefore, consider also providing a normal link to the inline framed document. Perhaps you can smoothly include it into the normal text around.

What if the inlined document is unreachable? An inlined document might be unreachable for various reasons, e.g. • user is viewing a page offline and an iframe element refers to a document elsewhere • the element refers to a document on another server which happens to be down or unreachable • the src attribute does not refer to any document, e.g. because the URL stopped working due to a site reorganization. In such cases, i.e. when the document referred to in the src attribute of an iframe is not available, Internet Explorer displays an error message from its attempt to access it, rather than the content of the iframe element as a replacement. Thus, it displays, in the area allocated for the inline frame, a message reporting that the page cannot be displayed. That message could be rather enigmatic, like "Navigation Canceled". It would naturally be better to display the content of the iframe element instead in such cases. But other browsers that support iframe seem to behave more or less similarly to IE in this respect. Unfortunately it seems that this cannot be classified as a bug. On the contrary, a literal interpretation of the HTML 4.01 specification suggests that this is how things should be: The information to be inserted inline is designated by the src attribute of this element. The contents of the IFRAME element, on the other hand, should only be displayed by user agents that do not support frames or are configured not to display frames. On the other hand, since the iframe element is conceptually rather close to the object element, we might compare this with the corresponding statement in the specification about object: If the user agent is not able to render the object for whatever reason (configured not to, lack of resources, wrong architecture, etc.), it must try to render its contents. And in fact, the object element is handled better than iframe by IE 4+: if the document specified in the data attribute is not available, the browser displays the content of the object element instead.

Strange focusing when #location used On Internet Explorer (at least on version 5.0, Win98), there is an odd feature that is triggered when the src attribute contains a fragment identifier, i.e. the URL proper is followed by #location, e.g. http://www.cs.tut.fi/~jkorpela/html/iframe.html#focus Such a construct can be expected to position the document in the inline frame at the specified anchor location, similarly to the similar behavior with normal links. And this does happen on IE, but the browser also positions the enclosing document (i.e. the one containing the iframe element) there when it is first accessed. This can be very confusing.

http://www.cs.tut.fi/~jkorpela/html/iframe.html

10/31/2009

Using inline frames (iframe elements) to embed documents into HTML documents

Page 13 of 13

Printing problems Printing inline frames seems to be rather problematic. To begin with, if there is a PDF document in an inline frame, printing the embedding document from IE seems to result in a failing attempt to print that PDF document only. (Tested with IE 4 on WinNT, using output to a PostScript printer, and with IE 5 on Win98, using a directly attached printer. I get an empty paper with a URL of the PDF document at the bottom.) Moreover, when I print a document containing an HTML document in an inline frame positioned at an anchor, i.e. I have iframe src="something.html#location, I get a print where the embedded document is positioned at the beginning, as if the part #location were not present. Yet another serious problem with printing is that inline frames with dimensions suggested via CSS get printed very oddly. It is as if the em unit got mapped to a small measure so that the inline frame is shrunk ridiculously. Perhaps this problem could be addressed by using separate style sheets for screen and print, but this would mean quite some extra effort. Interestingly, the printing problems were predicted as early as in 1996 in Jakob Nielsen's famous alertbox Why Frames Suck (Most of the Time): Finally, it seems that the inline frames introduced in HTML 4.0 will be mostly harmless. A frame that is inlined will be subordinate to the main page, and the user can still bookmark the main page and navigate as usual. Since mainstream browsers still do not implement HTML 4.0, we don't know whether inline frames will have their own implementation problems: in particular, it is doubtful whether good ways will be found to print pages that have scrolling inline frames (my current best guess is that it will be best to print the currently visible part of a scrolling inline frame in order to maintain the layout of the main page, but some users may want to have the entire contents printed, so messy option settings may be necessary).

References • description of iframe in the HTML 4.01 Specification • description of iframe element and object in Microsoft's documentation of HTML as interpreted by Internet Explorer, HTML Elements • description of iframe in WDG's HTML 4.0 Reference • description of iframe in Brian Wilson's HTML Support History • description of iframe in Mikodocs Guide to HTML by Miko O'Sullivan. Greg Shultz, the Windows Wizard, has written the review Inline Frames Revisited, which especially discusses the use of inline frames to replace normal frames. I don't think that's a good idea, but admittedly it might sometimes be an improvement over framesets with lots of frames just to to put a content frame in the midst of something. Interested in related works by me? There is a separate list of my documents related to Web authoring. Date of last update of this page: 2004-02-27. Some links fixed 2006-06-13/14. This page belongs to the free information site IT and communication by Jukka "Yucca" Korpela.

http://www.cs.tut.fi/~jkorpela/html/iframe.html

10/31/2009

---

Related Documents