notes.html

学习HTML的书籍

minimum width. Similarly, columns shouldn't be made so wide that the
table stretches well beyond the extent of the window. If a <a href="../struct/tables.html#edef-COL"><samp
class="einst">COL</samp></a> element specifies a relative width of zero,
the column should always be set to its minimum width.

<p>When using the two pass layout algorithm, the default alignment
position in the absence of an explicit or inherited <a href="../struct/tables.html#adef-charoff"><samp
class="ainst-TABLE">charoff</samp></a> 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 <tt>align="char"</tt>. For incremental
table layout the suggested default is <tt>charoff="50%"</tt>. 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 column apply when the explicit or implied alignment
results in a situation where the data exceeds the assigned width of
the column.

<div class="note"><P>
<em><strong>Choice of attribute names.</strong> 
It would have been
preferable to choose values for the <a href="../struct/tables.html#adef-frame"><samp class="ainst-TABLE">frame</samp></a>
attribute consistent with the <a href="../struct/tables.html#adef-rules"><samp class="ainst-TABLE">rules</samp></a>
attribute and the values used for alignment. For instance: <tt>none,
top, bottom, topbot, left, right, leftright, all</tt>. 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<a href="../struct/tables.html#adef-frame"><samp class="ainst-TABLE">frame</samp></a> attribute have been chosen to
avoid clashes with the <a href="../struct/tables.html#adef-rules"><samp class="ainst-TABLE">rules</samp></a>, <a href="../struct/tables.html#adef-align-TABLE"><samp
class="ainst-TABLE">align</samp></a> and <samp class="ainst-TABLE">valign-COLGROUP</samp>
attributes. This provides a measure of future proofing, as it is
anticipated that that the <a href="../struct/tables.html#adef-frame"><samp class="ainst">frame</samp></a> and <a href="../struct/tables.html#adef-rules"><samp
class="ainst">rules</samp></a> attributes will be added to other table
elements in future revisions to this specification. An alternative
would be to make <a href="../struct/tables.html#adef-frame"><samp class="ainst-TABLE">frame</samp></a> 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.</em>
</div>

<h2><a name="styles"> Notes on styles</a><a name="h-13.2.3">&nbsp;</a></h2>

<p>Some people have voiced concerns over performance issues for style
sheets. For instance, retrieving an external style sheet may delay the
full presentation for the user. A similar situation arises if the
document head includes a lengthy set of style rules.

<p>The current proposal addresses these issues by allowing authors
to include rendering instructions within each HTML element. The
rendering information is then always available by the time the user
agent wants to render each element.

<p>In many cases, authors will take advantage of a common style sheet
for a group of documents. In this case, distributing style rules
throughout the document will actually lead to worse performance than
using a linked style sheet, since for most documents, the style sheet
will already be present in the local cache. The public availability of
good style sheets will encourage this effect.

<h3>New media types<a name="h-13.2.3.1">&nbsp;</a></h3>

<p>It is likely that the list of media types will grow in the future.  To
enable such extensions to be introduced smoothly, user agents
conforming to this specification must be able to parse the media type
attribute value as follows:

<ol>
<li>Comma characters (Unicode decimal 44) are used to break the
media attribute value into a list of entries. For example,

<pre>
    media="screen, 3d-glasses, print and resolution > 90dpi"
</pre>

<p>is mapped to:

<pre>
    "screen"
    "3d-glasses"
    "print and resolution > 90dpi"
</pre>

<li>Each entry is truncated just before the first character that
isn't a <em>US ASCII letter</em> [a-zA-Z] (Unicode decimal 65-90, 97-122),
or <em>hyphen</em> (Unicode decimal 45). In our example, this gives:

<pre>
    "screen"
    "3d-glasses"
    "print"
</pre>

<li>A case-insensitive match is then made with the set of media
types defined above. Entries that don't match should be ignored.
In the example we are left with <tt>screen</tt> and <tt>print</tt>.
</ol>


<div class="note"><P>
<em>Note: Style sheets may include media dependent variations
within them. For instance the proposed CSS <em>@media</em>
construct. In such cases it may be appropriate to use the
default value "all".</em>
</div>

<h2><a name="notes-forms">Notes on forms</a><a name="h-13.2.4">&nbsp;</a></h2>

<h3>Incremental display<a name="h-13.2.4.1">&nbsp;</a></h3> 
<p>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. 

<P>The incremental display of documents raises some issues with
respect to tabbing navigation. The heuristic of giving focus to the
lowest valued <a href="../interact/forms.html#adef-tabindex"><samp class="ainst">tabindex</samp></a> 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 <a href="../interact/forms.html#adef-tabindex"><samp class="ainst">tabindex</samp></a> may stil
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
<a href="../interact/forms.html#adef-tabindex"><samp class="ainst">tabindex</samp></a>.


<P>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.

<h3>Future projects<a name="h-13.2.4.2">&nbsp;</a></h3>
<p>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:

<ul>
<li>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.

<li>Servers cannot update the fields in a submitted form and instead have
to send a complete HTML document causing screen flicker.

<li>These also cause problems for speech based browsers, making it
difficult for the visually impaired to interact with HTML forms.
</ul>

<h2><a name="notes-scripting">Notes on scripting</a><a name="h-13.2.5">&nbsp;</a></h2>

<h3>Reserved syntax for future script macros<a name="h-13.2.5.1">&nbsp;</a></h3>

<p>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:

<pre>   attribute = "... &amp;{ <i>macro body</i> }; ... "</pre>

<h4>Current Practice for Script Macros<a name="h-13.2.5.1.1">&nbsp;</a></h4>
<p>The macro body is made up of one or more statements in the
default scripting language (as per instrinsic 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.

<p>The processing of CDATA attributes proceeds as follows:

<ol>
<li>The SGML parser evaluates any SGML entities (e.g., "&amp;gt;").
<li>Next the script macros are evaluated by the script engine.
<li>Finally the resultant character string is passed to the
application for subsequent processing.
</ol>

<p>Macro processing takes place when the document is loaded (or
reloaded) but does not reoccur when the document is resized,
repainted, etc.

<div class="example"><P>
Here are some examples using JavaScript. The first one randomizes
the document background color:

<pre>    
&lt;BODY bgcolor='&{randomrbg()};'&gt;
</pre>

<p>Perhaps you want to dim the background for evening viewing:

<pre>    
&lt;BACKGROUND src='&{if(Date.getHours &gt; 18)...};'&gt;
</pre>

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

<pre>    
&lt;MAP NAME=foo&gt;
   &lt;AREA shape="rect" coords="&{myrect(imageurl)};" href="&{myurl};"&gt;
 &lt;/MAP&gt;
</pre>

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

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

<p>You can set the URL for a link or image by script:

<pre>
 &lt;SCRIPT&gt;
   function manufacturer(widget) {
       ...
   }
   function location(manufacturer) {
       ...
   }
   function logo(manufacturer) {
       ...
   }
 &lt;/SCRIPT&gt;
  &lt;A href='&{location(manufacturer("widget"))};'&gt;widget&lt;/A&gt;
  &lt;IMG src='&{logo(manufacturer("widget"))};'&gt;
</pre>

<p>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 &amp;quot; for double quote
marks:

<pre>   
&lt;IMG src="&{logo(manufacturer(&amp;quot;widget&amp;quot;))};"&gt;
</pre>
</div>
<div class="navbar">
<hr><center><a href="changes.html">previous</a> &nbsp; <a href="orgs.html">next</a> &nbsp; <a href="../contents.html">contents</a> &nbsp; <a href="../index/elements.html">elements</a> &nbsp; <a href="../index/attribs.html">attributes</a>
</center></div>
</body>