HTML

Rather than a normal submit button (<input type="submit" ...>), you can use the image input type (<input type="image" ...>). The image input type specifies a graphical submit button that functions like a server-side image map.

Unlike normal submit buttons (which return a name=value pair), the image input type returns the x-y coordinates of the location where the user clicked on the image. The browser returns the x-y coordinates as name.x=000 and name.y=000 pairs.

For compatability with various non-graphical browsing environments, the VALUE and ALT attributes should be set to the same value as the NAME attribute. For example:

<input type="image" name="Send" alt="Send" value="Send" src="send-button.gif">

For the reset button, one could use <button type="reset" ...>, JavaScript, and/or style sheets, although none of these mechanisms work universally.

In HTML, characters can be represented in three ways:

1. a properly coded character, in the encoding specified by the "charset" attribute of the "Content-type:" header;

2. a character entity (&entityname;), from the appropriate HTML specification (HTML 2.0/3.2, HTML 4, etc.);

3. a numeric character reference (&#number;) that specifies the Unicode reference of the desired character. We recommend using decimal references; hexadecimal references are less widely supported.

In theory these representations are equally valid. In practice, authoring convenience and limited support by browsers complicate the issue.

HTTP being a guaranteed "8-bit clean" protocol, you can safely send out 8-bit or multibyte coded characters, in the various codings that are supported by browsers.

A. HTML 2.0/3.2 (Latin-1)

By now there seems no convincing reason to choose &entityname; versus &#number;, so use whichever is convenient.

If you can confidently handle 8-bit-coded characters this is fine too, probably preferred for writing heavily-accented languages. Take care if authoring on non-ISO-8859-based platforms such as Mac, Psion, IBM mainframes etc., that your upload technique delivers a correctly coded document to the server. Using &-representations avoids such problems.

B. A single repertoire other than Latin-1

In such codings as ISO-8859-7 Greek, koi8-r Russian Cyrillic, and Chinese, Japanese and Korean (CJK) codings, use of coded characters is the most widely supported and used technique.

Although not covered by HTML 3.2, browsers have supported this quite widely for some time now; it is a valid option within the HTML 4 specifications--use a validator such as the WDG HTML Validator or the W3C HTML Validation Service which supports HTML 4 and understands different character encodings.

Browser support for coded characters may depend on configuration and font resources. In some cases, additional programs called "helpers" or "add-ins" supply virtual fonts to browsers.

"Add-in" programs have in the past been used to support numeric references to 15-bit or 16-bit code protocols such as Chinese Big5 or Chinese GB2312.

In theory you should be able to include not only coded characters but also Unicode numeric character references, but browser support is generally poor. Numeric references to the "charset-specified" encoding may appear to produce the desired characters on some browsers, but this is wrong behavior and should not be used. Character entities are also problematical, aside from the HTML-significant characters <, & etc.

C. Internationalization per HTML 4

Recent versions of the popular browsers have support for some of these features, but at time of writing it seems unwise to rely on this when authoring for a general audience.

In short, there is no real method or script for making standard HTML source code not viewable. You may consider doing any of the below if they are concerned about your source code.

1. Create the web page in Macromedia Flash or a similar program. The visitor would need to download the Macromedia Flash plug-in and would be unable to view the source code for the flash applet.

2. There are various scripts that will disable the right click feature, preventing the user from saving images or viewing the source. However, this will not protect the source code of your page. For example, Internet Explorer users may still click "View" and "Source" to view the source code of the page, or a user could disable scripts and images can be saved by simply saving the web page to the hard drive.

3. There are several programs that will help scramble your code, making it difficult (not impossible) to read. Again, this is not going to prevent someone from viewing your code.

Thumbnails are very useful, but they take a little bit of time to make. All you need is a graphics editing program that has functions to resize an image (sometimes it's under a function called image attributes). Be advised--when you have made a thumbnail, you will need to save it as something different than the original. Also, you will generally want to link to the larger graphic when you are done.

Here are the steps:

1. Load a copy of the image into your graphics editing program.

2. Determine the ratio the thumbnail to be. (Do you want it to be half the size? One third of the size? One quarter of the size? One tenth of the size?)

3. Find the resize (or change attributes) function of your program. Most programs will recogize a percentage, for example you can type in 25% for height and width if you want the thumbnail to be a quarter of the size. (It it doesn't do percentages, you can calculate it by multiplying the pixels by the percentage. If you have a graphic that is 400 by 100, and you want it 25% of the size, multiple each measurement by .25. In this case, you'll get 100 and 25.)

4. Once you are satisfied with the thumbnail, think of a name for the image. Choose Save As and enter that name. (Tip: I like to just add t after the image name. For taco.jpg I'd use tacot.jpg)

5. Upload the image to your site, and edit your HTML to load the new image name with the new, smaller size. If you wish, you can link to the larger image around the image.

Example: You have taco.jpg which is 400 pixels wide and 100 pixels high. You made a thumbnail of it called tacot.jpg, which is now 100 pixels wide and 25 pixels high. After you have both images uploaded, here's the code:

<a href="taco.jpg"><img src="tacot.jpg" width=100 height=25 border=0 alt="click for larger taco"></a>

You'll find border=0 to be helpful in eliminating a link-colored box around your thumbnail.

Yes, there are several ways to do this. But remember, HTML is not a programming language - it doesn't have `directives': it's a markup language, so trying to compare it to C or Pascal is not going to be very meaningful.

SGML already provides the standard way to do this, using an entry in the DocType Declaration for a file:

<!doctype html public "-//IETF//DTD HTML 3.0//EN" [

<!entity foo system "bar.html">

]>

...

and then later when you want to include the file

...

&foo;

This is the General Entity mechanism used universally in normal SGML work and does exactly what is wanted, with the added benefit that you can have multiple occurrences of &foo; if you need to include some text at more than one place. Unfortunately none of the browsers except Panorama support it, basically because very few of the programmers who write browsers bothered to read up on what can be done.

* The second way is to use the facilities of your server. This has to be enabled by someone with access to the server configuration files (ask your WebMeister). For example, the NCSA server lets you embed a command inside an SGML comment:

<!--#exec cmd="cat myfile.html"-->

Provided this occurs in a file with a special file type (eg .shtml, and this is what has to be specified in the server configuration), the server will parse the file and send out the result of the command embedded in the document.

* There is in fact a vastly easier way to do this. SGML provides a PI mechanism (Processing Instruction) in the form:

<?cat myfile>

SGML/HTML couldn't care what you put inside (except it must not, for obvious reasons, contain the `>' character!). This would be a great way to specify a page break, for example: suppose you were processing an SGML file using PostScript, you could say <?showpage>...but again, none of the browsers except Panorama support this, again because they guys who write them have never bothered to actually read up on how SGML works.

In the frameset document (the HTML document containing the <frameset> <frame> tags), make sure to name the individual frames using the NAME attribute. The following example creates a top frame named "navigation" and a bottom frame named "content":

<frameset rows="*,3*">

<frame name="navigation" src="navigation.html">

<frame name="content" src="content.html">

<noframes><body>

<!-- Alternative non-framed version -->

</body></noframes>

</frameset>

Then, in the document with the link, use the TARGET attribute to specify which frame should be used to display the link. (The value of the TARGET attribute should match the value of the target frame's NAME attribute.) For example:

<a target="content" href=...>

To target a form submission, use the TARGET attribute of the FORM element, like this:

<form target="content" action=...>

Note that when forms are processed entirely by JavaScript, the target frame must be specified in the JavaScript. The value of the TARGET attribute is irrelevant.

Normally, the default target frame is the current frame ("_self"). To change the default target for every link/form on the page, use the TARGET attribute of the BASE element, like this:

There are two basic techniques for updating multiple frames with a single link: The HTML-based technique links to a new frameset document that specifies the new combination of frames. The JavaScript-based solution uses the onClick attribute of the link to update the additional frame (or frames).

The HTML-based technique can link to a new frameset document with the TARGET="_top" attribute (replacing the entire frameset). However, there is an alternative if the frames to be updated are part of a nested frameset. In the initial frameset document, use a secondary frameset document to define the nested frameset. For example:

<frameset cols="*,3*">

<frame src="contents.html" name="Contents">

<frame src="frameset2.html" name="Display">

<noframes>

<!-- Alternative non-framed version -->

</body></noframes>

</frameset>

A link can now use the TARGET="Display" attribute to replace simultaneously all the frames defined by the frameset2.html document.

The JavaScript-based solution uses the onClick attribute of the link to perform the secondary update. For example:

<a href="URL1" target="Frame1" onClick="top.Frame2.location='URL2';">Update frames

The link will update Frame1 with URL1 normally. If the reader's browser supports JavaScript (and has it enabled), then Frame2 will also be updated (with URL2).

The fundamental problem with the design of frames is that framesets create states in the browser that are not addressable. Once any of the frames within a frameset changes from its default content, there is no longer a way to address the current state of the frameset. It is difficult to bookmark - and impossible to link or index - such a frameset state. It is impossible to reference such a frameset state in other media. When the sub-documents of such a frameset state are accessed directly, they appear without the context of the surrounding frameset. Basic browser functions (e.g., printing, moving forwards/backwards in the browser's history) behave differently with framesets. Also, browsers cannot identify which frame should have focus, which affects scrolling, searching, and the use of keyboard shortcuts in general.

Furthermore, frames focus on layout rather than on information structure, and many authors of framed sites neglect to provide useful alternative content in the NOFRAMES element. Both of these factors cause accessibility problems for browsers that differ significantly from the author's expectations and for search engines.