Contents
The following sections discuss issues surrounding the structuring of text. Elements that format text (alignment elements, font elements, style sheets, etc.) are discussed in later sections of the specification. Please consult the section on SGML for questions about character syntax.
The SGML specification distinguishes between record start characters (line feeds) and record ends (carriage returns). On the Internet, some platforms use carriage return line feed pairs for line breaks, some use just line feeds, and others just carriage returns. As a result, HTML user agents should consider both isolated line feed and carriage return characters as line breaks, with carriage return line feed pairs treated as single line breaks.
A line break occurring immediately following a start tag should be discarded, as should a line break occurring immediately before an end tag. This applies to all HTML elements without exceptions. In addition, for all elements except PRE, a sequence of contiguous white space characters such as spaces, horizontal tabs, form feeds and line breaks, should be replaced by a single word space.
Since the notion of what word space is varies from script (written language) to script, user agents should collapse white space in script-sensitive ways. For example, in Latin scripts, a single word space is just a space (ASCII decimal 32), while in Thai it is a zero-width word separator. In Japanese and Chinese, a word space is ignored entirely.
These rules allow authors to use white space to lay out their markup as desired, clarifying the source HTML with white space that will not be rendered by a user agent.
For instance, the following source HTML:
<P>
This example shows a paragraph and a list.
</P>
<UL>
<LI>
This is the <EM>first</EM> item
</LI>
<LI>
This is the <EM>second</EM> item
</LI>
</UL>
may be rewritten (by omitting end tags) and laid out differently (by using less white space):
<P>This example shows a paragraph and a list. <UL> <LI>This is the <EM>first</EM> item <LI>This is the <EM>second</EM> item </UL>
but should be rendered identically by a user agent.
The PRE element is used for preformatted text, where white space is significant. The PRE element is described below.
<!ENTITY % phrase "EM | STRONG | DFN | CODE |
SAMP | KBD | VAR | CITE | ACRONYM">
<!ELEMENT (%font|%phrase) - - (%inline)*>
<!ATTLIST (%font|%phrase)
%attrs; -- %coreattrs, %i18n, %events --
>
Start tag: required, End tag: required
Attributes defined elsewhere
Phrasal elements add structural information to text fragments. The usual meanings of phrasal elements are following:
EM and STRONG are useful in general to indicate emphasis. The other phrasal elements have particular significance in technical documents. These examples illustrate the rendering of some of the textual markup elements:
"More information can be found in <CITE>[ISO-0000]</CITE>." "Please refer to the following reference number in future correspondence: <STRONG>1-234-55</STRONG>"
The ACRONYM element allows authors to clearly indicate a sequence of characters that compose an acronym (e.g., "WWW", "FNAC", "IRS", etc.). The ability to identify acronyms is useful to spell checkers, speech synthesizers, and other user agents and tools.
The content of the ACRONYM element specifies the acronym itself. The title attribute may be used to provide the text to which the acronym expands. Here are some sample acronym definitions:
<ACRONYM title="World Wide Web">WWW</ACRONYM> <ACRONYM lang="fr" title="Société Nationale de Chemins de Fer"> SNCF </ACRONYM>
The presentation of phrasal elements depends on the user agent. Generally, visual user agents present EM text in italics and STRONG text in bold font. Speech synthesiser agents might change the synthesis parameters, such as volume, pitch and rate accordingly. Acronyms are generally spoken by pronouncing the individual letters separately.
Note: This version of HTML doesn't include special markup for abbreviations. We recommend that speech synthesizers use client-side dictionaries to expand any abbreviations found in the document. For specialized vocabularies, LINK elements in the document head can be used to reference suitable dictionaries.
<!ELEMENT BLOCKQUOTE - - %block> <!ATTLIST BLOCKQUOTE %attrs; -- %coreattrs, %i18n, %events -- cite %URL #IMPLIED -- URL for source document or msg -- > <!ELEMENT Q - - (%inline)*> <!ATTLIST Q %attrs; -- %coreattrs, %i18n, %events -- cite %URL #IMPLIED -- URL for source document or msg -- >
Start tag: required, End tag: required
Attribute definitions
Attributes defined elsewhere
These two elements designate quoted text. BLOCKQUOTE is for long quotations and Q is intended for short quotations that don't require paragraph breaks.
This example formats an excerpt from "The Two Towers", by J.R.R. Tolkien, as a blockquote.
<BLOCKQUOTE cite="http://www.mycom.com/tolkien/twotowers.html"> They went in single file, running like hounds on a strong scent, and an eager light was in their eyes. Nearly due west the broad swath of the marching Orcs tramped its ugly slot; the sweet grass of Rohan had been bruised and blackened as they passed. </BLOCKQUOTE>
Visual user agents generally render BLOCKQUOTE as an indented block.
Quotation marksIt is recommended that style sheets provide a way to insert quotation marks before and after a quotation delimited by Q or BLOCKQUOTE in a manner appropriate to the current language context (see the lang attribute) and the degree of nesting of quotations.
However, as some authors have used BLOCKQUOTE merely as a mechanism to indent text, in order to preserve the intention of the authors, it is recommended that user agents not insert quotation marks in the default style.
Furthermore, if authors include quotation marks in a Q or BLOCKQUOTE element, user agents should not insert additional quotation marks.
The usage of BLOCKQUOTE to indent text is deprecated in favor of style sheets.
<!-- subscripts and superscripts --> <!ELEMENT (SUB|SUP) - - (%inline)*> <!ATTLIST (SUB|SUP) %attrs; -- %coreattrs, %i18n, %events -- >
Start tag: required, End tag: required
Attributes defined elsewhere
Many scripts (e.g., French) require superscripts or subscripts for proper rendering. The SUB and SUP elements should be used to markup text in these cases.
Here, we use SUP to raise the "lle" in the French "Mlle Dupont":
M<sup>lle</sup> Dupont
The HTML markup for defining a paragraph is straightforward: the P element defines a paragraph.
The visual presentation of paragraphs is not so simple. A number of issues, both stylistic and technical, must be addressed:
We address these questions below. Paragraph alignment and floating objects are discussed later in this document.
<!ELEMENT P - O (%inline)*> <!ATTLIST P %attrs; -- %coreattrs, %i18n, %events -- %align; -- align, text alignment -- >
Start tag: required, End tag: optional
Attributes defined elsewhere
The P element represents a paragraph. It cannot contain block-level elements (including P itself). You can omit the end tag, which is then implied by the next block-level start tag. It is also implied by the end tag of the element that encloses the P element.
<P>This is the first paragraph.</P> <P>This is the second paragraph.</P> ...a block element...
may be rewritten without their end tags:
<P>This is the first paragraph. <P>This is the second paragraph. ...a block element...
since both are implicitly ended by the block elements that follow them. Similarly, if a paragraph is enclosed by a block element, as in:
<DIV> <P>This is the paragraph. </DIV>
the end tag of the enclosing block element (here, DIV) implies the end tag of the P element.
Empty P elements are bad form and should be ignored by the renderer.
How paragraphs are rendered visually depends on the user agent. Paragraphs are usually rendered flush left with a ragged right margin. Other defaults are appropriate for right-to-left scripts.
HTML user agents have traditionally rendered paragraphs with white space before and after, e.g.,
At the same time, there began to take form a system of numbering, the calendar, hieroglyphic writing, and a technically advanced art, all of which later influenced other peoples. Within the framework of this gradual evolution or cultural progress the Preclassic horizon has been divided into Lower, Middle and Upper periods, to which can be added a transitional or Protoclassic period with several features that would later distinguish the emerging civilizations of Mesoamerica.
This contrasts with the style used in novels which indents the first line of the paragraph and uses the regular line spacing between the line of the last paragraph and the first line of the next, e.g.,
At the same time, there began to take form a system of
numbering, the calendar, hieroglyphic writing, and a technically
advanced art, all of which later influenced other peoples.
Within the framework of this gradual evolution or cultural
progress the Preclassic horizon has been divided into Lower,
Middle and Upper periods, to which can be added a transitional
or Protoclassic period with several features that would later
distinguish the emerging civilizations of Mesoamerica.
Following the precedent set by the NCSA Mosaic browser in 1993, user agents generally don't justify both margins, in part because it's hard to do this effectively without sophisticated hyphenation routines. The advent of style sheets, and antialiased fonts with subpixel positioning promises to offer richer choices to HTML authors than previously possible.
Style sheets provide rich control over the size and style of a font, the margins, space before and after a paragraph, the first line indent, justification and many other details. The user agent's default style sheet renders P elements in a familar form, as illustrated above. You could in principle override this to render paragraphs without the breaks that conventionally distinguish successive paragraphs, but this would be confusing to readers and as a rule bad practice.
By convention, visual HTML user agents wrap text lines to fit within the available margins. Wrapping algorithms depend on the script being formatted.
In Western scripts, for example, text should only be wrapped at white space. Early user agents incorrectly wrapped lines at the beginning (or end) of elements, which resulted in dangling punctuation. For example,
A statue of the <a href="cih78">Cihuateteus</a>, who are patron ...
Wrapping the line at the end of the anchor tag causes the comma to be stranded at the beginning of the next line:
A statue of the Cihuateteus , who are patron goddesses ...
This is an error, since there was no white space at that point in the markup.
<!ELEMENT BR - O EMPTY -- forced line break --> <!ATTLIST BR %coreattrs; -- id, class, style, title -- clear (left|all|right|none) none -- control of text flow -- >
Start tag: required, End tag: forbidden
Attributes defined elsewhere
The BR element forcibly breaks (ends) the current line of text.
For visual user agents, the clear attribute can be used to determine whether markup following the BR element flows around images and other objects floated to the left or right margin, or whether it starts after the bottom of such objects. Further details are given in the section on alignment and floating objects. Authors are advised to use style sheets to control text flow around floating images and other objects. The clear attribute, along with other HTML presentation attributes and tags, is only appropriate when you need to consider user agents that don't support style sheets.
With respect to bidirectional formatting, the BR element should be treated in the same way as a Unicode LINE SEPARATOR character.
Sometimes you will want to prevent a line break from occurring between two words. The entity ( ,  ) acts as a space where user agents should not cause a line break.
In HTML, there are two types of hyphens: the plain hyphen and the soft hyphen. The plain hyphen should be interpreted by a user agent as just another character. The soft hyphen tells the user agent where a line break can occur.
Those browsers that interpret soft hyphens must observe the following semantics: If a line is broken at a soft hyphen, a hyphen character must be displayed at the end of the first line. If a line is not broken at a hyphen, the user agent must not display a hyphen character. For operations such as searching and sorting, the soft hyphen should always be ignored.
In HTML, the plain hyphen is represented by the "-" character (-, -). The soft hyphen is represented by the named character entity ­ (­, ­)
<!ENTITY % pre.exclusion "IMG|BIG|SMALL|SUB|SUP|FONT"> <!ELEMENT PRE - - (%inline)* -(%pre.exclusion)> <!ATTLIST PRE %attrs; -- %coreattrs, %i18n, %events -- width NUMBER #IMPLIED >
Start tag: required, End tag: required
Attribute definitions
Attributes defined elsewhere
The PRE element tells visual user agents that the enclosed text is "preformatted". Visual user agents must treat preformatted text as follows:
Note that the SGML standard requires that the parser remove a newline immediately following the start tag or immediately preceding the end tag.
The DTD fragment above indicates which elements may not appear within a PRE declaration. This is the same as in HTML 3.2, and is intended to preserve constant line spacing and column alignment for text rendered in a fixed pitch font. Authors are discouraged from altering this behavior through style sheets.
The following example shows a preformatted verse from Shelly's poem To a Skylark:
<PRE>
Higher still and higher
From the earth thou springest
Like a cloud of fire;
The blue deep thou wingest,
And singing still dost soar, and soaring ever singest.
</PRE>
Here is the same verse as rendered by your user agent:
Higher still and higher
From the earth thou springest
Like a cloud of fire;
The blue deep thou wingest,
And singing still dost soar, and soaring ever singest.
The horizontal tab character
The horizontal tab character (encoded in [UNICODE], US ASCII, and [ISO88591]
as decimal 9) is usually interpreted by visual user agents as the
smallest non-zero number of spaces necessary to line characters up along
tab stops that are every 8 characters. We strongly discourage using
horizontal tabs in preformatted text since it is common practice, when
editing, to set the tab-spacing to other values, leading to misaligned
documents.
<!-- INS/DEL are handled by inclusion on BODY --> <!ELEMENT (INS|DEL) - - (%inline)* -- inserted/deleted text --> <!ATTLIST (INS|DEL) %attrs -- %coreattrs, %i18n, %events -- cite %URL #IMPLIED -- info on reason for change -- datetime CDATA #IMPLIED -- when changed: ISO date format -- >
Start tag: required, End tag: required
Attribute definitions
Attributes defined elsewhere
INS and DEL are used to markup sections of the document that have been inserted or deleted since a previous version of a document (e.g., in draft legislation where law makers need to view the changes).
These two elements are unsual for HTML in that they are neither block-level nor inline elements. They may contain one or more words within a paragraph or englobe one or more block-level elements such as paragraphs, lists and tables.
User agents may render inserted and deleted text in ways that make the change obvious. For instance, inserted text may appear in a special font, deleted text may not be shown at all or be shown as struck-through or with special markings, etc.
User agents that do not recognize the DEL element must render that element's content nonetheless.
[ISO8601] allows many options and variations in the representation of dates and times. This specification defines a specific format which is one of those allowed by [ISO8601].
The format is:
YYYY-MM-DDThh:mm:ssTZDwhere:
YYYY = four-digit year
MM = two-digit month (01=January, etc.)
DD = two-digit day of month (01 through 31)
hh = two digits of hour (00 through 23) (am/pm NOT allowed)
mm = two digits of minute (00 through 59)
ss = two digits of second (00 through 59)
TZD = time zone designator
The time zone designator is one of:
Exactly the components shown here must be present, with exactly this punctuation. Note that the "T" appears literally in the string, to indicate the beginning of the time element, as specified in [ISO8601]
If a generating application does not know the time to the second, it may use the value "00" for the seconds (and minutes and hours if necessary).
1994-11-05T13:15:30Z
1994-11-05T08:15:30-05:00
Used with INS, this gives:
<INS datetime="1994-11-05T08:15:30-05:00"> I added this on November 5th </INS>