HTML FAQ's
FAQ's Questions C FAQ's Questions JAVA FAQ's Questions PHP FAQ's Questions .Net FAQ's Questions HTML FAQ's Questions
Html Faq's
If you want others to view your web page with specific colors, the most appropriate way is to suggest the colors with a style sheet. Cascading Style Sheets use the color and background-color properties to specify text and background colors. To avoid conflicts between the reader's default colors and those suggested by the author, these two properties should always be used together. 
With HTML, you can suggest colors with the TEXT, LINK, VLINK (visited link), ALINK (active link), and BGCOLOR (background color) attributes of the BODY element. 
Note that these attributes are deprecated by HTML 4. Also, if one of these attributes is used, then all of them should be used to ensure that the reader's default colors do not interfere with those suggested by the author. Here is an example: 
<body bgcolor="#ffffff" text="#000000" link="#0000ff" vlink="#800080" alink="#000080"> 
Authors should not rely on the specified colors since browsers allow their users to override document-specified colors.
The only reliable mechanism for processing form submissions is with a server-side (e.g., CGI) program. To send form data to yourself via email, you should use a server-side program that processes the form submission and sends the data to your email address. 
Some web service providers make standard form-to-email programs available to their customers. Check with your service provider for details. 
If you can install CGI programs on your own server, see the answer to the previous question for a list of useful resources. 
If you can't run CGI programs on your own server, you can use a remotely hosted form-to-email services. Note that the provider of a remotely hosted service will have access to any data submitted via the service. 
Forms that use action="mailto:..." are unreliable. According to the HTML specifications, form behavior is explicitly undefined for mailto URIs (or anything else other than HTTP URIs). They may work one way with one software configuration, may work other ways in other software configurations, and may fail completely in other software configurations.
No. The server-side (e.g., CGI) program that processes the form submission must handle duplicate submissions gracefully. 
You could generate the form with a server-side (e.g., CGI) program that adds a hidden field with a unique session ID. Then the server-side program that processes the form submission can check the session ID against a list of previously used session IDs. If the session ID has already been used, then an appropriate action can be taken (e.g., reject the submission, or update the previously submitted data). 
Ultimately, your server-side program must be smart enough to handle resubmitted data. But you can avoid getting resubmitted data by not expiring the confirmation page from form submissions. Since you want to expire pages quickly when they have transient data, you might want to avoid putting transient data on the confirmation page. You could provide a link to a database query that returns transient data though.
These things are necessary for Web-based uploads:
* An HTTP server that accepts uploads.
* Access to the /cgi-bin/ to put the receiving script. Prewritten CGI file-upload scripts are available.
* A form implemented something like this:
<form method="post" enctype="multipart/form-data" action="fup.cgi">
File to upload: <input type=file name=upfile><br>
Notes about the file: <input type=text name=note><br>
<input type=submit value=Press> to upload the file!
</form>
Not all browsers support form-based file upload, so try to give alternatives where possible.
The Perl CGI.pm module supports file upload. The most recent versions of the cgi-lib.pl library also support file upload. Also, if you need to do file upload in conjunction with form-to-email, the Perl package MIME::Lite handles email attachments.
Have the server-side (e.g., CGI) program that processes the form submission send an error message if the field is not filled in properly. Ideally, this error message should include a copy of the original form with the original (incomplete or incorrect) data filled in as the default values for the form fields. The Perl CGI.pm module provides helpful mechanisms for returning partially completed forms to the user. 
In addition, you could use JavaScript in the form's ONSUBMIT attribute to check the form data. If JavaScript support is enabled, then the ONSUBMIT event handler can inform the user of the problem and return false to prevent the form from being submitted. 
Note that the server-side program should not rely upon the checking done by the client-side script.
How do I change the title of a framed document? 
The title displayed is the title of the frameset document rather than the titles of any of the pages within frames. To change the title displayed, link to a new frameset document using TARGET="_top" (replacing the entire frameset).
Just use the image as the link content, like this:

<a href=...><img src=... alt=...></a>
Should I end my URLs with a slash? 
The URL structure defines a hierarchy similar to a filesystem's hierarchy of subdirectories or folders. The segments of a URL are separated by slash characters ("/"). When navigating the URL hierarchy, the final segment of the URL (i.e., everything after the final slash) is similar to a file in a filesystem. The other segments of the URL are similar to the subdirectories and folders in a filesystem. 
When resolving relative URLs (see the answer to the previous question), the browser's first step is to strip everything after the last slash in the URL of the current document. If the current document's URL ends with a slash, then the final segment (the "file") of the URL is null. If you remove the final slash, then the final segment of the URL is no longer null; it is whatever follows the final remaining slash in the URL. Removing the slash changes the URL; the modified URL refers to a different document and relative URLs will resolve differently. 
For example, the final segment of the URL http://www.mysite.com/faq/html/ is empty; there is nothing after the final slash. In this document, the relative URL all.html resolves to http://www.mysite.com/faq/html/all.html (an existing document). If the final slash is omitted, then the final segment of the modified URL http://www.mysite.com/faq/html is "html". In this (nonexistent) document, the relative URL all.html would resolve to http://www.mysite.com/faq/all.html (another nonexistent document). 
When they receive a request that is missing its final slash, web servers cannot ignore the missing slash and just send the document anyway. Doing so would break any relative URLs in the document. Normally, servers are configured to send a redirection message when they receive such a request. In response to the redirection message, the browser requests the correct URL, and then the server sends the requested document. (By the way, the browser does not and cannot correct the URL on its own; only the server can determine whether the URL is missing its final slash.) 
This error-correction process means that URLs without their final slash will still work. However, this process wastes time and network resources. If you include the final slash when it is appropriate, then browsers won't need to send a second request to the server. 
The exception is when you refer to a URL with just a hostname (e.g., http://www.mysite.com). In this case, the browser will assume that you want the main index ("/") from the server, and you do not have to include the final slash. However, many regard it as good style to include it anyway.
"Getting framed" refers to having your documents displayed within someone else's frameset without your permission. This can happen accidentally (the frameset author forgot to use TARGET="_top" when linking to your document) or intentionally (the frameset author wanted to display your content with his/her own navigation or banner frames).

To avoid "framing" other people's documents, you must add TARGET="_top" to all links that lead to documents outside your intended scope.
Unfortunately, there is no reliable way to specify that a particular document should be displayed in the full browser window, rather than in the current frame. One workaround is to use <BASE TARGET="_top"> in the document, but this only specifies the default target frame for links in the current document, not for the document itself.

If the reader's browser has JavaScript enabled, the following script will automatically remove any existing framesets:
<script type="text/javascript">
if (top.frames.length!=0) {
if (window.location.href.replace)
top.location.replace(self.location.href);
else
top.location.href=self.document.href;
}
</script>

An alternative script is

<script type="text/javascript">
function breakOut() {
if (self != top)
window.open("my URL","_top","");
}
</script>
</HEAD>
<BODY onLoad="breakOut()">
Older versions of Netscape Navigator seems to convert pixel-based frame dimensions to whole percentages, and to use those percentage-based dimensions when laying out the frames. Thus, frames with pixel-based dimensions will be rendered with a slightly different size than that specified in the frameset document. The rounding error will vary depending on the exact size of the browser window. 
Furthermore, Navigator seems to store the percentage-based dimensions internally, rather than the original pixel-based dimensions. Thus, when a window is resized, the frames are redrawn based on the new window size and the old percentage-based dimensions. 
There is no way to prevent this behavior. To accommodate it, you should design your site to adapt to variations in the frame dimensions. This is another situation where it is a good idea to accommodate variations in the browser's presentation.
With HTML, you can suggest a background image with the BACKGROUND attribute of the BODY element. Here is an example: 
<body background="imagefile.gif" bgcolor="#ffffff" text="#000000" link="#0000ff" vlink="#800080" alink="#000080"> 
If you specify a background image, you should also specify text, link, and background colors since the reader's default colors may not provide adequate contrast against your background image. The background color may be used by those not using your background image. Authors should not rely on the specified background image since browsers allow their users to disable image loading or to override document-specified backgrounds.
1: Plaintext or any text information viewable from your browser can be easily copied like any other text from any other file. 
2; HTML and web scripts - you will need to view the web page's source code. In the page's source code, copying the <script> and </script> tags as well as all the information in-between these tags will usually enable the script to work on your web page. 
3: Images, sounds, or movies - Almost all images, sounds, and movies can be copied to your computer and then viewed on your webpage. Images can be easily copied from a webpage by right-clicking an image and selecting "Save Picture as" or "Save Image as". Unless the sound or movies file has a direct link to download and save the file to a specified location on your hard disk drive or to view your Internet browser's cache and locate the sound or movie file saved in the cache. 
4. Embedded objects - Looking at the source code of the object to determine the name of the file and how it is loaded, and copy both the code and the file.
How do I specify a specific combination of frames instead of the default document?
This is unfortunately not possible. When you navigate through a site using frames, the URL will not change as the documents in the individual frames change. This means that there is no way to indicate the combination of documents that make up the current state of the frameset. 
The author can provide multiple frameset documents, one for each combination of frame content. These frameset documents can be generated automatically, perhaps being created on the fly by a CGI program. Rather than linking to individual content documents, the author can link to these separate frameset documents using TARGET="_top". Thus, the URL of the current frameset document will always specify the combination of frames being displayed, which allows links, bookmarks, etc. to function normally.