iframe
elements)
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
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.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:
<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 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.
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>
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 to the iframe
element is not very wide
yet, but increasing:
iframe
since version 3. However, IE as well other browsers have
problems in the support, as discussed later in this document.
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
.
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.
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).
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.
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
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.
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:
The basic design is relatively simple:
table
elements, the first one containing
a thead
element
and the second one containing a tbody
.
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.
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.
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.)
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:
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.
For more information, see
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 percentage (e.g. "20%" ) | width of the inline frame; see notes below |
height
| height of the inline frame; see notes below | |
align | "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 | |
frameborder
| "1"
| specifies that a border is to appear around the frame; this is the default |
"0" | suppresses the border | |
marginwidth | number of pixels | size of the top and bottom margin inside the inline frame; see notes below |
marginheight
| size of the left and right margin inside the inline frame; see notes below | |
scrolling
| "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.
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.
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 pure green and 0.2em
thick,
you would use e.g.
<body style="background:#cfc none; color:#000">
in
the 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.)
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:
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:
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.)
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
:
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):
One drawback is that if the inline frame is wide, it may
force a horizontal scroll bar for the entire document window.
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 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:
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.
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.
An inlined document might be unreachable for various reasons, e.g.
iframe
element refers to a document elsewhere
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.
#
location usedOn 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://jkorpela.fi/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 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).
iframe
in the
HTML 4.01 Specification
iframe
element and object in
Microsoft's documentation of HTML as interpreted by
Internet Explorer,
HTML Elements
iframe
in
WDG's
HTML 4.0 Reference
iframe
in
Brian Wilson's
HTML Support History
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.