Performance, Implementation, and Design Notes

]]>
SGML also defines the use of marked sections for CDATA content, within which
"<" is not treated as the start of a tag, e.g.,
example of markup that is
not to write with < and such.
]]>
The telltale sign that a user agent doesn't recognize a marked section is
the appearance of "]]>", which is seen when the user agent mistakenly uses
the first ">" character as the end of the tag starting with "B.3.6
Processing Instructions
Processing instructions are a mechanism to capture platform-specific idioms.
A processing instruction begins with
instruction
For example:



...
Authors should be aware that many user agents render processing instructions
as part of the document's text.
B.3.7
Shorthand markup
Some SGML SHORTTAG constructs save typing but add no expressive capability
to the SGML application. Although these constructs technically introduce no
ambiguity, they reduce the robustness of documents, especially when the
language is enhanced to include new elements. Thus, while SHORTTAG constructs
of SGML related to attributes are widely used and implemented, those related to
elements are not. Documents that use them are conforming SGML documents, but
are unlikely to work with many existing HTML tools.
The SHORTTAG constructs in question are the following:
NET tags:
closed Start Tag:

Empty Start Tag:
<>
Empty End Tag:

B.4
Notes on helping search engines index your Web
site
This section provides some simple suggestions that will make your documents
more accessible to search engines.
Define the document language
In the global context of the Web it is important to know which human
language a page was written in. This is discussed in the section on
language information
Specify language variants of this document
If you have prepared translations of this document into other languages,
you should use the
LINK
element to reference these. This allows an
indexing engine to offer users search results in the user's preferred language,
regardless of how the query was written. For instance, the following links
offer French and German alternatives to a search engine:
type="text/html"
href="mydoc-fr.html" hreflang="fr"
lang="fr" title="La vie souterraine">
type="text/html"
href="mydoc-de.html" hreflang="de"
lang="de" title="Das Leben im Untergrund">
Provide keywords and descriptions
Some indexing engines look for
META
elements that define a
comma-separated list of keywords/phrases, or that give a short description.
Search engines may present these keywords as the result of a search. The value
of the
name
attribute sought by a search engine is not
defined by this specification. Consider these examples,


Indicate the beginning of a collection
Collections of word processing documents or presentations are frequently
translated into collections of HTML documents. It is helpful for search results
to reference the beginning of the collection in addition to the page hit by the
search. You may help search engines by using the
LINK
element with
rel="start"
along with the
title
attribute, as in:
type="text/html"
href="page1.html"
title="General Theory of Relativity">
Provide robots with indexing instructions
People may be surprised to find that their site has been indexed by an
indexing robot and that the robot should not have been permitted to visit a
sensitive part of the site. Many Web robots offer facilities for Web site
administrators and content providers to limit what the robot does. This is
achieved through two mechanisms: a "robots.txt" file and the
META
element in HTML documents, described below.
B.4.1
Search robots
The robots.txt file
When a Robot visits a Web site, say http://www.foobar.com/, it firsts checks
for http://www.foobar.com/robots.txt. If it can find this document, it will
analyze its contents to see if it is allowed to retrieve the document. You can
customize the robots.txt file to apply only to specific robots, and to disallow
access to specific directories or files.
Here is a sample robots.txt file that prevents all robots from visiting the
entire site
User-agent: * # applies to all robots
Disallow: / # disallow indexing of all pages
The Robot will simply look for a "/robots.txt" URI on your site, where a
site is defined as a HTTP server running on a particular host and port number.
Here are some sample locations for
robots.txt
Site URI
URI for
robots.txt
There can only be a single "/robots.txt" on a site. Specifically, you should
not put "robots.txt" files in user directories, because a robot will never look
at them. If you want your users to be able to create their own "robots.txt",
you will need to merge them all into a single "/robots.txt". If you don't want
to do this your users might want to use the Robots META Tag instead.
Some tips: URI's are case-sensitive, and "/robots.txt" string must be all
lower-case. Blank lines are not permitted within a single record in the
"robots.txt" file.
There must be exactly one "User-agent" field per record. The robot should be
liberal in interpreting this field. A case-insensitive substring match of the
name without version information is recommended.
If the value is "*", the record describes the default access policy for any
robot that has not matched any of the other records. It is not allowed to have
multiple such records in the "/robots.txt" file.
The "Disallow" field specifies a partial URI that is not to be visited. This
can be a full path, or a partial path; any URI that starts with this value will
not be retrieved. For example,
Disallow: /help
disallows both /help.html and /help/index.html, whereas
Disallow: /help/
would disallow /help/index.html but allow /help.html.
An empty value for "Disallow", indicates that all URIs can be retrieved. At
least one "Disallow" field must be present in the robots.txt file.
Robots and the META element
The
META
element allows HTML authors to tell visiting robots
whether a document may be indexed, or used to harvest more links. No server
administrator action is required.
In the following example a robot should neither index this document, nor
analyze it for links.

The list of terms in the content is
ALL
INDEX
NOFOLLOW
NOINDEX
Note.
In early 1997 only a few robots implement this,
but this is expected to change as more public attention is given to controlling
indexing robots.
B.5
Notes on tables
B.5.1
Design rationale
The HTML table model has evolved from studies of existing SGML tables
models, the treatment of tables in common word processing packages, and a wide
range of tabular layout techniques in magazines, books and other paper-based
documents. The model was chosen to allow simple tables to be expressed simply
with extra complexity available when needed. This makes it practical to create
the markup for HTML tables with everyday text editors and reduces the learning
curve for getting started. This feature has been very important to the success
of HTML to date.
Increasingly, people are creating tables by converting from other document
formats or by creating them directly with WYSIWYG editors. It is important that
the HTML table model fit well with these authoring tools. This affects how the
cells that span multiple rows or columns are represented, and how alignment and
other presentation properties are associated with groups of cells.
Dynamic reformatting
A major consideration for the HTML table model is that the author does not
control how a user will size a table, what fonts he or she will use, etc. This
makes it risky to rely on column widths specified in terms of absolute pixel
units. Instead, tables must be able to change sizes dynamically to match the
current window size and fonts. Authors can provide guidance as to the relative
widths of columns, but user agents should ensure that columns are wide enough
to render the width of the largest element of the cell's content. If the
author's specification must be overridden, relative widths of individual
columns should not be changed drastically.
Incremental display
For large tables or slow network connections, incremental table display is
important to user satisfaction. User agents should be able to begin displaying
a table before all of the data has been received. The default window width for
most user agents shows about 80 characters, and the graphics for many HTML
pages are designed with these defaults in mind. By specifying the number of
columns, and including provision for control of table width and the widths of
different columns, authors can give hints to user agents that allow the
incremental display of table contents.
For incremental display, the browser needs the number of columns and their
widths. The default width of the table is the current window size
width="100%"
). This can be altered by setting the
width
attribute of the
TABLE
element. By default, all columns have the same width, but you
can specify column widths with one or more
COL
elements before the table data starts.
The remaining issue is the number of columns. Some people have suggested
waiting until the first row of the table has been received, but this could take
a long time if the cells have a lot of content. On the whole it makes more
sense, when incremental display is desired, to get authors to explicitly
specify the number of columns in the
TABLE
element.
Authors still need a way of telling user agents whether to use incremental
display or to size the table automatically to fit the cell contents. In the two
pass auto-sizing mode, the number of columns is determined by the first pass.
In the incremental mode, the number of columns must be stated up front (with
COL
or
COLGROUP
elements).
Structure and presentation
HTML distinguishes structural markup such as paragraphs and quotations from
rendering idioms such as margins, fonts, colors, etc. How does this distinction
affect tables? From the purist's point of view, the alignment of text within
table cells and the borders between cells is a rendering issue, not one of
structure. In practice, though, it is useful to group these with the structural
information, as these features are highly portable from one application to the
next. The HTML table model leaves most rendering information to associated
style sheets. The model presented in this specification is designed to take
advantage of such style sheets but not to require them.
Current desktop publishing packages provide very rich control over the
rendering of tables, and it would be impractical to reproduce this in HTML,
without making HTML into a bulky rich text format like RTF or MIF. This
specification does, however, offer authors the ability to choose from a set of
commonly used classes of border styles. The
frame
attribute controls the appearance of the border frame around
the table while the
rules
attribute determines the choice of
rulings within the table. A finer level of control will be supported via
rendering annotations. The
style
attribute can be used for
specifying rendering information for individual elements. Further rendering
information can be given with the
STYLE
element in the document
head or via linked style sheets.
During the development of this specification, a number of avenues were
investigated for specifying the ruling patterns for tables. One issue concerns
the kinds of statements that can be made. Including support for edge
subtraction as well as edge addition leads to relatively complex algorithms.
For instance, work on allowing the full set of table elements to include the
frame
and
rules
attributes led to an
algorithm involving some 24 steps to determine whether a particular edge of a
cell should be ruled or not. Even this additional complexity doesn't provide
enough rendering control to meet the full range of needs for tables. The
current specification deliberately sticks to a simple intuitive model,
sufficient for most purposes. Further experimental work is needed before a more
complex approach is standardized.
Row and column groups
This specification provides a superset of the simpler model presented in
earlier work on HTML+. Tables are considered as being formed from an optional
caption together with a sequence of rows, which in turn consist of a sequence
of table cells. The model further differentiates header and data cells, and
allows cells to span multiple rows and columns.
Following the CALS table model (see
[CALS]
), this specification
allows table rows to be grouped into head and body and foot sections. This
simplifies the representation of rendering information and can be used to
repeat table head and foot rows when breaking tables across page boundaries, or
to provide fixed headers above a scrollable body panel. In the markup, the foot
section is placed before the body sections. This is an optimization shared with
CALS for dealing with very long tables. It allows the foot to be rendered
without having to wait for the entire table to be processed.
For the visually impaired, HTML offers the hope of setting to rights the
damage caused by the adoption of windows based graphical user interfaces. The
HTML table model includes attributes for labeling each cell, to support high
quality text to speech conversion. The same attributes can also be used to
support automated import and export of table data to databases or
spreadsheets.
B.5.2
Recommended Layout Algorithms
If
COL
or
COLGROUP
elements are present, they
specify the number of columns and the table may be rendered using a fixed
layout. Otherwise the autolayout algorithm described below should be used.
If the
width
attribute is not specified, visual user agents
should assume a default value of
100%
for formatting.
It is recommended that user agents increase table widths beyond the value
specified by
width
in cases when cell contents would otherwise
overflow. User agents that override the specified width should do so within
reason. User agents may elect to split words across lines to avoid the need for
excessive horizontal scrolling or when such scrolling is impractical or
undesired.
For the purposes of layout, user agents should consider that table captions
(specified by the
CAPTION
element) behave like cells. Each caption
is a cell that spans all of the table's columns if at the top or bottom of the
table, and rows if at the left or right side of the table.
Fixed Layout Algorithm
For this algorithm, it is assumed that the number of columns is known. The
column widths by default should be set to the same size. Authors may override
this by specifying relative or absolute column widths, using the
COLGROUP
or
COL
elements. The default table width is the
space between the current left and right margins, but may be overridden by the
width
attribute on the
TABLE
element, or determined from absolute column widths. To deal
with mixtures of absolute and relative column widths, the first step is to
allocate space from the table width to columns with absolute widths. After
this, the space remaining is divided up between the columns with relative
widths.
The table syntax alone is insufficient to guarantee the consistency of
attribute values. For instance, the number of
COL
and
COLGROUP
elements may be inconsistent
with the number of columns implied by the table cells. A further problem occurs
when the columns are too narrow to avoid overflow of cell contents. The width
of the table as specified by the
TABLE
element or
COL
elements may result in overflow of cell contents. It is
recommended that user agents attempt to recover gracefully from these
situations, e.g., by
hyphenating
words
and resorting to splitting words if hyphenation points are
unknown.
In the event that an indivisible element causes cell overflow, the user
agent may consider adjusting column widths and re-rendering the table. In the
worst case, clipping may be considered if column width adjustments and/or
scrollable cell content are not feasible. In any case, if cell content is split
or clipped this should be indicated to the user in an appropriate manner.
Autolayout Algorithm
If the number of columns is not specified with
COL
and
COLGROUP
elements, then the user agent
should use the following autolayout algorithm. It uses two passes through the
table data and scales linearly with the size of the table.
In the first pass, line wrapping is disabled, and the user agent keeps track
of the minimum and maximum width of each cell. The maximum width is given by
the widest line. Since line wrap has been disabled, paragraphs are treated as
long lines unless broken by
BR
elements. The minimum width is given
by the widest text element (word, image, etc.) taking into account leading
indents and list bullets, etc. In other words, it is necessary to determine the
minimum width a cell would require in a window of its own before the cell
begins to overflow. Allowing user agents to split words will minimize the need
for horizontal scrolling or in the worst case, clipping the cell contents.
This process also applies to any nested tables occurring in cell content.
The minimum and maximum widths for cells in nested tables are used to determine
the minimum and maximum widths for these tables and hence for the parent table
cell itself. The algorithm is linear with aggregate cell content, and broadly
speaking, independent of the depth of nesting.
To cope with character alignment of cell contents, the algorithm keeps three
running min/max totals for each column: Left of align char, right of align char
and unaligned. The minimum width for a column is then:
max(min_left +
min_right, min_non-aligned)
The minimum and maximum cell widths are then used to determine the
corresponding minimum and maximum widths for the columns. These in turn, are
used to find the minimum and maximum width for the table. Note that cells can
contain nested tables, but this doesn't complicate the code significantly. The
next step is to assign column widths according to the available space (i.e.,
the space between the current left and right margins).
For cells that span multiple columns, a simple approach consists of
apportioning the min/max widths evenly to each of the constituent columns. A
slightly more complex approach is to use the min/max widths of unspanned cells
to weight how spanned widths are apportioned. Experiments suggest that a blend
of the two approaches gives good results for a wide range of tables.
The table borders and intercell margins need to be included in assigning
column widths. There are three cases:
The minimum table width is equal to or wider than the available
space.
In this case, assign the minimum widths and allow the user to scroll
horizontally. For conversion to braille, it will be necessary to replace the
cells by references to notes containing their full content. By convention these
appear before the table.
The maximum table width fits within the available space.
In this
case, set the columns to their maximum widths.
The maximum width of the table is greater than the available space, but
the minimum table width is smaller.
In this case, find the difference
between the available space and the minimum table width, lets call it
Lets also call
the difference between maximum and minimum width of the
table.
For each column, let
be the difference between maximum and minimum
width of that column. Now set the column's width to the minimum width plus
times
over
. This makes columns with large differences
between minimum and maximum widths wider than columns with smaller
differences.
This assignment step is then repeated for nested tables using the minimum
and maximum widths derived for all such tables in the first pass. In this case,
the width of the parent table cell plays the role of the current window size in
the above description. This process is repeated recursively for all nested
tables. The topmost table is then rendered using the assigned widths. Nested
tables are subsequently rendered as part of the parent table's cell
contents.
If the table width is specified with the
width
attribute, the user agent attempts to set column
widths to match. The
width
attribute is not binding if
this results in columns having less than their minimum (i.e., indivisible)
widths.
If relative widths are specified with the
COL
element, the algorithm is modified to increase column widths
over the minimum width to meet the relative width constraints. The
COL
elements should be taken as hints only, so columns shouldn't be
set to less than their minimum width. Similarly, columns shouldn't be made so
wide that the table stretches well beyond the extent of the window. If a
COL
element specifies a relative width of zero, the column should
always be set to its minimum width.
When using the two pass layout algorithm, the default alignment position in
the absence of an explicit or inherited
charoff
attribute can be determined by choosing the position that
would center lines for which the widths before and after the alignment
character are at the maximum values for any of the lines in the column for
which
align="char"
. For incremental table layout the suggested default
is
charoff="50%"
. If several cells in different rows for the same
column use character alignment, then by default, all such cells should line up,
regardless of which character is used for alignment. Rules for handling objects
too large for a column apply when the explicit or implied alignment results in
a situation where the data exceeds the assigned width of the column.
Choice of attribute names.
It would have been
preferable to choose values for the
frame
attribute consistent
with the
rules
attribute and the values used for alignment. For
instance:
none, top, bottom, topbot, left, right, leftright, all
Unfortunately, SGML requires enumerated attribute values to be unique for each
element, independent of the attribute name. This causes immediate problems for
"none", "left", "right" and "all". The values for the
frame
attribute have been chosen to avoid clashes with the
rules
align
, and
valign
attributes. This provides a measure of future proofing, as it
is anticipated that the
frame
and
rules
attributes will be added to other table elements in future
revisions to this specification. An alternative would be to make
frame
a CDATA attribute. The consensus of the W3C HTML Working Group
was that the benefits of being able to use SGML validation tools to check
attributes based on enumerated values outweighs the need for consistent
names.
B.6
Notes on forms
B.6.1
Incremental display
The incremental display of documents being received from the network gives
rise to certain problems with respect to forms. User agents should prevent
forms from being submitted until all of the form's elements have been
received.
The incremental display of documents raises some issues with respect to
tabbing navigation. The heuristic of giving focus to the lowest valued
tabindex
in the document seems reasonable enough at first glance.
However this implies having to wait until all of the document's text is
received, since until then, the lowest valued
tabindex
may still change. If the user hits the tab key before then,
it is reasonable for user agents to move the focus to the lowest currently
available
tabindex
If forms are associated with client-side scripts, there is further potential
for problems. For instance, a script handler for a given field may refer to a
field that doesn't yet exist.
B.6.2
Future projects
This specification defines a set of elements and attributes powerful enough
to fulfill the general need for producing forms. However there is still room
for many possible improvements. For instance the following problems could be
addressed in the future:
The range of form field types is too limited in comparison with modern user
interfaces. For instance there is no provision for tabular data entry, sliders
or multiple page layouts.
Servers cannot update the fields in a submitted form and instead have to
send a complete HTML document causing screen flicker.
These also cause problems for speech based browsers, making it difficult
for the visually impaired to interact with HTML forms.
Another possible extension would be to add the
usemap
attribute to
INPUT
for use as client-side
image map when "
type
=image". The
AREA
element corresponding to the location clicked would contribute
the value to be passed to the server. To avoid the need to modify server
scripts, it may be appropriate to extend
AREA
to provide x and y values for use with the
INPUT
element.
B.7
Notes on
scripting
B.7.1
Reserved syntax for future
script macros
This specification reserves syntax for the future support of script macros
in HTML CDATA attributes. The intention is to allow attributes to be set
depending on the properties of objects that appear earlier on the page. The
syntax is:
attribute = "... &{
macro body
}; ... "
Current Practice for Script Macros
The macro body is made up of one or more statements in the default scripting
language (as per intrinsic event attributes). The semicolon following the right
brace is always needed, as otherwise the right brace character "}" is treated
as being part of the macro body. Its also worth noting that quote marks are
always needed for attributes containing script macros.
The processing of CDATA attributes proceeds as follows:
The SGML parser evaluates any SGML entities (e.g., ">").
Next the script macros are evaluated by the script engine.
Finally the resultant character string is passed to the application for
subsequent processing.
Macro processing takes place when the document is loaded (or reloaded) but
does not take place again when the document is resized, repainted, etc.
DEPRECATED EXAMPLE:
Here are some examples using JavaScript. The first one randomizes the document
background color:

Perhaps you want to dim the background for evening viewing:

The next example uses JavaScript to set the coordinates for a client-side
image map:

This example sets the size of an image based upon document properties:

You can set the URI for a link or image by script:

widget

This last example shows how SGML CDATA attributes can be quoted using single
or double quote marks. If you use single quotes around the attribute string
then you can include double quote marks as part of the attribute string.
Another approach is use " for double quote marks:

B.8
Notes on frames
Since there is no guarantee that a frame target name is unique, it is
appropriate to describe the current practice in finding a
frame given a target name
If the target name is a reserved word as described in the normative text,
apply it as described.
Otherwise, perform a depth-first search of the frame hierarchy in the
window that contained the link. Use the first frame whose name is an exact
match.
If no such frame was found in (2), apply step 2 to each window, in a
front-to-back ordering. Stop as soon as you encounter a frame with exactly the
same name.
If no such frame was found in (3), create a new window and assign it the
target name.
B.9
Notes on
The W3C Web Accessibility Initiative (
[WAI]
) is producing a series of guidelines to
improve Web accessibility for people with disabilities. There are three sets of
guidelines:
Web Content Accessibility Guidelines (
[WCGL]
), for authors and
site managers. Please consult the Web Content Accessibility Guidelines for
information about supplying alternative text for images, applets, scripts,
etc.
User Agent Accessibility Guidelines (
[UAGL]
), for user agent
developers (browsers, multimedia players, assistive technologies). Please
consult these guidelines for guidance on handling alternate text.
Authoring Tool Accessibility Guidelines (
[ATGL]
), for authoring tool
developers.
B.10
Notes on security
Anchors, embedded images, and all other elements that contain
URIs
as parameters may cause the URI to be
dereferenced in response to user input. In this case, the security issues of
[RFC1738]
, section 6, should be considered. The widely deployed methods for
submitting form requests -- HTTP and SMTP -- provide little assurance of
confidentiality. Information providers who request sensitive information via
forms -- especially with the
INPUT
element,
type
="password" -- should be aware and make their
users aware of the lack of confidentiality.
B.10.1
Security issues for
forms
A user agent should not send any file that the user has not explicitly asked
to be sent. Thus, HTML user agents are expected to confirm any default file
names that might be suggested by the
value
attribute of the
INPUT
element. Hidden controls must not specify files.
This specification does not contain a mechanism for encryption of the data;
this should be handled by whatever other mechanisms are in place for secure
transmission of data.
Once a file is uploaded, the processing agent should process and store it
appropriately.
previous
next
contents
elements
attributes
index