Errata

The statement "There must be a space after the initial <!-- and preceding the final -->" is not correct. There is no
such requirement in either HTML nor XML according to the w3c documents referenced below.

However, there is a restriction on the content of a comment that is not mentioned in the book: Two adjacent hyphens may
not appear in the body of a comment. This is a strange restriction since --> is
the terminator and -- followed by something other than > should not be that hard for a parser to deal with.

Even stranger, the HTML doc says that whitespace may appear between the -- and the > terminating the comment. So <!--
comment -- > is a valid comment. This is just plain dumb. No wonder XHTML was invented.

http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.4
http://www.w3.org/TR/xml11/#sec-comments

Author reply:
This is all correct, but covers more than we address in this chapter. Moreover, although the spec advises against (but
does not formally prohibit) the use of two dashes in a comment, both IE and Firefox correctly handle the comment.
We will replace the sentence: “There must be a space after the initial <!-- and preceding the final -->, but
otherwise you can put nearly anything inside the comment.”

with:

“You can put nearly anything you’d like inside a comment.”

The statement "There must be a space after the initial <!-- and preceding the final -->" is not correct. There is no
such requirement in either HTML nor XML according to the w3c documents referenced below.

However, there is a restriction on the content of a comment that is not mentioned in the book: Two adjacent hyphens may
not appear in the body of a comment. This is a strange restriction since --> is
the terminator and -- followed by something other than > should not be that hard for a parser to deal with.

Even stranger, the HTML doc says that whitespace may appear between the -- and the > terminating the comment. So <!--
comment -- > is a valid comment. This is just plain dumb. No wonder XHTML was invented.

http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.4
http://www.w3.org/TR/xml11/#sec-comments

Author reply:
This is all correct, but covers more than we address in this chapter. Moreover, although the spec advises against (but
does not formally prohibit) the use of two dashes in a comment, both IE and Firefox correctly handle the comment.
We will replace the sentence: “There must be a space after the initial <!-- and preceding the final -->, but
otherwise you can put nearly anything inside the comment.”

with:

“You can put nearly anything you’d like inside a comment.”

"http_equiv" should read "http-equiv"

The book says:

You can use a mailto URL as the value of the form's action attribute. The latest browsers automatically email the
various form parameters and values to the address supplied in the URL.

I tried the following form (with the right email address) and my IE 6.0 brings up my email client - the browser doesn't
email the form.

<form method=POST action="mailto:email_address">
<input type=submit>
</form>

The issue is also described and discussed at -

http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=20&t=008553

Author reply:
Here an email is composed for you, but the user must actually click the send button to send it. This is a deviation
from early browsers, which silently sent the message on your behalf.

In any case, the sentence: “The latest browsers automatically email the various form parameters and values to the
address supplied in the URL.”

will be replaced by:

“Older browserswill silently email the various form parameters and values to the address supplied in the URL. For
security purposes, the latest browsers will instead use the default messaging client to compose the email, relying upon
the user to click the “Send” button to transmit the message.”.

The book says:

You can use a mailto URL as the value of the form's action attribute. The latest browsers automatically email the
various form parameters and values to the address supplied in the URL.

I tried the following form (with the right email address) and my IE 6.0 brings up my email client - the browser doesn't
email the form.

<form method=POST action="mailto:email_address">
<input type=submit>
</form>

The issue is also described and discussed at -

http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=20&t=008553

Author reply:
Here an email is composed for you, but the user must actually click the send button to send it. This is a deviation
from early browsers, which silently sent the message on your behalf.

In any case, the sentence: “The latest browsers automatically email the various form parameters and values to the
address supplied in the URL.”

will be replaced by:

“Older browserswill silently email the various form parameters and values to the address supplied in the URL. For
security purposes, the latest browsers will instead use the default messaging client to compose the email, relying upon
the user to click the “Send” button to transmit the message.”.

The text of this section refer to 'virtual' and 'physical' as valid values for the wrap attribute. 'soft' and 'hard'
should be used instead.

Author reply:
True enough. Netscape 3.0 tried to make the virtual/physical values a standard but gave up. All occurrences
of “physical” will be replaced by “hard” in this section, and all occurrences of “virtual” with “soft.” In addition,
the following paragraph will be included at the very end of the section:

Note that early versions of the Netscape browser used virtual and physical in place of soft and hard for this
attribute. These values are generally not supported today; we mention them here only to provide clarity should you
stumble across some ancient bit of HTML in your web wanderings.

The text of this section refer to 'virtual' and 'physical' as valid values for the wrap attribute. 'soft' and 'hard'
should be used instead.

Author reply:
True enough. Netscape 3.0 tried to make the virtual/physical values a standard but gave up. All occurrences
of “physical” will be replaced by “hard” in this section, and all occurrences of “virtual” with “soft.” In addition,
the following paragraph will be included at the very end of the section:

Note that early versions of the Netscape browser used virtual and physical in place of soft and hard for this
attribute. These values are generally not supported today; we mention them here only to provide clarity should you
stumble across some ancient bit of HTML in your web wanderings.

Setting the tabIndex to 0 does not always exclude the element from the
tabbing order. In my IE version 6.0 setting tabIndex to -1 works fine, though.

Author reply:
This is true. Positive integers create a tab order, -1 removes an element from the tab order, and 0 leaves the item in
the order after numbered items, in the order declared in the file.

This paragraph will be replaced:

The value of the tabindex attribute is a positive integer indicating the position of the tagged contents in the overall
tab sequence for the document. The tabbing order begins with elements with explicit tabindex values, starting from the
lowest to the highest numbers. Same-valued tags get tab-selected in the order in which they appear in the document. All
other selectable tags, such as the various form controls and hyperlinks, are the last to get tabbed, in the order in
which they appear in the document. To exclude an element from the tab order, set the value of tabindex to 0. The
element is skipped when the user tabs around the form.

with this:

The value of the tabindex attribute is a positive integer indicating the position of the tagged contents in the overall
tab sequence for the document. The tabbing order begins with elements with explicit tabindex values greater than zero,
starting from the lowest to the highest numbers. Same-valued tags get tab-selected in the order in which they appear in
the document. All other selectable tags, including those with tabindex set to 0, then get tabbed in the order in which
they appear in the document. To exclude an element from the tab order, set the value of tabindex to -1. The element is
skipped when the user tabs around the form. Finally, in the next paragraph, replace “while notab is equivalent to
tabindex=0” with “while notab is equivalent to tabindex=-1”.

Setting the tabIndex to 0 does not always exclude the element from the
tabbing order. In my IE version 6.0 setting tabIndex to -1 works fine, though.

Author reply:
This is true. Positive integers create a tab order, -1 removes an element from the tab order, and 0 leaves the item in
the order after numbered items, in the order declared in the file.

This paragraph will be replaced:

The value of the tabindex attribute is a positive integer indicating the position of the tagged contents in the overall
tab sequence for the document. The tabbing order begins with elements with explicit tabindex values, starting from the
lowest to the highest numbers. Same-valued tags get tab-selected in the order in which they appear in the document. All
other selectable tags, such as the various form controls and hyperlinks, are the last to get tabbed, in the order in
which they appear in the document. To exclude an element from the tab order, set the value of tabindex to 0. The
element is skipped when the user tabs around the form.

with this:

The value of the tabindex attribute is a positive integer indicating the position of the tagged contents in the overall
tab sequence for the document. The tabbing order begins with elements with explicit tabindex values greater than zero,
starting from the lowest to the highest numbers. Same-valued tags get tab-selected in the order in which they appear in
the document. All other selectable tags, including those with tabindex set to 0, then get tabbed in the order in which
they appear in the document. To exclude an element from the tab order, set the value of tabindex to -1. The element is
skipped when the user tabs around the form. Finally, in the next paragraph, replace “while notab is equivalent to
tabindex=0” with “while notab is equivalent to tabindex=-1”.