[Terry Allen: comments on HTML spec]
"Daniel W. Connolly" <connolly@hal.com>
Message-id: <9406101615.AA07825@ulua.hal.com>
To: html-ig@oclc.org
Subject: [Terry Allen: comments on HTML spec]
Date: Fri, 10 Jun 1994 11:15:19 -0500
From: "Daniel W. Connolly" <connolly@hal.com>
Content-Length: 58701
------- Forwarded Message
Message-Id: <199406091521.IAA15477@rock>
From: Terry Allen <terry@ora.com>
Date: Thu, 9 Jun 1994 08:21:05 PDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: connolly@hal.com
Subject: comments on HTML spec
Cc: terry@rock.west.ora.com
I inserted comments beginning with >> rather than make changes in
the text (again). See how this works for you. I cut off the
text after the last comment.
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| Hypertext Markup Language (HTML)
| HYPERTEXT MARKUP LANGUAGE (HTML)
|
| An SGML Application Conforming to International Standard I
| SO 8879 -- Standard Generalized Markup Language
|
| About of this Document
|
| This document describes the current practice and current proposals
| for future standardisation of HTML, as a basis for review and
| enhancement.
|
| The document is a draft form of a standard for interchange of
| information on the network which is proposed to be registered as a
| MIME (RFC1521) content type.
|
| Please send comments to connolly@hal.com or the discussion list
| www-html@info.cern.ch.
|
| VERSION
|
| This is version 2.0 of this document, (released $Date: 1994/06/03
| 22:18:28 $) It introduces forms for user input of information. This
| feature is known as a level 2 feature of HTML. All other specified
| features are known as level 1 features. Features of higher levels
| which are under discussion, (such as tables, figures, and
| mathematical formulae) where mentioned are described as "proposed".
|
| The latest version of this document is currently available in
| hypertext on the World-Wide Web as
|
|
| http://www.hal.com/%7Econnolly/html-spec
|
| Abstract
|
| HyperText Markup Language (HTML)
>>is a structured text format that
| can be used to represent
|
| Hypertext news, mail, online documentation, and collaborative
| hypermedia;
|
| Menus of options;
|
| Database query results;
|
| Simple structured documents with inlined graphics.
|
| Hypertext views of existing bodies of information
|
| The World Wide Web (W3) initiative links related information
| throughout the globe. HTML provides one simple format for providing
| linked information, and all W3 compatible programs are required to
| be capable of handling HTML. W3 uses an Internet protocol
| (Hypertext Transfer Protocol, HTTP), which allows transfer
| representations to be negotiated between client and server, the
| result being returned in an extended MIME message. HTML is
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 2
|
|
| therefore just one, but an important one, of the representations
| used with W3.
|
| HTML is proposed as a MIME content type.
|
| HTML refers to the URI specification RFCxxxx.
|
| Implementations of HTML parsers and generators can be found in the
| various W3 servers and browsers, in the public domain W3 code, and
| may also be built using various public domain SGML parsers such as
| [SGMLS] . HTML documents are SGML documents with fairly generic
| semantics appropriate for representing information from a wide
| range of applications.
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| Vocabulary usied in the HTML specification
| VOCABULARY
|
| This specification uses the words below with the precise meaning
| given.
|
| Representation The encoding of information for interchange.
| For example, HTML is a representation of
| hypertext.
|
| Rendering The form of presentation to information to
| the human reader.
|
| Imperatives
|
| may The implementation is not obliged to follow
| this in any way.
|
| must If this is not followed, the implementation
| does not conform to this specification.
|
| shall as "must"
|
| should If this is not followed, though the
| implementation officially conforms to the
| standard, undesirable results may occur in
>> conforms to THIS standard
| practice.
|
| typical Typical rendering is described for many
| elements. This is not a mandatory part of the
| standard but is given as guidance for
| designers and to help explain the uses for
| which the elements were intended.
|
| Notes
|
| Sections marked "Note:" are not mandatory parts of the
| specification but for guidance only.
|
| Status of features
|
| Mandatory These features must be implemented in the
| rendering. Features are mandatory unless
| otherwise mentioned.
|
| Optional Standard HTML features which may safely be
>> what is the force of "Standard" here and s.v. Obsolete?
| ignored by parsers. It is legal to ignore
| these, treat the contents as though the tags
| were not there. (e.g. EM, and processing
>> PIs shouldn't have any content in the sense that elements have
content; what lies between <? and > should be ignored.
| instructions) . Authors should be awarethat
| these features may be ignored by some
| applications.
|
| Proposed The specification of these features is not
| final. They should not be regarded as part
| ofthe standard, but indicate possible
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 2
|
|
| directions for future versions.
|
| Obsolete Not standard HTML. Parsers should implement
| these features as far as possible in order to
| preserve back-compatibility with previous
| versions of this specification.
|
|
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| HTML and MIME
| HTML AND MIME
|
| The definition of the HTML content subtype is
|
| MIME Type name text
|
| MIME subtype name: html
|
| Required parameters: none
|
| Optional parameters: level, version, charset
|
| Level
|
| The level parameter specifies the feature set which is used in the
| document. The level is an integer number, implying that any
| features of same or lower level may be present in the document.
| Levels are defined by this specification.
|
| Version
|
| In order to help avoid future compatibility problems, the version
| parameter may be used to give the version number of this
| specification to which the document conforms. The version number
| appears at the front of this document and within public identifier
| for the SGML DTD.
>> HTML DTD.
|
| Character sets
|
| The base character set (the SGML BASESET) for HTML is ISO Latin-1.
| This is the set referred to by any numeric character references .
| The actual character set used in the representation of an HTML
| document may be ISO Latin 1, or its 7-bit subset which is ASCII.
| There is no obligation for an HTML document to contain any
| characters above decimal 127. It is possible that a transport
>> queerly phrased: "obligation" What are you really trying
to say?
| medium such as electronic mail imposes constraints on the number of
| bits in a representation of a document, though the HTTP access
| protocol used by W3 always allows 8 bit transfer.
|
| When an HTML document is encoded using 7-bit characters, then the
| mechanisms of character references and entity references may be
| used to encode characters in the upper half of the ISO Latin-1 set.
| In this way, documents may be prepared which are suitable for
| mailing through 7-bit limited systems.
|
| CHARACTER SET OPTION (PROPOSED)
|
| The SGML declaration specified ISO Latin 1 as the base character
| set. The charset parameter is reserved for future use. Its intended
>> say what this parameter is, here. An attribute somehwere?
| significance is to override the base character set of the SGML
| declaration. Support of character sets other than ISO-Latin-1 is
| not a requirement for conformance with this specification.
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| Hypertext Markup language and SGML
| HTML AND SGML
|
| This section describes the relationship between HTML and SGML, and
| guides the newcomer through interpretation of the DTD . (This is
| not a full tutorial on SGML, and in the event of any apparent
| conflict, the SGML standard is definitive.)
|
| The HyperText Markup Language is an application conforming to
| International Standard ISO 8879 -- Standard Generalized Markup
| Language [ SGML ]. SGML is a system for defining structured
| document types, and markup languages to represent instances of
| those document types.
|
| Every SGML document has three parts:
|
| An SGML declaration, which binds SGML processing quantities and
| syntax token names to specific values. For example, the SGML
| declaration in the HTML DTD specifies that the string that opens
| a tag is </ and the maximum length of a name is 34 characters.
|
| A prologue including one or more document type declarations,
| which specifiy the element types, element relationships and
| attributes, and references that can be represented by markup.
| The HTML DTD specifies, for example, that the HEAD element
| contains at most one TITLE element.
|
| An instance, which contains the data and markup of the document.
|
| We use the term HTML to mean both the document type and the markup
| language for representing instances of that document type.
|
| The SGML declaration for HTML is given in the appendix ``SGML
| Delcaration for HTML.'' It is implicit among WWW implementations.
|
| The prologue for an HTML document should look like:
>> should be, exactly, except for case.
|
|
| <!DOCTYPE HTML PUBLIC "-//W3O//DTD W3 HTML 2.0//EN">
|
| NOTE: MISSING <DOCTYPE DECLARATION
|
| Many extant HTML documents do not contain a prologue.
| Implementations are encouraged to infer the above prologue if the
| document does not begin with <!.
>> "are encouraged to" but "should". However, the string <!
is too short; when HTML3.0 happens, the entire doctype line
must be scanned.
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| Structured Text in HTML
| STRUCTURED TEXT
|
| An HTML instance is like a text file, except that some of the
| characters are interpreted as markup. The markup gives structure to
| the document.
|
| The instance represents a hierarchy of elements. Each element has a
| name , some attributes , and some content. Most elements are
| represented in the document as a start tag, which gives the name
| and attributes, followed by the content, followed by the end tag.
| For example:
|
|
| <!DOCTYPE HTML PUBLIC "-//W3O//DTD W3 HTML 2.0//EN">
| <HTML>
| <HEAD>
| <TITLE>
| A sample HTML document
| </TITLE>
| </HEAD>
|
| <BODY>
| <H1>
| An Example of Structure
| <br>
| In HTML
| </H1>
| <P>
| Here's a typical paragraph.
| <UL>
| <LI>
| Item one has an
| <A NAME="anchor">
| anchor
| </A>
| <LI>
| Here's item two.
| </UL>
| </BODY>
| </HTML>
|
| Some elements (e.g. BR) are empty. They have no content. They show
| up as just a start tag.
|
| For the rest of the elements, the content is a sequence of data
| characters and nested elements. Some things such as forms and
| anchors cannot be nested, in which case this is mentioned in the
>> in the text below.
| text. Anchors and character highlighting may be put inside other
| constructs.
|
| Tags
>> repetitious of the above
| Most elements start and end with tags. Empty elements have no end
| tag. Start tags are delimited by <and >, and end tags are delimited
| by </ and >. For example:
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 2
|
|
|
|
| <h1> ... </H1> <!-- uppercase = lowercase -->
| <h1 > ... </h1 > <!-- spaces OK before > -->
|
| The following are not valid tags:
|
|
| < h1> <!-- this is not a tag at all -->
>>perfectly valid: it's a start tag. Combine this section
with previous or move it to before previous.
| <H1/> <H=1> <!-- these are markup errors -->
|
| NOTE: SHORTTAG
|
| The SGML declaration for HTML specifies SHORTTAG YES , which means
| that there are some other valid syntaxes for tags, e.g. NET tags:
>> NET = null end tag
| <em/.../ , empty start tags: <> , empty end tags: </> . Until such
| time as support for these idioms is widely deployed, their use is
| strongly discouraged.
|
| The start and end tags for the HTML, HEAD, and BODY elements are
| omissable. The end tags of some other elements (e.g. P, LI, DT, DD)
| can be ommitted (see the DTD for details). This does not change the
| document structure -- the following documents are equivalent:
|
|
| <!DOCTYPE HTML PUBLIC "-//W3O//DTD W3 HTML 2.0//EN">
| <TITLE>Structural Example</TITLE>
| <H1>Structural Example</H1>
| <P>A paragraph...
|
| <!DOCTYPE HTML PUBLIC "-//W3O//DTD W3 HTML 2.0//EN">
| <HTML><HEAD>
| <TITLE>Structural Example</TITLE>
| </HEAD>
| <BODY>
| <H1>Structural Example</H1>
| <P>A paragraph...</P>
| </BODY>
|
| NAMES
|
| The element name immediately follows the tag open delimiter. Names
| consist of a letter followed by up to 33 letters, digits, periods,
| or hyphens. Names are not case sensitive. For example:
|
|
| A H1 h1 another.name name-with-hyphens
|
| ATTRIBUTES
|
| In a start tag, whitespace and attributes are allowed between the
| element name and the closing delimiter. An attribute consists of a
| name, an equal sign, and a value. Whitespace is allowed around the
| equal sign.
|
| The value is either:
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 3
|
|
|
| A string literal, delimited by single quotes or double quotes,
| or
|
| A name token; that is, a sequence of letters, digits, periods,
| or hyphens.
|
| For example:
|
|
| <A HREF="http://host/dir/file.html">
| <A HREF=foo.html >
| <IMG SRC="mrbill.gif" ALT="Mr. Bill says, "Oh Noooo"">
|
| The length of an attribute value (after replacing entity and
| numeric character referencees) is limited to 1024 characters.
|
| NOTE: UNQUOTED ATTRIBUTE VALUE LITERALS
|
| Some implementations allowed any character except space or '>' in a
| name token, for example <A HREF=foo/bar.html> . As a result, there
| are many documents that contain attribute values that should be
| quoted but are not. While parser implementators are encouraged to
| support this idiom, its use in future documents is stictly
| prohibited.
|
| NOTE: > IN ATTRIBUTE VALUE LITERALS
|
| Some implementations also consider any occurence of the > character
| to signal the end of a tag. For compatibility with such
| implementations, it may be necessary to represent > with an entity
| or numeric character reference; for example: <IMG SRC="eq1.ps"
| ALT="a > b">
|
| Attributes with a delcared value of NAME (e.g. ISMAP, COMPACT) may
| be written using a minimized syntax. The markup:
|
|
| <UL COMPACT="COMPACT">
|
| can be written as
|
|
| <UL COMPACT>
|
| Undefined tag and attribute names
|
| It is a principle to be conservative in that which one produces,
| and liberal in that which one accepts. HTML parsers should be
| liberal except when verifying code. HTML generators should generate
| strictly conforming HTML.
|
| The behaviour of WWW applications reading HTML documents and
| discovering tag or attribute names which they do not understand
| should be to behave as though, in the case of a tag, the whole tag
| had not been there but its content had, or in the case of an
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 4
|
|
| attribute, that the attribute had not been present.
|
| Character Data
|
| The charcters between the tags represent text in the ISO-Latin-1
| character set, which is a superset of ASCII. Because certain
| characters will be interpreted as markup, they should be "escaped";
| that is, represented by markup -- entity or numeric character
| references. For example:
|
|
| When a<b, we can show that...
| Brought to you by AT&T
|
| The HTML DTD includes entities for each of the non-ASCII characters
| so that one may reference them by name if it is inconvenient to
| enter them directly:
|
| Kurt Gödel was a famous logician and mathematician.
>>Dan, this is the method that should be encouraged, because the source
is then portable among systems that may not used ISO-Latin1 in
their text-entry environment. ISO-Latin1 may be the native charset
of WWW, but it's not everyone's native charset; yet they can
still use & rather than <
| NOTE: MARKUP CHARACTERS
|
| To ensure that a string of characters has no markup, it is
| sufficient to represent all occurrences of < , > , and & by
| character or entity references.
|
| NOTE: CDATA, RCDATA
|
| There are SGML features ( CDATA , RCDATA ) to allow most < , > ,
| and & characters to be entered without the use of entity or
| character references. Because these features tend to be used and
| implemented inconsistently, and because they require 8-bit
| characters to represent non-ASCII characters, they are not employed
| in this version of the HTML DTD. An earlier HTML specification
| included an XMP element whose syntax is not expressible in SGML.
| Inside the XMP , no markup was recognized except the </XMP> end
| tag. While implementations are encouraged to support this idiom,
| its use is obsolete.
>>I think implementations should not be so encouraged; time to
stamp it out now. It was never legal. Perfect backward
compatibility is impossible with broken instances.
| COMMENTS
|
| To include comments in an HTML document that will be ignored by the
| parser, surround them with <!-- and -->. After the comment
| delimiter, all text up to the next occurrence of -- is ignored.
| Hence comments cannot be nested. Whitespace is allowed between the
| closing -- and >. (But not between the opening <! and --.)
|
| For example:
|
| <HEAD>
| <TITLE>HTML Guide: Recommended Usage</TITLE>
| <!-- Id: Text.html,v 1.6 1994/04/25 17:33:48 connolly Exp -->
| </HEAD>
|
| NOTE: TAGS IN COMMENTS
|
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 5
|
|
| Some historical implementations incorrectly consider a > sign to
| terminate a comment.
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| Elements of HTML
| HTML ELEMENTS
|
| This is a discussion of the elements in the HTML language, and how
| they interact to represent documents.
|
| The HTML Document Element
|
| An HTML document is organized as a HEAD and a BODY, much like memo
| or a mail message:
|
|
| HTML
| |
| |_head
| |_body
|
| The HEAD element is an small unordered collection of information
| about the document, whereas the BODY is an ordered sequence of
| information elements of arbitrary length. This organization allows
| an implementation to determine certain properties of a document --
| the title, for example -- without parsing the entire document.
|
| Information in the HEAD Element
|
| TITLE The title of the document
|
| ISINDEX Sent by a server in a searchable document
|
| NEXTID A parameter used by editors to generate
| unique identifiers
|
| LINK Relationship between this document and
| another. See also the Anchor element ,
| Relationships . A document may have many LINK
| elements.
|
| BASE A record of the URL of the document when
| saved
What does "when saved" mean?
|
| PROPOSED HEAD ELEMENTS
|
| EXPIRES The date after which the document is invalid.
| Semantics as in the HTTP specification.
|
| OBSOLETE HEAD ELEMENTS
|
| META A wrapper for an HTTP element
|
| Body Elements (level 1)
|
| The order of the contents of the BODY element should be preserved
| when it is rendered on the output device.
|
| HYPERTEXT ANCHORS
|
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 2
|
|
| Anchors Sections of text which form the beginning
| and/or end of hypertext links are called
| "anchors" and defined by the A tag.
|
| BLOCK ELEMENTS
|
| These elements typically stack vertically in the rendered flow of
>> These *kinds of elements*, if you don't want to give the element
names directly.
| text. Whitespace between them is ignored.
|
| Headings Several levels of headings are supported.
|
| Paragraph The P element represents a paragraph.
|
| Horizontal Rule A horizontal dividing line
|
| Address style Used to represent authorship or status of a
| document
|
| Blockquote style A block of text quoted from another source.
| Lists Bulleted lists, glossaries, etc.
>> Glossary *lists*, not Glossaries
| Preformatted text Sections in fixed-width font for preformatted
| text.
|
| INLINE ELEMENTS
|
| These elements fall left to right in the rendered flow of text.
>> better, these elements cause no line breaks
| Whitespace between them separates words, except in the PRE element,
| where it has its literal ASCII meaning.
>>what does that mean? that white space shouldn't be collapsed in
PRE but should be everywhere else?
| Special Phrases Emphasis, typographic distinctions, etc.
|
| Line Breaks Indicates a line break in a flow of text.
>> doesn't belong here; goes above with Block Els?
| IMG The IMG tag allows inline graphics.
|
| Body elements (level 2)
|
| ELEMENTS FOR FORMS
|
| The FORM element and various other elements allowed only within it
| describe forms which allow user input.
|
| FORM elements FORM, INPUT, SELECT, OPTION, TEXTAREA, etc
|
| Obsolete elements
|
| The other elements are obsolete but should be recognised by parsers
| for back-compatibility.
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| HEAD -- Elements
| HEAD
|
| The HEAD element contains all information about the document in
| general. It does not contain any text which is part of the
| document: this is in the BODY. Within the head element, only
| certain elements are allowed.
>>without suggesting a change here, I have to remark that I consider
TITLE part of the content of the document, just as the title of a
book is content.
|
| Jun 3 17:22 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| The TITLE element in HTML
| TITLE
|
| The title of a document is specified by the TITLE element. The
| TITLE element must occur in the HEAD of the document.
|
| There may only be one title in any document. It should identify the
| content of the document in a fairly wide context.
|
| It may not contain anchors, paragraph marks, or highlighting. The
| title may be used to identify the node in a history list, to label
| the window displaying the node, etc. It is not normally displayed
| in the text of a document itself. Contrast titles with headings .
| The title should ideally be less than 64 characters in length. That
| is, many applications will display document titles in window
| titles, menus, etc where there is only limited room. Whilst there
| is no limit on the length of a title (as it may be automatically
| generated from other data), information providers are warned that
| it may be truncated if long.
|
| EXAMPLES OF USE
|
| Appropriate titles might be
|
| <TITLE>Rivest and Neuman. 1989(b)</TITLE>
|
| or
|
| <TITLE>A Recipe for Maple Syrup Flap-Jack</TITLE>
|
| or
|
| <TITLE>Introduction -- AFS user's Guide</TITLE>
|
| Examples of inappropriate titles are those which are only
| meaningful within context,
|
| <TITLE>Introduction</TITLE>
|
| or too long,
|
| <TITLE>Remarks on the Quantum-Gravity effects of "Bean
| Pole" diversification in Mononucleosis patients in Developing
| Countries under Economic Conditions Prevalent during
| the Second half of the Twentieth Century, and Related Papers:
| a Summary</TITLE>
|
|
|
|
|
|
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| ISINDEX element in HTML
| ISINDEX
|
| This element informs the reader that the document is an index
| document. As well as reading it, the reader may use a keyword
| search.
|
| The node may be queried with a keyword search by suffixing the node
| address with a question mark, followed by a list of keywords
| separated by plus signs. See the network address format .
|
| Note that this tag is normally generated automatically by a server.
| If it is added by hand to an HTML document, then the client will
| assume that the server can handle a search on the document.
| Obviously the server must have this capability for it to work:
| simply adding <ISINDEX> in the document is not enough to make
| searches happen if the server does not have a search engine!
|
| Status: standard.
|
| Example of use:
|
| <ISINDEX>
>> should remark that this should not be implemented a la Mosaic,
as a field in the flow of the text.
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| LINK -- Elements
| LINK
|
| The LINK element occurs within the HEAD element of an HTML
| document. It is used to indicate a relationship between the
| document and some other object. A document may have any number of
| LINK elements.
|
| The LINK element is empty, but takes the same attributes as the
| anchor element .
|
| Typical uses are to indicate authorship, related indexes and
| glossaries, older or more recent versions, etc. Links can indicate
| a static tree structure in which the document was authored by
| pointing to a "parent" and "next" and "previous" document, for
| example.
|
| Servers may also allow links to be added by those who do not have
| the right to alter the body of a document.
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| The BASE element in HTML
| BASE
|
| This element allows the URL of the document itself to be recorded
| in situations in which the document may be read out of context.
| URLs within the document may be in a "partial" form relative to
| this base address.
|
| Where the base address is not specified, the reader will use the
| URL it used to access the document to resolve any relative URLs.
|
| The one attribute is:
|
| HREF the URL
|
|
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| Tags used in HTML
| NEXT ID
|
| This tag takes a single attribute which is the number of the next
| document-wide numeric identifier to be allocated of the form z123.
|
| When modifying a document, old anchor ids should not be reused, as
>>don't say this; one might want to reuse old anchors. Say that if you
do reuse old anchors, then:
| there may be references stored elsewhere which point to them. This
| is read and generated by hypertext editors. Human writers of HTML
| usually use mnemonic alphabetical identifiers. Browser software may
| ignore this tag.
|
| Example of use:
|
| <NEXTID N=z27>
|
|
|
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| The BODY element in HTML
| BODY
|
| The BODY element contains all the information which is part of the
| document, as opposed information about the document which is in the
| HEAD .
|
| The elements within the BODY element are in the order in which they
| should be presented to the reader.
|
| See the list of things which are allowed within a BODY element .
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| The Anchor element in HTML
| ANCHORS
|
| An anchor is a piece of text which marks the beginning and/or the
| end of a hypertext link.
|
| The text between the opening tag and the closing tag is either the
| start or destination (or both) of a link. Attributes of the anchor
| tag are as follows.
|
| HREF OPTIONAL. If the HREF attribute is present,
| the anchor is sensitive text: the start of a
| link. If the reader selects this text, (s)he
| should be presented with another document
| whose network address is defined by the value
| of the HREF attribute . The format of the
| network address is specified elsewhere . This
| allows for the form HREF="#identifier" to
| refer to another anchor in the same document.
| If the anchor is in another document, the
| attribute is a relative name , relative to
| the documents address (or specified base
| address if any).
|
| NAME OPTIONAL. If present, the attribute NAME
| allows the anchor to be the destination of a
| link. The value of the attribute is an
| identifier for the anchor. Identifiers are
| arbitrary strings but must be unique within
| the HTML document. Another document can then
| make a reference explicitly to this anchor by
| putting the identifier after the address,
| separated by a hash sign .
|
| REL OPTIONAL. An attribute REL may give the
| relationship (s) described by the hypertext
| link. The value is a comma-separated list of
| relationship values. Values and their
| semantics will be registered by the HTML
| registration authority . The default
>> who is that?
this gives false hopes of interoperability, which one can never get
with an open set of attribute values
| relationship if none other is given is void.
| REL should not be present unless HREF is
| present. See Relationship values , REV .
|
| REV OPTIONAL. The same as REL , but the semantics
| of the link type are in the reverse
| direction. A link from A to B with REL="X"
| expresses the same relationship as a link
| from B to A with REV="X". An anchor may have
| both REL and REV attributes.
|
| URN OPTIONAL. If present, this specifies a
| uniform resource number for the document. See
>> for the document that contains it?
| note .
|
| TITLE OPTIONAL. This is informational only. If
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 2
|
|
| present the value of this field should equal
| the value of the TITLE of the document whose
| address is given by the HREF attribute. See
| note .
>> ick; never knew about that.
| METHODS OPTIONAL. The value of this field is a string
| which if present must be a comma separated
>>should be, not must. Other values will parse.
| list of HTTP METHODS supported by the object
| for public use. See note .
|
| All attributes are optional, although one of NAME and HREF is
| necessary for the anchor to be useful. See also: LINK .
|
| Example of use:
|
| See <A HREF="http://info.cern.ch/">CERN</A>'s information for
| more details.
|
| A <A NAME=serious>serious</A> crime is one which is associated
| with imprisonment.
|
| The Organization may refuse employment to anyone convicted
| of a <a href="#serious">serious</A> crime.
|
|
|
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| URN -- MarkUp
| NOTE : UNIVERSAL RESOURCE NUMBERS
|
| URNs are provided to allow a document to be recognized if duplicate
| copies are found. This should save a client implementation from
| picking up a copy of something it already has.
|
| The format of URNs is under discussion (1993) by various working
| groups of the Internet Engineering Task Force.
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| Note: On TITLE attributes of links
| NOTE: TITLE ATTRIBUTE OF LINKS
|
| The link may carry a TITLE attribute which should if present give
| the title of the document whose address is given by the HREF
| attribute.
|
| This is useful for at least two reasons
|
| The browser software may chose to display the title of the
| document as a preliminary to retrieving it, for example as a
| margin note or on a small box while the mouse is over the
| anchor, or during document fetch.
>>Except that this isn't really the title of the doc, which may have
changed, or the TITLE att may have been given the wrong value.
| Some documents -- mainly those which are not marked up text,
| such as graphics, plain text and also Gopher menus, do not come
| with a title themselves, and so putting a title in the link is
| the only way to give them a title. This is how Gopher works.
>>this doesn't give the docs titles at all; the whole mechanism
duplicates the effect of providing the string as the content of the A.
You might say it attributes titles to docs.
| Obviously it leads to duplication of data, and so it is
| dangerous to assume that the title attribute of the link is a
| valid and unique title for the destination document.
|
|
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| LinkMethods -- Elements
| NOTE: METHODS ATTRIBUTE OF LINKS
|
| The METHODS attributes of anchors and links are used to provide
| information about the functions which the user may perform on an
| object. These are more accurately given by the HTTP protocol when
| it is used, but it may, for similar reasons as for the TITLE
| attribute, be useful to include the information in advance in the
| link.
|
| For example, The browser may chose a different rendering as a
| function of the methods allowed (for example something which is
| searchable may get a different icon)
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| Heading elements in HTML
| HEADINGS
|
| Six levels of heading are supported. (Note that a hypertext node
| within a hypertext work tends to need fewer levels of heading than
| a work whose only structure is given by the nesting of headings.)
>>just your opinion. please delete
| A heading element implies all the font changes, paragraph breaks
| before and after, and white space (for example) necessary to render
| the heading. Further character emphasis or paragraph marks are not
| required in HTML.
^^^^^^^^^^^^^^^^
>>may be required by content: delete that too.
| H1 is the highest level of heading, and is recommended for the
| start of a hypertext node. It is suggested that the the text of the
| first heading be suitable for a reader who is already browsing in
| related information, in contrast to the title tag which should
| identify the node in a wider context.
|
| The heading elements are
|
| <H1>, <H2>, <H3>, <H4>, <H5>, <H6>
|
| It is not normal practice to jump from one header to a header level
| more than one below, for example for follow an H1 with an H3.
>>people do it all the time, and you've done it yourself. It doesn't
help to talk about "normal practice."
| Although this is legal, it is discouraged, as it may produce
| strange results for example when generating other representations
| from the HTML.
|
| Example:
example of what re previous note?
|
| <H1>This is a heading</H1>
| Here is some text
| <H2>Second level heading</H2>
| Here is some more text.
|
| Parser Note:
|
| Parsers should not require any specific order to heading elements,
| even if the heading level increases by more than one between
| successive headings.
|
| Typical Rendering
|
| H1 Bold very large font, centered. One or two
| lines clear space between this and anything
| following. If printed on paper, start new
| page.
|
| H2 Bold, large font,, flush left against left
| margin, no indent. One or two clear lines
| above and below.
|
| H3 Italic, large font, slightly indented from
| the left margin. One or two clear lines above
| and below.
|
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 2
|
|
| H4 Bold, normal font, indented more than H3. One
| clear line above and below.
|
| H5 Italic, normal font, indented as H4. One
| clear line above.
|
| H6 Bold, indented same as normal text, more than
| H5. One clear line above.
|
| These typical values are just an indication, and it is up to the
| designer of the presentation software to define the styles. The
| reader may have options to customize these. When writing documents,
| you should assume that whatever is done it is designed to have the
| same sort of effect as the styles above.
|
| The rendering software is responsible for generating suitable
| vertical white space between elements, so it is NOT normal or
| required to follow a heading element with a paragraph mark.
>>it certainly is if a para follows a heading. Say instead that
it is not necessary to obtain white space to use a P HERE.
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| Paragraphs in HTML
| P: PARAGRAPH
|
| The empty P element represents a paragraph. The exact rendering of
| this (indentation, leading, etc) is not defined here, and may be a
| function of other tags, style sheets etc.
|
| You do NOT need to use <P> to put white space around heading, list,
| address or blockquote elements. It is the responsibility of the
| rendering software to generate that white space. An empty paragraph
| has undefined effect and should be avoided.
|
| Typical rendering
|
| Typically, paragraphs are surrounded by a small vertical space (of
| a line or half a line). This is not the case (typically) within
| ADDRESS or (ever) within PRE elements. With some implementations,
| normal paragraphs may have a small extra left indent on the first
| line.
|
| Examples of use
|
| <h1>What to do</h1>
| <p>This is a one paragraph.<P>This is a second.
| <P>
| This is a third.
|
| Bad example
|
| <h1><P>What not to do</h1>
| <address><p>I found that on my XYZ browser it looked prettier
| to
| me if I put some paragraph tags</address>
| <p>
| <ul><p><li>Around lists, and
| <li>Inside headings.
| </ul>
| <p>
| <h2>None of the paragraph tags in this example should
| be there.</h2>
|
| See also
|
| Line Break
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| Line Breaks in HTML
| LINE BREAK
|
| The line break element marks that a new line must be started at the
| given point.
|
| Typical rendering
|
| A new line with indent the same as that of line-wrapped text.
|
| Examples
|
| <ADDRESS>Tim Berners-Lee<BR>
| World Wide Web project<BR>
| CERN<BR>1211 Geneva 23<BR>Switzerland
| </ADDRESS>
|
| I think that I shall never see<BR>
| A hoarding lovely as a tree<BR>
| In fact, unless the hoardings fall<BR>
| I'll never see a tree at all.<P>
|
|
|
| See also:
|
| the P (paragraph) element
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| Highlighting in HTML
| CHARACTER HIGHLIGHTING
|
| Status: Extra
|
| These elements allow sections of text to be formatted in a
| particular way, to provide emphasis, etc. The tags do NOT cause a
| paragraph break, and may be used on sections of text within
| paragraphs.
|
| Where not supported by implementations, like all tags, these tags
| should be ignored but the content rendered.
|
| All these tags have related closing tags, as in
|
| This is <EM>emphasized</EM> text.
|
| Some of these styles are more explicit than others about how they
| should be physically represented. The logical styles should be used
>>too prescriptive; say "may produce better results"
| wherever possible, unless for example it is necessary to refer to
| the formatting in the text. (Eg, "The italic parts are mandatory".)
|
| NOTE:
|
| Browsers unable to display a specified style may render it in some
| alternative, or the default, style, with some loss of quality for
| the reader. Some implementations may ignore these tags altogether,
| so information providers should attempt not to rely on them as
| essential to the information content.
|
| These element names are derived from TeXInfo macro names.
|
| Physical styles
|
| TT Fixed-width typewriter font.
|
| B Boldface, where available, otherwise
| alternative mapping allowed.
|
| I Italic font (or slanted if italic
| unavailable).
>>do you want to say what I get if I <b><i>do this?</></>
| U Underline.
|
| Logical styles
|
| EM Emphasis, typically italic.
|
| STRONG Stronger emphasis, typically bold.
|
| CODE Example of code. typically monospaced font.
| (Do not confuse with PRE )
|
| SAMP A sequence of literal characters.
|
| KBD in an instruction manual, Text typed by a
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 2
|
|
| user.
|
| VAR A variable name.
|
| DFN The defining instance of a term. Typically
| bold or bold italic.
|
| CITE A citation. Typically italic.
|
| STRIKE "strike out" text, as in a legal document.
|
| Examples of use
|
| This text contains an <em>emphasized</em> word.
| <strong>Don't assume</strong> that it will be italic!
| It was made using the <CODE>EM</CODE> element. A citation is
| typically italic and has no formal necessary structure:
| <cite>Moby Dick</cite> is a book title.
|
|
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| The IMG Element in HTML
| IMG: EMBEDDED IMAGES
|
| Status: Extra
|
| The IMG element allows another document to be inserted inline. The
| document is normally an icon or small graphic, etc. This element is
| NOT intended for embedding other HTML text.
|
| Browsers which are not able to display inline images ignore IMG
| elements. Authors should note that some browsers will be able to
| display (or print) linked graphics but not inline graphics. If the
| graphic is essential, it may be wiser to make a link to it rather
| than to put it inline. If the graphic is essentially decorative,
| then IMG is appropriate.
|
| The IMG element is empty: it has no closing tag. It has two
| attributes:
|
| SRC The value of this attribute is the URL of the
| document to be embedded. Its syntax is the
| same as that of the HREF attribute of the A
| tag. SRC is mandatory.
|
| ALIGN Take values TOP or MIDDLE or BOTTOM, defining
| whether the tops or middles of bottoms of the
| graphics and text should be aligned
| vertically.
|
| ALT Optional alternative text as an alternative
| to the graphics for display in text-only
| environments.
|
| Note that IMG elements are allowed within anchors.
|
| Example
|
| Warning: < IMG SRC ="triangle.gif" ALT="Warning:"> This must b
| e done by a
| qualified technician.
|
| < A HREF="Go.html">< IMG SRC ="Button.ps" ALT="GO"></A>
|
|
|
|
|
|
|
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| Horizontal Rules in HTML
| HORIZONTAL RULE
|
| Typical Rendering
|
| Some sort of divider between sections of text such as a full width
| horizontal rule or equivalent graphic.
|
| Example
|
| The horizontal rule is typically used for separating heading
| information (when more than just a heading) from content, etc.
|
| <H1>The Albatross</H1>
| <Address>The Bumstead Monthly, 1948</Address>
| The following information is culled from
| this and suvccessive issues of the magazine.
| Thanks are due to the editor-in-chief,
| A.R. Bunstead, for her help and advice.
| <H2>Copyright IQR Inc.</h2>
| This recording may not be sold, resold,
| hired out, used, or talked about in too great
| a depth without the publisher's written or
| videotaped consent.
| <HR>
| The Albatross, most fabled and infamous of ..
|
|
|
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| Tags used in HTML
| ADDRESS
|
| This element is for address information, signatures, authorship,
| etc, often at the top or bottom of a document.
|
| Typical rendering
|
| Typically, an address element is italic and/or right justified or
| indented. The address element implies a paragraph break. Paragraph
| marks within the address element do not cause extra white space to
| be inserted.
|
| Examples of use:
|
| <ADDRESS><A HREF="Author.html">A.N.Other</A></ADDRESS>
|
|
| <ADDRESS>
| Newsletter editor<p>
| J.R. Brown<p>
| JimquickPost News, Jumquick, CT 01234<p>
| Tel (123) 456 7890
| </ADDRESS>
|
|
|
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| BlockQuote in HTML
| BLOCKQUOTE
|
| The BLOCKQUOTE element allows text quoted from another source to be
| rendered specially.
|
| Typical rendering
|
| A typical rendering might be a slight extra left and right indent,
| and/or italic font. BLOCKQUOTE causes a paragraph break, and
| typically a line or so of white space will be allowed between it
| and any text before or after it.
|
| Single-font rendition may for example put a vertical line of ">"
| characters down the left margin to indicate quotation in the
| Internet mail style.
|
| Example
|
| I think it ends
| <BLOCKQUOTE>Soft you now, the fair Ophelia. Nymph, in thy orisons,
| be all my sins remembered.
| </BLOCKQUOTE>
| but I am not sure.
|
|
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 1
|
|
| Lists and glossaries in HTML
| FORMS OF LIST IN HTML
|
| These lists may be nested
>>A glossary is a book part, like a chapter. These are glossary *LISTS*
| Glossaries
|
| A glossary (or definition list) is a list of paragraphs each of
| which has a short title alongside it. Apart from glossaries, this
| element is useful for presenting a set of named elements to the
| reader. The elements within a glossary follow are introduced by
| these elements:
|
| DT The "term", typically placed in a wide left
| indent
|
| DD The "definition", which may wrap onto many
| lines
|
| These elements must appear in pairs. Single occurrences of DT
| without a following DD are allowed, and have the same significance
| as if the DD had been present with no text.. The one attribute
| which DL can take is
|
| COMPACT suggests that a compact rendering be used,
| because the enclosed elements are
| individually small, or the whole glossary is
| rather large, or both.
|
| TYPICAL RENDERING
|
| The definition list DT, DD pairs are arranged vertically. For each
| pair, the DT element is on the left, in a column of about a third
| of the display area, and the DD element is in the right hand two
| thirds of the display area. The DT term is normally small enough to
| fit on one line within the left-hand column. If it is longer, it
| will either extend across the page, in which case the DD section is
| moved down to separate them, or it is wrapped onto successive lines
| of the left hand column.
|
| This is sometimes implemented with the use of a large negative
| first line indent.
|
| White space is typically left between successive DT,DD pairs unless
| the COMPACT attribute is given. The COMPACT attribute is
| appropriate for lists which are long and/or have DT,DD pairs which
| each take only a line or two. It is of course possible for the
| rendering software to discover these cases itself and make its own
| decisions, and this is to be encouraged.
|
| The COMPACT attribute may also reduce the width of the left-hand
| (DT) column.
|
| EXAMPLES OF USE
|
| <DL>
| Jun 3 17:23 1994 HTML Specification Connolly and Berners-Lee Page 2
|
|
| <DT>Term the first<DD>definition paragraph is reasonably
| long but is still displayed clearly
| <DT>Term2 follows<DD>Definition of term2
| </DL>
|
| <DL COMPACT>
| <DT>Term<DD>definition paragraph
| <DT>Term2<DD>Definition of term2
| </DL>
|
|
|
|
| Lists
|
| A list is a sequence of paragraphs, each of which may be preceded
| by a special mark or sequence number. The syntax is:
>>no, it's a sequence of list items, each of which may have multiple
paras. You should give one example of multiple paras here.
>>end of Terry's comments
- --
Terry Allen (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472
------- End of Forwarded Message