This is the header. Not much use except for the TITLE.
**********************************************************************
Updated: Feb. 02, 1994
Archived at:
http://ftp.eff.org/pub/Net_info/Technical/html_beginners.template
ftp.eff.org, /pub/Net_info/Technical/html_beginners.template
**********************************************************************
NOTE: READ THIS FILE AS TEXT, not as HTML (or, rather, view as HTML to see the examples in action, after reading as plain text). For best results, view with line-wrap OFF, so that overly-long lines go off-screen.
Note that WWW browsers will automatically wrap text (see several examples in this document of overly-long lines). They ignore carriage returns & line feeds.
To view as HTML save as {filename}.html - both lynx and Mosaic seem to
require the .html extension, which is annoying. Parts of this doc will
look terrible in HTML, since they are just examples - some of the text
won't even be visisble at all. Some of the links are real, and some are fake.
**********************************************************************
You can put whatever you want for text, just like any text file or document. Note that use of angle-brackets (greater-than and less-than signs) should be avoided except for HTML tags, unless you know how to properly cause them to display without being interpreted as mangled HTML tags.
will cause a line break.
"Real" carriage returns in the source are ignored, like this.
The above will appear as one line when viewed as a hypertext doc. If the line is overly long, it will be auto-wrapped. Use
to force a break. Note that
breaks, and inserts a blank line (it's a paragraph break).
To just insert a break, with no blank space between it and next line,
use
.
Also, BR, P, and HR do not need /BR, /P or /HR. Many formatting tags DO need closing /COMMANDS or they really mess up the document. If something doesn't look right, look for missing /COMMANDS, missing "s and missing angle-brackets. Those are almost always the culprit.
If you have problems with HR, such that the line appears appended at the end of the previous text material, rather than below it, precede the HR with a BR command.
This will come out italiziced too, but only in graphical browsers. In lynx, it looks like normal text. VAR is intended for specifying variables, and at some point browsers may make it look different from the other tags that italicize.
There are a lot of other similar tags, such as CITE and /CITE (usually italicizes), BLOCKQUOTE (and /BLOCKQUOTE) which indents on both sides, for quoting large excerpts, PRE and /PRE for preformatted text (between PRE and /PRE, spaces, tabs and line endings are NOT ignored, allowing you to place things more carefully, e.g. for program code. Most browsers also display PRE text in a fixed-width/monospaced/nonproportional font.)
This also italicizes in some viewers (probably stands for emphasis). I think one or another of them also accepts EMP instead of EM, but it's best to avoid this tag. STRONG does the same thing as B. This "displays the names of keys on the keyboard whatever that means. This is yet another italicizing tag not supported by all browsers, and intended, similarly to VAR, for displaying a definition. In most such cases, you should avoid these tags, as few browsers implement them, and I and B do just fine.
However, according to some predictions, so-called "physical tags" that say precisely what to do (make it italic, make it bold, etc.) such as I and B will be completely replaced eventually with "logical tags", such as CITE, DFN, VAR, etc. that simply tell the browser what *kind* of text it is, and leave it up to the user's settings (usually called "styles" in the browser configuration) for text display to decide how to display the text. I remain skeptical, as authors have traditionally placed a premium on the abilility to create a work and present it the way it was intended to be presented. The "user controls everything" paradigm makes a mockery of the entire arts and sciences of design, typesetting/typography, and graphic art, and for this reason is unlikely to win out in the end. HTML is primarily a publishers medium, not an audience medium (that is, it was created by and for those that wished to present documents online in a more readable format than ASCII. It was not created by or for readers to gain control over the display of textual information - that control, where it exists, is an incidental, and in some cases counter-productive, by-product of the way browsers work.) At any rate, one should expect a compromise of some sort eventually, probably favoring publishers over audience.
OK! Back to the tags...
This will make a monospaced font text sample, like an example of
a command to type, etc.
This only works in some graphical browsers
(MacWeb, Mosaic). In lynx and some other graphical browsers, it looks like
regular text. (In the case of lynx, it just might have something to do with
the fact that ALL lynx text is monospaced font...)
ADDRESS is a rather useless tag, but frequently used for a "signature" at the bottom of a document:
Stanton McCandlish, mech@eff.org. Personally, I prefer: Stanton McCandlish,mech@eff.org which is much more functional.HTML isn't case sensitive with the angle-bracketed commands (tags). I and i do the same thing.
WARNING: Some browsers do require that the scheme (protocol) definition in a URL be lower case! That is, a URL must be given as http://www.eff.org/ or news:comp.org.eff.news, NOT HTTP://www.eff.org/ or NEWS:comp.org.eff.news (much less NEWS:COMP.ORG.EFF.NEWS). If you are telling your browser to goto a specific URL, and you know it supports uppercase protocol definitions, go for it. But please, NEVER use them in documents on the WWW - your documents will not work for anyone else unless they also use a browser that supports uppercase scheme definitions.
One should also be aware that three characters (the left and right angle-brackets, also known as greater-than and lesser-than, as well as the ampersand or and-sign) must be "escaped" (represented with a code, rather than just typed in) if you want them to appear. This is because they are used for other purposes (e.g. the angle brackets are what define the beginning and end of HTML tags). It's worth noting here that I have yet to find a single browser that will not properly display the ampersand (correct me if I'm wrong - do you see it here?: &), so I suspect the more recent versions of the HTML standard have fixed this. Either that, or people used it so frequently that browsermakers just made sure on their own that it was properly displayed. The ampersand is used (ironically) as the marker for the begining of an escape sequence for one of the three characters, thus its supposed need to BE one of the escaped chars. Go figure. At any rate, ALL the browsers appear to require the angle brackets to be escaped. The codes to use in place of these three characters are: < for lesser-than/open-angle-bracket, > for greater-than/close-angle-bracket, and & for ampersand/and-sign. NOTE: The preceeding sentence will look like nonsense unless you read it in a plain text editor rather than a web browser. IMPORTANT NOTE: The semi-colon after the "&??" parts is mandatory. It does not appear in the text, it simply marks the end of the escape sequence.
This begins the list, and serves as a list title.It's optional
Pretty neat, eh?
This is the EFF Logo
Note that lynx users cannot get regular inlined graphics at all. If you want it downloadable by EVERYONE, make it a clickable link. You can even be really clever about it, and make it both at once, so if someone clicks on the inlined pic, they get a copy of it as a file. You can make a clickable link by doing this:
That just makes a clickable button. The /A tells it that there's a link there, but with no text, so it's just the graphic. This kind of syntax, but with both HREF and SRC pointing to same file, can make a clickable in- lined graphic that can be downloaded as a file, for lynx users. GUI users can also benefit from this technique, since it makes it easier to get and save a copy of the picture, and you can make the inlined version a small preview that points to a larger version to download, to help speed page loading (trust me, readers will appreciate it!) If you're very savvy, you can even include an ALT name saying "click here to get the picture" or something so text-mode readers understand.]
Because some people can't see the graphics, you might want to include text, like so, if you don't want to precede the graphic with a description like we did in the above example:
EFF Welcome Page
That will make *both* the graphic and the "EFF" text -- that is, EVERYTHING between 'A HREF=...' and the /A -- clickable as one unit. For non-gphx. viewers, they see the text, so it makes sense. It may be preferable to use an ALT name, esp.if the picture says what the link is (e.g. the EFF logo, which says "EFF", followed by text that says "EFF", is a bit redundant). Up to you. See below for info on ALT.
You can make an Anchor to point to a file in the same directory.
[NOTE: Previous version of this primer had an error here, and said ..., which is wrong, wrong, wrong. Apologies for any difficulties this caused!] This sometimes works too, but well, that's sloppy syntax, and breaks some clients. No matter what you are linking to, what protocol is used, or where it is, the name of the item should always be in "quotes". Note all the unneccessary spaces in the A HREF="FILENAME_HERE" example. That can actually look ugly in graphical browsers like Mosaic, though it looks OK in lynx. A better version is:
You can make an Anchor to point to a file in the same directory.
You can make an Anchor to point to a file in a *specific* directory. This is the preferred method for all such links, since it is site-independent.
Similarly, a sound can be linked.
And a non-inlined graphic that has to be clicked for to be viewed: Picture!
Such pictures will be downloaded as files, rather than displayed on the web page.
(NOTE: Mozilla/Netscape may actually display it internally using one of it's new features, if you have configured it to do so.) Note that the above did not use a full path, just a filename. As explained above, this means "look in the present directory". It's not a "real" URL, just a local file reference. The better way to do it (e.g. because brittle browsers like MacWeb choke on the above type of link) is to use a full URL, again with "quotes" around the entire path and filename:
[sigh...another serious bug was corrected in the above. Apologies again for any hassle the mistake caused. In this case, it gave wrong info regarding quotes.]
Another cool thing to do for non-graphics users is to add an "ALTernate" text in place of the graphic, e.g. a title or note or description. Do that with the ALT command:
EFF Logo: Click Here
With that syntax, the ALT text replaces the standard and boring "[IMAGE]" note that text-mode browsers replace the image with. It's always best to be maximally informative.
A link to telnet netfind
Another test link to some files & directories
A link to Usenet (NOTE: usenet links use the LOCAL [user's] news server, so for some users, these links will not work, as in cases where no news server is available, or the user's site does not carry the newsgroup in question. To guarantee the availability, you'll need to use special scripts to convert news articles into HTML on your site, and have them available [again via script-based automation] as "http://" not "news:" documents.)
Reference a specific netnews article. (WARNING: These links are NOT permanent - when the news expires, the link will no longer function! Useful mainly for temporary items, and for scripts [e.g. programs that search out news items that match a search criteria, and auto-update links on other pages, etc.])
Post to Usenet. (WARNING: this can be dangerous...use with care - you don't want a newsgroup of 4,000 people mad at you because idiots have posted rude messages via your home page!)
Stanton McCandlish, mech@eff.org
Or: Email Dan Brown, EFF SysAdmin
Pretty nifty.
There are lots of other tricks, some of which are fairly recent developments and not yet supported by all servers and clients, such as HTML forms; image maps - graphics that have specific "hot spots" to click on (e.g. maps where you can click on a city in the picture, and get info about the city); unusual path specifications to account for spaces and odd characters in pathnames or to point to programs and other less common items and options, MPEG animation links, etc., as well as methods to link into specific sections of single documents, as if they were separate documents.
That's all beyond the scope of this small HTML intro. One of the best ways to figure out how to do interesting things with HTML, besides reading as much documentation as you can, is to download pages you like and save them as HTML documents, to review them in a text editor and observe how the authors did what they did.
This is a link back to EFF
[* Systems that charge for access are specifically exempted, as are CD-ROM collections, and similar distribution methods. Just don't demand a special fee for this file itself, you know what we mean. If in doubt, send email about it.]
The Electronic Frontier Foundation
1001 G Street NW, Suite 950 E
Washington DC 20001 USA
+1 202 347 5400 (voice)
+1 202 393 5509 (fax)
+1 202 638 6120 (BBS)
Internet: ask@eff.org
Internet fax gate: remote-printer.EFF@9.0.5.5.3.9.3.2.0.2.1.tpc.int
The Electronic Frontier Foundation (EFF) was founded in July of 1990 to ensure that the principles embodied in the Constitution and the Bill of Rights are protected as new communications technologies emerge. Since its inception, EFF has worked to shape our nation's communications infrastructure and the policies that govern it in order to maintain and enhance First Amendment, privacy and other democratic values. We believe that our overriding public goal must be the creation of Electronic Democracy.
Membership & General Info: info@eff.org