- From: Ian B. Jacobs <ij@w3.org>
- Date: Mon, 29 Jun 1998 11:40:50 -0400
- To: Steve <liberty@i1.net>
- CC: www-html-editor@w3.org
Steve wrote:
>
> I have just completed reading the referenced document (downloaded via
> <http://www.w3.org/TR/1998/REC-html40-19980424/html40.zip>). First I'd like
> to say the documents are very thorough and very well done.
Thank you for your support, and the time you have taken to review the
specification (and comment!). Sorry for the delay in responding.
> Significant Errors
> - From "cover.html," when I clicked on the "3. On SGML and HTML" link,
> Netscape 4.04 for the Macintosh crashes loading the referenced page. This
> is probably a Netscape problem, however, I eliminated the crash by removing
> the <DFN> element from around the "Boolean attributes" content of one of
> the "tocxref" classed anchors within "intro/sgmltut.html". (The cover page
> available via the Internet [i.e., <http://www.w3.org/TR/REC-html40/>] is
> significantly different [even though they are both dated 24-Apr-1998!] so I
> can't tell whether the problem is just with the contents of the zipped file
> or not.)
This is apparently due to a Mac bug that may have been fixed in a recent
release. However, I am trying to put together a page for the W3C Web
site that would document such problems and offer solutions (and bring
awareness to W3C authors). For now, I think the problem goes
away if you turn off style sheets and/or java support in your browser.
> - In "intro/intro.html" under "2.1.1 Introduction to URIs": The anchor
> around [RFC2068] should probably have class="normref" instead of
> class="informref".
For this and other comments related to normref/informref: Some of our
references are informative references to sources that are referenced
elsewhere normatively. We considered it "legal" to have normative and
informative links to a resource that is referenced normatively at least
once. We considered it legal to have an informative link to an
informative reference, but *illegal* to have a normative link
to an informative reference. We ran scripts on the spec to verify
that the latter case didn't occur (if it did, please let us know!).
> - In "intro/sgmltut.html" under "3.2.1 Elements": In the paragraph that
> starts "Please consult the SGML standard..." the phrase "an end tag closes
> all omitted start tags up to the matching start tag" is unclear (the start
> tags aren't ommited, are they?).
> Shouldn't it read "an end tag closes all
> start tags up to its matching start tag" [without the word "omitted" and
> "the" changed to "its"]? Or maybe better yet: "an end tag closes all start
> tags associated with omitted end tags up to its matching start tag".
Yes.
> - In "intro/sgmltut.html" under "3.3.3 Element declarations": In item 2
> of the ordered list, shouldn't "Whether the element's end tag is optional"
> read "Whether the element's tags are optional"?
Yes.
> - In "types.html" under "6.2 SGML basic types": It seems to me "a
> summary of key information" for the PCDATA type has been overlooked. (When
> this information is added, don't forget to update "dtd.html" to point to
> the new information similar to the other SGML basic types.)
It was not overlooked, just omitted for reasons of space and simplicity.
> - In "struct/global.html" under "7.5.2 Element identifiers: the id and
> class attributes": In the second last paragraph, which begins "By
> setting...", item 2 ("override class style information with instance style
> information") implies that the id attribute must have a value in order to
> use the style attribute of an element. This is only correct if you don't
> consider the "style" attribute "instance style information".
I see your point, but I don't think the implication is that strong.
In this paragraph, we are only referring to what "id" can do, not
everything that is possible (e.g., we don't talk about HTTP
headers either in this paragraph).
> - In "struct/global.html" under "7.5.6 The ADDRESS element": Under
> "Attributes defined elsewhere" both "title" & "style" are part of
> "%coreattrs" and should be shown with appropriate links.
Yes.
> - In "struct/tables.html" under "11.2.5 Table rows: The TR element":
> Under attribute defined elsewhere, the transitional attribute "bgcolor" is
> missing.
Yes.
> - In "struct/objects.html" under "13.7.2 White space around images and
> objects": The "hspace" and "vspace" attributes are not here marked as
> deprecated, yet they are only in the transitional DTD.
At the beginning of section 13.7, we say that presentation attributes
in the sections below are deprecated. However, we could make this
clearer.
> - In "struct/objects.html" under "13.7.4 Alignment": The "align"
> attribute is not here marked as deprecated, yet it is only in the
> transitional DTD.
Same reasoning for "align".
> Also, I don't understand why "align" is not handled
> similar to "border" (above it) with italisized "Attribute definitions" and
> allowed values shown as "bottom|middle|top|left|right". (I realize the
> information is all there, but why the different presentation?
No particular reason. Sorry for this inconsistency.
> - In "present/styles.html" under "14.3.2 Specifying external style
> sheets": Under the second bulletted item, the "type" attribute should
> probably have an anchor element around it with an appropriate destination.
Yes, I'll fix this.
> - In "present/styles.html" under "14.4.1 Media-dependent cascades": In
> the example, the STYLE element does not specify a "media" attribute but the
> descriptive text immediately above it says, "The color rule defined by the
> STYLE element is used for print and screen but not for aural rendering."
> Why is aural excluded? Is the example missing a "media" attribute?
I agree, since the default value of "screen" would not include
print (i.e., the lack of an attribute implies the default value).
> - In "present/graphics.html" under "15.3 Rules: the HR element": The
> "align" attribute appears under both "Attribute definitions" and
> "Attributes defined elsewhere". I presume it doesn't belong under
> "Attributes defined elsewhere".
You're correct.
> - In "present/frames.html" under "16.2.2 The FRAME element": The
> attributes "marginwidth" and "marginheight" are defined to have a value
> greater than one. Was *greater than or equal to" one intended? (I couldn't
> figure any reason why the margins couldn't be one, so I'm just guessing
> that I caught an error. I wouldn't be the least surprised to learn I was
> wrong.)
I'm asking the HTML Coordination Group about this one, but I suspect
you're
correct.
> - In "present/frames.html" under "16.3.1 Setting the default target for
> links": In the second paragraph, "factorizing" is not a word in any
> dictionary I looked in. "Factoring" was probably intended.
Yes.
> - In "interact/scripts.html" under "18.2.1 The SCRIPT element": The DTD
> fragment doesn't contain the "for" attribute which is present in both the
> Strict and Transitional DTDs. <!ENTITY % LAlign "(top|bottom|left|right)">
That's because this attribute is reserved, therefore not made easily
visible to readers.
> - In "sgml/dtd.html": The line "<!ENTITY % LAlign
> "(top|bottom|left|right)">" is from the Transitional DTD and is
> unneccessary in the Strict DTD.
Yes.
> - In "sgml/loosedtd.html" under "NOFRAMES": Am I reading the loose DTD
> correctly in that it seems to state that, for 4.0 Frameset, NOFRAMES must
> include one and only one BODY element that cannot contain NOFRAMES? In
> other words, in "ENTITY % noframes.content" (for the Frameset DTD),
> shouldn't there be an asterisk after "(BODY)"?
No, (BODY) means one and only one BODY, the desired content model.
> - In "appendix/notes.html" under "B.4 Notes on helping search engines
> index your Web site": Under the subheading "Provide keywords and
> descriptions", in the sentence "The value of the name attribute sought by a
> search attribute is not defined by this specification", the word
> "attribute" after "search" should probably be "engine".
Yes.
> - In "appendix/notes.html" under "B.4.1 Search robots": Under the
> subheading "Robots and the META element", appears this statement: "The list
> of terms in the content is ALL, INDEX, NOFOLLOW, NOINDEX. The name and the
> content attribute values are case-insensitive." This is directly
> contradictory with the case sensativity specified under the META element
> (see global.html#edef-META).
Yes.
> Significant Oversights
> - In "intro/sgmltut.html" under "3.3.3 Element declarations": Under the
> subhead "Content model definitions", when neither "&", "*" or "+" is
> appended to an element or group, the implied default is unclear? I assume
> the default meaning is "one & only one". Whatever the implied default, it
> should be explicitly stated. Cf. the question earlier about "NOFRAMES".
Yes.
> - In "struct/tables" under "11.3.2 Horizontal and vertical alignment":
>Under the "align" attribute definition, "left" is indicated as the default
>for "table data". Does this include TR and TD. Under the "align" attribute
>definition, "center" is indicated as the default for "table headers". Does
>this include COLGROUP, COL, THEAD, TFOOT, and TH. In other words, the
>current indications for "align" default is unclear regarding COLGROUP, COL,
>THEAD, TFOOT and TR elements.
I agree, this is ambiguous. I'll ask the HTML Coordination Group
their opinion.
> - In "struct/links.html" under "12.2.3 Anchors with the id attribute":
> One finds this statement: "The id and name attributes share the same name
> space. This means that they cannot both define an anchor with the same name
> in the same document." Because each anchor requires a unique identifier,
> this makes sense, but the documents don't address the question of backwards
> compatability for user agents that recognize "name" but don't recognize
> "id".
The HTML 4.0 spec doesn't specify "error behavior" if anchor names are
duplicated even in HTML 4.0 documents (let alone earlier versions of
HTML).
> The example given shows identical "id" and "name" values in disparate
> elements. It fails to indicate whether "id" and "name" values can be
> identical within one element (e.g., <A NAME="a1" ID="a1"></A>).
> Can a valid HTML document have identical values for "id" and "name"
> within one element? Are user agents required to recognize either or both?
Since the condition "in the same document" still holds, the above
constraint is still applicable. "id" and "name" cannot have identical
values in the same element.
> - In "present/styles.html" under "14.3.2 Specifying external style
> sheets": The documents imply that the LINK element's "title" attribute can
> group several external style sheets together under a single name placed in
> a user agent menu. The documents never mention whether the STYLE elements
> "title" attribute, if identical to a LINK element's "title," would apply to
> the same group.
Good point. I'll raise this with the HTML Coordination Group.
> - Too often, when I'm viewing "sgml/dtd.html", I come across a type
> parameter entity definition about which I can't remember all of the
> specifics. It would be much better if the parameter entity definition
> linked to its description.
I agree.
> For example, the named anchor (i.e., name="ContentType") around the
> ContentType parameter entity definition (in "dtd.html") should have as its
> destination the named anchor "types.html#type-content-type". In other
> words, said anchor in "dtd.html" should be:
> <A src="types.html#type-content-type" name="ContentType">ContentType</A>.
> This has already been done for the SGML basic types (CDATA, ID, NAME,
> IDREF, IDREFS and NUMBER). Why not for the derived more specific types?
> Assuming "->" means "should have as its destination," the effected
> anchors (within "dtd.html") would be:
> name="ContentType" -> "types.html#type-content-type"
> name="ContentTypes" -> "types.html#type-content-type"
> name="Charset" -> "types.html#type-charset"
> name="Charsets" -> "types.html#type-charset"
> name="LanguageCode" -> "types.html#type-langcode"
> name="Character" -> "types.html#type-character"
> name="LinkTypes" -> "types.html#type-links"
> name="MediaDesc" -> "types.html#type-media-descriptors"
> name="URI" -> "types.html#type-uri"
> name="Datetime" -> "types.html#type-datetime"
> name="Script" -> "types.html#type-script"
> name="StyleSheet" -> "types.html#type-style"
> name="Text" -> "types.html#type-text"
> name="Coords" -> "struct/objects.html#adef-coords"
> name="Length" -> "types.html#type-length"
> name="MultiLength" -> "types.html#type-multi-length"
> name="MultiLengths" -> "types.html#type-multi-length"
> name="Pixels" -> "types.html#type-pixels"
> Of course all of the above holds true for "sgml/loosedtd.html" which
> also has:
> name="FrameTarget" -> "types.html#type-frame-target"
> name="Color" -> "types.html#type-color"
> name="OLStyle" -> "struct/lists.html#h-10.3.1"
> name="LIStyle" -> "struct/lists.html#h-10.3.1"
I'll have to check with my co-editors about implementing this feature
in a new revision of the document.
> - Within the DTDs (i.e., sgml/dtd.html#block, sgml/loosedtd.html#block,
> etc.) within every ENTITY definition, every entity that is part of the
> definition (i.e., those things inside the quotation marks) *should be* a
> link to the entity or element definition in the DTD. For example, in
> "ENTITY % block", the P entity is shown but (currently) the P is not a link
> to where the P entity is defined in the DTD. It should be.
Also a good idea.
By the way, I'm glad to hear that you are using the many links we
generated
for this document, even though we are missing a few.
> Minor Typographical Errors
> - In "intro/intro.html" under "2.1.3 Relative URIs": In the 3rd item of
> the unordered list, shouldn't "applets" be singular?
Yes.
> - In "intro/sgmltut.html" under "3.2.2 Attributes": The sentence
> "Attribute names are always case-insensitive" is missing its closing
> punctuation.
Yes.
> - In "intro/sgmltut.html" under "3.3.4 Attribute declarations": Just
> after the first DTD fragment, it doesn't seem to me that the "Start tag:
> required, End tag: forbidden" is relevant to the discussion.
Perhaps, but this text is generated by our scripts. I don't think
we'll have time to repair the script.
> - In "intro/types.html" under "6.5.1 Notes on using colors": The first
> sentence needs the indefinite article "a" before the word "document" so the
> sentence would read: "Although colors can add significant amounts of
> information to a document and make them more readable...."
Ok.
> - In "intro/types.html" under "6.10 Single characters": The first
> sentence needs the indefinite article "a" before the word "single" so the
> sentence would read: "Certain attributes call for a single character from
> the document character set."
Yes.
> - In "struct/global.html" under "7.4.4 Meta data": Under the subheading
> "Meta data profiles", in the second unordered list item, the comma should
> be removed from the second sentence.
Yes.
> - In "struct/global.html" under "7.5.4 Grouping elements: the DIV and
> SPAN elements": In the sentence that begins "Later, we may easily...": It
> should read either, "... we may easily add a style sheet declaration to
> fine tune the presentation..." [adding the word "a" before "style"], or
> "... we may easily add style sheet declarations to fine tune the
> presentation" ["declaration" becomes plural].
Yes.
> - In "struct/global.html" under "7.5.6 The ADDRESS element": The
> sentence that begins "The ADDRESS element...": needs the indefinite article
> "a" before the word "document" so the sentence would read: "... to supply
> contact information for a document...."
Yes.
> - In "struct/dirlang.html" under "8.2.3 Setting the direction of
> embedded text": In the paragraph that begins "Authors may also...": the
> word "multiply" should be "multiple".
Although "multiply" is correct English (meaning "multiple times"), I
prefer
your choice.
> - In "struct/text.html" under "9.2.2 Quotations: The BLOCKQUOTE and Q
> elements": Within the DTD fragment, I don't see why the "cite" under Q is a
> link but under BLOCKQUOTE it is not.
I'll fix this.
> - In "struct/tables.html" under "11.2.6 Table cells: The TH and TD
> elements": Immediately before the subheading "Cells that span several rows
> or columns", the preformatted block of text mimicking a table does not line
> up vertically.
I don't see this one.
> - In "struct/tables.html" under "11.3.1 Borders and rules": The first
> sentence under the "frame" attribute should read "This attribute specifies
> which sides of the frame surrounding a table will be visible" [substitute
> "surrounding" for "that surrounds"].
Ok.
> - In "struct/links.html" under "12.1.2 Other link relationships": The
> last sentence should read "Further information is given below on using
> links for..." [change "of" to "on"]. This sentence is also missing its
> closing punctuation.
Yes.
> - In "struct/links.html" under "12.2.2 Nested links are illegal": The
> last paragraph should read "Since the DTD defines the LINK element to be
> empty..." [insert definite article "the" before "LINK"].
Yes.
> - In "struct/objects.html" under "13.3.4 Object declarations and
> instantiations": In the paragraph that begins "In the following
> example...", the phrase "cause it so be instantiated" should be changed to
> "cause it to be instantiated" [change "so" to "to"].
Yes.
> - In "struct/objects.html" under "13.6.1 Client-side image maps: the MAP
> and AREA elements": Under the "coords" attribute, the word "and" should be
> substituted for the word "a" so the sentece reads, "This attribute
> specifies the position and shape on the screen".
Yes.
> - In "present/styles.html" under "14.5 Hiding style data from user
> agents": In the second paragraph, there should be a comma between "older"
> and "non-conforming".
ok.
> - In "present/graphics.html" under "15.1.3 Floating objects": Under the
> subheading "Float an object", in the first paragraph, the first use of the
> word "object" should probably be plural so that it reads, "The align
> attribute for objects, images...."
Yes.
> - In "present/graphics.html" under "15.1.3 Floating objects": Under the
> subheading "Float text around an object", in the deprecated example, the
> definite article "the" should be in front of the word "next".
Yes.
> - In "present/frames.html" under "16.1 Introduction to frames": In the
> last sentence of the first paragraph, the word "though" in the
first should be "through".
Yes.
> - In "interact/forms.html" under "17.1 Introduction to forms": In the
> second set of parentheses of the first paragraph, there should be a comma
> after "entering text". Also, there should not be a comma after the closing
> parenenthesis.
Yes.
> - In "interact/forms.html" under "17.5 The BUTTON element": In the
> paragraph that begins "Visual user agents may render...", the indefinite
> article "a" should be removed from in front of the word "'flat'".
Yes.
> - In "interact/scripts.html" under "18.2.2 Specifying the scripting
> language": Under the subhead "The default scripting language", in the first
> sentence of the first paragraph, the indefinite article before
> "content-type" needs to be "a", not "an". The same thing applies to
> "content-type" in the next paragraph.
Yes.
> Under this same subhead, in the paragraph that begins, "Documents that
> do not specify...", the indefinite article "a" needs to be removed from
> before "default scripting language information".
Yes.
> - In "interact/forms.html" under "18.2.3 Intrinsic events": In the first
> sentence of the first note, the word "realm" should be preceded by the
> definte article "the".
Yes.
> - In "interact/forms.html" under "18.2.3 Intrinsic events": Under the
> "onfocus" event, the SELECT element is probably missing an anchor.
Yes.
> - In "interact/forms.html" under "18.3.1 The NOSCRIPT element": In the
> second sentence of the first paragraph, the word "be" needs to be inserted
> between the words "only" and "rendered".
Yes.
> - In both "sgml/dtd.html" and "sgml/loosedtd" in "ELEMENT COLGROUP": The
> possible element is shown as "col". It should probably be "COL".
yes.
> - In "sgml/entities.html" under "24.4 Character entity references for
> markup-significant and internationalization characters": The second
> paragraph refers to CP-1252 two distinct times: once where "cp is
> uppercase, and once where "cp" is lowercase. I assume one of them is a typo.
Ok.
> - In "appendix/changes.html" under "A.1.7 Changes for tables": In the
> last sentence of the paragraph beginning "A new element, COLGROUP...", the
> phrase "has been" needs to be inserted before the word "replaced". As it
> stands, it is too easy to misread.
Yes.
> - In "appendix/notes.html" under "B.5.1 Design rationale": Under the
> subheading "Incremental display", at the end of the last sentence of the
> last paragraph, the closing parentesis is missing.
Yes.
> - In "appendix/notes.html" under "B.7.1 Reserved syntax for future
> script macros": Under the subheading "Current Practice for Script Macros",
> the first deprecated example should probably be "<BODY
> bgcolor='&{randomrgb};'>" [using "randomrgb" instead of "randomrbg"].
>
Yes.
> I hope my comments have been helpful and not too trivial.
Very helpful and not at all trivial. Thanks again,
- Ian
P.S. Really good work!!
--
Ian Jacobs (jacobs@w3.org)
Tel/Fax: (212) 684-1814
http://www.w3.org/People/Jacobs
Received on Monday, 29 June 1998 11:44:04 UTC