Appendix B: Performance, Implementation, and Design Notes

The following notes are informative, not normative. Despite the appearanceof words such as "must" and "should", all requirements in this section appearelsewhere in the specification.

B.1 Notes on invaliddocuments

This specification does not define how conforming user agents handle generalerror conditions, includinghow user agents behave when they encounter elements, attributes, attributevalues, or entities not specified in this document.

However, to facilitate experimentation and interoperability betweenimplementations of various versions of HTML, we recommend the followingbehavior:

• If a user agent encounters an element it does not recognize, it should tryto render the element's content.
• If a user agent encounters an attribute it does not recognize, it shouldignore the entire attribute specification (i.e., the attribute and itsvalue).
• If a user agent encounters an attribute value it doesn't recognize, itshould use the default attribute value.
• If it encounters an undeclared entity, the entity should be treated ascharacter data.

We also recommend that user agents provide support for notifying the user ofsuch errors.

Since user agents may vary in how they handle error conditions, authors andusers must not rely on specific error recovery behavior.

The HTML 2.0 specification ([RFC1866]) observes thatmany HTML 2.0 user agents assume that a document that does not begin with adocument type declaration refers to the HTML 2.0 specification. As experienceshows that this is a poor assumption, the current specification does notrecommend this behavior.

For reasons of interoperability, authors must not "extend" HTML through theavailable SGML mechanisms (e.g., extending the DTD, adding a new set of entitydefinitions, etc.).

B.2 Special characters in URI attribute values

B.2.1 Non-ASCII charactersin URI attribute values

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 handlingnon-ASCII characters in such cases:

1. Represent each character in UTF-8 (see [RFC2279]) as one or morebytes.
2. Escape these bytes with the URI escaping mechanism (i.e., by convertingeach 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) thatis independent of the characterencoding to which the HTML document carrying the URI may have beentranscoded.

B.2.2 Ampersands in URIattribute values

The URI that is constructed when a form is submitted may be used as ananchor-style link (e.g., the href attribute for the Aelement). Unfortunately, the use of the "&" character to separate formfields interacts with its use in SGML attribute values to delimit character entity references. Forexample, to use the URI "http://host/?x=1&y=2" as a linking URI, it must bewritten <A href="http://host/?x=1&#38;y=2"> or <Ahref="http://host/?x=1&amp;y=2">.

We recommend that HTTP server implementors, and in particular, CGIimplementors support the use of ";" in place of "&" to save authors thetrouble of escaping "&" characters in this manner.

B.3 SGML implementationnotes

B.3.1 Line breaks

SGML (see [ISO8879], section 7.6.1) specifies that a line break immediatelyfollowing a start tag must be ignored, as must a line break immediately beforean end tag. This applies to all HTML elements without exception.

The following two HTML examples must be rendered identically:

<P>Thomas is watching TV.</P>

<P>Thomas is watching TV.</P>

So must the following two examples:

<A>My favorite Website</A>

<A>My favorite Website</A>

B.3.2 Specifyingnon-HTML data

Script and style data may appear as element content orattribute values. The following sections describe the boundary between HTMLmarkup and foreign data.

Element content 

When script or style data is the content of an element (SCRIPT and STYLE), the data beginsimmediately 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 notbe the element's end tag. Authors should therefore escape "</" within thecontent. Escape mechanisms are specific to each scripting or style sheetlanguage.

 <SCRIPT type="text/javascript">  document.write ("<EM>This won't work</EM>") </SCRIPT>

 <SCRIPT type="text/javascript">  document.write ("<EM>This will work</EM>") </SCRIPT>

 <SCRIPT type="text/tcl">  document write "<EM>This will work</EM>" </SCRIPT>

 "<EM>This will work<" & Chr(47) & "EM>"

Attribute values 

When script or style data is the value of an attribute (either style or the intrinsicevent attributes), authors should escape occurrences of the delimitingsingle or double quotation mark within the value according to the script orstyle language convention. Authors should also escape occurrences of "&" ifthe "&" is not meant to be the beginning of a character reference.

• '"' should be written as "&quot;" or "&#34;"
• '&' should be written as "&amp;" or "&#38;"

 <INPUT name="num" value="0" onchange="if (compare(this.value, &quot;help&quot;)) {gethelp()}">

B.3.3 SGML features with limitedsupport

SGML systems conforming to [ISO8879] are expected torecognize a number of features that aren't widelysupported by HTML user agents. We recommend that authors avoid using all ofthese features.

B.3.4 Booleanattributes

Authors should be aware that many user agents only recognize the minimizedform of boolean attributes and not the full form.

<OPTION selected>

<OPTION selected="selected">

B.3.5 Marked Sections

Marked sections play a role similar to the #ifdef construct recognized by Cpreprocessors.

<![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 isthe appearance of "]]>", which is seen when the user agent mistakenly usesthe 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 <? and ends with >

<?instruction >

<?><?style tt = font courier><?page break><?experiment> ... <?/experiment>

Authors should be aware that many user agents render processing instructionsas part of the document's text.

B.3.7 Shorthand markup

Some SGML SHORTTAG constructs save typing but add no expressive capabilityto the SGML application. Although these constructs technically introduce noambiguity, they reduce the robustness of documents, especially when thelanguage is enhanced to include new elements. Thus, while SHORTTAG constructsof SGML related to attributes are widely used and implemented, those related toelements are not. Documents that use them are conforming SGML documents, butare unlikely to work with many existing HTML tools.

The SHORTTAG constructs in question are the following:

B.4 Notes on helping search engines index your Website

This section provides some simple suggestions that will make your documentsmore accessible to search engines.

Define the document language

In the global context of the Web it is important to know which humanlanguage 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 anindexing engine to offer users search results in the user's preferred language,regardless of how the query was written. For instance, the following linksoffer 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 acomma-separated list of keywords/phrases, or that give a short description.Search engines may present these keywords as the result of a search. The valueof the name attribute sought by a search engine is notdefined 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 frequentlytranslated into collections of HTML documents. It is helpful for search resultsto reference the beginning of the collection in addition to the page hit by thesearch. 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 anindexing robot and that the robot should not have been permitted to visit asensitive part of the site. Many Web robots offer facilities for Web siteadministrators and content providers to limit what the robot does. This isachieved 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 checksfor http://www.foobar.com/robots.txt. If it can find this document, it willanalyze its contents to see if it is allowed to retrieve the document. You cancustomize the robots.txt file to apply only to specific robots, and to disallowaccess to specific directories or files.

Here is a sample robots.txt file that prevents all robots from visiting theentire 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 asite is defined as a HTTP server running on a particular host and port number.Here are some sample locations for robots.txt:

There can only be a single "/robots.txt" on a site. Specifically, you shouldnot put "robots.txt" files in user directories, because a robot will never lookat 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 wantto 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 alllower-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 beliberal in interpreting this field. A case-insensitive substring match of thename without version information is recommended.

If the value is "*", the record describes the default access policy for anyrobot that has not matched any of the other records. It is not allowed to havemultiple such records in the "/robots.txt" file.

The "Disallow" field specifies a partial URI that is not to be visited. Thiscan be a full path, or a partial path; any URI that starts with this value willnot 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. Atleast 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 robotswhether a document may be indexed, or used to harvest more links. No serveradministrator action is required.

<META name="ROBOTS" content="NOINDEX, NOFOLLOW">

B.5 Notes on tables

B.5.1 Design rationale

The HTML table model has evolved from studies of existing SGML tablesmodels, the treatment of tables in common word processing packages, and a widerange of tabular layout techniques in magazines, books and other paper-baseddocuments. The model was chosen to allow simple tables to be expressed simplywith extra complexity available when needed. This makes it practical to createthe markup for HTML tables with everyday text editors and reduces the learningcurve for getting started. This feature has been very important to the successof HTML to date.

Increasingly, people are creating tables by converting from other documentformats or by creating them directly with WYSIWYG editors. It is important thatthe HTML table model fit well with these authoring tools. This affects how thecells that span multiple rows or columns are represented, and how alignment andother presentation properties are associated with groups of cells.

Dynamic reformatting 

A major consideration for the HTML table model is that the author does notcontrol how a user will size a table, what fonts he or she will use, etc. Thismakes it risky to rely on column widths specified in terms of absolute pixelunits. Instead, tables must be able to change sizes dynamically to match thecurrent window size and fonts. Authors can provide guidance as to the relativewidths of columns, but user agents should ensure that columns are wide enoughto render the width of the largest element of the cell's content. If theauthor's specification must be overridden, relative widths of individualcolumns should not be changed drastically.

Incremental display 

For large tables or slow network connections, incremental table display isimportant to user satisfaction. User agents should be able to begin displayinga table before all of the data has been received. The default window width formost user agents shows about 80 characters, and the graphics for many HTMLpages are designed with these defaults in mind. By specifying the number ofcolumns, and including provision for control of table width and the widths ofdifferent columns, authors can give hints to user agents that allow theincremental display of table contents.

For incremental display, the browser needs the number of columns and theirwidths. 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 youcan 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 suggestedwaiting until the first row of the table has been received, but this could takea long time if the cells have a lot of content. On the whole it makes moresense, when incremental display is desired, to get authors to explicitlyspecify the number of columns in the TABLE element.

Authors still need a way of telling user agents whether to use incrementaldisplay or to size the table automatically to fit the cell contents. In the twopass 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 fromrendering idioms such as margins, fonts, colors, etc. How does this distinctionaffect tables? From the purist's point of view, the alignment of text withintable cells and the borders between cells is a rendering issue, not one ofstructure. In practice, though, it is useful to group these with the structuralinformation, as these features are highly portable from one application to thenext. The HTML table model leaves most rendering information to associatedstyle sheets. The model presented in this specification is designed to takeadvantage of such style sheets but not to require them.

Current desktop publishing packages provide very rich control over therendering 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. Thisspecification does, however, offer authors the ability to choose from a set ofcommonly used classes of border styles. The frame attribute controls the appearance of the border frame aroundthe table while the rules attribute determines the choice ofrulings within the table. A finer level of control will be supported viarendering annotations. The style attribute can be used forspecifying rendering information for individual elements. Further renderinginformation can be given with the STYLE element in the documenthead or via linked style sheets.

During the development of this specification, a number of avenues wereinvestigated for specifying the ruling patterns for tables. One issue concernsthe kinds of statements that can be made. Including support for edgesubtraction 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 analgorithm involving some 24 steps to determine whether a particular edge of acell should be ruled or not. Even this additional complexity doesn't provideenough rendering control to meet the full range of needs for tables. Thecurrent specification deliberately sticks to a simple intuitive model,sufficient for most purposes. Further experimental work is needed before a morecomplex approach is standardized.

Row and column groups 

This specification provides a superset of the simpler model presented inearlier work on HTML+. Tables are considered as being formed from an optionalcaption together with a sequence of rows, which in turn consist of a sequenceof table cells. The model further differentiates header and data cells, andallows cells to span multiple rows and columns.

Following the CALS table model (see [CALS]), this specificationallows table rows to be grouped into head and body and foot sections. Thissimplifies the representation of rendering information and can be used torepeat table head and foot rows when breaking tables across page boundaries, orto provide fixed headers above a scrollable body panel. In the markup, the footsection is placed before the body sections. This is an optimization shared withCALS for dealing with very long tables. It allows the foot to be renderedwithout having to wait for the entire table to be processed.

Accessibility 

For the visually impaired, HTML offers the hope of setting to rights thedamage caused by the adoption of windows based graphical user interfaces. TheHTML table model includes attributes for labeling each cell, to support highquality text to speech conversion. The same attributes can also be used tosupport automated import and export of table data to databases orspreadsheets.

B.5.2 Recommended Layout Algorithms

If COL or COLGROUP elements are present, theyspecify the number of columns and the table may be rendered using a fixedlayout. Otherwise the autolayout algorithm described below should be used.

If the width attribute is not specified, visual user agentsshould assume a default value of 100% for formatting.

It is recommended that user agents increase table widths beyond the valuespecified by width in cases when cell contents would otherwiseoverflow. User agents that override the specified width should do so withinreason. User agents may elect to split words across lines to avoid the need forexcessive horizontal scrolling or when such scrolling is impractical orundesired.

For the purposes of layout, user agents should consider that table captions(specified by the CAPTION element) behave like cells. Each captionis a cell that spans all of the table's columns if at the top or bottom of thetable, 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. Thecolumn widths by default should be set to the same size. Authors may overridethis by specifying relative or absolute column widths, using the COLGROUP or COL elements. The default table width is thespace between the current left and right margins, but may be overridden by thewidth attribute on the TABLE element, or determined from absolute column widths. To dealwith mixtures of absolute and relative column widths, the first step is toallocate space from the table width to columns with absolute widths. Afterthis, the space remaining is divided up between the columns with relativewidths.

The table syntax alone is insufficient to guarantee the consistency ofattribute values. For instance, the number of COL and COLGROUP elements may be inconsistentwith the number of columns implied by the table cells. A further problem occurswhen the columns are too narrow to avoid overflow of cell contents. The widthof the table as specified by the TABLE element or COL elements may result in overflow of cell contents. It isrecommended that user agents attempt to recover gracefully from thesesituations, e.g., by hyphenatingwords and resorting to splitting words if hyphenation points areunknown.

In the event that an indivisible element causes cell overflow, the useragent may consider adjusting column widths and re-rendering the table. In theworst case, clipping may be considered if column width adjustments and/orscrollable cell content are not feasible. In any case, if cell content is splitor 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 agentshould use the following autolayout algorithm. It uses two passes through thetable data and scales linearly with the size of the table.

In the first pass, line wrapping is disabled, and the user agent keeps trackof the minimum and maximum width of each cell. The maximum width is given bythe widest line. Since line wrap has been disabled, paragraphs are treated aslong lines unless broken by BR elements. The minimum width is givenby the widest text element (word, image, etc.) taking into account leadingindents and list bullets, etc. In other words, it is necessary to determine theminimum width a cell would require in a window of its own before the cellbegins to overflow. Allowing user agents to split words will minimize the needfor 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 determinethe minimum and maximum widths for these tables and hence for the parent tablecell itself. The algorithm is linear with aggregate cell content, and broadlyspeaking, independent of the depth of nesting.

To cope with character alignment of cell contents, the algorithm keeps threerunning min/max totals for each column: Left of align char, right of align charand 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 thecorresponding minimum and maximum widths for the columns. These in turn, areused to find the minimum and maximum width for the table. Note that cells cancontain nested tables, but this doesn't complicate the code significantly. Thenext 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 ofapportioning the min/max widths evenly to each of the constituent columns. Aslightly more complex approach is to use the min/max widths of unspanned cellsto weight how spanned widths are apportioned. Experiments suggest that a blendof the two approaches gives good results for a wide range of tables.

The table borders and intercell margins need to be included in assigningcolumn widths. There are three cases:

1. The minimum table width is equal to or wider than the availablespace. In this case, assign the minimum widths and allow the user to scrollhorizontally. For conversion to braille, it will be necessary to replace thecells by references to notes containing their full content. By convention theseappear before the table.
2. The maximum table width fits within the available space. In thiscase, set the columns to their maximum widths.
3. The maximum width of the table is greater than the available space, butthe minimum table width is smaller. In this case, find the differencebetween the available space and the minimum table width, lets call it W.Lets also call D the difference between maximum and minimum width of thetable.

   For each column, let d be the difference between maximum and minimumwidth of that column. Now set the column's width to the minimum width plus d times W over D. This makes columns with large differencesbetween minimum and maximum widths wider than columns with smallerdifferences.

This assignment step is then repeated for nested tables using the minimumand 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 inthe above description. This process is repeated recursively for all nestedtables. The topmost table is then rendered using the assigned widths. Nestedtables are subsequently rendered as part of the parent table's cellcontents.

If the table width is specified with the width attribute, the user agent attempts to set columnwidths to match. The width attribute is not binding ifthis 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 widthsover the minimum width to meet the relative width constraints. The COL elements should be taken as hints only, so columns shouldn't beset to less than their minimum width. Similarly, columns shouldn't be made sowide that the table stretches well beyond the extent of the window. If a COL element specifies a relative width of zero, the column shouldalways be set to its minimum width.

When using the two pass layout algorithm, the default alignment position inthe absence of an explicit or inherited charoff attribute can be determined by choosing the position thatwould center lines for which the widths before and after the alignmentcharacter are at the maximum values for any of the lines in the column forwhich align="char". For incremental table layout the suggested defaultis charoff="50%". If several cells in different rows for the samecolumn use character alignment, then by default, all such cells should line up,regardless of which character is used for alignment. Rules for handling objectstoo large for a column apply when the explicit or implied alignment results ina situation where the data exceeds the assigned width of the column.

B.6 Notes on forms

B.6.1 Incremental display

The incremental display of documents being received from the network givesrise to certain problems with respect to forms. User agents should preventforms from being submitted until all of the form's elements have beenreceived.

The incremental display of documents raises some issues with respect totabbing 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 isreceived, 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 currentlyavailable tabindex.

If forms are associated with client-side scripts, there is further potentialfor problems. For instance, a script handler for a given field may refer to afield that doesn't yet exist.

B.6.2 Future projects

This specification defines a set of elements and attributes powerful enoughto fulfill the general need for producing forms. However there is still roomfor many possible improvements. For instance the following problems could beaddressed in the future:

• The range of form field types is too limited in comparison with modern userinterfaces. For instance there is no provision for tabular data entry, slidersor multiple page layouts.
• Servers cannot update the fields in a submitted form and instead have tosend a complete HTML document causing screen flicker.
• These also cause problems for speech based browsers, making it difficultfor the visually impaired to interact with HTML forms.

Another possible extension would be to add the usemap attribute to INPUT for use as client-sideimage map when "type=image". The AREA element corresponding to the location clicked would contributethe value to be passed to the server. To avoid the need to modify serverscripts, it may be appropriate to extend AREA to provide x and y values for use with the INPUT element.

B.7 Notes onscripting

B.7.1 Reserved syntax for futurescript macros

This specification reserves syntax for the future support of script macrosin HTML CDATA attributes. The intention is to allow attributes to be setdepending on the properties of objects that appear earlier on the page. Thesyntax is:

   attribute = "... &{ macro body }; ... "

Current Practice for Script Macros 

The macro body is made up of one or more statements in the default scriptinglanguage (as per intrinsic event attributes). The semicolon following the rightbrace is always needed, as otherwise the right brace character "}" is treatedas being part of the macro body. Its also worth noting that quote marks arealways needed for attributes containing script macros.

The processing of CDATA attributes proceeds as follows:

1. The SGML parser evaluates any SGML entities (e.g., "&gt;").
2. Next the script macros are evaluated by the script engine.
3. Finally the resultant character string is passed to the application forsubsequent processing.

Macro processing takes place when the document is loaded (or reloaded) butdoes not take place again when the document is resized, repainted, etc.

 <BODY bgcolor='&{randomrgb};'>

 <BODY bgcolor='&{if(Date.getHours > 18)...};'>

 <MAP NAME=foo>   <AREA shape="rect" coords="&{myrect(imageuri)};" href="&{myuri};" alt=""> </MAP>

 <IMG src="bar.gif" width='&{document.banner.width/2};' height='50%' alt="banner">

 <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">

   <IMG src="&{logo(manufacturer(&quot;widget&quot;))};" alt="logo">

B.8 Notes on frames

Since there is no guarantee that a frame target name is unique, it isappropriate to describe the current practice in finding a frame given a target name:

1. If the target name is a reserved word as described in the normative text,apply it as described.
2. Otherwise, perform a depth-first search of the frame hierarchy in thewindow that contained the link. Use the first frame whose name is an exactmatch.
3. If no such frame was found in (2), apply step 2 to each window, in afront-to-back ordering. Stop as soon as you encounter a frame with exactly thesame name.
4. If no such frame was found in (3), create a new window and assign it thetarget name.

B.9 Notes onaccessibility

The W3C Web Accessibility Initiative ([WAI]) is producing a series of guidelines toimprove Web accessibility for people with disabilities. There are three sets ofguidelines:

• Web Content Accessibility Guidelines ([WCGL]), for authors andsite managers. Please consult the Web Content Accessibility Guidelines forinformation about supplying alternative text for images, applets, scripts,etc.
• User Agent Accessibility Guidelines ([UAGL]), for user agentdevelopers (browsers, multimedia players, assistive technologies). Pleaseconsult these guidelines for guidance on handling alternate text.
• Authoring Tool Accessibility Guidelines ([ATGL]), for authoring tooldevelopers.

B.10 Notes on security

Anchors, embedded images, and all other elements that contain URIs as parameters may cause the URI to bedereferenced in response to user input. In this case, the security issues of [RFC1738], section 6, should be considered. The widely deployed methods forsubmitting form requests -- HTTP and SMTP -- provide little assurance ofconfidentiality. Information providers who request sensitive information viaforms -- especially with the INPUT element, type="password" -- should be aware and make theirusers aware of the lack of confidentiality.

B.10.1 Security issues forforms

A user agent should not send any file that the user has not explicitly askedto be sent. Thus, HTML user agents are expected to confirm any default filenames 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 securetransmission of data.

Once a file is uploaded, the processing agent should process and store itappropriately.