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
<div>The basic syntax for a form is: <form action="[URL]">...</form> <br>When the form is submitted, the form data is sent to the URL specified in the ACTION attribute. This URL should refer to a server-side (e.g., CGI) program that will process the form data. The form itself should contain<br><br>* at least one submit button (i.e., an <input ...="" type="submit"> element),<br>* form data elements (e.g., <input>, <textarea>, and <SELECT>) as needed, and<br>* additional markup (e.g., identifying data elements, presenting instructions) as needed.</textarea> </div>
HTML validators check HTML documents against a formal definition of HTML syntax and then output a list of errors. Validation is important to give the best chance of correctness on unknown browsers (both existing browsers that you haven't seen and future browsers that haven't been written yet).
HTML checkers (linters) are also useful. These programs check documents for specific problems, including some caused by invalid markup and others caused by common browser bugs. Checkers may pass some invalid documents, and they may fail some valid ones.
All validators are functionally equivalent; while their reporting styles may vary, they will find the same errors given identical input. Different checkers are programmed to look for different problems, so their reports will vary significantly from each other. Also, some programs that are called validators (e.g. the "CSE HTML Validator") are really linters/checkers. They are still useful, but they should not be confused with real HTML validators.
When checking a site for errors for the first time, it is often useful to identify common problems that occur repeatedly in your markup. Fix these problems everywhere they occur (with an automated process if possible), and then go back to identify and fix the remaining problems.
Link checkers follow all the links on a site and report which ones are no longer functioning. CSS checkers report problems with CSS style sheets.
No. Most programs that help you write HTML code already know most tags, and create them when you press a button. But you should understand what a tag is, and how it works. That way you can correct errors in your page more easily.
How do I make a form so it can be submitted by hitting ENTER?
The short answer is that the form should just have one <INPUT TYPE=TEXT> and no TEXTAREA, though it can have other form elements like checkboxes and radio buttons.
You cannot do this with HTML. However, you can include a script after the form that sets the focus to the appropriate field, like this:
<form id="myform" name="myform" action=...>
<input type="text" id="myinput" name="myinput" ...>
</form>
<script type="text/javascript">
document.myform.myinput.focus();
</script>
A similar approach uses <body onload=...> to set the focus, but some browsers seem to process the ONLOAD event before the entire document (i.e., the part with the form) has been loaded.
HTML has no mechanism to control this. However, with CSS, you can set the margin-bottom of the form to 0. For example:
<form style="margin-bottom:0;" action=...>
You can also use a CSS style sheet to affect all the forms on a page:
form { margin-bottom: 0 ;
Small forms are sometimes placed within a TD element within a table. This can be a useful for positioning a form relative to other content, but it doesn't help position the form-related elements relative to each other.
To position form-related elements relative to each other, the entire table must be within the form. You cannot start a form in one TH or TD element and end in another. You cannot place the form within the table without placing it inside a TH or TD element. You can put the table inside the form, and then use the table to position the INPUT, TEXTAREA, SELECT, and other form-related elements, as shown in the following example.
<form action="[URL]">
<table border="0">
<tr>
<th scope="row">
<label for="account">Account:</label>
</th>
<td>
<input type="text" name="account" id="account">
</td>
</tr>
<tr>
<th scope="row">
<label for="password">Password:
</th>
<td>
<input type="password" name="password" id="password">
</td>
</tr>
<tr>
<td> </td>
<td><input type="submit" name="Log On"></td>
</tr>
</table>
</form>
No. A form must have exactly one action. However, the server-side (e.g., CGI) program that processes your form submissions can perform any number of tasks (e.g., updating a database, sending email, logging a transaction) in response to a single form submission.
There is no way to do this in HTML only; something else must process the form. JavaScript processing will work only for readers with JavaScript-enabled browsers. CGI and other server-side processing is reliable for human readers, but search engines have problems following any form-based navigation.
The URL structure defines a hierarchy (or relationship) that is similar to the hierarchy of subdirectories (or folders) in the filesystems used by most computer operating systems. 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.
A relative URL omits some of the information needed to locate the referenced document. The omitted information is assumed to be the same as for the base document that contains the relative URL. This reduces the length of the URLs needed to refer to related documents, and allows document trees to be accessed via multiple access schemes (e.g., "file", "http", and "ftp") or to be moved without changing any of the embedded URLs in those documents.
Before the browser can use a relative URL, it must resolve the relative URL to produce an absolute URL. If the relative URL begins with a double slash (e.g., //www.yoursite.com/faq/html/), then it will inherit only the base URL's scheme. If the relative URL begins with a single slash (e.g., /faq/html/), then it will inherit the base URL's scheme and network location.
If the relative URL does not begin with a slash (e.g., all.html , ./all.html or ../html/), then it has a relative path and is resolved as follows.
1. The browser strips everything after the last slash in the base document's URL and appends the relative URL to the result.
2. Each "." segment is deleted (e.g., ./all.html is the same as all.html, and ./ refers to the current "directory" level in the URL hierarchy).
3. Each ".." segment moves up one level in the URL hierarchy; the ".." segment is removed, along with the segment that precedes it (e.g., foo/../all.html is the same as all.html, and ../ refers to the parent "directory" level in the URL hierarchy).
Some examples may help make this clear. If the base document is <URL:http://www.yoursite.com/faq/html/basics.html>, then
all.html and ./all.html
refer to <URL:http://www.yoursite.com/faq/html/all.html>
./
refers to <URL:http://www.yoursite.com/faq/html/>
../
refers to <URL:http://www.yoursite.com/faq/>
../cgifaq.html
refers to <URL:http://www.yoursite.com/faq/cgifaq.html>
../../reference/
refers to <URL:http://www.yoursite.com/reference/>
Please note that the browser resolves relative URLs, not the server. The server sees only the resulting absolute URL. Also, relative URLs navigate the URL hierarchy. The relationship (if any) between the URL hierarchy and the server's filesystem hierarchy is irrelevant.
The HTML 3.2 and HTML 4.0 specifications allow only integer values (representing a number of pixels) for the WIDTH attribute of the TD element. However, the HTML 4.0 DTD allows percentage (and other non-integer) values, so an HTML validator will not complain about <TD WIDTH="xx%">.
It should be noted that Netscape and Microsoft's browsers interpret percentage values for <TD WIDTH=...> differently. However, their interpretations (and those of other table-aware browsers) happen to match when combined with <TABLE WIDTH="100%">. In such situations, percentage values can be used relatively safely, even though they are prohibited by the public specifications.