Nonsensical frames
The problem with arranging the document
Anyone who is delving into HTML should have had his fair share in this problem:
How is a document arranged and – even more important – how is that implemented
in HTML?
This question doesn't come up any more since CSS 2, because the position of
any elements may be set at one's discretion. These pages, for xample, are
making good use of this so that there is a clear subdivision into a header, a
navigation bar plus additional information, and the document body proper.
Subdividing a document is necessary if for no other reason than to both avoid a
topsy-turvy appearance and allow for an easy handling.
The problem before CSS 2 has been that the appearance of individual elements
could be changed, but the layout of the document couldn't be changed this way.
In order to allow for subdividing a document, frames have been invented. They
allowed for splitting documents in multiple parts so that anything that should
be persistent would persist, and only those parts that were supposed to be
volatile would actually have to be reloaded.
The frame set
This allows for partitioning a window in multiple subunits that in turn could each serve a different purpose. This way e. g. a navigation bar can be placed at the left hand side that allows for accessing the various pages, or a header is added that could contain a main menu. However, other variants are conceivable as well, e. g. defining a footer to which links to the Terms of Use, the imprint, etc. can be added.
In order to set up a frame set a superordinate document must be defined that
defines the individual frames and determines which documents are to be loaded
into them. Unfortunately it's not possible to code HTML directly into the
frames, but instead files have to be specified that are in turn loaded by the
superordinate document.
To this end the document type for the superordinate file should be set to HTML
4.01 Frameset or XHTML 1.0 Frameset. The other documents may have any document
type, although HTML 4.01 Transitional or XHTML 1.0 Transitional should be
preferred, because they provide a few options to access the frame set that has
loaded them.
Unfortunately using frames isn't without problems, and one is going to come across some in part significant problems without an adequate means of resolving them so utilizing frames should be avoided.
to the topThe iframe
The iframe essentially serves a similar
purpose like a normal frame, but in contrast to the latter it's an inline
element that is placed in a normal document and so loads additional content.
It is necessary to specify HTML 4.01 Transitional, HTML 4.01 Frameset, XHTML
1.0 Transitional, Xhtml 1.0 Frameset, or (X)HTML5 as document type to use the
iframe. However, this incurs some
nasty problems that cannot be resolved that easily when using this
technique, so it should as a general rule be avoided even though the
iframe has been incorporated into (X)HTML5.
On top of that the iframe possesses
some traits that make it even more problematic than a normal
frame set.
Integration problems
The main problem that arises with the use of frames is that a document that is supposed to be partitioned has to be split in multiple parts. These in turn have to be loaded into the frames defined as individual documents, which means that there is no logical, but instead an actual partitioning of the document. Every frame constitutes, like a window, an individual viewport that can be accessed independently from the other frames. This in turn results in some restrictions, because other frames cannot be accessed from a particular frame without the help of JavaScript. So when a document is loaded into a frame and it is supposed to have an effect on other frames, it's impossible to achieve this by means of pure HTML.
You are furthermore required to lay out your page in such a fashion that you can split it into a frame set. This may work with a lot of page layouts, but when you are in need of more specific layouts, frames reach their limits once again.
to the topAnnoying accessory phenomena
When you are using a frame set or an iframe you are
going to find out that you come across a bunch of problems that you wouldn't
have had without frames. Since you are splitting a browser window into several
parts by using a frame set, things aren't that simple when attempting to get
creative in this case. This isn't so much of a problem when working with rather
simple layouts, but when you intend to, for example, incorporate background
images, things become difficult: You have to integrate them separately for each
frame. But here it is necessary to split the background graphics into several
parts and then integrate them into the respective frames depending on their
position. On first glance this isn't so much of a problem, because the
dimensions of each frame are known and you can cut the image on the pixel level
with an image editor so that splitting it is optically unnoticeable. However,
a closer look reveals several pitfalls: When changing the dimensions of the
frame your carefully planned layout is instantaneously and thoroughly messed
up. The second problem arises when you are defining in your document that the
individual frames may not be scrolled, but your users instead instructed the
browser to permit scrolling the contents of frames no matter what has been set
by a web page – up to the point that the frame set is blown by displaying
scroll bars. The appearance of a document disintgrates in this case, rendering
it unsightly.
This problem could be mitigated by designing the individual frames in such a
fashion that each area is clearly distinct from the others and that this
subdivision isn't hidden from your users. But even in this event the
usability of the page is at most suboptimal.
The showcase effect
The main problem caused by frames is the possibility to use them to incorporate
foreign documents into one's own pages in a way that they appear to be a part
of one's own web project. A normal user cannot determine that easily that an
entirely different site is being referenced here when he doesn't make the
effort to analyze the source code of the page and thus could come to the
conclusion that that which is shown within your frame actually belongs to your
web project.
Here it would be necessary to either notify any users that the content of the
frame originates from another site or take care of destroying the frame set
when external links are invoked so that the entire browser window is available
to the target page. Unfortunately this is neglected, oftentimes due to lack of
better knowledge, which in turn leads to the aforementioned showcase effect.
This may become particularly bad when the target page defines frames itself,
because the frame into which it is loaded gets subdivided by a frame set again.
The space into which pages may be loaded is made even smaller by the frame set
within a frame, up to a point at which any pages loaded are rendered unusable.
There are unfortunately some rotten apples around who make deliberate use of this effect in order to adorn themselves with borrowed plumes by masquerading the true origin of a page being incorporated from unwitting visitors. Not only is this extremely unfair in respect to the author of the page being “absorbed” this way, but it could also entail trouble.
It's for these reasons that the following code can frequently be found in HTML documents:
This way the loaded document takes care of destroying the frame set or iframe into which it is loaded and so the target document is the only one in the browser window. This is an easy means of mitigating the showcase effect, and even neglect on behalf of the one referencing other pages doesn't constitute a problem any more.
to the topHandling problems
However, the usability of a page is adversely affected as well. If you want to e. g. tab between links, problems are going to occur e. g. when the navigation has been placed in its own frame, because it won't be reached except by clicking into the frame holding the navigation. In that event you cannot switch between tle kinks in the document proper any more without clicking its frame again. It furthermore entails problems as far as the accessibility of a page is concerned, because screen readers and braille lines aren't normally designed to web pages being split in multiple parts in this fashion.
Another problem appears when your site is indexed by a search engine, because
they usually don't return the superordinate frame set in their search results,
but instead it's the actual page that matches your query. However, when you
access it you are presented with the problem that you don't have any navigation
at your disposal in case it has been placed in an individual frame on the site
that you are accessing. Loading the frame set and displaying the page you have
accessed in it could only be achieved with considerable effort.
And even though the navigation may be visible, other problems are inevitably
going to occur. Since a frame only has very limited capability of reacting on
events that occur in other frames – if at all, one would have to go to great
lengths, plus without using JavaScript this won't be possible in the first
place – the navigation thus integrated usually is static so that the link to
the current page stays active, which shouldn't be the case. Here one would have
to sift through the entire list of links and reenable every link before
disabling the one that points to the current page so that one cannot invoke the
current document again. It is therefore recommended to apply other techniques,
e. g. SSI, that are much more suited to avoid this kind of problems.
But problems may also occur when you want to set a bookmark: You are always
going to set the superordinate document as bookmark, which brings up the frame
set with its default settings (that is, the page that is initially loaded by
the frame set) and you would have to explicitly click the desired document.
This, however, quickly annoys any user who finds himself confronted with
unnecessary actions and so could quickly decide to leave the site.
The same problem shows up when you examine the address bar of the window into
which a frame set has been loaded. You are always going to find the address of
the superordinate frame set; the documents loaded into the frames don't make an
appearance at all. It's exactly this characteristic that abets the
showcase effect.
To avoid problems in advance you should resort to server-side technologies like
CSS, script languages, and SSI that allow integrating portions in your document
without having to split it in multiple part-documents. The pages on this
domain, for example, make intensive use of such techniques; the menu at the top
left corner, for example, is created by a Perl script that is invoked by means
of SSI and inserts the XHTML code necessary for navigating at the spot where
the call is put down. The advantage of these techniques is obvious: You can put
some tests into the script, e. g. to check whether or not the destination file
is present and disable the link if not. This way you don't have to change the
menu or sift through umpteen documents when you add a page to your web project
and in turn risk missing anything in the process. On top of that the document
being displayed retains its physical integrity.
The page that you are currently viewing could very well have been created with
the aid of frames, because it has a suitable layout, but as already pointed
out, this would entail various problems that don't exist in its current form.
Problematic traits of the iframe
When using frames, the iframe turns out to be even
more problematic than the regular frame set, because one can easily let it
disappear within an HTML document. The only thing you would have to do is add
a style attribute that contains a value of
display: none; only, causing the
iframe to disappear. The document containing an
iframe thus hidden appears as a normal document so
that an unwitting user doesn't even suspect that something is hidden in the
document. One would have to have a look at the source code to find elements
hidden in this fashion.
A frame hidden in this manner may, for example, be abused to load foreign
JavaScript that may execute additional actions in the
context of the document containing the iframe.
This behavior is used to some extent by cybercriminals who foist malicious code
on unwitting users which is unnoticedly executed. This becomes particularly
nasty when the web server that delivers these pages is replaced with a variant
that injects such an iframe into the actual HTML
code and then delivers the modified HTML code to the caller. This way it isn't
necessary any more to modify the HTML pages on a web site, which drastically
reduces the amount of telltale traces on the server side. This problem, also
known as
Linux/Cdorked.A
in the form of a modified Apache, appeared at the end of 2012 or at the
beginning of 2013, but in the meantime modified variants have shown up for
other web servers.
This clearly demonstrates the potential for abuse of hidden
iframes. One could hide normal frames in a similar
fashion, but that would be much more long-winded to foist malicious code on
users this way, because one would have to modify an existing frame set, which
either requires a lexical analysis of the invoked document, or one would have
to set up a frame set that contains a hidden frame. However, this could cause
problems when the HTML variant that is used doesn't support frame sets, as is
the case on these pages. XHTML 1.1, for example, doesn't implement frames, and
they cannot just be created by using JavaScript, because the required node
isn't present in the DOM. So injecting normal frames or an
iframe doesn't work here, because the browser would
refuse to display the document and instead present you with an error.
Conclusion
However you look at it, frames, no matter their flavor, do far more harm than
good. The options have admittedly been rather limited by the time that frames
were invented – and even today by some providers of free web space – and so
have been the only viable solution to set up a fixed navigation bar since CSS
hadn't been that far developed as nowadays, plus scripting languages aren't
available and setting up a JavaScript turns out far too tedious and advanced
techniques on the server side like SSI have been disabled. But with a
sensibly-configured web space that offers these options there are much better
ways of structuring a document without having to split it apart and so destroy
the logical relation of the individual subdocuments.
The navigation bar can easily be included by means of SSI, and with a
well-written script it is even possible to construct the navigation in such a
fashion that e. g. the current document cannot be invoked again and is also
specially highlighted. The document can additionally be logically structured by
means of CSS so that a small area at the top and one side is reserved for the
header and the navigation bar whereas the rest is retained for the actual text
of the document.
Since the document is only visibly structured, but otherwise retains its
integrity, it remains barrier-free, because screen readers and braille lines
can process it without trouble and so extract any information. Furthermore the
navigation isn't lost when you are directed to such a page by a search engine
since it is an integral part of it, and last but not least JavaScript that is
able to work with every part of the page can easily be created. Loop ways via
the element nodes of individual frames don't apply, plus any JavaScript doesn't
have to determine what it is dealing with in the other frames.
It is solely the iframe that can be used somewhat
sensibly for integrating certain lements from other domains in one's own
documents. Facebook and Google, for example, make use of this approach for
providing various widgets for integration in other web pages, but other
entities like PayPal and providers of
captchas provide elements that have
to be integrated in this fashion. This, however, requires a document type that
provides the iframe, because things wouldn't work
otherwise. This would require other, considerably cleaner solutions, especially
when document types are used that don't define it, alas various developers
eschew the adherent additional effort.