Way 2 Freshers

HTML for Lists

1. Bulleted Lists:

 <ul>

begins a bulleted, indented list. Each item in the list is then prefaced with the

<li>

tag. It is not necessary to insert a break at the end of each line — the

<li>

tag automatically creates a new line.

* with <li type=disc>
* with <li type=square>
* with <li type=circle>

2. Numbered Lists:

<ol>

begins a numbered, indented list. Each item in the list is then prefaced with the

 <li>

tag. You need to close the list with the

</ol>

tag. Note: You can expand the

<ol>

to specify the TYPE of numbering:

<ol> 1

(decimal numbers: 1, 2, 3, 4, 5, …)

<ol type="a">

a (lowercase alphabetic: a, b, c, d, e, …)

<ol type="A">

A (uppercase alphabetic: A, B, C, D, E, …)

< ol type="i">

i (lowercase Roman numerals: i, ii, iii, iv, v, …)

< ol type="I">

I (uppercase Roman numerals: I, II, III, IV, V, …)

Are there any problems with using tables for layout?

On current browsers, the entire table must be downloaded and the dimensions of everything in the table must to be known before the table can be rendered. That can delay the rendering of your content, especially if your table contains images without HEIGHT or WIDTH attributes.
If any of your table’s content is too wide for the available display area, then the table stretches to accomodate the oversized content. The rest of the content then adjusts to fit the oversized table rather than fitting the available display area. This can force your readers to scroll horizontally to read your content, or can cause printed versions to be cropped.
For readers whose displays are narrower than the author anticipated, fixed-width tables cause the same problems as other oversized tables. For readers whose displays are wider than the author anticipated, fixed-width tables cause extremely wide margins, wasting much of the display area. For readers who need larger fonts, fixed-width tables can cause the content to be displayed in short choppy lines of only a few words each.
Many browsers are especially sensitive to invalid syntax when tables are involved. Correct syntax is especially critical. Even with correct syntax, nested tables may not display correctly in older versions of Netscape Navigator.
Some browsers ignore tables, or can be configured to ignore tables. These browsers will ignore any layout you’ve created with tables. Also, search engines ignore tables. Some search engines use the text at the beginning of a document to summarize it when it appears in search results, and some index only the first n bytes of a document. When tables are used for layout, the beginning of a document often contains many navigation links that appear before than actual content.
Many versions of Navigator have problems linking to named anchors when they are inside a table that uses the ALIGN attribute. These browsers seem to associate the named anchor with the top of the table, rather than with the content of the anchor. You can avoid this problem by not using the ALIGN attribute on your tables.
If you use tables for layout, you can still minimize the related problems with careful markup. Avoid placing wide images, PRE elements with long lines, long URLs, or other wide content inside tables. Rather than a single full-page layout table, use several independent tables. For example, you could use a table to lay out a navigation bar at the top/bottom of the page, and leave the main content completely outside any layout tables.

How do I eliminate the blue border around linked images?

In your HTML, you can specify the BORDER attribute for the image:

<a href=...><img src=... alt=... border="0"></a>

However, note that removing the border that indicates an image is a link makes it harder for users to distinguish quickly and easily which images on a web page are clickable.

How do I eliminate the space around/between my images?

If your images are inside a table, be sure to set the BORDER, CELLSPACING, and CELLPADDING attributes to 0.
Extra space between images is often created by whitespace around the

 <IMG> tag in the markup.

It is safe to use newlines inside a tag (between attributes), but not between two tags. For example, replace this:

<td ...>
<img src=... alt=...>
<img src=... alt=...>
</td>
 
with this:
 
<td ...><img src=... alt=...><img src=... alt=...></td>

According to the latest specifications, the two should be equivalent. However, common browsers do not comply with the specifications in this situation.
Finally, extra space between images can appear in documents that trigger the “standards” rendering mode of Gecko-based browsers like Mozilla and Firefox.

How can I specify colors?

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.

How do I get form data emailed to me?

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.

Can I prevent a form from being submitted again?

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.

How can I allow file uploads to my web site?

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.

How can I require that fields be filled in, or filled in correctly?

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.

ShareThis