RFC 1866

Hypertext Markup Language - 2.0

πŸ“… published November 1995, from ietf

RFC 1866: Hypertext Markup Language - 2.0 πŸ’–

Okay bestie, this is RFC 1866, titled Hypertext Markup Language - 2.0 πŸŽ€ It's a Network Working Group document, written by T. Berners-Lee (MIT/W3C) and D. Connolly (also MIT/W3C). It's on the Standards Track and it's dated November 1995 πŸ“…. The title block doesn't list anything it obsoletes or updates, so there's no drama there πŸ™ˆ


Status of this Memo ✨

Okay so this part is the official vibe check. This document is an Internet standards track protocol for the Internet community, and it literally wants your discussion and suggestions for improvements 🫢 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited 🌈

Abstract 🌸

The Hypertext Markup Language (HTML) is a simple markup language used to create hypertext documents that are platform independent. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML markup can represent hypertext news, mail, documentation, and hypermedia; menus of options; database query results; simple structured documents with in-lined graphics; and hypertext views of existing bodies of information. It's giving versatile πŸ’…

HTML has been in use by the World Wide Web (WWW) global information initiative since 1990. This specification roughly corresponds to the capabilities of HTML in common use prior to June 1994. HTML is an application of ISO Standard 8879:1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML).

The "text/html" Internet Media Type (RFC 1590) and MIME Content Type (RFC 1521) is defined by this specification πŸ¦‹

Table of Contents πŸ“œ

    1.     Introduction ........................................... 2
    1.1    Scope .................................................. 3
    1.2    Conformance ............................................ 3
    2.     Terms .................................................. 6
    3.     HTML as an Application of SGML .........................10
    3.1    SGML Documents .........................................10
    3.2    HTML Lexical Syntax ................................... 12
    3.3    HTML Public Text Identifiers .......................... 17
    3.4    Example HTML Document ................................. 17
    4.     HTML as an Internet Media Type ........................ 18
    4.1    text/html media type .................................. 18
    4.2    HTML Document Representation .......................... 19
    5.     Document Structure .................................... 20
    5.1    Document Element: HTML ................................ 21
    5.2    Head: HEAD ............................................ 21
    5.3    Body: BODY ............................................ 24
    5.4    Headings: H1 ... H6 ................................... 24
    5.5    Block Structuring Elements ............................ 25
    5.6    List Elements ......................................... 28
    5.7    Phrase Markup ......................................... 30
    5.8    Line Break: BR ........................................ 34
    5.9    Horizontal Rule: HR ................................... 34
    5.10   Image: IMG ............................................ 34
    6.     Characters, Words, and Paragraphs ..................... 35
    6.1    The HTML Document Character Set ....................... 36
    7.     Hyperlinks ............................................ 36
    7.1    Accessing Resources ................................... 37
    7.2    Activation of Hyperlinks .............................. 38
    7.3    Simultaneous Presentation of Image Resources .......... 38
    7.4    Fragment Identifiers .................................. 38
    7.5    Queries and Indexes ................................... 39
    7.6    Image Maps ............................................ 39
    8.     Forms ................................................. 40
    8.1    Form Elements ......................................... 40
    8.2    Form Submission ....................................... 45
    9.     HTML Public Text ...................................... 49
    9.1    HTML DTD .............................................. 49
    9.2    Strict HTML DTD ....................................... 61
    9.3    Level 1 HTML DTD ...................................... 62
    9.4    Strict Level 1 HTML DTD ............................... 63
    9.5    SGML Declaration for HTML ............................. 64
    9.6    Sample SGML Open Entity Catalog for HTML .............. 65
    9.7    Character Entity Sets ................................. 66
    10.    Security Considerations ............................... 69
    11.    References ............................................ 69
    12.    Acknowledgments ....................................... 71
    12.1   Authors' Addresses .................................... 71
    13.    The HTML Coded Character Set .......................... 72
    14.    Proposed Entities ..................................... 75

1. Introduction ✨

The HyperText Markup Language (HTML) is a simple data format used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains 🌈

Since HTML is an application of SGML, this spec assumes you already have a working knowledge of [SGML] 🧚

1.1. Scope 🌸

HTML has been in use by the World-Wide Web (WWW) global information initiative since 1990. Before that, informal documentation on HTML was floating around on the Internet from a number of sources. This specification brings together, clarifies, and formalizes a set of features that roughly corresponds to the capabilities of HTML in common use prior to June 1994. A number of new features for HTML are being proposed and experimented with in the Internet community πŸ‘‘

This document defines HTML 2.0 (to distinguish it from the previous informal specifications). Future versions of HTML with new features will be released with higher version numbers, and they're generally upwardly compatible πŸ’–

HTML is an application of ISO Standard 8879:1986, "Information Processing Text and Office Systems; Standard Generalized Markup Language" (SGML). The HTML Document Type Definition (DTD) is a formal definition of the HTML syntax in terms of SGML πŸŽ€

This specification also defines HTML as an Internet Media Type[IMEDIA] and MIME Content Type[MIME] called `text/html'. So it defines the semantics of the HTML syntax and how that syntax should be interpreted by user agents πŸ¦‹

1.2. Conformance πŸ’…

This specification governs the syntax of HTML documents and aspects of the behavior of HTML user agents 🫢

1.2.1. Documents πŸ¦‹

A document is a conforming HTML document if:

  • It is a conforming SGML document, and it conforms to the HTML DTD (see 9.1, "HTML DTD").
NOTE - There are a number of syntactic idioms that are not supported or are supported inconsistently in some historical user agent implementations. These idioms are identified in notes like this throughout this specification. πŸ™ˆ
  • It conforms to the application conventions in this specification. For example, the value of the HREF attribute of the <A> element must conform to the URI syntax.
  • Its document character set includes [ISO-8859-1] and agrees with [ISO-10646]; that is, each code position listed in 13, "The HTML Coded Character Set" is included, and each code position in the document character set is mapped to the same character as [ISO-10646] designates for that code position.
NOTE - The document character set is somewhat independent of the character encoding scheme used to represent a document. For example, the `ISO-2022-JP' character encoding scheme can be used for HTML documents, since its repertoire is a subset of the [ISO-10646] repertoire. The critical distinction is that numeric character references agree with [ISO-10646] regardless of how the document is encoded. 🌈

1.2.2. Feature Test Entities πŸŽ€

The HTML DTD defines a standard HTML document type and several variations, using feature test entities. These are declarations in the HTML DTD that control the inclusion or exclusion of portions of the DTD, so they're kind of the switches 🧚

HTML.Recommended : Certain features of the language are necessary for compatibility with widespread usage, but they may compromise the structural integrity of a document. This feature test entity selects a more prescriptive document type definition that eliminates those features. It is set to `IGNORE' by default.

For example, in order to preserve the structure of a document, an editing user agent may translate HTML documents to the recommended subset, or it may require that the documents be in the recommended subset for import. ✨

HTML.Deprecated : Certain features of the language are necessary for compatibility with earlier versions of the specification, but they tend to be used and implemented inconsistently, and their use is deprecated. This feature test entity enables a document type definition that allows these features. It is set to `INCLUDE' by default.

Documents generated by translation software or editing software should not contain deprecated idioms. πŸ’€

1.2.3. User Agents πŸ’œ

An HTML user agent conforms to this specification if:

  • It parses the characters of an HTML document into data characters and markup according to [SGML].
NOTE - In the interest of robustness and extensibility, there are a number of widely deployed conventions for handling non-conforming documents. See 4.2.1, "Undeclared Markup Error Handling" for details. πŸ“
  • It supports the `ISO-8859-1' character encoding scheme and processes each character in the ISO Latin Alphabet No. 1 as specified in 6.1, "The HTML Document Character Set".
NOTE - To support non-western writing systems, HTML user agents are encouraged to support `ISO-10646-UCS-2' or similar character encoding schemes and as much of the character repertoire of [ISO-10646] as is practical. 🌸
  • It behaves identically for documents whose parsed token sequences are identical.
  • It allows the user to traverse (or at least attempt to traverse, resources permitting) all hyperlinks from <A> elements in an HTML document.

For example, comments and the whitespace in tags disappear during tokenization, so they don't influence the behavior of conforming user agents πŸ™Œ

An HTML user agent is a level 2 user agent if, additionally:

  • It allows the user to express all form field values specified in an HTML document and to (attempt to) submit the values as requests to information services. πŸ”₯

2. Terms ✨

okay bestie, this is the glossary section and it's giving dictionary but make it iconic πŸ’… Every term here has a specific meaning in the rest of the doc, so pls don't skip it 🫢

  • absolute URI: a URI in absolute form, for example as per [URL] πŸ”—
  • anchor: one of the two ends of a hyperlink, usually a phrase marked as an <A> element πŸ’–
  • base URI: an absolute URI that gets combined with a relative URI to figure out another absolute URI 🧭
  • character: an atom of information, like a letter or a digit ✨ Graphic characters have glyphs (the pretty visible shapes), while control characters have processing semantics (they tell the system to do something) πŸŽ€
  • character encoding scheme: a function whose domain is sequences of octets and whose range is sequences of characters from a character repertoire. So an octet sequence plus a character encoding scheme gives you a sequence of characters πŸ¦‹
  • character repertoire: a finite set of characters, e.g. the range of a coded character set πŸ“š
  • code position: an integer. A coded character set and a code position from its domain together determine a character πŸ”’
  • coded character set: a function whose domain is a subset of the integers and whose range is a character repertoire. Basically, for some set of integers (usually something like {0, 1, 2, ..., N}), a coded character set and an integer in that set give you a character. And the reverse works too: a character and a coded character set give you its code position (or, in rare cases, a few code positions) 🌈
  • conforming HTML user agent: a user agent that conforms to this specification in how it processes the Internet Media Type text/html πŸ’œ
  • data character: characters other than markup, which make up the content of elements 🌸
  • document character set: a coded character set whose range includes all the characters used in a document. Every SGML document has exactly one document character set, and numeric character references get resolved through it πŸ”‘
  • DTD: document type definition. Rules that apply SGML to the markup of a particular type of document, including a set of element and entity declarations. [SGML] πŸ“œ
  • element: a component of the hierarchical structure defined by a DTD. In a document instance it's identified by descriptive markup, usually a start-tag and end-tag. [SGML] 🧱
  • end-tag: descriptive markup that identifies the end of an element. [SGML] 🏁
  • entity: data with an associated notation or interpretation, for example a sequence of octets associated with an Internet Media Type. [SGML] 🎁
  • fragment identifier: the portion of an HREF attribute value that comes after the # character, and which modifies the presentation of a hyperlink's destination πŸ¦„
  • form data set: a sequence of name/value pairs. The names come from an HTML document and the values come from a user πŸ“
  • HTML document: an SGML document that conforms to this document type definition πŸ’…
  • hyperlink: a relationship between two anchors, called the head and the tail. The link goes from the tail to the head. The head and tail are also known as the destination and source, respectively πŸ”—βœ¨
  • markup: syntactically delimited characters added to a document's data to represent its structure. There are four kinds: descriptive markup (tags), references, markup declarations, and processing instructions. [SGML] 🧩
  • may: a document or user interface is conforming whether this statement applies or not. Totally optional, and totally fine 🌷
  • media type: an Internet Media Type, as per [IMEDIA] πŸŽ€
  • message entity: a head and a body. The head is a collection of name/value fields, and the body is a sequence of octets. The head defines the content type and content transfer encoding of the body. [MIME] πŸ’Œ
  • minimally conforming HTML user agent: a user agent that conforms to this specification except for form processing. It may only process level 1 HTML documents 🌱
  • must: documents or user agents in conflict with this statement are not conforming 🚫
  • numeric character reference: markup that refers to a character by its code position in the document character set πŸ”’πŸ’–
  • SGML document: a sequence of characters organized physically as a set of entities, and logically into a hierarchy of elements. It's made of data characters and markup. The markup describes the structure of the information and an instance of that structure. [SGML] 🌟
  • shall: if a document or user agent conflicts with this statement, it does not conform to this specification πŸ™…β€β™€οΈ
  • should: if a document or user agent conflicts with this statement, undesirable results may occur in practice, even though it still conforms to this specification πŸ™ˆ
  • start-tag: descriptive markup that identifies the start of an element and specifies its generic identifier and attributes. [SGML] πŸš€
  • syntax-reference character set: a coded character set whose range includes all the characters used for markup, e.g. name characters and delimiter characters 🧠
  • tag: markup that delimits an element. A tag includes a name that refers to an element declaration in the DTD, and may include attributes. [SGML] 🏷️
  • text entity: a finite sequence of characters. It typically takes the form of a sequence of octets with some associated character encoding scheme, transmitted over the network or stored in a file. [SGML] πŸ“„
  • typical: typical processing is described for many elements. It's not a mandatory part of the spec, but it's given as guidance for designers and to explain what the elements were intended for 🧁
  • URI: a Uniform Resource Identifier is a formatted string that serves as an identifier for a resource, typically on the Internet. URIs are used in HTML to identify the anchors of hyperlinks. URIs in common practice include Uniform Resource Locators (URLs) [URL] and Relative URLs [RELURL] πŸŒπŸ¦‹
  • user agent: a component of a distributed system that presents an interface and processes requests on behalf of a user. For example, a www browser or a mail user agent 🧚
  • WWW: the World-Wide Web is a hypertext-based, distributed information system created by researchers at CERN in Switzerland. <URL:http://www.w3.org/> πŸ•ΈοΈβœ¨

3. HTML as an Application of SGML

okay so HTML is an application of ISO 8879:1986 -- Standard Generalized Markup Language (SGML) πŸŽ€ SGML is a system for defining structured document types and markup languages to represent instances of those document types [SGML]. The public text (the DTD and SGML declaration) of the HTML document type definition is given in 9, "HTML Public Text" πŸ“–

The term "HTML" refers to both the document type defined here and the markup language used to represent instances of that document type. two-for-one, iconic πŸ’…

3.1. SGML Documents

an HTML document is an SGML document πŸ’– That means it's a sequence of characters organized physically into a set of entities, and logically as a hierarchy of elements 🧩

In the SGML specification, the first production of the SGML syntax grammar splits an SGML document into three parts: an SGML declaration, a prologue, and an instance. For the purposes of this specification, the prologue is a DTD. This DTD describes another grammar. The start symbol is given in the doctype declaration, the terminals are data characters and tags, and the productions are determined by the element declarations. The instance must conform to the DTD, which means it has to be in the language defined by this grammar 🌸

The SGML declaration decides the lexicon of the grammar. It specifies the document character set, which determines a character repertoire that contains all the characters appearing in all text entities in the document, plus the code positions associated with those characters πŸ”‘

The SGML declaration also specifies the syntax-reference character set of the document, and a few other parameters that bind the abstract syntax of SGML to a concrete syntax. This concrete syntax determines how the sequence of characters in the document gets mapped to a sequence of terminals in the grammar of the prologue πŸ¦„

For example, consider the following document:

<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
<title>Parsing Example</title>
<p>Some text. <em>&#42;wow&#42;</em></p>

An HTML user agent should use the SGML declaration given in 9.5, "SGML Declaration for HTML". According to its document character set, &#42; refers to an asterisk character, * ✨

The instance above gets read as the following sequence of terminals πŸ‘‘

  1. start-tag: TITLE
  2. data characters: "Parsing Example"
  3. end-tag: TITLE
  4. start-tag: P
  5. data characters "Some text."
  6. start-tag: EM
  7. data characters: "*wow*"
  8. end-tag: EM
  9. end-tag: P

The start symbol of the DTD grammar is HTML, and the productions are given in the public text identified by -//IETF//DTD HTML 2.0//EN (9.1, "HTML DTD"). The terminals above parse as 🧚

HTML
 |
 \-HEAD
 |  |
 |  \-TITLE
 |      |
 |      \-<TITLE>
 |      |
 |      \-"Parsing Example"
 |      |
 |      \-</TITLE>
 |
 \-BODY
   |
   \-P
     |
     \-<P>
     |
     \-"Some text. "
     |
     \-EM
     |  |
     |  \-<EM>
     |  |
     |  \-"*wow*"
     |  |
     |  \-</EM>
     |
     \-</P>

Some of the elements are delimited explicitly by tags, while the boundaries of others are inferred 🌈 The <HTML> element contains a <HEAD> element and a <BODY> element. The <HEAD> contains <TITLE>, which is explicitly delimited by start- and end-tags πŸŽ€

3.2. HTML Lexical Syntax

SGML specifies an abstract syntax and a reference concrete syntax. Aside from certain quantities and capacities (e.g. the limit on the length of a name), all HTML documents use the reference concrete syntax. In particular, all markup characters are in the repertoire of [ISO-646]. Data characters are drawn from the document character set (see 6, "Characters, Words, and Paragraphs") πŸ’œ

A complete discussion of SGML parsing, e.g. the mapping of a sequence of characters to a sequence of tags and data, is left to the SGML standard [SGML]. This section is only a summary 🫢✨

3.2.1. Data Characters ✨

okay so bestie, any sequence of characters that isn't markup just gets mapped straight to data characters πŸ’– (see 9.6 "Delimiter Recognition" of [SGML] for how markup gets spotted). Some markup maps to data characters too πŸ¦‹. Numeric character references become single-character strings through the document character set, and every one of the general entities defined in the HTML DTD maps to a single-character string πŸ’…

For example,

 abc&lt;def    => "abc","<","def"
 abc&#60;def   => "abc","<","def"

the terminating semicolon on entity or numeric character references is only necessary when the character after the reference would otherwise get read as part of the name (see 9.4.5 "Reference End" in [SGML]) πŸ™ˆ

abc &lt def     => "abc ","<"," def"
abc &#60 def    => "abc ","<"," def"

an ampersand only counts as markup when it's followed by a letter, or by a `#' and a digit πŸ”₯

abc & lt def    => "abc & lt def"
abc &# 60 def    => "abc &# 60 def"

if you want to turn plain text into HTML, a useful trick is to swap each '<', '&', and '>' for an entity reference or numeric character reference, like so πŸŽ€

          ENTITY      NUMERIC
CHARACTER REFERENCE   CHAR REF     CHARACTER DESCRIPTION
--------- ----------  -----------  ---------------------
  &       &amp;       &#38;        Ampersand
  <       &lt;        &#60;        Less than
  >       &gt;        &#62;        Greater than
NOTE πŸ’€ SGML has mechanisms called CDATA and RCDATA declared content that let most <, >, and & characters go in without entity references. But these get used and implemented inconsistently, and they clash with the tricks for squishing HTML down to 7-bit ASCII for transport, so this version of HTML deprecates them. See 5.5.2.1, "Example and Listing: XMP, LISTING" for more on that.

3.2.2. Tags 🏷️

tags are how elements get marked off, like headings, paragraphs, lists, character highlighting, and links 🌸 Most HTML elements show up as a start-tag (which gives the element name and attributes), then the content, then an end tag πŸ’œ Start-tags sit between < and >, and end tags sit between </ and > ✨ Here's an example:

<H1>This is a Heading</H1>

some elements only have a start-tag and no end-tag. For instance, you use the <BR> tag to make a line break πŸ“ Also, the end tags of some other elements can be left out, like Paragraph (</P>), List Item (</LI>), Definition Term (</DT>), and Definition Description (</DD>) elements 🧚

the content of an element is a mix of data character strings and nested elements πŸ¦‹ Some elements, like anchors, can't be nested 😭 Anchors and character highlighting can go inside other constructs though πŸ’… Check out 9.1, "HTML DTD" in the HTML DTD for all the full details.

NOTE πŸ™ˆ The SGML declaration for HTML sets SHORTTAG YES, which means there are other valid tag syntaxes too: NET tags, <EM/.../'; empty start tags, <>; and empty end-tags, </>. Until support for these idioms is widely deployed, their use is strongly discouraged.

3.2.3. Names πŸŽ€

a name is a letter followed by letters, digits, periods, or hyphens πŸ’– A name can be at most 72 characters, thanks to the NAMELEN' parameter in the SGML declaration for HTML (see 9.5, "SGML Declaration for HTML") ✨ Element and attribute names don't care about case, but entity names do πŸ‘‘ So <BLOCKQUOTE>, <BlockQuote>, and <blockquote>are all the same, whereas&amp;is different from&AMP;` πŸ’…

In a start-tag, the element name has to come right after the tag open delimiter < 🫢

3.2.4. Attributes πŸ¦‹

in a start-tag, white space and attributes can sit between the element name and the closing delimiter 🌈 An attribute specification usually looks like an attribute name, an equal sign, and a value, though some can be just a name token πŸ’œ White space is allowed around the equal sign ✨

The value of the attribute may be either:

  • A string literal, delimited by single quotes or double quotes and not containing any occurrences of the delimiting character.
    • NOTE πŸ’€ Some historical implementations treat any > character as the end of a tag. For compatibility with them, when > shows up in an attribute value, it should be written as a numeric character reference. For example, <IMG SRC="eq1.jpg" alt="a>b"> should be written <IMG SRC="eq1.jpg" alt="a&#62;b"> or <IMG SRC="eq1.jpg" alt="a&gt;b">.
  • A name token (a sequence of letters, digits, periods, or hyphens). Name tokens are not case sensitive.
    • NOTE πŸ™ˆ Some historical implementations let any character except space or > appear in a name token.

In this example, <img> is the element name, src is the attribute name, and 'http://host/dir/file.gif' is the attribute value πŸ“

<img src='http://host/dir/file.gif'>

if you need an attribute value literal for a given string, a handy trick is to swap each quote and white space character for an entity reference or numeric character reference, like this πŸŽ€

          ENTITY      NUMERIC
CHARACTER REFERENCE   CHAR REF     CHARACTER DESCRIPTION
--------- ----------  -----------  ---------------------
  HT                  &#9;         Tab
  LF                  &#10;        Line Feed
  CR                  &#13;        Carriage Return
  SP                  &#32;        Space
  "       &quot;      &#34;        Quotation mark
  &       &amp;       &#38;        Ampersand

for example 🧚

<IMG SRC="image.jpg" alt="First &quot;real&quot; example">

the `NAMELEN' parameter in the SGML declaration (9.5, "SGML Declaration for HTML") caps the length of an attribute value at 1024 characters πŸ”₯

attributes like ISMAP and COMPACT can use a minimized syntax (see 7.9.1.2 "Omitted Attribute Name" in [SGML]) 🌸 So this markup:

<UL COMPACT="compact">

can be written with the minimized syntax like this:

<UL COMPACT>
NOTE πŸ’€ Some historical implementations only understand the minimized syntax.

3.2.5. Comments πŸ’¬

to put comments in an HTML document, you use a comment declaration πŸ’– It starts with <!, followed by zero or more comments, followed by > πŸ’… Each comment begins with -- and covers all the text up to and including the next -- ✨ Inside a comment declaration, white space can go after each comment, but not before the first one πŸ¦‹ The whole comment declaration gets ignored 🫢

NOTE πŸ’€ Some historical HTML implementations wrongly treat any > character as the end of a comment.

for example 🌈

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HEAD>
<TITLE>HTML Comment Example</TITLE>
<!-- Id: html-sgml.sgm,v 1.5 1995/05/26 21:29:50 connolly Exp  -->
<!-- another -- -- comment -->
<!>
</HEAD>
<BODY>
<p> <!- not a comment, just regular old data characters ->

3.3. HTML Public Text Identifiers πŸͺͺ

to say a piece of information is an HTML document that follows this spec, each document must start with one of the document type declarations below πŸ’…

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

this one refers to the HTML DTD in 9.1, "HTML DTD" ✨

NOTE πŸ™ˆ If the body of a text/html message entity doesn't begin with a document type declaration, an HTML user agent should infer the declaration above.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Level 2//EN">

this document type declaration also refers to the HTML DTD that shows up in 9.1, "HTML DTD" πŸ¦‹

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Level 1//EN">

this one points to the level 1 HTML DTD in 9.3, "Level 1 HTML DTD" 🌸 Form elements must not show up in level 1 documents 😭

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Strict//EN">
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Strict Level 1//EN">

these two declarations refer to the HTML DTD in 9.2, "Strict HTML DTD" and 9.4, "Strict Level 1 HTML DTD" πŸ‘‘ They point to the more structurally rigid definition of HTML, so no cap, they're the strict ones πŸ’…

HTML user agents may support other document types 🌈 In particular, they may support other formal public identifiers, or other document types altogether 🧚 They may also support an internal declaration subset with supplemental entity, element, and other markup declarations πŸ’œ

3.4. Example HTML Document πŸ“„

here's a full example document, bestie, so you can see how all the pieces fit together πŸŽ€

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML>
<!-- Here's a good place to put a comment. -->
<HEAD>
<TITLE>Structural Example</TITLE>
</HEAD><BODY>
<H1>First Header</H1>
<P>This is a paragraph in the example HTML file. Keep in mind
that the title does not appear in the document text, but that
the header (defined by H1) does.</P>
<OL>
<LI>First item in an ordered list.
<LI>Second item in an ordered list.
  <UL COMPACT>
  <LI> Note that lists can be nested;
  <LI> Whitespace may be used to assist in reading the
       HTML source.
  </UL>
<LI>Third item in an ordered list.
</OL>
<P>This is an additional paragraph. Technically, end tags are
not required for paragraphs, although they are allowed. You can
include character highlighting in a paragraph. <EM>This sentence
of the paragraph is emphasized.</EM> Note that the &lt;/P&gt;
end tag has been omitted.
<P>
<IMG SRC ="triangle.xbm" alt="Warning: ">
Be sure to read these <b>bold instructions</b>.
</BODY></HTML>

4. HTML as an Internet Media Type ✨

an HTML user agent lets users interact with resources that have HTML representations πŸ’– At a minimum, it must let users examine and navigate the content of HTML level 1 documents 🫢 HTML user agents should be able to keep all the formatting distinctions in an HTML document, and show the resources referred to by IMG elements at the same time 🌸 (They can skip some formatting distinctions or IMG resources if the user asks them to πŸ™ˆ) Level 2 HTML user agents should support form entry and submission πŸ’…

4.1. text/html media type ✨

okay so this spec officially defines the Internet Media Type [IMEDIA] (back in the day it was called the Content Type [MIME]) named text/html πŸŽ€ and it gets registered with [IANA] πŸ’…

Media Type name
        text

Media subtype name
        html

Required parameters
        none

Optional parameters
        level, charset

Encoding considerations
        any encoding is allowed

Security considerations
        see 10, "Security Considerations"

bestie, the two optional parameters are where it gets fun 🧚

Level 🌸 The level parameter tells you which feature set the document uses. It's an integer, and it means any features at the same level or lower MAY be in the document. Level 1 is everything in this spec EXCEPT the stuff that needs the <FORM> element. Level 2 adds form processing. Level 2 is the default, so if you don't say, that's what you get πŸ’–

Charset πŸ¦‹ The charset parameter (as defined in section 7.1.1 of RFC 1521[MIME]) MAY be given to say which character encoding scheme is used to turn the HTML document into a sequence of octets. The default is outside the scope of this spec, but for example it's US-ASCII in MIME mail and ISO-8859-1 over HTTP [HTTP] πŸ“


4.2. HTML Document Representation πŸ“œ

a message entity with a content type of text/html represents an HTML document, and it's made of a single text entity πŸ’œ The charset parameter (whether it's implicit or explicit) names the character encoding scheme. The text entity is made of the characters that scheme decodes, plus the octets in the body of the message entity. no cap, it's that simple 🫢

4.2.1. Undeclared Markup Error Handling πŸ™ˆ

okay this part is so clever. To help experiments and interop between different HTML versions, the installed base of HTML user agents actually supports a superset of HTML 2.0 by reducing it back down to HTML 2.0. So markup in the form of a start-tag or end-tag whose generic identifier is NOT declared just gets mapped to nothing during tokenization 🧹 Undeclared attributes get the same treatment. The whole attribute spec of an unknown attribute (the attribute, plus its value if it has one) SHOULD be ignored. On the flip side, references to undeclared entities SHOULD be treated as data characters ✨

here are the examples, lowkey my favourite part:

<div class=chapter><h1>foo</h1><p>...</div>
  => <H1>,"foo",</H1>,<P>,"..."
xxx <P ID=z23> yyy
  => "xxx ",<P>," yyy
Let &alpha; &amp; &beta; be finite sets.
  => "Let &alpha; & &beta; be finite sets."

Support for telling the user about these errors is encouraged πŸ””

Warning 🚨 Information providers, this convention is NOT binding. Unspecified behavior may result, because markup like this doesn't conform to this spec. don't say I didn't warn you πŸ’€

4.2.2. Conventional Representation of Newlines πŸƒ

SGML says a text entity is a sequence of records. Each one starts with a record start character and ends with a record end character (code positions 10 and 13 respectively) (section 7.6.1, "Record Boundaries" in [SGML]) 🌈

[MIME] says a body of type text/* is a sequence of lines, and each line is terminated by CRLF, which is octets 13, 10 πŸ’…

the tea is that in practice, HTML docs get represented and sent with whatever end-of-line convention the source uses. Usually that's CR only, LF only, or a CR LF pair. So when you decode the octets, you often end up with a text entity that's missing some record start and record end characters 😭

Since there's no ambiguity about what they should be, HTML user agents are encouraged to infer the missing record start and end characters 🧠✨

An HTML user agent SHOULD treat end of line, in any of its variations, as a word space in every context EXCEPT preformatted text. Inside preformatted text, an HTML user agent SHOULD treat any of the three common end-of-line representations as starting a new line πŸŽ€


5. Document Structure ✨

an HTML document is a tree of elements. It has a head and a body, plus headings, paragraphs, lists, and so on 🌳 Form elements are covered in 8, "Forms" πŸ’–

5.1. Document Element: HTML πŸ‘‘

the HTML document element is a head and a body, kinda like a memo or a mail message πŸ’Œ The head holds the title and some optional elements. The body is the text flow, made of paragraphs, lists, and other elements 🌸

5.2. Head: HEAD 🧁

the head of an HTML document is an unordered collection of info about the doc. Like this:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HEAD>
<TITLE>Introduction to HTML</TITLE>
</HEAD>
...

5.2.1. Title: TITLE πŸ’œ

Every HTML document MUST contain a <TITLE> element 🏷️

the title should identify what the doc is about in a global context. A short title like "Introduction" can be meaningless out of context πŸ™ƒ A title like "Introduction to HTML Elements" is way more appropriate ✨

NOTE The length of a title is not limited, but long titles may be truncated in some applications. To keep that from happening, titles SHOULD be fewer than 64 characters. πŸ’…

A user agent MAY display the title of a document in a history list, or as the label for the window showing the doc. This is different from headings (5.4, "Headings: H1 ... H6"), which usually show up in the body text flow πŸ¦‹

5.2.2. Base Address: BASE πŸ—ΊοΈ

the optional <BASE> element gives a base address for interpreting relative URLs when the doc is read out of context (see 7, "Hyperlinks") πŸ”— The value of the HREF attribute MUST be an absolute URI πŸ™Œ

5.2.3. Keyword Index: ISINDEX πŸ”

the <ISINDEX> element tells the user agent that the user should be able to search an index by typing keywords πŸ”Ž See 7.5, "Queries and Indexes" for the deets 🫢

the <LINK> element represents a hyperlink (see 7, "Hyperlinks") 🌈 Any number of LINK elements MAY occur in the <HEAD> element of an HTML doc. It has the same attributes as the <A> element (see 5.7.3, "Anchor: A") πŸ’–

LINK is typically used for authorship, related indexes and glossaries, older or newer versions, document hierarchy, and associated resources like style sheets, etc. It's giving organization πŸ“š

5.2.5. Associated Meta-information: META 🧾

the <META> element is an extensible container for identifying specialized document meta-information πŸͺ„ Meta-information does two main jobs:

  • to give a way to discover that the data set exists, and how it might be obtained or accessed; and
  • to document the content, quality, and features of a data set, so you can tell whether it's fit for use.

Each <META> element specifies a name/value pair. If there are multiple META elements with the same name, their combined contents (concatenated as a comma-separated list) become the value for that name πŸŽ€

NOTE The <META> element SHOULD NOT be used where a specific element, like <TITLE>, would be more appropriate. Instead of a <META> element with a URI as the CONTENT value, use a <LINK> element πŸ™ˆ

HTTP servers MAY read the content of the document <HEAD> to generate header fields for any elements that define a value for the HTTP-EQUIV attribute 🧚

NOTE How a server pulls out the document meta-information is unspecified and NOT mandatory. The <META> element is just an extensible way to identify and embed that info. How it gets used is up to the server implementation and the HTML user agent πŸ’…

Attributes of the META element 🌸

  • HTTP-EQUIV binds the element to an HTTP header field. An HTTP server MAY use this info to process the doc. In particular, it MAY include a header field in responses to requests for this doc: the header name comes from the HTTP-EQUIV attribute value, and the header value comes from the CONTENT attribute. HTTP header names are not case sensitive πŸ™Œ
  • NAME specifies the name of the name/value pair. If it isn't present, HTTP-EQUIV gives the name 🏷️
  • CONTENT specifies the value of the name/value pair πŸ’–

Examples ✨

if the document contains:

<META HTTP-EQUIV="Expires"
      CONTENT="Tue, 04 Dec 1993 21:29:02 GMT">
<meta http-equiv="Keywords" CONTENT="Fred">
<META HTTP-EQUIV="Reply-to"
      content="fielding@ics.uci.edu (Roy Fielding)">
<Meta Http-equiv="Keywords" CONTENT="Barney">

then the server MAY include these header fields:

Expires: Tue, 04 Dec 1993 21:29:02 GMT
Keywords: Fred, Barney
Reply-to: fielding@ics.uci.edu (Roy Fielding)

as part of the HTTP response to a GET or HEAD request for that doc πŸ¦‹

An HTTP server MUST NOT use the <META> element to form an HTTP response header UNLESS the HTTP-EQUIV attribute is present πŸ›‘

An HTTP server MAY disregard any <META> elements that specify info controlled by the HTTP server itself, like Server, Date, and Last-modified 🫢

5.2.6. Next Id: NEXTID πŸͺͺ

the <NEXTID> element is only there for historical reasons πŸ•°οΈ HTML docs SHOULD NOT contain <NEXTID> elements πŸ™ˆ

<NEXTID> gives a hint for the name to use for a new <A> element when you're editing an HTML doc. It SHOULD be distinct from all NAME attribute values on <A> elements. For example:

<NEXTID N=Z27>

5.3. Body: BODY 🌷

the <BODY> element holds the text flow of the doc, including headings, paragraphs, lists, etc. πŸ“–

<BODY>
<h1>Important Stuff</h1>
<p>Explanation about important stuff...
</BODY>

5.4. Headings: H1 ... H6 πŸŽ€

the six heading elements, <H1> through <H6>, mark section headings πŸ’… The DTD doesn't restrict the order or how often headings show up, but docs SHOULD NOT skip levels (like going from H1 straight to H3), because converting them to other formats is often a mess 😩

Example of use:

<H1>This is a heading</H1>
Here is some text
<H2>Second level heading</H2>
Here is some more text.

Typical renderings are:

  • H1: bold, very large font, centered. One or two blank lines above and below. πŸ‘‘
  • H2: bold, large font, flush-left. One or two blank lines above and below. 🌸
  • H3: italic, large font, slightly indented from the left margin. One or two blank lines above and below. πŸ¦‹
  • H4: bold, normal font, indented more than H3. One blank line above and below. πŸ“
  • H5: italic, normal font, indented as H4. One blank line above. 🧚
  • H6: bold, indented same as normal text, more than H5. One blank line above. πŸ’œ

5.5. Block Structuring Elements 🧱

block structuring elements include paragraphs, lists, and block quotes ✨ They MUST NOT contain heading elements, but they MAY contain phrase markup, and in some cases they MAY be nested 🫢

5.5.1. Paragraph: P πŸ’–

okay so the <P> element is how you mark up a paragraph πŸŽ€ the exact indentation, leading space, all that stuff isn't locked down, and it MAY depend on other tags, style sheets, etc. ✨

usually paragraphs get a vertical gap of one line or half a line around them 🌸 and sometimes the first line gets indented πŸ’…

example of use bc you need to see it 🫢

<H1>This Heading Precedes the Paragraph</H1>
<P>This is the text of the first paragraph.
<P>This is the text of the second paragraph. Although you do not
need to start paragraphs on new lines, maintaining this
convention facilitates document maintenance.</P>
<P>This is the text of a third paragraph.</P>

5.5.2. Preformatted Text: PRE πŸ“

the <PRE> element is for a character cell block of text 🧚 it's perfect for anything formatted for a monospaced font, so it's giving typewriter energy ⌨️

the <PRE> tag MAY be used with the OPTIONAL WIDTH attribute 🌈 WIDTH sets the max number of characters on a line and lets the HTML user agent pick a good font and indent πŸ’–

inside preformatted text, here's the tea:

  • line breaks in the text get rendered as a move to the beginning of the next line πŸ¦‹
  • anchor elements and phrase markup MAY be used 🫢
  • elements that define paragraph formatting (headings, address, etc.) MUST NOT be used πŸ™…β€β™€οΈ
  • the horizontal tab character (code position 9 in the HTML document character set) MUST be interpreted as the smallest positive nonzero number of spaces which will leave the number of characters so far on the line as a multiple of 8. documents SHOULD NOT contain tab characters, bc they aren't supported consistently 😭
NOTE - References to the "beginning of a new line" do not imply that the renderer is forbidden from using a constant left indent for rendering preformatted text. The left indent MAY be constrained by the width REQUIRED.
NOTE - Constraints on the processing of <PRE> content MAY limit or prevent the ability of the HTML user agent to faithfully render phrase markup.
NOTE - Some historical documents contain <P> tags in <PRE> elements. User agents are encouraged to treat this as a line break. A <P> tag followed by a newline character SHOULD produce only one line break, not a line break plus a blank line. no double dipping on the spacing, bestie πŸ’€

example of use πŸŽ€

<PRE>
Line 1.
       Line 2 is to the right of line 1.     <a href="abc">abc</a>
       Line 3 aligns with line 2.            <a href="def">def</a>
</PRE>

5.5.2.1. Example and Listing: XMP, LISTING 🧚

the <XMP> and <LISTING> elements are like <PRE> but with a different syntax πŸ™ˆ their content is declared as CDATA, which means no markup is recognized except the end-tag open delimiter-in-context (see 9.6 "Delimiter Recognition" of [SGML]). it's a whole vibe πŸŒ€

NOTE - In a previous draft of the HTML specification, the syntax of <XMP> and <LISTING> elements allowed closing tags to be treated as data characters, as long as the tag name was not <XMP> or <LISTING>, respectively.

ok but CDATA content has a bunch of messy interactions with processing techniques and gets implemented inconsistently 😭 so HTML documents SHOULD NOT contain <XMP> nor <LISTING> elements. <PRE> is more expressive and more consistently supported, so use that instead πŸ’…

the <LISTING> element SHOULD be rendered so that at least 132 characters fit on a line πŸ“ the <XMP> element SHOULD be rendered so that at least 80 characters fit on a line, but otherwise it's identical to <LISTING> 🫢

NOTE - In a previous draft, HTML included a <PLAINTEXT> element that is similar to the <LISTING> element, except that there is no closing tag: all characters after the <PLAINTEXT> start-tag are data. πŸ¦–

5.5.3. Address: ADDRESS πŸ’Œ

the <ADDRESS> element holds info like address, signature and authorship, usually at the beginning or end of the body of a document ✍️

it's typically rendered in an italic typeface and MAY be indented 🌸

example of use πŸ“

<ADDRESS>
Newsletter editor<BR>
J.R. Brown<BR>
JimquickPost News, Jimquick, CT 01234<BR>
Tel (123) 456 7890
</ADDRESS>

5.5.4. Block Quote: BLOCKQUOTE πŸŽ€

the <BLOCKQUOTE> element holds text quoted from another source πŸ“œ

a typical rendering is a slight extra left and right indent, and/or italic font, with space above and below the quote πŸ’œ a single-font rendition MAY reflect the quotation style of Internet mail by putting a vertical line of graphic characters, like the greater than symbol (>), in the left margin 🌈

example of use 🎭

I think the play ends
<BLOCKQUOTE>
<P>Soft you now, the fair Ophelia. Nymph, in thy orisons, be all
my sins remembered.
</BLOCKQUOTE>
but I am not sure.

5.6. List Elements πŸ“‹

HTML has a bunch of list elements 🫧 they MAY be used in combination. for example, an <OL> MAY be nested in an <LI> element of a <UL> πŸͺ„

the COMPACT attribute suggests a compact rendering 🀏

5.6.1. Unordered List: UL, LI πŸ”Έ

the <UL> represents a list of items, typically rendered as a bulleted list 🫧

its content is a sequence of <LI> elements. for example πŸ’–

<UL>
<LI>First list item
<LI>Second list item
 <p>second paragraph of second item
<LI>Third list item
</UL>

5.6.2. Ordered List: OL πŸ”’

the <OL> element represents an ordered list of items, sorted by sequence or order of importance πŸ‘‘ it's typically rendered as a numbered list ✨

its content is a sequence of <LI> elements. for example πŸŽ€

<OL>
<LI>Click the Web button to open URI window.
<LI>Enter the URI number in the text field of the Open URI
window. The Web document you specified is displayed.
  <ol>
   <li>substep 1
   <li>substep 2
  </ol>
<LI>Click highlighted text to move from one link to another.
</OL>

5.6.3. Directory List: DIR πŸ“

the <DIR> element is like <UL>. it represents a list of short items, typically up to 20 characters each 🧁 items in a directory list MAY be arranged in columns, typically 24 characters wide 🌷

its content is a sequence of <LI> elements. nested block elements are not allowed in <DIR> content πŸ™…β€β™€οΈ for example πŸ’…

<DIR>
<LI>A-H<LI>I-M
<LI>M-R<LI>S-Z
</DIR>

5.6.4. Menu List: MENU πŸ”

the <MENU> element is a list of items with typically one line per item 🍭 the menu list style is typically more compact than an unordered list 🀏

its content is a sequence of <LI> elements. nested block elements are not allowed in <MENU> content πŸ™…β€β™€οΈ for example 🌸

<MENU>
<LI>First item in the list.
<LI>Second item in the list.
<LI>Third item in the list.
</MENU>

5.6.5. Definition List: DL, DT, DD πŸ“–

a definition list is a list of terms and their definitions 🧠 they're typically formatted with the term flush-left and the definition, in paragraph style, indented after the term 🫢

the content of a <DL> element is a sequence of <DT> elements and/or <DD> elements, usually in pairs. multiple <DT> MAY be paired with a single <DD> element. documents SHOULD NOT contain multiple consecutive <DD> elements 🚫

example of use πŸŽ€

<DL>
<DT>Term<DD>This is the definition of the first term.
<DT>Term<DD>This is the definition of the second term.
</DL>

if the DT term doesn't fit in the DT column (typically one third of the display area), it MAY be extended across the page with the DD section moved to the next line, or it MAY be wrapped onto successive lines of the left hand column 🌈

the OPTIONAL COMPACT attribute suggests a compact rendering, bc the list items are small and/or the whole list is large 🀏

unless COMPACT is present, an HTML user agent MAY leave white space between successive DT, DD pairs. the COMPACT attribute MAY also reduce the width of the left-hand (DT) column πŸ’–

<DL COMPACT>
<DT>Term<DD>This is the first definition in compact format.
<DT>Term<DD>This is the second definition in compact format.
</DL>

5.7. Phrase Markup ✏️

phrases MAY be marked up according to idiomatic usage, typographic appearance, or for use as hyperlink anchors πŸ¦‹

ok this part is important 🚨 User agents MUST render highlighted phrases distinctly from plain text. on top of that, <EM> content MUST be rendered as distinct from <STRONG> content, and <B> content MUST rendered as distinct from <I> content πŸ’…

phrase elements MAY be nested within the content of other phrase elements. however, HTML user agents MAY render nested phrase elements indistinctly from non-nested elements 🫧

plain <B>bold <I>italic</I></B> may be rendered
the same as plain <B>bold </B><I>italic</I>

5.7.1. Idiomatic Elements 🎭

phrases MAY be marked up to indicate certain idioms 🧠

NOTE - User agents MAY support the <DFN> element, not included in this specification, as it has been deployed to some extent. It is used to indicate the defining instance of a term, and it is typically rendered in italic or bold italic. πŸ“Œ

5.7.1.1. Citation: CITE πŸ“š

the <CITE> element is used to indicate the title of a book or other citation πŸ“– it's typically rendered as italics. for example 🌸

He just couldn't get enough of <cite>The Grapes of Wrath</cite>.

5.7.1.2. Code: CODE πŸ’»

the <CODE> element indicates an example of code, typically rendered in a monospaced font πŸ‘©β€πŸ’» it's meant for short words or phrases of code 🫢 the <PRE> block structuring element (5.5.2, "Preformatted Text: PRE") is more appropriate for multiple-line listings. for example πŸ’…

The expression <code>x += 1</code>
is short for <code>x = x + 1</code>.

5.7.1.3. Emphasis: EM πŸ’—

the <EM> element indicates an emphasized phrase, typically rendered as italics. for example 🫢

A singular subject <em>always</em> takes a singular verb.

5.7.1.4. Keyboard: KBD ⌨️

the <KBD> element indicates text typed by a user, typically rendered in a monospaced font 🧚 it's commonly used in instruction manuals. for example πŸ“

Enter <kbd>FIND IT</kbd> to search the database.

5.7.1.5. Sample: SAMP πŸ§ͺ

the <SAMP> element indicates a sequence of literal characters, typically rendered in a monospaced font 🌷 for example πŸ¦‹

The only word containing the letters <samp>mt</samp> is dreamt.

5.7.1.6. Strong Emphasis: STRONG πŸ’ͺ

the <STRONG> element indicates strong emphasis, typically rendered in bold πŸ”₯ for example πŸ’–

<strong>STOP</strong>, or I'll say "<strong>STOP</strong>" again!

5.7.1.7. Variable: VAR πŸ”€

the <VAR> element indicates a placeholder variable, typically rendered as italic 🌈 for example ✨

Type <SAMP>html-check <VAR>file</VAR> | more</SAMP>
to check <VAR>file</VAR> for markup errors.

5.7.2. Typographic Elements πŸŽ€

okay so typographic elements are the ones that tell the browser exactly how the marked text should LOOK πŸ’… typical renderings for idiomatic elements MAY vary between user agents. but if you need a specific look, like when you're talking about a specific text attribute (think "The italic parts are mandatory" πŸ™ˆ), a typographic element makes sure the intended typography gets used where possible ✨

NOTE - User agents MAY support some typographic elements not included in this specification, since they've been deployed to some extent πŸ‘€ The <STRIKE> element indicates a horizontal line through the characters, and the <U> element indicates an underline πŸ¦‹

5.7.2.1. Bold: B πŸ’–

the <B> element indicates bold text πŸ’ͺ where bold typography is unavailable, an alternative representation MAY be used.

5.7.2.2. Italic: I 🌸

the <I> element indicates italic text 🫢 where italic typography is unavailable, an alternative representation MAY be used.

5.7.2.3. Teletype: TT 🧚

the <TT> element indicates teletype (monospaced )text ⌨️ where a teletype font is unavailable, an alternative representation MAY be used.


5.7.3. Anchor: A πŸ”—

the <A> element indicates a hyperlink anchor (see 7, "Hyperlinks") 🧷 at least one of the NAME and HREF attributes SHOULD be present. here are the attributes of the <A> element πŸ‘‘

  • HREF
    • gives the URI of the head anchor of a hyperlink.
  • NAME
    • gives the name of the anchor, and makes it available as a head of a hyperlink.
  • TITLE
    • suggests a title for the destination resource. it's advisory only πŸ™Œ the TITLE attribute MAY be used:
      • for display prior to accessing the destination resource, for example as a margin note, or on a small box while the mouse is over the anchor, or while the document is being loaded
      • for resources that do not include a title, such as graphics, plain text and Gopher menus, for use as a window title
  • REL
    • the REL attribute gives the relationship(s) described by the hyperlink. the value is a whitespace separated list of relationship names. the semantics of link relationships are not specified in this document.
  • REV
    • same as the REL attribute, but the semantics of the relationship 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
    • specifies a preferred, more persistent identifier for the head anchor of the hyperlink. the syntax and semantics of the URN attribute are not yet specified πŸ₯Ί
  • METHODS
    • specifies methods to be used in accessing the destination, as a whitespace-separated list of names. the set of applicable names is a function of the scheme of the URI in the HREF attribute. for similar reasons as for the TITLE attribute, it may be useful to include the information in advance in the link. for example, the HTML user agent may chose a different rendering as a function of the methods allowed, like how something searchable may get a different icon πŸ”

5.8. Line Break: BR πŸ“

the <BR> element specifies a line break between words (see 6, "Characters, Words, and Paragraphs") ✨ for example:

<P> Pease porridge hot<BR>
Pease porridge cold<BR>
Pease porridge in the pot<BR>
Nine days old.

5.9. Horizontal Rule: HR 🌈

the <HR> element is a divider between sections of text πŸͺ„ typically it's a full width horizontal rule or an equivalent graphic. for example:

<HR>
<ADDRESS>February 8, 1995, CERN</ADDRESS>
</BODY>

5.10. Image: IMG πŸ“Έ

the <IMG> element refers to an image or icon via a hyperlink (see 7.3, "Simultaneous Presentation of Image Resources") πŸ’…

HTML user agents MAY process the value of the ALT attribute as an alternative to processing the image resource indicated by the SRC attribute.

NOTE - Some HTML user agents can process graphics linked via anchors, but not <IMG> graphics. if a graphic is essential, it SHOULD be referenced from an <A> element rather than an <IMG> element. if the graphic is not essential, then the <IMG> element is appropriate πŸ™ˆ

here are the attributes of the <IMG> element:

  • ALIGN
    • alignment of the image with respect to the text baseline.
      • TOP' specifies that the top of the image aligns with the tallest item on the line containing the image.
      • MIDDLE' specifies that the center of the image aligns with the baseline of the line containing the image.
      • BOTTOM' specifies that the bottom of the image aligns with the baseline of the line containing the image.
  • ALT
    • text to use in place of the referenced image resource, for example due to processing constraints or user preference.
  • ISMAP
    • indicates an image map (see 7.6, "Image Maps") πŸ—ΊοΈ
  • SRC
    • specifies the URI of the image resource.
    • > NOTE - In practice, the media types of image resources are limited to a few raster graphic formats: typically image/gif', image/jpeg'. In particular, `text/html' resources are not intended to be used as image resources.

examples of use:

<IMG SRC="triangle.xbm" ALT="Warning:"> Be sure
to read these instructions.

<a href="http://machine/htbin/imagemap/sample">
<IMG SRC="sample.xbm" ISMAP>
</a>

6. Characters, Words, and Paragraphs ✨

an HTML user agent SHOULD present the body of an HTML document as a collection of typeset paragraphs and preformatted text. except for preformatted elements (<PRE>, <XMP>, <LISTING>, <TEXTAREA>), each block structuring element is regarded as a paragraph by taking the data characters in its content and the content of its descendant elements, concatenating them, and splitting the result into words, separated by space, tab, or record end characters (and perhaps hyphen characters). the sequence of words is typeset as a paragraph by breaking it into lines πŸ“œ

6.1. The HTML Document Character Set πŸ”€

the document character set specified in 9.5, "SGML Declaration for HTML" MUST be supported by HTML user agents 🫢 it includes the graphic characters of Latin Alphabet No. 1, or simply Latin-1. Latin-1 comprises 191 graphic characters, including the alphabets of most Western European languages 🌍

NOTE - Use of the non-breaking space and soft hyphen indicator characters is discouraged because support for them is not widely deployed.
NOTE - To support non-western writing systems, a larger character repertoire will be specified in a future version of HTML. The document character set will be [ISO-10646], or some subset that agrees with [ISO-10646]; in particular, all numeric character references MUST use code positions assigned by [ISO-10646] 🌏

in SGML applications, the use of control characters is limited in order to maximize the chance of successful interchange over heterogeneous networks and operating systems. in the HTML document character set only three control characters are allowed: Horizontal Tab, Carriage Return, and Line Feed (code positions 9, 13, and 10) 🧠

the HTML DTD references the Added Latin 1 entity set, to allow mnemonic representation of selected Latin 1 characters using only the widely supported ASCII character repertoire. for example:

Kurt G&ouml;del was a famous logician and mathematician.

see 9.7.2, "ISO Latin 1 Character Entity Set" for a table of the "Added Latin 1" entities, and 13, "The HTML Coded Character Set" for a table of the code positions of [ISO 8859-1] and the control characters in the HTML document character set πŸ—‚οΈ


in addition to general purpose elements such as paragraphs and lists, HTML documents can express hyperlinks. an HTML user agent allows the user to navigate these hyperlinks πŸ¦‹

a hyperlink is a relationship between two anchors, called the head and the tail of the hyperlink[DEXTER]. anchors are identified by an anchor address: an absolute Uniform Resource Identifier (URI), optionally followed by a '#' and a sequence of characters called a fragment identifier. for example:

http://www.w3.org/hypertext/WWW/TheProject.html
http://www.w3.org/hypertext/WWW/TheProject.html#z31

in an anchor address, the URI refers to a resource. it may be used in a variety of information retrieval protocols to obtain an entity that represents the resource, such as an HTML document. the fragment identifier, if present, refers to some view on, or portion of, the resource πŸ”

each of the following markup constructs indicates the tail anchor of a hyperlink or set of hyperlinks:

  • <A> elements with HREF present.
  • <LINK> elements.
  • <IMG> elements.
  • <INPUT> elements with the SRC attribute present.
  • <ISINDEX> elements.
  • <FORM> elements with `METHOD=GET'.

these markup constructs refer to head anchors by a URI, either absolute or relative, or a fragment identifier, or both πŸ’œ

in the case of a relative URI, the absolute URI in the address of the head anchor is the result of combining the relative URI with a base absolute URI as in [RELURL]. the base document is taken from the document's <BASE> element, if present; else, it is determined as in [RELURL] 🧭

7.1. Accessing Resources πŸ“‚

once the address of the head anchor is determined, the user agent MAY obtain a representation of the resource πŸ™Œ

for example, if the base URI is `http://host/x/y.html' and the document contains:

<img src="../icons/abc.gif">

then the user agent uses the URI `http://host/icons/abc.gif' to access the resource, as in [URL].. 🫧

an HTML user agent allows the user to navigate the content of the document and request activation of hyperlinks denoted by <A> elements. HTML user agents SHOULD also allow activation of <LINK> element hyperlinks πŸ’–

to activate a link, the user agent obtains a representation of the resource identified in the address of the head anchor. if the representation is another HTML document, navigation MAY begin again with this new document πŸ”

7.3. Simultaneous Presentation of Image Resources πŸ–ΌοΈ

an HTML user agent MAY activate hyperlinks indicated by <IMG> and <INPUT> elements concurrently with processing the document. that is, image hyperlinks MAY be processed without explicit request by the user. image resources SHOULD be embedded in the presentation at the point of the tail anchor, that is the <IMG> or <INPUT> element 🌸

<LINK> hyperlinks MAY also be processed without explicit user request. for example, style sheet resources MAY be processed before or during the processing of the document πŸŽ€

7.4. Fragment Identifiers ✨

okay so anything that comes after a # character in a hypertext address is a fragment identifier πŸ¦‹ and an address like #fragment points to an anchor in the same document. it's giving bookmark energy πŸ”–

what the fragment identifier means depends on the media type of the anchor's resource 🧚 for text/html representations, it refers to the <A> element with a NAME attribute whose value matches the fragment identifier. the matching is case sensitive, so capitalization matters πŸ’… the document should have exactly one such element. the user agent should indicate the anchor element, for example by scrolling to it and/or highlighting the phrase ✨

for example, say the base URI is http://host/x/y.html and the user activates the link in this markup:

<p> See: <a href="app1.html#bananas">appendix 1</a>
for more detail on bananas.

then the user agent accesses the resource identified by http://host/x/app1.html. assuming it's represented as text/html, the user agent must locate the <A> element whose NAME attribute is bananas and begin navigation there 🍌🫢

7.5. Queries and Indexes πŸ”

the <ISINDEX> element represents a set of hyperlinks, and the user can pick from that set by giving keywords to the user agent πŸŽ€ the user agent computes the head URI by appending ? and the keywords to the base URI. the keywords are escaped according to [URL] and joined by +. for example, if a document contains:

 <BASE HREF="http://host/index">
 <ISINDEX>

and the user provides the keywords apple and berry, then the user agent must access the resource http://host/index?apple+berry 🍎🫐

<FORM> elements with METHOD=GET also represent sets of hyperlinks, so see 8.2.2, "Query Forms: METHOD=GET" for details πŸ’œ

7.6. Image Maps πŸ—ΊοΈ

if the ISMAP attribute is present on an <IMG> element, the <IMG> element must be contained in an <A> element with an HREF present πŸ™ˆ this construct represents a set of hyperlinks, and the user picks one by clicking a pixel of the image. the user agent computes the head URI by appending ? and the x and y coordinates of the pixel to the URI given in the <A> element. for example, if a document contains:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<head><title>ImageMap Example</title>
<BASE HREF="http://host/index"></head>
<body>
<p> Choose any of these icons:<br>
<a href="/cgi-bin/imagemap"><img ismap src="icons.gif"></a>

and the user chooses the upper-leftmost pixel, the chosen hyperlink is the one with the URI http://host/cgi-bin/imagemap?0,0 🌈⭐

8. Forms πŸ“

a form is a template for a form data set, plus an associated method and action URI 🌸 a form data set is a sequence of name/value pair fields. the names are specified on the NAME attributes of form input elements, and the values get initial values from various forms of markup and are then edited by the user. the resulting form data set is used to access an information service as a function of the action and method πŸ‘‘

form elements can be mixed in with document structuring elements. for example, a <PRE> element may contain a <FORM> element, or a <FORM> element may contain lists which contain <INPUT> elements. this gives considerable flexibility in designing the layout of forms πŸŽ€

form processing is a level 2 feature πŸ’…

8.1. Form Elements 🧁

8.1.1. Form: FORM

the <FORM> element contains a sequence of input elements, along with document structuring elements. the attributes are:

  • ACTION: specifies the action URI for the form. the action URI of a form defaults to the base URI of the document (see 7, "Hyperlinks").
  • METHOD: selects a method of accessing the action URI. the set of applicable methods is a function of the scheme of the action URI of the form. see 8.2.2, "Query Forms: METHOD=GET" and 8.2.3, "Forms with Side-Effects: METHOD=POST".
  • ENCTYPE: specifies the media type used to encode the name/value pairs for transport, in case the protocol does not itself impose a format. see 8.2.1, "The form-urlencoded Media Type".

8.1.2. Input Field: INPUT

the <INPUT> element represents a field for user input. the TYPE attribute tells apart several variations of fields πŸ¦‹

the <INPUT> element has a number of attributes. the set of applicable attributes depends on the value of the TYPE attribute πŸ’–

8.1.2.1. Text Field: INPUT TYPE=TEXT

the default value of the TYPE attribute is TEXT, which means a single line text entry field. (use the <TEXTAREA> element for multi-line text fields 🫢)

required attributes are:

  • NAME: name for the form field corresponding to this element.

the optional attributes are:

  • MAXLENGTH: constrains the number of characters that can be entered into a text input field. if the value of MAXLENGTH is greater than the value of the SIZE attribute, the field should scroll appropriately. the default number of characters is unlimited.
  • SIZE: specifies the amount of display space allocated to this input field according to its type. the default depends on the user agent.
  • VALUE: the initial value of the field.

for example:

<p>Street Address: <input name=street><br>
Postal City code: <input name=city size=16 maxlength=16><br>
Zip Code: <input name=zip size=10 maxlength=10 value="99999-9999"><br>

8.1.2.2. Password Field: INPUT TYPE=PASSWORD

an <INPUT> element with TYPE=PASSWORD is a text field just like the one above, except the value is obscured as it's entered πŸ™ˆ (see also: 10, "Security Considerations").

for example:

<p>Name: <input name=login> Password: <input type=password name=passwd>

8.1.2.3. Check Box: INPUT TYPE=CHECKBOX

an <INPUT> element with TYPE=CHECKBOX represents a boolean choice. a set of these elements that share the same name represents an n-of-many choice field β˜‘οΈ required attributes are:

  • NAME: symbolic name for the form field corresponding to this element or group of elements.
  • VALUE: the portion of the value of the field contributed by this element.

optional attributes are:

  • CHECKED: indicates that the initial state is on.

for example:

  <p>What flavors do you like?
  <input type=checkbox name=flavor value=vanilla>Vanilla<br>
  <input type=checkbox name=flavor value=strawberry>Strawberry<br>
  <input type=checkbox name=flavor value=chocolate checked>Chocolate<br>

8.1.2.4. Radio Button: INPUT TYPE=RADIO

an <INPUT> element with TYPE=RADIO also represents a boolean choice πŸ”˜ a set of these elements that share the same name represents a 1-of-many choice field. the NAME and VALUE attributes are required, same as for check boxes. optional attributes are:

  • CHECKED: indicates that the initial state is on.

at all times, exactly one of the radio buttons in a set is checked πŸ’… if none of the <INPUT> elements in a set of radio buttons specifies CHECKED, then the user agent must check the first radio button of the set initially.

for example:

    <p>Which is your favorite?
    <input type=radio name=flavor value=vanilla>Vanilla<br>
    <input type=radio name=flavor value=strawberry>Strawberry<br>
    <input type=radio name=flavor value=chocolate>Chocolate<br>

8.1.2.5. Image Pixel: INPUT TYPE=IMAGE

an <INPUT> element with TYPE=IMAGE specifies an image resource to display, and lets the user input two form fields: the x and y coordinate of a pixel picked from the image πŸ—ΊοΈ the names of the fields are the name of the field with .x and .y appended. TYPE=IMAGE implies TYPE=SUBMIT processing, which means that when a pixel is chosen, the form as a whole is submitted πŸš€

the NAME attribute is required, same as for other input fields. the SRC attribute is required, and ALIGN is optional, the same as for the <IMG> element (see 5.10, "Image: IMG").

for example:

    <p>Choose a point on the map:
    <input type=image name=point src="map.gif">

8.1.2.6. Hidden Field: INPUT TYPE=HIDDEN

an <INPUT> element with TYPE=HIDDEN represents a hidden field. the user does not interact with this field 🫣 instead, the VALUE attribute specifies the value of the field. the NAME and VALUE attributes are required.

for example:

   <input type=hidden name=context value="l2k3j4l2k3j4l2k3j4lk23">

8.1.2.7. Submit Button: INPUT TYPE=SUBMIT

an <INPUT> element with TYPE=SUBMIT represents an input option, typically a button, that tells the user agent to submit the form πŸŽ‰ optional attributes are:

  • NAME: indicates that this element contributes a form field whose value is given by the VALUE attribute. if the NAME attribute is not present, this element does not contribute a form field.
  • VALUE: indicates a label for the input (button).

for example:

    You may submit this request internally:
    <input type=submit name=recipient value=internal><br>
    or to the external world:
    <input type=submit name=recipient value=world>

8.1.2.8. Reset Button: INPUT TYPE=RESET

an <INPUT> element with TYPE=RESET represents an input option, typically a button, that tells the user agent to reset the form's fields to their initial states 🧹 the VALUE attribute, if present, indicates a label for the input (button).

for example:

   When you are finished, you may submit this request:
   <input type=submit><br>
   You may clear the form and start over at any time: <input type=reset>

8.1.3. Selection: SELECT

the <SELECT> element constrains the form field to an enumerated list of values. the values are given in <OPTION> elements 🍦 the attributes are:

  • MULTIPLE: indicates that more than one option may be included in the value.
  • NAME: specifies the name of the form field.
  • SIZE: specifies the number of visible items. select fields of size one are typically pop-down menus, whereas select fields with size greater than one are typically lists.

for example:

    <SELECT NAME="flavor">
    <OPTION>Vanilla
    <OPTION>Strawberry
    <OPTION value="RumRasin">Rum and Raisin
    <OPTION selected>Peach and Orange
    </SELECT>

the initial state has the first option selected, unless a SELECTED attribute is present on any of the <OPTION> elements 🌸

8.1.3.1. Option: OPTION

the Option element can only occur within a Select element. it represents one choice, and has the following attributes:

  • SELECTED: indicates that this option is initially selected.
  • VALUE: indicates the value to be returned if this option is chosen. the field value defaults to the content of the <OPTION> element.

the content of the <OPTION> element is presented to the user to represent the option. it's used as the returned value if the VALUE attribute is not present πŸ¦‹

8.1.4. Text Area: TEXTAREA ✨

Okay so the <TEXTAREA> element is your multi-line text field, bestie πŸ“ It's giving big box energy. It takes three attributes:

  • COLS: the number of visible columns for the text area, in characters.
  • NAME: the name of the form field.
  • ROWS: the number of visible rows for the text area, in characters.

Here's a cute example 🌸

<TEXTAREA NAME="address" ROWS=6 COLS=64>
HaL Computer Systems
1315 Dell Avenue
Campbell, California 95008
</TEXTAREA>

Whatever is inside the <TEXTAREA> element becomes the field's starting value, so it's basically the field's first outfit πŸ‘—

The ROWS and COLS attributes usually decide how big the field looks, measured in characters. The field is usually drawn in a fixed-width font πŸŽ€ HTML user agents should still let the text go past those limits by scrolling, so nothing gets cut off, periodt πŸ’…


8.2. Form Submission πŸ¦‹

Okay, here's how a form gets going. The HTML user agent starts by showing you the document with every field in its starting state. You're allowed to change the fields, but only within the rules of each field type, obviously πŸ™ˆ Once you hit a submit button (or an image input) to say "send it!", the form data set gets processed based on its method, its action URI, and its enctype ✨

When a form has just one single-line text input field, the user agent should let you press Enter in that field to submit the form. So cute and so convenient 🫢

8.2.1. The form-urlencoded Media Type πŸ’œ

The default encoding for every form is application/x-www-form-urlencoded. In this media type, a form data set is represented like this:

  1. The form field names and values get escaped. Spaces turn into +, and then reserved characters are escaped following [URL]. Basically, any non-alphanumeric character becomes %HH, which is a percent sign plus two hex digits for that character's ASCII code. Line breaks (like in multi-line text fields) are written as CR LF pairs, so %0D%0A πŸ’–
  2. The fields are listed in the order they show up in the document. Each name is separated from its value by =, and the pairs are separated by & ✨ Fields with null values may be omitted. Unselected radio buttons and checkboxes should not appear in the encoded data, but hidden fields with VALUE attributes should show up 🌈
NOTE: The URI from a query form submission can be used in a normal anchor style hyperlink. Unfortunately, the use of the & character to separate form fields interacts with its use in SGML attribute values as an entity reference delimiter. For example, the URI http://host/?x=1&y=2 must be written <a href="http://host/?x=1&#38;y=2" or <a href="http://host/?x=1&amp;y=2">. HTTP server implementors, and in particular, CGI implementors are encouraged to support the use of ; in place of & to save users the trouble of escaping & characters this way. πŸ™Œ

8.2.2. Query Forms: METHOD=GET πŸ”

If processing a form is idempotent (meaning it has no lasting observable effect on the state of the world), then the form method should be GET. Tbh database searches are the perfect example, since they usually have no visible side-effects, so they're the ideal query forms 🧚

To process a form whose action URL is an HTTP URL and whose method is GET, the user agent starts with the action URI, adds a ?, and then adds the form data set in application/x-www-form-urlencoded format, like we covered above. After that, the user agent follows the link to this URI just like it would an anchor (see 7.2, "Activation of Hyperlinks") πŸ¦‹

NOTE: The URL encoding may result in very long URIs, which cause some historical HTTP server implementations to exhibit defective behavior. As a result, some HTML forms are written using METHOD=POST even though the form submission has no side-effects. πŸ’€

8.2.3. Forms with Side-Effects: METHOD=POST πŸ“

If the service behind a form has side effects (like modifying a database or subscribing you to something), the method should be POST πŸ’…

To process a form whose action URL is an HTTP URL and whose method is POST, the user agent runs an HTTP POST transaction using the action URI, with a message body in application/x-www-form-urlencoded format, as above. After that, the user agent should display the response from the HTTP POST interaction just like it would display a response from an HTTP GET πŸ‘‘

8.2.4. Example Form Submission: Questionnaire Form πŸ“‹

Let's look at this example document πŸ‘€

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<title>Sample of HTML Form Submission</title>
<H1>Sample Questionnaire</H1>
<P>Please fill out this questionnaire:
<FORM METHOD="POST" ACTION="http://www.w3.org/sample">
<P>Your name: <INPUT NAME="name" size="48">
<P>Male <INPUT NAME="gender" TYPE=RADIO VALUE="male">
<P>Female <INPUT NAME="gender" TYPE=RADIO VALUE="female">
<P>Number in family: <INPUT NAME="family" TYPE=text>
<P>Cities in which you maintain a residence:
<UL>
<LI>Kent <INPUT NAME="city" TYPE=checkbox VALUE="kent">
<LI>Miami <INPUT NAME="city" TYPE=checkbox VALUE="miami">
<LI>Other <TEXTAREA NAME="other" cols=48 rows=4></textarea>
</UL>
Nickname: <INPUT NAME="nickname" SIZE="42">
<P>Thank you for responding to this questionnaire.
<P><INPUT TYPE=SUBMIT> <INPUT TYPE=RESET>
</FORM>

The starting state of the form data set looks like this 🧁

name
        ""

gender
        "male"

family
        ""

other
        ""

nickname
        ""

Notice that the radio input already has a starting value, but the checkbox doesn't have one at all πŸ‘€

Now the user fills things in and hits submit. Say the values end up like this ✨

name
        "John Doe"

gender
        "male"

family
        "5"

city
        "kent"

city
        "miami"

other
        "abc\ndefk"

nickname
        "J&D"

The user agent then runs an HTTP POST transaction using the URI http://www.w3.org/sample. The message body would be (ignore the line break):

name=John+Doe&gender=male&family=5&city=kent&city=miami&other=abc%0D%0Adef&nickname=J%26D

Ngl, the line break in the original is just for display, so you can read it, but the actual body is one long line 🫢


9. HTML Public Text 🌸

9.1. HTML DTD πŸ’–

This is the Document Type Definition for the HyperText Markup Language, level 2. It's the official rulebook πŸ“–βœ¨

<!--    html.dtd

        Document Type Definition for the HyperText Markup Language
                 (HTML DTD)

        $Id: html.dtd,v 1.30 1995/09/21 23:30:19 connolly Exp $

        Author: Daniel W. Connolly <connolly@w3.org>
        See Also: html.decl, html-1.dtd
          http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
-->

<!ENTITY % HTML.Version
        "-//IETF//DTD HTML 2.0//EN"

        -- Typical usage:

            <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
            <html>
            ...
            </html>
        --
        >


<!--============ Feature Test Entities ========================-->

<!ENTITY % HTML.Recommended "IGNORE"
        -- Certain features of the language are necessary for
           compatibility with widespread usage, but they may
           compromise the structural integrity of a document.
           This feature test entity enables a more prescriptive
           document type definition that eliminates
           those features.
        -->

<![ %HTML.Recommended [
        <!ENTITY % HTML.Deprecated "IGNORE">

]]>

<!ENTITY % HTML.Deprecated "INCLUDE"
        -- Certain features of the language are necessary for
           compatibility with earlier versions of the specification,
           but they tend to be used and implemented inconsistently,
           and their use is deprecated. This feature test entity
           enables a document type definition that eliminates
           these features.
        -->

<!ENTITY % HTML.Highlighting "INCLUDE"
        -- Use this feature test entity to validate that a
           document uses no highlighting tags, which may be
           ignored on minimal implementations.
        -->

<!ENTITY % HTML.Forms "INCLUDE"
        -- Use this feature test entity to validate that a document
           contains no forms, which may not be supported in minimal
           implementations
        -->

<!--============== Imported Names ==============================-->

<!ENTITY % Content-Type "CDATA"
        -- meaning an internet media type
           (aka MIME content type, as per RFC1521)
        -->

<!ENTITY % HTTP-Method "GET | POST"
        -- as per HTTP specification, in progress
        -->

<!--========= DTD "Macros" =====================-->

<!ENTITY % heading "H1|H2|H3|H4|H5|H6">

<!ENTITY % list " UL | OL | DIR | MENU " >


<!--======= Character mnemonic entities =================-->

<!ENTITY % ISOlat1 PUBLIC
  "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
%ISOlat1;

<!ENTITY amp CDATA "&#38;"     -- ampersand          -->
<!ENTITY gt CDATA "&#62;"      -- greater than       -->
<!ENTITY lt CDATA "&#60;"      -- less than          -->
<!ENTITY quot CDATA "&#34;"    -- double quote       -->


<!--========= SGML Document Access (SDA) Parameter Entities =====-->

<!-- HTML 2.0 contains SGML Document Access (SDA) fixed attributes
in support of easy transformation to the International Committee
for Accessible Document Design (ICADD) DTD
         "-//EC-USA-CDA/ICADD//DTD ICADD22//EN".
ICADD applications are designed to support usable access to
structured information by print-impaired individuals through
Braille, large print and voice synthesis.  For more information on
SDA & ICADD:
        - ISO 12083:1993, Annex A.8, Facilities for Braille,
          large print and computer voice
        - ICADD ListServ
          <ICADD%ASUACAD.BITNET@ARIZVM1.ccit.arizona.edu>
        - Usenet news group bit.listserv.easi
        - Recording for the Blind, +1 800 221 4792
-->

<!ENTITY % SDAFORM  "SDAFORM  CDATA  #FIXED"
          -- one to one mapping        -->
<!ENTITY % SDARULE  "SDARULE  CDATA  #FIXED"
          -- context-sensitive mapping -->
<!ENTITY % SDAPREF  "SDAPREF  CDATA  #FIXED"
          -- generated text prefix     -->
<!ENTITY % SDASUFF  "SDASUFF  CDATA  #FIXED"
          -- generated text suffix     -->
<!ENTITY % SDASUSP  "SDASUSP  NAME   #FIXED"
          -- suspend transform process -->


<!--========== Text Markup =====================-->

<![ %HTML.Highlighting [

<!ENTITY % font " TT | B | I ">

<!ENTITY % phrase "EM | STRONG | CODE | SAMP | KBD | VAR | CITE ">

<!ENTITY % text "#PCDATA | A | IMG | BR | %phrase | %font">

<!ELEMENT (%font;|%phrase) - - (%text)*>
<!ATTLIST ( TT | CODE | SAMP | KBD | VAR )
        %SDAFORM; "Lit"
        >
<!ATTLIST ( B | STRONG )
        %SDAFORM; "B"
        >
<!ATTLIST ( I | EM | CITE )
        %SDAFORM; "It"
        >

<!-- <TT>       Typewriter text                         -->
<!-- <B>        Bold text                               -->
<!-- <I>        Italic text                             -->

<!-- <EM>       Emphasized phrase                       -->
<!-- <STRONG>   Strong emphasis                         -->
<!-- <CODE>     Source code phrase                      -->
<!-- <SAMP>     Sample text or characters               -->
<!-- <KBD>      Keyboard phrase, e.g. user input        -->
<!-- <VAR>      Variable phrase or substitutable        -->
<!-- <CITE>     Name or title of cited work             -->

<!ENTITY % pre.content "#PCDATA | A | HR | BR | %font | %phrase">

]]>

<!ENTITY % text "#PCDATA | A | IMG | BR">

<!ELEMENT BR    - O EMPTY>
<!ATTLIST BR
        %SDAPREF; "&#RE;"
        >

<!-- <BR>       Line break      -->


<!--========= Link Markup ======================-->

Phew, that's a lot of DTD, but we're getting there πŸ’œ

okay bestie, links are literally the main character of this whole DTD πŸ¦‹ we start with the linkType setup and the A anchor element, which is the source and destination of every link ✨

<!ENTITY % linkType "NAMES">

<!ENTITY % linkExtraAttributes
        "REL %linkType #IMPLIED
        REV %linkType #IMPLIED
        URN CDATA #IMPLIED
        TITLE CDATA #IMPLIED
        METHODS NAMES #IMPLIED
        ">

<![ %HTML.Recommended [
        <!ENTITY % A.content   "(%text)*"
        -- <H1><a name="xxx">Heading</a></H1>
                is preferred to
           <a name="xxx"><H1>Heading</H1></a>
        -->
]]>

<!ENTITY % A.content   "(%heading|%text)*">

<!ELEMENT A     - - %A.content -(A)>
<!ATTLIST A
        HREF CDATA #IMPLIED
        NAME CDATA #IMPLIED
        %linkExtraAttributes;
        %SDAPREF; "<Anchor: #AttList>"
        >
<!-- <A>                Anchor; source/destination of link      -->
<!-- <A NAME="...">     Name of this anchor                     -->
<!-- <A HREF="...">     Address of link destination             -->
<!-- <A URN="...">      Permanent address of destination        -->
<!-- <A REL=...>        Relationship to destination             -->
<!-- <A REV=...>        Relationship of destination to this     -->
<!-- <A TITLE="...">    Title of destination (advisory)         -->
<!-- <A METHODS="...">  Operations on destination (advisory)    -->

so the anchor can have a NAME, an HREF, a URN, REL, REV, TITLE and METHODS, and the last few are all tagged advisory πŸ’…

now the images πŸ–ΌοΈβœ¨ IMG is an empty element, so no content inside, just the attributes doing all the work

<!--========== Images ==========================-->

<!ELEMENT IMG    - O EMPTY>
<!ATTLIST IMG
        SRC CDATA  #REQUIRED
        ALT CDATA #IMPLIED
        ALIGN (top|middle|bottom) #IMPLIED
        ISMAP (ISMAP) #IMPLIED
        %SDAPREF; "<Fig><?SDATrans Img: #AttList>#AttVal(Alt)</Fig>"
        >

<!-- <IMG>              Image; icon, glyph or illustration      -->
<!-- <IMG SRC="...">    Address of image object                 -->
<!-- <IMG ALT="...">    Textual alternative                     -->
<!-- <IMG ALIGN=...>    Position relative to text               -->
<!-- <IMG ISMAP>        Each pixel can be a link                -->

<!--========== Paragraphs=======================-->

<!ELEMENT P     - O (%text)*>
<!ATTLIST P
        %SDAFORM; "Para"
        >

<!-- <P>        Paragraph       -->

SRC is the one that's REQUIRED on IMG, so it's the non-negotiable accessory 🌸 ALT, ALIGN and ISMAP are IMPLIED, meaning optional, and ISMAP is the one that lets each pixel be a link 🧚

paragraphs are the simplest thing here, just P with its text inside πŸ“πŸ’œ

<!--========== Headings, Titles, Sections ===============-->

<!ELEMENT HR    - O EMPTY>
<!ATTLIST HR
        %SDAPREF; "&#RE;&#RE;"
        >

<!-- <HR>       Horizontal rule -->

<!ELEMENT ( %heading )  - -  (%text;)*>
<!ATTLIST H1
        %SDAFORM; "H1"
        >
<!ATTLIST H2
        %SDAFORM; "H2"
        >
<!ATTLIST H3
        %SDAFORM; "H3"
        >
<!ATTLIST H4
        %SDAFORM; "H4"
        >
<!ATTLIST H5
        %SDAFORM; "H5"
        >
<!ATTLIST H6
        %SDAFORM; "H6"
        >

<!-- <H1>       Heading, level 1 -->
<!-- <H2>       Heading, level 2 -->
<!-- <H3>       Heading, level 3 -->
<!-- <H4>       Heading, level 4 -->
<!-- <H5>       Heading, level 5 -->
<!-- <H6>       Heading, level 6 -->


<!--========== Text Flows ======================-->

<![ %HTML.Forms [
        <!ENTITY % block.forms "BLOCKQUOTE | FORM | ISINDEX">
]]>

<!ENTITY % block.forms "BLOCKQUOTE">
<![ %HTML.Deprecated [
        <!ENTITY % preformatted "PRE | XMP | LISTING">
]]>

<!ENTITY % preformatted "PRE">

<!ENTITY % block "P | %list | DL
        | %preformatted
        | %block.forms">

<!ENTITY % flow "(%text|%block)*">

<!ENTITY % pre.content "#PCDATA | A | HR | BR">
<!ELEMENT PRE - - (%pre.content)*>
<!ATTLIST PRE
        WIDTH NUMBER #implied
        %SDAFORM; "Lit"
        >

<!-- <PRE>              Preformatted text               -->
<!-- <PRE WIDTH=...>    Maximum characters per line     -->

headings are giving structure, H1 through H6, so your doc can have a whole hierarchy πŸ‘‘

the text flows bit is where the block stuff gets sorted, and BLOCKQUOTE only shows up in forms if the forms flag is on πŸŽ€ PRE is for preformatted text, and its WIDTH is the max characters per line πŸ“

<![ %HTML.Deprecated [

<!ENTITY % literal "CDATA"
        -- historical, non-conforming parsing mode where
           the only markup signal is the end tag
           in full
        -->

<!ELEMENT (XMP|LISTING) - -  %literal>
<!ATTLIST XMP
        %SDAFORM; "Lit"
        %SDAPREF; "Example:&#RE;"
        >
<!ATTLIST LISTING
        %SDAFORM; "Lit"
        %SDAPREF; "Listing:&#RE;"
        >

<!-- <XMP>              Example section         -->
<!-- <LISTING>          Computer listing        -->

<!ELEMENT PLAINTEXT - O %literal>
<!-- <PLAINTEXT>        Plain text passage      -->

<!ATTLIST PLAINTEXT
        %SDAFORM; "Lit"
        >
]]>

<!--========== Lists ==================-->

<!ELEMENT DL    - -  (DT | DD)+>
<!ATTLIST DL
        COMPACT (COMPACT) #IMPLIED
        %SDAFORM; "List"
        %SDAPREF; "Definition List:"
        >

<!ELEMENT DT    - O (%text)*>
<!ATTLIST DT
        %SDAFORM; "Term"
        >

<!ELEMENT DD    - O %flow>
<!ATTLIST DD
        %SDAFORM; "LItem"
        >

<!-- <DL>               Definition list, or glossary    -->
<!-- <DL COMPACT>       Compact style list              -->
<!-- <DT>               Term in definition list         -->
<!-- <DD>               Definition of term              -->

<!ELEMENT (OL|UL) - -  (LI)+>
<!ATTLIST OL
        COMPACT (COMPACT) #IMPLIED
        %SDAFORM; "List"
        >
<!ATTLIST UL
        COMPACT (COMPACT) #IMPLIED
        %SDAFORM; "List"
        >
<!-- <UL>               Unordered list                  -->
<!-- <UL COMPACT>       Compact list style              -->
<!-- <OL>               Ordered, or numbered list       -->
<!-- <OL COMPACT>       Compact list style              -->


<!ELEMENT (DIR|MENU) - -  (LI)+ -(%block)>
<!ATTLIST DIR
        COMPACT (COMPACT) #IMPLIED
        %SDAFORM; "List"
        %SDAPREF; "<LHead>Directory</LHead>"
        >

<!ATTLIST MENU
        COMPACT (COMPACT) #IMPLIED
        %SDAFORM; "List"
        %SDAPREF; "<LHead>Menu</LHead>"
        >

<!-- <DIR>              Directory list                  -->
<!-- <DIR COMPACT>      Compact list style              -->
<!-- <MENU>             Menu list                       -->
<!-- <MENU COMPACT>     Compact list style              -->

<!ELEMENT LI    - O %flow>
<!ATTLIST LI
        %SDAFORM; "LItem"
        >

<!-- <LI>               List item                       -->

the lists are where it gets iconic 🫢 DL is your definition list with DT terms and DD definitions, OL and UL are ordered and unordered, and then there's DIR and MENU, which are giving old-school vibes πŸ’€ they just wrap LI items

and the PLAINTEXT, XMP and LISTING stuff sits inside that deprecated bracket, so it only counts if that flag is on πŸ™ˆ

<!--========== Document Body ===================-->

<![ %HTML.Recommended [
        <!ENTITY % body.content "(%heading|%block|HR|ADDRESS|IMG)*"
        -- <h1>Heading</h1>
           <p>Text ...
                is preferred to
           <h1>Heading</h1>
           Text ...
        -->
]]>

<!ENTITY % body.content "(%heading | %text | %block |
                                 HR | ADDRESS)*">

<!ELEMENT BODY O O  %body.content>

<!-- <BODY>     Document body   -->

<!ELEMENT BLOCKQUOTE - - %body.content>
<!ATTLIST BLOCKQUOTE
        %SDAFORM; "BQ"
        >

<!-- <BLOCKQUOTE>       Quoted passage  -->

<!ELEMENT ADDRESS - - (%text|P)*>
<!ATTLIST  ADDRESS
        %SDAFORM; "Lit"
        %SDAPREF; "Address:&#RE;"
        >

<!-- <ADDRESS>  Address, signature, or byline   -->

BODY is the whole body of the doc, and it's a total vibe πŸ’œ BLOCKQUOTE is for quoted passages and ADDRESS is for your address, signature or byline ✍️

<!--======= Forms ====================-->

<![ %HTML.Forms [

<!ELEMENT FORM - - %body.content -(FORM) +(INPUT|SELECT|TEXTAREA)>
<!ATTLIST FORM
        ACTION CDATA #IMPLIED
        METHOD (%HTTP-Method) GET
        ENCTYPE %Content-Type; "application/x-www-form-urlencoded"
        %SDAPREF; "<Para>Form:</Para>"
        %SDASUFF; "<Para>Form End.</Para>"
        >

<!-- <FORM>                     Fill-out or data-entry form     -->
<!-- <FORM ACTION="...">        Address for completed form      -->
<!-- <FORM METHOD=...>          Method of submitting form       -->
<!-- <FORM ENCTYPE="...">       Representation of form data     -->

<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX |
                        RADIO | SUBMIT | RESET |
                        IMAGE | HIDDEN )">
<!ELEMENT INPUT - O EMPTY>
<!ATTLIST INPUT
        TYPE %InputType TEXT
        NAME CDATA #IMPLIED
        VALUE CDATA #IMPLIED
        SRC CDATA #IMPLIED
        CHECKED (CHECKED) #IMPLIED
        SIZE CDATA #IMPLIED
        MAXLENGTH NUMBER #IMPLIED
        ALIGN (top|middle|bottom) #IMPLIED
        %SDAPREF; "Input: "
        >

<!-- <INPUT>                    Form input datum                -->
<!-- <INPUT TYPE=...>           Type of input interaction       -->
<!-- <INPUT NAME=...>           Name of form datum              -->
<!-- <INPUT VALUE="...">        Default/initial/selected value  -->
<!-- <INPUT SRC="...">          Address of image                -->
<!-- <INPUT CHECKED>            Initial state is "on"           -->
<!-- <INPUT SIZE=...>           Field size hint                 -->
<!-- <INPUT MAXLENGTH=...>      Data length maximum             -->
<!-- <INPUT ALIGN=...>          Image alignment                 -->
<!ELEMENT SELECT - - (OPTION+) -(INPUT|SELECT|TEXTAREA)>
<!ATTLIST SELECT
        NAME CDATA #REQUIRED
        SIZE NUMBER #IMPLIED
        MULTIPLE (MULTIPLE) #IMPLIED
        %SDAFORM; "List"
        %SDAPREF;
        "<LHead>Select #AttVal(Multiple)</LHead>"
        >

<!-- <SELECT>                   Selection of option(s)          -->
<!-- <SELECT NAME=...>          Name of form datum              -->
<!-- <SELECT SIZE=...>          Options displayed at a time     -->
<!-- <SELECT MULTIPLE>          Multiple selections allowed     -->

<!ELEMENT OPTION - O (#PCDATA)*>
<!ATTLIST OPTION
        SELECTED (SELECTED) #IMPLIED
        VALUE CDATA #IMPLIED
        %SDAFORM; "LItem"
        %SDAPREF;
        "Option: #AttVal(Value) #AttVal(Selected)"
        >

<!-- <OPTION>                   A selection option              -->
<!-- <OPTION SELECTED>          Initial state                   -->
<!-- <OPTION VALUE="...">       Form datum value for this option-->

<!ELEMENT TEXTAREA - - (#PCDATA)* -(INPUT|SELECT|TEXTAREA)>
<!ATTLIST TEXTAREA
        NAME CDATA #REQUIRED
        ROWS NUMBER #REQUIRED
        COLS NUMBER #REQUIRED
        %SDAFORM; "Para"
        %SDAPREF; "Input Text -- #AttVal(Name): "
        >

<!-- <TEXTAREA>                 An area for text input          -->
<!-- <TEXTAREA NAME=...>        Name of form datum              -->
<!-- <TEXTAREA ROWS=...>        Height of area                  -->
<!-- <TEXTAREA COLS=...>        Width of area                   -->

]]>

forms are the full glow-up 🌈✨ FORM, INPUT, SELECT, OPTION and TEXTAREA all come together so people can actually fill stuff in πŸ’…

INPUT's TYPE defaults to TEXT and the options run from TEXT all the way through HIDDEN πŸ¦‹

<!--======= Document Head ======================-->

<![ %HTML.Recommended [

        <!ENTITY % head.extra "">
]]>
<!ENTITY % head.extra "& NEXTID?">

<!ENTITY % head.content "TITLE & ISINDEX? & BASE? %head.extra">

<!ELEMENT HEAD O O  (%head.content) +(META|LINK)>

<!-- <HEAD>     Document head   -->

<!ELEMENT TITLE - -  (#PCDATA)*  -(META|LINK)>
<!ATTLIST TITLE
        %SDAFORM; "Ti"    >

<!-- <TITLE>    Title of document -->

<!ELEMENT LINK - O EMPTY>
<!ATTLIST LINK
        HREF CDATA #REQUIRED
        %linkExtraAttributes;
        %SDAPREF; "Linked to : #AttVal (TITLE) (URN) (HREF)>"    >

<!-- <LINK>             Link from this document                 -->
<!-- <LINK HREF="...">  Address of link destination             -->
<!-- <LINK URN="...">   Lasting name of destination             -->
<!-- <LINK REL=...>     Relationship to destination             -->
<!-- <LINK REV=...>     Relationship of destination to this     -->
<!-- <LINK TITLE="..."> Title of destination (advisory)         -->
<!-- <LINK METHODS="..."> Operations allowed (advisory)         -->

<!ELEMENT ISINDEX - O EMPTY>
<!ATTLIST ISINDEX
        %SDAPREF;
   "<Para>[Document is indexed/searchable.]</Para>">

<!-- <ISINDEX>          Document is a searchable index          -->

<!ELEMENT BASE - O EMPTY>
<!ATTLIST BASE
        HREF CDATA #REQUIRED     >

<!-- <BASE>             Base context document                   -->
<!-- <BASE HREF="...">  Address for this document               -->

<!ELEMENT NEXTID - O EMPTY>
<!ATTLIST NEXTID
        N CDATA #REQUIRED     >

<!-- <NEXTID>           Next ID to use for link name            -->
<!-- <NEXTID N=...>     Next ID to use for link name            -->

<!ELEMENT META - O EMPTY>
<!ATTLIST META
        HTTP-EQUIV  NAME    #IMPLIED
        NAME        NAME    #IMPLIED
        CONTENT     CDATA   #REQUIRED    >

<!-- <META>                     Generic Meta-information        -->
<!-- <META HTTP-EQUIV=...>      HTTP response header name       -->
<!-- <META NAME=...>            Meta-information name           -->
<!-- <META CONTENT="...">       Associated information          -->

and the head is where all the metadata lives 🧚 TITLE is required, and LINK, META, BASE, ISINDEX and NEXTID are all doing their own thing up top πŸ’–

<!--======= Document Structure =================-->

<![ %HTML.Deprecated [
        <!ENTITY % html.content "HEAD, BODY, PLAINTEXT?">
]]>
<!ENTITY % html.content "HEAD, BODY">

<!ELEMENT HTML O O  (%html.content)>
<!ENTITY % version.attr "VERSION CDATA #FIXED '%HTML.Version;'">

<!ATTLIST HTML
        %version.attr;
        %SDAFORM; "Book"
        >

<!-- <HTML>                     HTML Document   -->

9.2. Strict HTML DTD ✨

okay so this declaration points at the HTML DTD but flips HTML.Recommended from IGNORE to INCLUDE, which means you get the stricter, more structurally rigid version of HTML. no cap, it's giving strict teacher energy πŸ§πŸ’…

<!--    html-s.dtd

        Document Type Definition for the HyperText Markup Language
        with strict validation (HTML Strict DTD).

        $Id: html-s.dtd,v 1.3 1995/06/02 18:55:46 connolly Exp $

        Author: Daniel W. Connolly <connolly@w3.org>
        See Also: http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
-->
<!ENTITY % HTML.Version
        "-//IETF//DTD HTML 2.0 Strict//EN"

        -- Typical usage:

            <!DOCTYPE HTML PUBLIC
                "-//IETF//DTD HTML Strict//EN">
            <html>
            ...
            </html>
        --
        >

<!-- Feature Test Entities -->
<!ENTITY % HTML.Recommended "INCLUDE">

<!ENTITY % html PUBLIC "-//IETF//DTD HTML 2.0//EN">
%html;

9.3. Level 1 HTML DTD πŸŽ€

this one refers to the HTML DTD too, but HTML.Forms is set to IGNORE instead of INCLUDE. bestie, if your doc has <FORM> elements it's not gonna pass this DTD, so you'd need the level 2 one instead πŸ™ˆ

<!--    html-1.dtd

        Document Type Definition for the HyperText Markup Language
        with Level 1 Extensions (HTML Level 1 DTD).

        $Id: html-1.dtd,v 1.2 1995/03/29 18:53:10 connolly Exp $

        Author: Daniel W. Connolly <connolly@w3.org>
        See Also: http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html

-->

<!ENTITY % HTML.Version
        "-//IETF//DTD HTML 2.0 Level 1//EN"

        -- Typical usage:

            <!DOCTYPE HTML PUBLIC
                "-//IETF//DTD HTML Level 1//EN">
            <html>
            ...
            </html>

        --
        >

<!-- Feature Test Entities -->
<!ENTITY % HTML.Forms "IGNORE">

<!ENTITY % html PUBLIC "-//IETF//DTD HTML 2.0//EN">
%html;

9.4. Strict Level 1 HTML DTD πŸ“

combo move alert: this is the level 1 DTD with HTML.Recommended set to INCLUDE instead of IGNORE, so it's the level 1 version that's extra strict. the structure is locked in, periodt πŸ’…βœ¨

<!--    html-1s.dtd

        Document Type Definition for the HyperText Markup Language
        Struct Level 1

        $Id: html-1s.dtd,v 1.3 1995/06/02 18:55:43 connolly Exp $

        Author: Daniel W. Connolly <connolly@w3.org>
        See Also: http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
-->

<!ENTITY % HTML.Version
        "-//IETF//DTD HTML 2.0 Strict Level 1//EN"

        -- Typical usage:

            <!DOCTYPE HTML PUBLIC
                "-//IETF//DTD HTML Strict Level 1//EN">
            <html>
            ...
            </html>
        --
        >

<!-- Feature Test Entities -->


<!ENTITY % HTML.Recommended "INCLUDE">

<!ENTITY % html-1 PUBLIC "-//IETF//DTD HTML 2.0 Level 1//EN">
%html-1;

9.5. SGML Declaration for HTML 🧚

this is the SGML Declaration for HyperText Markup Language, aka the rulebook that tells SGML how HTML is allowed to look. it's kinda iconic, ngl πŸ€“

<!SGML  "ISO 8879:1986"
--
        SGML Declaration for HyperText Markup Language (HTML).

--

CHARSET
         BASESET  "ISO 646:1983//CHARSET
                   International Reference Version
                   (IRV)//ESC 2/5 4/0"
         DESCSET  0   9   UNUSED
                  9   2   9
                  11  2   UNUSED
                  13  1   13
                  14  18  UNUSED
                  32  95  32
                  127 1   UNUSED
     BASESET   "ISO Registration Number 100//CHARSET
                ECMA-94 Right Part of
                Latin Alphabet Nr. 1//ESC 2/13 4/1"

         DESCSET  128  32   UNUSED
                  160  96    32

CAPACITY        SGMLREF
                TOTALCAP        150000
                GRPCAP          150000
                ENTCAP          150000

SCOPE    DOCUMENT
SYNTAX
         SHUNCHAR CONTROLS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
                 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 127
         BASESET  "ISO 646:1983//CHARSET
                   International Reference Version
                   (IRV)//ESC 2/5 4/0"
         DESCSET  0 128 0
         FUNCTION
                  RE          13
                  RS          10
                  SPACE       32
                  TAB SEPCHAR  9
         NAMING   LCNMSTRT ""
                  UCNMSTRT ""
                  LCNMCHAR ".-"
                  UCNMCHAR ".-"
                  NAMECASE GENERAL YES
                           ENTITY  NO
         DELIM    GENERAL  SGMLREF
                  SHORTREF SGMLREF
         NAMES    SGMLREF
         QUANTITY SGMLREF
                  ATTSPLEN 2100
                  LITLEN   1024
                  NAMELEN  72    -- somewhat arbitrary; taken from
                                internet line length conventions --
                  PILEN    1024
                  TAGLVL   100
                  TAGLEN   2100
                  GRPGTCNT 150
                  GRPCNT   64

FEATURES
  MINIMIZE
    DATATAG  NO
    OMITTAG  YES
    RANK     NO
    SHORTTAG YES
  LINK
    SIMPLE   NO
    IMPLICIT NO
    EXPLICIT NO
  OTHER
    CONCUR   NO
    SUBDOC   NO
    FORMAL   YES
  APPINFO    "SDA"  -- conforming SGML Document Access application
                    --
>
<!--
        $Id: html.decl,v 1.17 1995/06/08 14:59:32 connolly Exp $

        Author: Daniel W. Connolly <connolly@w3.org>

        See also: http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
 -->

9.6. Sample SGML Open Entity Catalog for HTML πŸ—‚οΈ

so an "entity manager" is the bit of an SGML system that maps entities onto real storage, like files on your computer. the SGML standard talks about this but doesn't pick a specific way to do the mapping, so it's kinda up to you πŸ€·β€β™€οΈ

to keep all the SGML tools playing nicely together, the SGML Open consortium passed a technical resolution. it defines a catalog format that's not tied to any one application and maps public identifiers and/or entity names to file names.

every catalog entry links a storage object identifier (like a file name) to info about an external entity in the SGML document. on top of public identifiers, an entry can also link an entity name to a storage object identifier. here are some example entries, bestie:

        -- catalog: SGML Open style entity catalog for HTML --
        -- $Id: catalog,v 1.3 1995/09/21 23:30:23 connolly Exp $ --

        -- Ways to refer to Level 2: most general to most specific --
PUBLIC  "-//IETF//DTD HTML//EN"                 html.dtd
PUBLIC  "-//IETF//DTD HTML 2.0//EN"             html.dtd
PUBLIC  "-//IETF//DTD HTML Level 2//EN"         html.dtd
PUBLIC  "-//IETF//DTD HTML 2.0 Level 2//EN"     html.dtd

        -- Ways to refer to Level 1: most general to most specific --
PUBLIC  "-//IETF//DTD HTML Level 1//EN"         html-1.dtd
PUBLIC  "-//IETF//DTD HTML 2.0 Level 1//EN"     html-1.dtd

        -- Ways to refer to
                 Strict Level 2: most general to most specific --
PUBLIC  "-//IETF//DTD HTML Strict//EN"                  html-s.dtd
PUBLIC  "-//IETF//DTD HTML 2.0 Strict//EN"              html-s.dtd
PUBLIC  "-//IETF//DTD HTML Strict Level 2//EN"          html-s.dtd
PUBLIC  "-//IETF//DTD HTML 2.0 Strict Level 2//EN"      html-s.dtd

        -- Ways to refer to
                 Strict Level 1: most general to most specific --
PUBLIC  "-//IETF//DTD HTML Strict Level 1//EN"          html-1s.dtd
PUBLIC  "-//IETF//DTD HTML 2.0 Strict Level 1//EN"      html-1s.dtd

        -- ISO latin 1 entity set for HTML --
PUBLIC  "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML" ISOlat1\
sgml

9.7. Character Entity Sets πŸ’–

the HTML DTD defines a bunch of entities. each one stands for a graphic character that either has a special job in the markup or just isn't something the writer can type on their keyboard πŸ¦‹

9.7.1. Numeric and Special Graphic Entity Set 🌈

this table lists the characters from the Numeric and Special Graphic entity set, with each one's name, how to write it, and what it is. it's pulled from ISO Standard 8879:1986//ENTITIES Numeric and Special Graphic//EN, but HTML only grabs the entities in this list, not the whole set, so don't come for the rest πŸ™…β€β™€οΈ

GLYPH   NAME    SYNTAX  DESCRIPTION
<       lt      &lt;    Less than sign
>       gt      &gt;    Greater than signn
&       amp     &amp;   Ampersand
"       quot    &quot;  Double quote sign

9.7.2. ISO Latin 1 Character Entity Set 🌸

this public text lists every character from the Added Latin 1 entity set, with names, syntax, and descriptions. it's based on ISO Standard 8879:1986//ENTITIES Added Latin 1//EN, and unlike the last table, HTML includes the entire set, so you get all of it ✨

<!-- (C) International Organization for Standardization 1986
     Permission to copy in any form is granted for use with
     conforming SGML systems and applications as defined in
     ISO 8879, provided this notice is included in all copies.
-->
<!-- Character entity set. Typical invocation:
     <!ENTITY % ISOlat1 PUBLIC
       "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
     %ISOlat1;
-->
<!--    Modified for use in HTML
        $Id: ISOlat1.sgml,v 1.2 1994/11/30 23:45:12 connolly Exp $ -->
<!ENTITY AElig  CDATA "&#198;" -- capital AE diphthong (ligature) -->
<!ENTITY Aacute CDATA "&#193;" -- capital A, acute accent -->
<!ENTITY Acirc  CDATA "&#194;" -- capital A, circumflex accent -->
<!ENTITY Agrave CDATA "&#192;" -- capital A, grave accent -->
<!ENTITY Aring  CDATA "&#197;" -- capital A, ring -->
<!ENTITY Atilde CDATA "&#195;" -- capital A, tilde -->
<!ENTITY Auml   CDATA "&#196;" -- capital A, dieresis or umlaut mark -->
<!ENTITY Ccedil CDATA "&#199;" -- capital C, cedilla -->
<!ENTITY ETH    CDATA "&#208;" -- capital Eth, Icelandic -->
<!ENTITY Eacute CDATA "&#201;" -- capital E, acute accent -->
<!ENTITY Ecirc  CDATA "&#202;" -- capital E, circumflex accent -->
<!ENTITY Egrave CDATA "&#200;" -- capital E, grave accent -->
<!ENTITY Euml   CDATA "&#203;" -- capital E, dieresis or umlaut mark -->
<!ENTITY Iacute CDATA "&#205;" -- capital I, acute accent -->
<!ENTITY Icirc  CDATA "&#206;" -- capital I, circumflex accent -->
<!ENTITY Igrave CDATA "&#204;" -- capital I, grave accent -->
<!ENTITY Iuml   CDATA "&#207;" -- capital I, dieresis or umlaut mark -->
<!ENTITY Ntilde CDATA "&#209;" -- capital N, tilde -->
<!ENTITY Oacute CDATA "&#211;" -- capital O, acute accent -->
<!ENTITY Ocirc  CDATA "&#212;" -- capital O, circumflex accent -->
<!ENTITY Ograve CDATA "&#210;" -- capital O, grave accent -->
<!ENTITY Oslash CDATA "&#216;" -- capital O, slash -->
<!ENTITY Otilde CDATA "&#213;" -- capital O, tilde -->
<!ENTITY Ouml   CDATA "&#214;" -- capital O, dieresis or umlaut mark -->
<!ENTITY THORN  CDATA "&#222;" -- capital THORN, Icelandic -->
<!ENTITY Uacute CDATA "&#218;" -- capital U, acute accent -->
<!ENTITY Ucirc  CDATA "&#219;" -- capital U, circumflex accent -->
<!ENTITY Ugrave CDATA "&#217;" -- capital U, grave accent -->
<!ENTITY Uuml   CDATA "&#220;" -- capital U, dieresis or umlaut mark -->
<!ENTITY Yacute CDATA "&#221;" -- capital Y, acute accent -->
<!ENTITY aacute CDATA "&#225;" -- small a, acute accent -->
<!ENTITY acirc  CDATA "&#226;" -- small a, circumflex accent -->
<!ENTITY aelig  CDATA "&#230;" -- small ae diphthong (ligature) -->

Okay bestie, the entity list is still going, so here's the rest of the alphabet πŸ’–

<!ENTITY agrave CDATA "&#224;" -- small a, grave accent -->
<!ENTITY aring  CDATA "&#229;" -- small a, ring -->
<!ENTITY atilde CDATA "&#227;" -- small a, tilde -->
<!ENTITY auml   CDATA "&#228;" -- small a, dieresis or umlaut mark -->
<!ENTITY ccedil CDATA "&#231;" -- small c, cedilla -->
<!ENTITY eacute CDATA "&#233;" -- small e, acute accent -->
<!ENTITY ecirc  CDATA "&#234;" -- small e, circumflex accent -->
<!ENTITY egrave CDATA "&#232;" -- small e, grave accent -->
<!ENTITY eth    CDATA "&#240;" -- small eth, Icelandic -->
<!ENTITY euml   CDATA "&#235;" -- small e, dieresis or umlaut mark -->
<!ENTITY iacute CDATA "&#237;" -- small i, acute accent -->
<!ENTITY icirc  CDATA "&#238;" -- small i, circumflex accent -->
<!ENTITY igrave CDATA "&#236;" -- small i, grave accent -->
<!ENTITY iuml   CDATA "&#239;" -- small i, dieresis or umlaut mark -->
<!ENTITY ntilde CDATA "&#241;" -- small n, tilde -->
<!ENTITY oacute CDATA "&#243;" -- small o, acute accent -->
<!ENTITY ocirc  CDATA "&#244;" -- small o, circumflex accent -->
<!ENTITY ograve CDATA "&#242;" -- small o, grave accent -->
<!ENTITY oslash CDATA "&#248;" -- small o, slash -->
<!ENTITY otilde CDATA "&#245;" -- small o, tilde -->
<!ENTITY ouml   CDATA "&#246;" -- small o, dieresis or umlaut mark -->
<!ENTITY szlig  CDATA "&#223;" -- small sharp s, German (sz ligature)->
<!ENTITY thorn  CDATA "&#254;" -- small thorn, Icelandic -->
<!ENTITY uacute CDATA "&#250;" -- small u, acute accent -->
<!ENTITY ucirc  CDATA "&#251;" -- small u, circumflex accent -->
<!ENTITY ugrave CDATA "&#249;" -- small u, grave accent -->
<!ENTITY uuml   CDATA "&#252;" -- small u, dieresis or umlaut mark -->
<!ENTITY yacute CDATA "&#253;" -- small y, acute accent -->
<!ENTITY yuml   CDATA "&#255;" -- small y, dieresis or umlaut mark -->

10. Security Considerations ✨

Okay, this part is serious, so read it carefully 🚨

Anchors, embedded images, and every other element that takes a URI as a parameter can cause that URI to get dereferenced when a user interacts with it. When that happens, the security considerations of [URL] apply, so go check those too πŸ”

The two widely deployed ways of submitting form requests, HTTP and SMTP, give you pretty much no confidentiality 😭 If information providers ask for sensitive stuff through forms, especially with the PASSWORD type input field (see 8.1.2, "Input Field: INPUT"), they should be aware of that lack of confidentiality and make sure their users are aware of it too πŸ’€


11. References πŸ“š

  • [URI] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World- Wide Web", RFC 1630, CERN, June 1994. <URL:ftp://ds.internic.net/rfc/rfc1630.txt>
  • [URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994. <URL:ftp://ds.internic.net/rfc/rfc1738.txt>
  • [HTTP] Berners-Lee, T., Fielding, R., and H. Frystyk Nielsen, "Hypertext Transfer Protocol - HTTP/1.0", Work in Progress, MIT, UC Irvine, CERN, March 1995.
  • [MIME] Borenstein, N., and N. Freed. "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993. <URL:ftp://ds.internic.net/rfc/rfc1521.txt>
  • [RELURL] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995 <URL:ftp://ds.internic.net/rfc/rfc1808.txt>
  • [GOLD90] Goldfarb, C., "The SGML Handbook", Y. Rubinsky, Ed., Oxford University Press, 1990.
  • [DEXTER] Frank Halasz and Mayer Schwartz, "The Dexter Hypertext Reference Model", Communications of the ACM, pp. 30-39, vol. 37 no. 2, Feb 1994.
  • [IMEDIA] Postel, J., "Media Type Registration Procedure", RFC 1590, USC/Information Sciences Institute, March 1994. <URL:ftp://ds.internic.net/rfc/rfc1590.txt>
  • [IANA] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciecnes Institute, October 1994. <URL:ftp://ds.internic.net/rfc/rfc1700.txt>
  • [SQ91] SoftQuad. "The SGML Primer", 3rd ed., SoftQuad Inc., 1991. <URL:http://www.sq.com/>
  • [ISO-646] ISO/IEC 646:1991 Information technology -- ISO 7-bit coded character set for information interchange <URL:http://www.iso.ch/cate/d4777.html>
  • [ISO-10646] ISO/IEC 10646-1:1993 Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane <URL:http://www.iso.ch/cate/d18741.html>
  • [ISO-8859-1] ISO 8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. <URL:http://www.iso.ch/cate/d16338.html>
  • [SGML] ISO 8879. Information Processing -- Text and Office Systems - Standard Generalized Markup Language (SGML), 1986. <URL:http://www.iso.ch/cate/d16387.html>

12. Acknowledgments 🫢

The HTML document type came from Tim Berners-Lee at CERN, as part of the 1990 World Wide Web project 🌸 In 1992, Dan Connolly wrote the HTML Document Type Definition (DTD) and a brief HTML specification ✨

Since 1993, a huge crowd of Internet people has helped HTML grow 🌈 That includes the addition of in-line images, which came from the NCSA Mosaic software for WWW πŸ–ΌοΈ Dave Raggett was a big part of pulling the forms material over from the HTML+ specification πŸ’…

Dan Connolly and Karen Olson Muldrow rewrote the HTML Specification in 1994 πŸŽ€ Then the HTML working group edited it as a whole, with updates from Eric Schieler, Mike Knezovich, and Eric W. Sink at Spyglass, Inc. Finally, Roy Fielding restructured the entire draft into the form we have now πŸ‘‘

Special thanks to the many active members of the HTML working group, way too many to name one by one 🧚 Without them there would be no standards process and no standard, periodt πŸ’œ The fact that this document gets close to its goal of carefully converging a description of current practice with a formalization of HTML's relationship to SGML is honestly a tribute to all their effort πŸ¦‹

12.1. Authors' Addresses πŸ’Œ

Tim Berners-Lee
Director, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.

Phone: +1 (617) 253 9670
Fax: +1 (617) 258 8682
EMail: timbl@w3.org
Daniel W. Connolly
Research Technical Staff, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.

Phone: +1 (617) 258 8682
EMail: connolly@w3.org
URI: http://www.w3.org/hypertext/WWW/People/Connolly/

13. The HTML Coded Character Set ✨

okay bestie, this section is basically the master list of characters for HTML πŸ”€πŸ’– It maps every code position to the character it stands for, for the HTML document character set from 9.5, "SGML Declaration for HTML". And the whole thing is built on [ISO-8859-1] 🌸

Some slots are marked as Unused πŸ™ˆ which is giving "reserved, don't touch" energy, and the big blocks of letters and digits are listed as ranges so you don't have to read every single one πŸ’…

REFERENCE       DESCRIPTION
--------------  -----------
&#00; - &#08;   Unused
&#09;           Horizontal tab
&#10;           Line feed
&#11; - &#12;   Unused
&#13;           Carriage Return
&#14; - &#31;   Unused
&#32;           Space
&#33;           Exclamation mark
&#34;           Quotation mark
&#35;           Number sign
&#36;           Dollar sign
&#37;           Percent sign
&#38;           Ampersand
&#39;           Apostrophe
&#40;           Left parenthesis
&#41;           Right parenthesis
&#42;           Asterisk
&#43;           Plus sign
&#44;           Comma
&#45;           Hyphen
&#46;           Period (fullstop)
&#47;           Solidus (slash)
&#48; - &#57;   Digits 0-9
&#58;           Colon
&#59;           Semi-colon
&#60;           Less than
&#61;           Equals sign
&#62;           Greater than
&#63;           Question mark
&#64;           Commercial at
&#65; - &#90;   Letters A-Z
&#91;           Left square bracket
&#92;           Reverse solidus (backslash)
&#93;           Right square bracket
&#94;           Caret
&#95;           Horizontal bar (underscore)
&#96;           Acute accent
&#97; - &#122;  Letters a-z
&#123;          Left curly brace
&#124;          Vertical bar
&#125;          Right curly brace
&#126;          Tilde
&#127; - &#159; Unused
&#160;          Non-breaking Space
&#161;          Inverted exclamation
&#162;          Cent sign
&#163;          Pound sterling
&#164;          General currency sign
&#165;          Yen sign
&#166;          Broken vertical bar
&#167;          Section sign
&#168;          Umlaut (dieresis)
&#169;          Copyright
&#170;          Feminine ordinal
&#171;          Left angle quote, guillemotleft
&#172;          Not sign
&#173;          Soft hyphen
&#174;          Registered trademark
&#175;          Macron accent
&#176;          Degree sign
&#177;          Plus or minus
&#178;          Superscript two
&#179;          Superscript three
&#180;          Acute accent
&#181;          Micro sign
&#182;          Paragraph sign
&#183;          Middle dot
&#184;          Cedilla
&#185;          Superscript one
&#186;          Masculine ordinal
&#187;          Right angle quote, guillemotright
&#188;          Fraction one-fourth
&#189;          Fraction one-half
&#190;          Fraction three-fourths
&#191;          Inverted question mark
&#192;          Capital A, grave accent
&#193;          Capital A, acute accent
&#194;          Capital A, circumflex accent
&#195;          Capital A, tilde
&#196;          Capital A, dieresis or umlaut mark
&#197;          Capital A, ring
&#198;          Capital AE dipthong (ligature)
&#199;          Capital C, cedilla
&#200;          Capital E, grave accent
&#201;          Capital E, acute accent
&#202;          Capital E, circumflex accent
&#203;          Capital E, dieresis or umlaut mark
&#204;          Capital I, grave accent
&#205;          Capital I, acute accent
&#206;          Capital I, circumflex accent
&#207;          Capital I, dieresis or umlaut mark
&#208;          Capital Eth, Icelandic
&#209;          Capital N, tilde
&#210;          Capital O, grave accent
&#211;          Capital O, acute accent
&#212;          Capital O, circumflex accent
&#213;          Capital O, tilde
&#214;          Capital O, dieresis or umlaut mark
&#215;          Multiply sign
&#216;          Capital O, slash
&#217;          Capital U, grave accent
&#218;          Capital U, acute accent
&#219;          Capital U, circumflex accent
&#220;          Capital U, dieresis or umlaut mark
&#221;          Capital Y, acute accent
&#222;          Capital THORN, Icelandic
&#223;          Small sharp s, German (sz ligature)
&#224;          Small a, grave accent
&#225;          Small a, acute accent
&#226;          Small a, circumflex accent
&#227;          Small a, tilde
&#228;          Small a, dieresis or umlaut mark
&#229;          Small a, ring
&#230;          Small ae dipthong (ligature)
&#231;          Small c, cedilla
&#232;          Small e, grave accent
&#233;          Small e, acute accent
&#234;          Small e, circumflex accent
&#235;          Small e, dieresis or umlaut mark
&#236;          Small i, grave accent
&#237;          Small i, acute accent
&#238;          Small i, circumflex accent
&#239;          Small i, dieresis or umlaut mark
&#240;          Small eth, Icelandic
&#241;          Small n, tilde
&#242;          Small o, grave accent
&#243;          Small o, acute accent
&#244;          Small o, circumflex accent
&#245;          Small o, tilde
&#246;          Small o, dieresis or umlaut mark
&#247;          Division sign
&#248;          Small o, slash
&#249;          Small u, grave accent
&#250;          Small u, acute accent
&#251;          Small u, circumflex accent
&#252;          Small u, dieresis or umlaut mark
&#253;          Small y, acute accent
&#254;          Small thorn, Icelandic
&#255;          Small y, dieresis or umlaut mark
the 🫢 takeaway: every entry is just "this number means this character," so it's basically a lookup table you'll come back to again and again πŸ¦‹

Last one, bestie πŸ¦‹ yuml is the small y with dieresis (or umlaut), and it's the very final entry in the whole set, so this is literally the end of the line ✨

<!ENTITY yuml   CDATA "&#255;" -- small y, dieresis or umlaut mark -->

And that's the whole list, all the way to 255 πŸ’œ the end. Every ISO 8859-1 character now has its own symbolic name, so you can reference them without memorising the numbers πŸ«ΆπŸ’…

πŸ“¦ where this page comes from