The following notes are informative, not normative. Despite the appearance
of words such as "must" and "should", all requirements in this section appear
elsewhere in the specification.
This specification does not define how conforming user agents handle general
error conditions, including
how user agents behave when they encounter elements, attributes, attribute
values, or entities not specified in this document.
However, to facilitate experimentation and interoperability between
implementations of various versions of HTML, we recommend the following
behavior:
If a user agent encounters an element it does not recognize, it should try
to render the element's content.
If a user agent encounters an attribute it does not recognize, it should
ignore the entire attribute specification (i.e., the attribute and its
value).
If a user agent encounters an attribute value it doesn't recognize, it
should use the default attribute value.
If it encounters an undeclared entity, the entity should be treated as
character data.
We also recommend that user agents provide support for notifying the user of
such errors.
Since user agents may vary in how they handle error conditions, authors and
users must not rely on specific error recovery behavior.
The HTML 2.0 specification ([RFC1866]) observes that
many HTML 2.0 user agents assume that a document that does not begin with a
document type declaration refers to the HTML 2.0 specification. As experience
shows that this is a poor assumption, the current specification does not
recommend this behavior.
For reasons of interoperability, authors must not "extend" HTML through the
available SGML mechanisms (e.g., extending the DTD, adding a new set of entity
definitions, etc.).
Although URIs do not contain non-ASCII values (see [URI], section 2.1)
authors sometimes specify them in attribute values expecting URIs (i.e.,
defined with %URI; in the DTD). For instance, the following
href value is illegal:
<A href="http://foo.org/Håkon">...</A>
We recommend that user agents adopt the following convention for handling
non-ASCII characters in such cases:
Represent each character in UTF-8 (see [RFC2279]) as one or more
bytes.
Escape these bytes with the URI escaping mechanism (i.e., by converting
each byte to %HH, where HH is the hexadecimal notation of the byte value).
This procedure results in a syntactically legal URI (as defined in
[RFC1738], section 2.2 or [RFC2141], section 2) that
is independent of the character
encoding to which the HTML document carrying the URI may have been
transcoded.
Note. Some older user agents trivially process URIs in
HTML using the bytes of the character
encoding in which the document was received. Some older HTML documents rely
on this practice and break when transcoded. User agents that want to handle
these older documents should, on receiving a URI containing characters outside
the legal set, first use the conversion based on UTF-8. Only if the resulting
URI does not resolve should they try constructing a URI based on the bytes of
the character encoding in which the
document was received.
Note. The same conversion based
on UTF-8 should be applied to values of the
name attribute for the A element.
The URI that is constructed when a form is submitted may be used as an
anchor-style link (e.g., the href attribute for the A
element). Unfortunately, the use of the "&" character to separate form
fields interacts with its use in SGML attribute values to delimit character entity references. For
example, to use the URI "http://host/?x=1&y=2" as a linking URI, it must be
written <A href="http://host/?x=1&y=2"> or <A
href="http://host/?x=1&y=2">.
We recommend that HTTP server implementors, and in particular, CGI
implementors support the use of ";" in place of "&" to save authors the
trouble of escaping "&" characters in this manner.
SGML (see [ISO8879], section 7.6.1) specifies that a line break immediately
following a start tag must be ignored, as must a line break immediately before
an end tag. This applies to all HTML elements without exception.
The following two HTML examples must be rendered identically:
Script and style data may appear as element content or
attribute values. The following sections describe the boundary between HTML
markup and foreign data.
Note. The DTD defines
script and style data to be CDATA for both element content and attribute
values. SGML rules do not allow character
references in CDATA element content but do allow them in CDATA attribute
values. Authors should pay particular attention when cutting and pasting script
and style data between element content and attribute values.
This asymmetry also means that when transcoding from a richer to a
poorer character encoding, the transcoder cannot simply replace unconvertible
characters in script or style data with the corresponding numeric character
references; it must parse the HTML document and know about each script and
style language's syntax in order to process the data correctly.
Element content
When script or style data is the content of an element (SCRIPT and STYLE), the data begins
immediately after the element start tag and ends at the first ETAGO ("</")
delimiter followed by a name start character ([a-zA-Z]); note that this may not
be the element's end tag. Authors should therefore escape "</" within the
content. Escape mechanisms are specific to each scripting or style sheet
language.
ILLEGAL EXAMPLE:
The following script data incorrectly contains a "</" sequence (as part of
"</EM>") before the SCRIPT end tag:
In JavaScript, this code can be expressed legally by hiding the ETAGO
delimiter before an SGML name start character:
<SCRIPT type="text/javascript">
document.write ("<EM>This will work<\/EM>")
</SCRIPT>
In Tcl, one may accomplish this as follows:
<SCRIPT type="text/tcl">
document write "<EM>This will work<\/EM>"
</SCRIPT>
In VBScript, the problem may be avoided with the Chr()
function:
"<EM>This will work<" & Chr(47) & "EM>"
Attribute values
When script or style data is the value of an attribute (either
style or the intrinsic
event attributes), authors should escape occurrences of the delimiting
single or double quotation mark within the value according to the script or
style language convention. Authors should also escape occurrences of "&" if
the "&" is not meant to be the beginning of a character reference.
SGML systems conforming to [ISO8879] are expected to
recognize a number of features that aren't widely
supported by HTML user agents. We recommend that authors avoid using all of
these features.
Marked sections play a role similar to the #ifdef construct recognized by C
preprocessors.
<![INCLUDE[
<!-- this will be included -->
]]>
<![IGNORE[
<!-- this will be ignored -->
]]>
SGML also defines the use of marked sections for CDATA content, within which
"<" is not treated as the start of a tag, e.g.,
<![CDATA[
<an> example of <sgml> markup that is
not <painful> 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 "<![".
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:
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:
<LINK rel="alternate"
type="text/html"
href="mydoc-fr.html" hreflang="fr"
lang="fr" title="La vie souterraine">
<LINK rel="alternate"
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,
<META name="keywords" content="vacation,Greece,sunshine">
<META name="description" content="Idyllic European vacations">
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:
<LINK rel="start"
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.
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
http://www.w3.org/
http://www.w3.org/robots.txt
http://www.w3.org:80/
http://www.w3.org:80/robots.txt
http://www.w3.org:1234/
http://www.w3.org:1234/robots.txt
http://w3.org/
http://w3.org/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.
<META name="ROBOTS" content="NOINDEX, NOFOLLOW">
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.
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.
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.
Accessibility
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.
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 W.
Lets also call D the difference between maximum and minimum width of the
table.
For each column, let d be the difference between maximum and minimum
width of that column. Now set the column's width to the minimum width plus
d times W over D. 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.
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.
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.
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:
<BODY bgcolor='&{randomrgb};'>
Perhaps you want to dim the background for evening viewing:
<BODY bgcolor='&{if(Date.getHours > 18)...};'>
The next example uses JavaScript to set the coordinates for a client-side
image map:
You can set the URI for a link or image by script:
<SCRIPT type="text/javascript">
function manufacturer(widget) {
...
}
function location(manufacturer) {
...
}
function logo(manufacturer) {
...
}
</SCRIPT>
<A href='&{location(manufacturer("widget"))};'>widget</A>
<IMG src='&{logo(manufacturer("widget"))};' alt="logo">
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:
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.
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.
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.
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.
