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
</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 </iframe>). Browsers which do not support iframe (or
have such support disabled) do the opposite: process the content as if the <iframe...> and </iframe> 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 from Nowhere
news.html. We would like to embed that page into some other 2000-01-03 Film at 11.
page(s) so that the first few lines of its content are directly visible 2000-01-01 Still going strong.
and the rest of it can be viewed by vertical scrolling. This could be Contrary to widespread
written in HTML as follows:
<iframe src="news.html"
width="40%" height="80"
align="right">
<p>See our <a href="news.html">newsflashes</a>.</p>
</iframe>
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
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 (<p><iframe...>...</iframe></p>) or at least use <br> 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 </iframe> 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">

<ilayer src="news.html">
<p>See our <a href="news.html">newsflashes</a>.</p>
</ilayer>
</iframe>
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 block-
level 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:
<p><iframe src="foobar"...><p>yada yada...</p></iframe></p>
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.
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:
dec oct hex glyph official ISO 8859-1 (and Unicode) name
160 240 A0 NO-BREAK SPACE
161 241 A1 ¡ 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>
<br>
<iframe src="latin1body.html" width="100%" height="60"
style="height:4em"
marginwidth="0" marginheight="0">
</iframe>
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.
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.
<base target="_top">
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.
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 <base target="_top"> 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)
width number of pixels or width of the inline frame; see notes below
height percentage (e.g. "20%") height of the inline frame; see notes below
aligns the inline frame vertically on the top of the surrounding
"top"
content on its left and right
aligns the inline frame vertically on the bottom of the
"bottom"
surrounding content on its left and right
aligns the center of the inline frame vertically with the current
align "middle"
baseline
places the inline frame at the left margin so that subsequent page
"left"
content flows on the right of it
places the inline frame at the right margin so that subsequent
"right"
page content flows on the left of it
specifies that a border is to appear around the frame; this is the
"1"
frameborder default
"0" suppresses the border
size of the top and bottom margin inside the inline frame; see
marginwidth number of pixels
notes below
size of the left and right margin inside the inline frame; see notes
marginheight
below
scrollbars appear if and only if they are needed to see all the
"auto"
content; this is the default
scrolling "yes" scrollbars appear in any case
scrollbars do not appear, which may cause part of the content to
"no"
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

background of the text in it is light green and the border around it is News from Nowhere
pure green and 0.2em thick, you would use e.g. <body 2000-01-03 Film at 11.
style="background:#cfc none; color:#000"> in the 2000-01-01 Still going strong.
embedded document and <iframe frameborder="0" Contrary to widespread
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".
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. 2000-01-01 Still going strong. Contrary to
Contrary to widespread expectations, the widespread expectations, the world still exists.
world still exists. 1999-12-31 Great expectations. Yeltsin
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.
There is very little content in it, really. This is a very simple textual document
In total, it contains four lines only. There is very little content in it, re
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. <table width="100%">. 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.)
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:
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.
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.
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.

Using Inline Frames (Iframe Elements) To Embed Documents Into HTML

Uploaded by

Copyright:

Available Formats

You might also like

Using Inline Frames (Iframe Elements) To Embed Documents Into HTML

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Using Inline Frames (Iframe Elements) To Embed Documents Into HTML

Uploaded by

Copyright:

Available Formats

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 src="URL" more attributes>

As a simple example, consider the following situation. We have a

<iframe src="news.html" width="70%" height="80">

News from Nowhere

Inline frames vs. normal frames

For information about normal frames, see

Inline frames vs. object

See however notes on different treatment of unreachable documents.

Simulating scrollable tables

<iframe src="latin1head.html" width="100%" height="30"

IT and communication - Legal issues in IT:

Copyright basics for Web authors and

For more information, see

• Tim Berners-Lee: Links and Law

name value meaning

Using a style sheet to affect the appearance of an inline frame

The embedded document is displayed autonomously

Thus, for example, to make an inline frame appear so that the

News from Nowhere News from Nowhere

This is a very simple tex

This is a very simple textual document.

Embedding different media

The JavaScript Frames FAQ addresses in particular the following questions:

Separate access to the inlined document

What if the inlined document is unreachable?

Strange focusing when #location used

You might also like