Bag of Web tricks

Select your language:
German flag
British flagAmerican flag
French flag
Czech flag
Where would you like to go?
  • Table of contents
  • Home
  • The choice of document type
    • The MIME type
    • The doctype declaration
  • Accessibility
    • Why all this?
    • Document types
    • Accessible layout
      • Color schemes
      • The Dalton mode
      • Font types
      • Font sizes
      • Session not necessary!
    • Simplified language
      • Too complex – now what?
      • Effecting a better comprehension
      • Support and challenge
      • Implementation
    • Accessible operation
      • Keyboard support
    • Accessibility issues
      • Graphics
      • Flash
      • Phrasing
    • ARIA
      • Elements and their roles
      • Defining roles
      • States of elements
    • Forms
      • Labelling
      • Required fields
      • Feedback
  • Fighting spam!
    • Captchas – really necessary?
    • Spam-free guest book
      • How MySQL can help
      • How blacklists can help
      • Deploying spam traps
      • Content analysis
      • How moderating the guest book helps
      • Last but not least: The confirmation mail
    • Spam-resistant web statistics
  • Pimp your Apache
    • Power logging
    • Setting MIME types
    • Error documents – do it yourself
      • Why do it yourself in te first place?
      • Your own directory for error documents
      • Registering the error documents
      • Creating new error documents
    • Setting up virtual hosts
    • Stop the dork
      • Now what's going on here?
      • Denying unwanted access
      • Keeping junk data out of the logs
      • Cutting off referrer spam
      • Give the dorks a dose of their own medicine
      • Establish selective blocks
      • Traps for web scrapers
    • SSI
      • What are SSI?
      • Activate SSI
      • Predefining common elements
      • Dynamic content without CGI
        • Dynamic navigation
        • The central menu
        • The language selection
        • Show time of last modification
    • Security
      • SSL
        • Basics
        • Obtaining certificates
        • Security risks
        • SSL tweaked
        • Do away with SSL, TLSv1.0, and TLSv1.1!
        • Strict Transport Security
        • Private Key Pinning
        • Certificate Authority Authorization
      • Source restrictions
      • Prevent embedding into frames
      • CORS
        • Content of a different origin
        • Hotlinking
        • Verifying origins
        • Multiple valid origins
      • Referrer policy
      • Managing API permissions
  • Web pages for smartphones
    • Reasons for adaption
    • Adjusting the viewport
    • Navigation problems
    • Element sizes
    • Dealing with oversized content
    • Build a responsive design
    • Dedicated layout for mobile devices
  • XHTML
    • XHTML and HTML compared
    • Basics
    • The framework
    • Problems
    • Misconceptions
  • CSS
    • Basics
    • The box model
    • Defining the page layout
      • Fundamental styles
      • Selectors
      • Combinators
      • Properties
        • Text styles
        • Text formats
        • Text alignment
        • Boxes
        • Positioning
        • Display
        • The background
        • Animations
      • Pseudoelements and -classes
    • Creating a basic layout
    • Browser switches
    • Printer-friendly layout
    • Style selector
      • CSS and scripts
      • CSS and CGI
      • Color selection
      • Font sizes
      • Font types
      • Skins
  • JavaScript
    • Basics
      • Structure
      • The strict mode
      • Integration
      • Delayed execution
      • Error handling
    • The Document Object Model
    • Modules
      • Fundamental problems of JavaScript
      • Scope and namespace
      • Encapsulation
      • Object-oriented programming
    • AJAX
      • XMLHttpRequest
      • CORS
      • Script initialization
    • Usages
      • Tooltips
      • Country selector
      • Context menus
      • Error report
      • Dynamic help pages
      • Menu controls by keyboard
      • Debugging aids
    • Gimmicks
      • Display window dimensions
      • Offer a button for printing
      • Open links in a new window
    • Extensions
      • XHTML: Add document.write() to the DOM
      • Setting, reading and clearing cookies
      • Reading metadata
      • Modal elements
    • Supporting techniques
      • The document type switch
      • Content switch
    • Programming APIs
      • Security aspects
      • Reliability
  • Nonsensical frames
  • Cookies
    • Definition
    • Fields of application
    • Privacy concerns
    • Security aspects
  • Self-made control panel
    • Overview on running services
    • Web server controls
    • Crontab editor
    • Controlling virtual machines
  • Glossary
    A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

© 2013 - 2022 by Olaf Martens

Imprint
Privacy Policy
Nonliability statement

Valid XHTML 1.1 + ARIACSS is valid
Print page

Flattr button

Block my IP address
  • News
  • Contact
    • Guest book
    • Forum
  • Services
    • Keys for SSH
    • Request for SSL certificate
    • Resolve domain name
    • Define a virtual machine
    • Fingerprints of certificates
    • Sanitize defective HTML
  • FAQ
  • Sitemap
  • Support

Nonsensical frames

  • The problem with arranging the document
  • The frameset
  • The iframe
  • Integration problems
  • Annoying accessory phenomena
  • The showcase effect
  • Handling problems
  • Problematic traits of the iframe
  • Conclusion

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.

to the top

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 top

The 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.

to the top

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 top

Annoying 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.

to the top

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:

<script type="application/javascript"> /* <![CDATA[ */ if(self.location != top.location) top.location = self.location; /* ]]> */ </script>

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 top

Handling 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.

to the top

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.

to the top

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.

to the top