"How Do I Force...?"
See also Azerbaijanian, Estonian, French (from tr-ex.me), Greek, Hungarian, Lithuanian, Macedonian, Polish, Portuguese (from https://www.homeyou.com/~edu/), Russian, Slovak, Spanish, and Thai translations (done by others in their own sites)
TIP: Understand that HTML can't "force" any sort of action, and don't keep trying to get around this limitation; you'll just annoy your users and make your site less accessible.
Common "newbie" questions in the newsgroups devoted to Web authoring are those that begin "How do I force the user's browser to..."
...and the list goes on. They all display a lack of understanding of how the Web works. There is no way an author can force anything on the user. Various HTML constructs can suggest certain actions on the part of the browser, but they can't force them.
Even if it were possible to force such things on the user, the question is "Why do you want to do that?" A large portion of the user community is apt to get annoyed at such attempts to manipulate his or her browsing experience, and an annoyed user probably won't return to your Web site. Users are accustomed to using standard navigation tools like the browser's Back button, and won't like it if you somehow manage to disable them. Users may be using any number of different machine platforms and display resolutions, and may be unable or unwilling to force a particular pixel width just to suit your poorly-designed layouts that can't resize to the user's settings. Users may see a security risk in running embedded applets and scripts and will refuse to enable these settings, so if your site makes them mandatory for navigation he'll just go away.
The lack of ability to force browser behavior is certainly frustrating to developers who are used to creating standalone software products designed for one particular platform and that run completely from start to finish under the developer's control, but if you're developing for the Web, you'll have to lose that mindset and learn to accept the greater control the Web user has over the browsing experience.
Some Notes on Specific 'Force' Attempts
Here are some more specific comments on some of the particular things that people often wish to "force":
Forcing new browser windows to open, close, be sized to specific dimensions, and to lack normal controls like the Back button
Removing sites from the "Back-Button" history
A very common request is to make it impossible for the user to return to a page via the Back button. Sometimes there's even a legitimate reason for this, like to prevent form elements from being submitted twice or out of order, or to protect the security of personal information entered on the page. Other times it's just an unreasonable desire on the part of a control-freak client who can't stand users choosing their own sequence of viewing their site, or even surfing on to other people's sites and coming back to the original site later. Either way, it's not possible. Even with scripting languages, I know of no way to remove sites from the user's history. If your need for this is for an intranet or kiosk where you control the browser, you might look for a custom-made browser that has such functions built in.
Forcing font face, size, and color settings regardless of browser settings
You can suggest font settings in various ways, including stylesheets and various (deprecated in HTML 4.0) presentational tags and attributes. On some browsers, some of these settings "force" your desired settings regardless of the user's configuration. This is a bad idea, because it can result in pages that are unreadable to users with special needs. For instance, those with poor eyesight might want larger fonts, and those with color-blindness might need to set color combinations that are readable to them, even if they look odd to others. The more the site author does to try to defeat such things, and the more the browser cooperates, the less readable the site will be to such users.
Forcing files to download, run, launch specific applications, etc.
You can't do that. The Web protocols were designed to identify, via MIME Content-Type headers, what sort of content a data stream has, but not specify exactly what to do with it. This was done for a good reason; the site author has no way of knowing exactly what sort of system the end user has, or that user's preferences as to how to deal with different kinds of data. And some ways of dealing with data, like automatically running an .exe file, pose security risks such as viruses and "trojan horses". And if the user has a Macintosh or a Unix system, running DOS or Windows .EXEs is infeasible, anyway; but if you let the user download the file, he might be able to put it on a disk and run it on a PC down the hall.
In general, users may want to make their own choices as to how to deal with various kinds of files, displaying them in their browser, displaying them via an external helper application, or saving them to their hard disk, rather than letting your site force one particular behavior that might not even work on this particular user's system. So you should make sure your server sends an honest and accurate Content-Type header for each item it sends.
If you're sending data files of some sort which the user ought to be saving instead of
viewing in his/her browser, the best MIME type to use is
You can always encourage the user to make use of browser features to save a file to disk, such as right-clicking in Netscape or MSIE, which work no matter what MIME type is used or how the browser is configured to handle that type.
Suppressing warning dialog boxes
You might not like it that some browsers display "Security Risk Warnings" when your site tries to set a cookie, launch an applet or ActiveX control, go from secure (encrypted) to nonsecure pages and back again, or other activity that some browsers, under some configuration settings, warn about. Some authors dislike this so much that they ask if there's any way to force the disabling of such warnings. Well, if the Web author could do that, wouldn't that defeat the purpose of these warnings of possible security risks? Get real!
'Hiding' your page source code
This is probably the most common "How Do I Force..." request on the newsgroups these days. People have an exaggerated impression of the value of their HTML code and want to protect it from being "stolen." But there's no way to hide HTML source code from the user. The user's browser needs to receive all the HTML source code in order to display the page, so no matter what devious techniques the author uses to obscure the code, it still has to be parseable by the browser, and is thus not too hard for any halfway-intelligent user to turn into something readable.
One of the great things about the Web is that "newbies" can learn a lot about Web authoring by looking at the source code of pages. That's one of the ways I learned in the first place. By doing this, you'll see lots of examples (both good and bad) of Web authoring techniques, which may help you to eventually produce pages as nice as those of the professionals. The amateur/professional and beginner/expert gaps are much smaller in the Web than in other media, and it's perhaps out of a desire to widen this gap that some of the "professionals" want to find a way to hide their source code. But it still can't be done.
Similarly, there's no way to stop anyone from printing, bookmarking, or linking to your page. When you put something out on the Web, it's fair game for all of this. You still legally own copyright on everything you put on the Web (under present law you've got copyright to anything you create even if it doesn't have a copyright notice on it), and can sue somebody who distributes copies of it without your permission, but you can't stop normal Web use of your documents when they're on the Web, and that includes other sites making links to your page. If you want to make it harder on people, I guess you can keep moving your pages around so that anyone who links to one winds up with a 404 Not Found error the next day, but that would annoy your legitimate users at least as much as anyone you think is "ripping you off."
Some of the people who ask how to suppress the "View Source" feature are not doing this to prevent theft of their code, but because they want to maintain security of something in their code, such as an embedded password or other such thing which could be abused by "hackers" if they knew it. If this is the case, you need to completely re-think your site security plan. Nothing that is present in the code sent to the browser is secure from snooping by users trying to "hack" your site, not even things that are compiled into an applet (which can be decompiled by various utilities). You need to move any aspect of your site that requires security to the server side, not the client side. The server needs to be where passwords are compared, user status and history information is maintained, etc., if you want to be sure none of this is viewable or hackable by end users.
Suppressing right-clicks and copy-and-paste
Submitting or not submitting a form with ENTER
This is entirely under the browser's control, not the site author's. Most browsers will submit on ENTER if there's exactly one text-input field, and not if there are more than one. There's no way to override this. (The presence of checkboxes and radio buttons don't seem to affect browser behavior in this area.)
That MSIE "dotted box"
Make your site better by looking at other sites that show, by example, what not to do!
NOTE: The inclusion of a site in my "Hall of Shame" links should not be construed as any sort of personal attack on the site's creator, who may be a really great person, or even an attack on the linked Web site as a whole, which may be a source of really great information and/or entertainment. Rather, it is simply to highlight specific features (intentional or accidental) of the linked sites which cause problems that could have been avoided by better design. If you find one of your sites is linked here, don't get offended; improve your site so that I'll have to take down the link!
This page was first created 29 Nov 1997, and was last modified 08 May 2016.