Appendix B:
Comments on the work, implementation and development

The following comments are informative, not normative. Despite the use of such words as "necessary" and "should", all the requirements of this section are specified in other parts of the specification.

B.1 Notes on Invalid Documents

This specification does not specify how appropriate user agents should handle common error states, including the behavior of user agents when they meet items, attributes, attribute values, or objects not specified in this document.

However, in order to facilitate experiments and compatibility between implementations of different versions of HTML, the following behavior is recommended:

• If the user agent encounters an unknown item, it must try to present its contents.
• If the user agent encounters an unknown attribute, it must ignore the entire attribute specification (that is, the attribute and its value).
• If the user agent scans an unknown attribute value, it must use the default value.
• If the user agent encounters an undeclared object, this object should be treated as character data.

In addition, user agents are advised to notify users of such errors.

Because user agents can handle error conditions differently, authors and users should not rely on certain behavior in the event of an error.

The HTML 2.0 specification ( [RFC1866] ) noted that many HTML 2.0 user agents assume that a document that does not start with a document type declaration refers to the HTML 2.0 specification. Experience shows that this is an incorrect assumption, this specification does not recommend such behavior.

For reasons of compatibility, authors should not "supplement" HTML with existing SGML mechanisms (for example, extending the DTD by adding a new set of combination definitions, etc.).

B.2 Special characters in URI attribute values

B.2.1 Characters not in the ASCII set in the URI attribute values

Although URIs do not include characters that are not part of the ASCII set, (see [URI] , section 2.1), authors sometimes specify them in attribute values ​​in which URIs should be specified (for example, in attributes defined as % URI; in DTDs ) . For example, the following value for the href attribute is invalid :

  <A href="http://foo.org/Håkon"> ... </A>

To process characters that are not part of the ASCII set, in such cases, user agents are recommended:

1. Represent each UTF-8 character (see [RFC2044] ) as one or more bytes.
2. Select these bytes using the URI allocation mechanism (ie by converting each byte to% HH, where HH is the hexadecimal notation of the byte value).

This procedure results in the creation of a syntactically valid URI (in accordance with [ RFC1738 ] , section 2.2 or [RFC2141] , section 2), independent of the character encoding , by which the HTML document in which this URI is specified can be encoded.

B.2.2 Ampersands in URI Attribute Values

The URI constructed when the form is submitted can be used as an anchor type reference (for example, the href attribute for element A ). Unfortunately, the use of the & quot; & quot; to separate form fields affects its use in the SGML attribute values ​​for separating character references. For example, to use the "http: // host /? X = 1 & y = 2" URI as a reference, it must be written <A href="http://host/?x=1&#38;y=2"> or < A href = "http: // host /? X = 1 & amp; y = 2">.

We recommend that HTTP server developers, and especially CGI developers, provide support for the use of ";" Instead of "&", to solve for the problem of the problem of selecting the "&" symbols in such a manner.

B.3 Comments on the implementation of SGML

B.3.1 Line breaks

In SGML (see [ISO8879] , section 7.6.1), it is indicated that a line break immediately following the start tag should be ignored, like a line break just before the end tag. This applies to all HTML elements without exception.

The following two examples of HTML code should be represented identically:

  <P> Pasha is watching television. </ P>

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

The following two examples should equally be presented:

  <A> My favorite site </A>

  <A>
 My favorite site
 </A>

B.3.2 Specifying non-HTML data

The script and style data can be present as the contents of the element or the value of the attribute. The following sections describe the distinction between HTML markup and other data.

Content of the element  

If the script or style data is the contents of the element ( SCRIPT and STYLE ), the data starts immediately after the element's start tag and ends with the first ETAGO delimiter ("</") followed by the letter ([a-zA-Z]); Note that this is not necessarily the final element tag. Therefore, authors should select the "</" sequences in the content. The mechanisms of such allocation are specific for each language of scripts or tables of chants.

  <SCRIPT type = "text / javascript">
  Document.write ("<EM> This will not 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  

If the data of a script or style is an attribute value ( style or attributes of an internal event ), authors should single-delimited single or double quotes in the values ​​according to script or style conventions. Second, you should also select "&" instances, if this "&" does not indicate the beginning of the symbol 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 limited support

SGML systems corresponding to [ISO8879] must recognize a number of features that are not supported by all HTML user agents. Authors are advised to avoid using these functions.

B.3.4 Logical Attributes

Authors should be aware that many user agents recognize only a minimized form of logical attributes, but not a complete one.

 <OPTION selected>

 <OPTION selected = "selected">

B.3.5 Marked sections

The selected selected options play a role similar to the #ifdef construct recognized by the C preprocessor.

 <! [INCLUDE [
  <! - this will be enabled ->
 ]]>

 <! [IGNORE [
  <! - this will be ignored ->
 ]]>

SGML also defines the use of tagged partitions for CDATA content, in which "<" is not treated as the beginning of a tag, for example,

 <! [CDATA [
  <An> markup example <sgml> that does not call
  <Problems> when writing <etc.
 ]]>

The "]]>" view, when the user agent mistakenly uses the first ">" as the end of a tag beginning with "<! [", Is a signal symbol that the agent of the user does not recognize the marked partition.

B.3.6 Processing instructions

Processing instructions is a mechanism for capturing platform-dependent idiot \ m. The instruction begins with <? And ends with the symbol>

  <?  Instruction > 

 <?>
 <? Style tt = font courier>
 <? Page break>
 <? Experiment> ... <? / Experiment>

Authors should be aware that many agent agents present processing instructions as part of the document text.

B.3.7 Reduced markup

Some SGML SHORTTAG constructs allow you to save time on dialing, but do not add expressive abilities to the SGML application. Although such designs do not technically introduce ambiguities, they reduce the reliability of documents, especially if the language is expanded and includes new elements. Thus, while the SHORTTAG SGML constructions relating to attributes are widely used and implemented, the same constructions relating to elements are not common. The documents that use them are relevant SGML documents, but are unlikely to work with many existing HTML tools.

SHORTTAG designs:

B.4 Comments on the promotion of search engines in the indexing of a website

This section provides some simple suggestions that will make the documents more accessible to search engines.

Define the document language

In the global context of the Web, it is important to know the language in which the page is created. This is discussed in the section on language information .

Specify the language versions of the document

If you have prepared translations of a document into other languages, use the LINK element to reference them. This will allow index machines to offer users search results in a user-preferred language, regardless of the query building. For example, the following links offer the search engine French and German versions:

 <LINK rel = "alternate" 
  Type = "text / html"
  Href = "mydoc-fr.shtml" hreflang = "fr"
  Lang = "fr" title = "La vie souterraine">
 <LINK rel = "alternate" 
  Type = "text / html"
  Href = "mydoc-de.shtml" hreflang = "de"
  Lang = "de" title = "Das Leben im Untergrund">

Ask keywords and descriptions

Some indexing machines search for META elements in which a comma-separated list of keywords / phrases is defined or a brief description is given. Search engines can represent these keywords as a result of a search. The value of the name attribute found by the search attribute is not defined in this specification. Consider the following examples,

 <META name = "keywords" content = "vacation, Greece, the sun">
 <META name = "description" content = "Idyllic Holiday in Europe">

Specify the beginning of the set

Sets of documents or views of word processing systems are often translated into sets of HTML documents. For search engines it is useful to specify a link to the beginning of the set in addition to hitting the page in the search results. You can help search engines by using the LINK element with the rel = "begin" attribute and the TITLE attribute, as shown in the following example:

 
 <LINK rel = "begin" 
  Type = "text / html"
  Href = "page1.shtml" 
  Title = "General Theory of Relativity">

Provide instructions to the robots for indexing

People can be surprised to learn that their site is indexed by a robot, and did not get access to a large part of the site. Many Web robots offer Web site administrators the ability to limit the actions of robots. This is achieved through two mechanisms: the "robots.txt" file and the META element in the HTML documents described below.

B.4.1 Search robots

Robots.txt file  

When a robot browses a Web site, for example, http://www.foobar.com/, it first checks the http://www.foobar.com/robots.txt file. If this document is found, it analyzes its contents and looks at whether it is allowed to load the document. You can configure the robots.txt file only for specific robots and deny access to specific directories or files.

Here is an example of a robots.txt file that denies access to the entire site to all robots

  User-agent: * # applies to all robots
  Disallow: / # disable indexing of all pages

The robot will simply find the "/robots.txt" file of the URI on your site, where the site is an HTTP server running on a specific machine and port. Here are some examples of the location of the robots.txt file:

One site can have one "/robots.txt" file. More precisely, you should not put the "robots.txt" files in user directories, as the robot will not find them. If you want users to create their own "robots.txt" files, you will need to combine them all into one "/robots.txt" file. If you do not do this, users can use the Robots META tag instead.

Some tips: URIs are case-sensitive, and the string "/robots.txt" should always be lowercase. Empty lines are not allowed.

In each record there should be exactly one "User-agent" field. The robot should freely interpret this field. We recommend a case-insensitive string that matches the name and does not include version information.

If the value is "*", the entry describes the default access policy for any robot that does not match other records. In the file "/robots.txt" there can not be several such records.

The "Disallow" field specifies a partial URI, which is forbidden to visit. This can be a complete or partial path; Any URI starting with this value can not be loaded. For example,

  Disallow: / help disables access to /help.shtml and /help/index.shtml, while 
  Disallow: / help / disallows access to /help/index.shtml, but will allow access to /help.shtml. 

A blank value for the "Disallow" parameter means that all URIs can be loaded. The robots.txt file must contain at least one "Disallow" field.

Robots and the META element  

The META element allows authors of HTML documents to tell robots whether the document can be indexed or whether it can be used to obtain additional references. This does not require intervention from the server administrator.

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

B.5 Notes on the tables

B.5.1 Design rationale

The HTML table model was the result of studying existing SGML table models, processing tables in widely used word processing packages and a wide range of table layout techniques in magazines, books and other printed documents. This model is chosen to allow easier expression of tables with possible additional complexity. This allows you to markup HTML tables with text editors and reduces the cost of learning and preparing for work. This property is very important for HTML.

More and more people create tables by converting from documents of other formats or by creating them directly in the WYSIWYG editors. It is very important that the HTML table model can be used in these development tools. This affects the representation of cells that occupy multiple rows or columns, and the alignment and other view properties associated with groups of cells.

Dynamic Reformatting  

The main principle of the HTML table model is that the author does not control the size of the table by the user, the fonts used, etc. This leads to the fact that setting the width of the column in pixels becomes risky. Instead, the tables must support dynamic resizing and match the current window size and fonts. Authors can define recommended parameters for the type of relative column width, but user agents should check whether the column width is sufficient to represent the widest element of the cell content. If the author's specification can be replaced, the relative widths of individual columns should not be changed too much.

Consecutive representation  

For large tables or slow network connections, it is very important to consistently present the tables. User agents should be able to start displaying the table before receiving all the data. The default window width for most user agents is about 80 characters, and the drawings for most HTML pages are compiled with this number in mind. By specifying the number of columns and including the conditions for managing the width of the table and the width of the various columns, authors can give hints to user agents that provide a consistent representation of the contents of the table.

To consecutively view the browser, you need the number of columns and their width. The default width of the table is the current window size ( width = "100%" ). This can be changed by setting the width-TABLE attribute of the TABLE element. By default, all columns have the same width, but you can determine the width of the tampon using the COL elements before the table starts.

There remains the problem of the number of columns. Some suggest waiting for the first row of the table, but this can take a long time if the cells contain a lot of information. In general, when you sequentially represent authors, it makes sense to explicitly indicate the number of columns in a TABLE element.

Authors still need the option of notifying users' agents about whether to use a sequential view or to determine the size of the table automatically to match the contents of the cell. In the two-pass automatic mode, the number of columns is determined on the first pass. In sequential mode, the number of columns should be set from the beginning. It makes sense to set the cols attribute to a value equal to the number of columns, and not to use the "layout" attributes (for example, layout = "fixed" or layout = "auto").

Structure and Representation  

HTML differs from structural markup, such as paragraphs and quotes, and means of presentation such as fields, fonts, colors, etc. How does this difference affect the tables? From the purist's point of view, aligning the text in the cells of the table and the borders between cells is a mapping issue, not a structure. In practice, however, it makes sense to group them with structural information, since these properties are easily transferred from one application to another. The HTML table model shifts most of the information about the view to related style sheets. The model presented in this specification is designed to take advantage of such style sheets, but style sheets are not mandatory.

Currently used publishing packages provide very rich options for presenting tables, and it would be impractical to reproduce these features in HTML without turning HTML into a complex text format such as RTF or MIF. However, in this specification, authors are offered the option of selecting from a number of widely used classes or types of boundaries. The frame attribute controls the appearance of the border around the table, while the rules attribute specifies the choice of rulings in the table. A richer level of management will be supported by annotations on presentation. The style attribute can be used to determine information about the representation of individual elements. Further information about the view can be specified by using the STYLE element in the document header or by using linked style sheets.

In the process of developing this specification, a number of questions have been studied on setting frame templates for tables. One of the questions relates to the types of possible expressions. The inclusion of support for subtraction and addition of edges leads to rather complicated algorithms. For example, the work of providing support for the frame and rules attributes of all elements to represent tables has led to an algorithm for determining whether a particular part of the table frame is displayed, or not, from 24 steps. Even such complexity does not provide sufficient management of the presentation, which meets all the needs of table presentation. The current specification intentionally adheres to a simple intuitive model, sufficient in most cases. To standardize a more complex approach, further experimental work is needed.

Row and Column Groups  

This specification defines a superset of the simpler model presented in an earlier work on HTML +. It is believed that tables are formed from an optional header and a string sequence, which in turn consists of a sequence of cells. This model then distinguishes header and data cells and allows cells to occupy multiple rows or columns.

Following the model of CALS tables (see [CALS] ), this specification allows you to group the rows of the table into header, body and bottom header sections. This simplifies the presentation of display information and can be used to repeat table headers when moving tables or to provide persistent headers when the table body is scrolled. In the markup, the section of the lower header is placed before the partition of the table body. This optimization is used in CALS to work with long tables. This allows you to generate a lower header, without waiting for the entire table to be processed.

Availability  

For people with poor eyesight, HTML offers a simplified use of the Windows-based graphical user interface. The HTML table model includes the attributes of the mark of each cell to support high-quality text-to-speech conversion. The same attributes can be used to support the automated import and export of table data into databases and spreadsheets.

B.5.2 Recommended Composition Algorithms

If the number of columns in the cols attribute of the TABLE element is determined, the table can be represented using a fixed location, otherwise the automatic composition algorithm described below should be used.

If the width attribute is not specified, visual user agents should use a value of 100% for formatting.

Users of users are encouraged to extend the table beyond the value specified in the width attribute, in cases where the contents of the cell are not included in it. User agents that change the specified width should do this for some reason. User agents can break words into strings to avoid the use of horizontal scrolling.

For layout, user agents must assume that the table headers (specified by the CAPTION element) are similar to cells. Each header is a cell that occupies all the columns of the table, if it is located at the bottom or top of the table, and captures all rows of the table if it is on the left or right.

Fixed layout algorithm  

In this algorithm, it is considered that the number of columns is known. The default width of the columns should be the same. Authors can override this by specifying the relative or absolute width of columns using the COLGROUP or COL elements . The default width of the table is the entire space between the left and right margins, but you can re-define it using the width attribute of the TABLE element or determine from the absolute width of the columns. When using both absolute and relative column widths, the first step is to allocate space for columns with a fixed width. After that, the remaining space is divided for columns with a relative width.

A single table syntaxis is not enough to ensure that attribute values ​​match. For example, the number of columns specified by the cols attribute may not match the number of columns defined by the COL elements . In turn, this may not correspond to the number of columns determined from the cells of the table. Then, problems occur if the columns are too narrow and the content does not enter the cell. The width of the table specified in the TABLE element or COL element can lead to cell overflow. Users of users are advised to correctly exit such situations, for example, by transferring words and rearranging and splitting words if the transfer locations are unknown.

In the event that the cell overflow causes an indivisible element, the user agent can adjust the column widths and re-present the table in a new way. In the worst case, if you can not adjust the width of the column and scroll, you can crop the content. In any case, if the contents of the cell are formed or broken, this should be reported to the user accordingly.

Automatic layout algorithm  

If the COLS attribute is not present in the initial table tag, the user agent must use the following automatic layout algorithm. It uses two passes of the table data and a linear scaling of the table size.

On the first pass, the row transfer is disabled, and the user agent controls the minimum and maximum width of each cell. The maximum width is determined by the widest line. Because the breakdown of rows is disabled, paragraphs are processed by long lines, unless they are broken using BR elements. The minimum width is determined by the widest element of the text (word, image, etc.), taking into account the initial lacks, markers, etc. In other words, you need to determine the minimum width that the cell needs in a separate window without overflow. Allowing user agents to break down words will reduce the need for horizontal scrolling and trimming the contents of the cell.

This process also applies to nested tables in cells. The minimum and maximum widths of cells in nested tables are used to determine the minimum and maximum width of these tables and, therefore, for the outer table. The algorithm is linear with the total content of the cell, and, broadly speaking, does not depend on the level of nesting.

To equalize the contents of a cell, this algorithm stores three minimum / maximum values ​​for each cell: Left of align char, right of align char, and unaligned. The minimum width of the column is max (min_left + min_right, min_non-aligned) .

The minimum and maximum cell widths are used to determine the corresponding minimum and maximum column widths. In turn, they are used to find the minimum and maximum width of the table. Note that cells can contain nested tables, but this does not complicate the code. The next step is to determine the width of the columns in accordance with the free space (that is, the space between the left and right margins).

For cells that occupy several columns, a simple approach is to distribute the minimum / maximum width uniformly to all columns. A slightly more complex approach is to use the minimum / maximum width of cells that do not occupy multiple rows or columns to weigh how the widths of cells spanning several rows or columns are distributed. Based on the results of the experiments, we can say that the best results for a wide range of tables are provided by a combination of these two approaches.

The borders of the table and the fields between cells must be included in the assigned column width. There are three cases:

1. The minimum table width is equal to or greater than the available space. In this case, set the minimum width and let users scroll horizontally. To convert to the Braille alphabet, you need to replace the cells with references to the full content. By agreement, this is done before the table.
2. The maximum width of the table is included in the available space. In this case, set the maximum column width.
3. The maximum width of the table exceeds the available space, but the minimum table width does not exceed it. In this case, find the difference between the available space and the minimum width of the table, call it W. Let's call D the difference between the maximum and minimum width of the table.

   For each column, make d equal to the difference between the maximum and minimum width of this column. Then set the width of the column to the minimum width plus d times over W over D. This will allow you to make columns with a larger difference between the minimum and maximum widths wider than the columns with the difference.

This step is then repeated for the nested tables using the minimum and maximum widths obtained for all such tables in the first pass. In this case, the width of the cell of the parent table plays the role of the size of the current stake in the above description. This process is repeated recursively for all nested tables. The topmost table is then presented with the assigned widths. Nested tables are sequentially represented as part of the contents of the cell of the parent table.

If the width of the table is specified using the width attribute, the user agent tries to set the appropriate column width. The width attribute is not a limitation if the results in the columns are less than the minimum width (i.e., indivisible).

If the relative width is determined using the COL element, the algorithm changes, and the column width increases compared to the minimum width to match the relative width constraints. COL elements should be considered only as prompts, so the width of the columns should not be set less than the minimum. Similarly, the width of the columns should not be such that the table is stretched beyond the window. If the COL element specifies a relative width of zero, the column must always have a minimum width.

When using a two-pass layout algorithm, the default alignment position in the absence of an explicit or inherited charoff attribute can be determined by selecting a position that would be the center of the line for which the width before and after the alignment character would be the maximum values ​​for any of the rows in the column for which align = "This symbol" . For sequential layout of tables, charoff = "50%" is used by default. If several cells in different rows of the same column use alignment, such cells should be aligned by default, regardless of which character is used for alignment. Rules for processing objects that are too large for a column are applied if an explicit or inheritable alignment results in a situation where the data exceeds the designated column width.

B.6 Notes on forms

B.6.1 Sequential display

Sequential display of documents received over the network presents some problems with the forms. User agents should not allow the transfer of forms until all the elements of the form are received.

Sequentially displaying documents leads to some problems with the Tab key. The heuristic of the focus transition on tabindex with the lowest value in the document at first glance seems very logical. However, this implies the need to wait for the text of the entire document to be retrieved, since before this tabindex with the lowest value may change. If the user clicks the tab key before this, it makes sense for the user agents to move the focus to the lowest available tabindex .

If forms are associated with client scripts, additional problems may occur. For example, the script handler for this field can access a field that does not already exist.

B.6.2 Future projects

This specification defines a set of elements and attributes, powerful enough to represent the basic forms. However, there are still opportunities for improvement. For example, in the future you can try to solve the following problems:

• The range of form field types is too limited in comparison with modern user interfaces. For example, there is no element for entering tables, sliders, or multi-page options.
• Servers can not update fields in submitted forms and instead must send a complete HTML document, which causes the screen to flicker.
• In addition, there are problems with speech browsers, which makes it difficult to work with forms for people with poor eyesight.

Another possible extension is the addition of the usemap attribute for the INPUT element for use in client navigation maps, if " type = image". The AREA element corresponding to the click location determines the value transferred to the server. To avoid the need to change server scripts, it can be used to extend the AREA element and specify the x and y values ​​to use in the INPUT element.

B.7 Notes on scripts

B.7.1 Reserved syntax for future scripts macros

In this specification, the syntax is reserved to support script macros in the HTML CDATA attributes. This is intended to make it possible to set the attributes depending on the properties of the objects that are on the page above. Syntax:

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

Practice macros scripts currently  

The body of a macro consists of one or more expressions in the default script language (as in the attributes for internal events). The semicolon next to the right bracket is always required, otherwise the bracket "}" character is considered part of the body of the macro. Needless to say, quotes for attributes that contain script macros are mandatory.

The processing of CDATA attributes is as follows:

1. The SGML parser evaluates all SGML objects (for example, "& gt;").
2. Then the script kernel evaluates the scripts macros.
3. Finally, the resultant character string is passed to the application for further processing.

Macro processing occurs when the document is loaded (or during a reboot), but does not occur when the document size is changed, redrawing, etc.

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

 
 <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 Remarks about frames

Since the name of the target frame is not guaranteed, it is suitable for describing the current practice of searching for a frame with this target name :

1. If the target name is a reserved word, as described in the normative text, use it as described.
2. Otherwise, search the first level of the frame hierarchy in the window containing the link. Use the first frame with that name.
3. If such a frame is not found in step (2), repeat step 2 with each window in the order from the first to the last. Stop the search as soon as the frame with that name is encountered.
4. If the frame is not found in step (3), create a new window and assign it that target name.

B.9 Comments on availability

If the author has not set the alt attribute for the IMG or APPLET element, the user agents must themselves set the alternative text, calculated in the following order:

1. If a title is specified, the value of this attribute should be used as the alternative text.
2. Otherwise, if header information is given in HTTP headers when the included object is loaded, this information should be used as an alternative text.
3. Otherwise, if there are text fields in the included object (for example, GIF images have text fields), the information extracted from the text fields should be used as an alternative text. Because user agents may need to download the entire object for extracting textual information, they can use more economical approaches (for example, discussion of content).
4. Otherwise, if no other information is available, the user agent must use the file name (without an extension) as an alternative text.

If the author has not set the alt attribute for the INPUT element, the user agents must compute the alternative text in the following order:

1. If a title is specified, its value should be used as an alternative text.
2. Otherwise, if the name attribute is specified, its value should be used as an alternative text.
3. Otherwise (send and reset buttons), the value of the type attribute should be used as alternative text.

B.10 Notes on protection

Anchors, embedded images, and all other elements that contain URIs as parameters can result in dereferencing a URI in response to user input. In this case, consider the issues described in [ RFC1738 ] , Section 6. The widely used methods for sending form requests-HTTP and SMTP-provide a low degree of confidentiality. Information providers requesting important information through forms - especially with the help of INPUT elements, type = "password" - should warn their users about a non-high degree of protection.

B.10.1 Protection issues for forms

The user agent should not send files that the user did not explicitly request to be sent. Therefore, HTML user agents must acknowledge all file names used by reason, which can be specified in the value attribute of the INPUT element. In screened control elements, file names should not be specified.

This specification does not contain a data encryption mechanism; It must be carried out by any other mechanism for secure data transmission.

After downloading the file, the processing agent must properly process and save the file.